Tag: open source

What They Don’t Tell You

I wear a lot of hats in the Open Source World. I help teams. I represent and direct others. I herd the cats of software. I allow my name to be known. People talk about how we’re doing a good job, working hard, working together trying to make things better. They talk to you about the wonderful feeling of success that comes with releasing a product. They tell you about the joy, the friendships, and the community.

Well. Here’s what they don’t tell you.

They don’t tell you about the bad days.

They don’t tell you about the week you will spend being blamed and slandered and lied about in blog posts and on Social Media because people know half of thing.

They don’t tell you about the fact that you can’t speak up and defend your actions because it’ll make things worse.

They don’t tell you about the subtle misogyny that makes you wonder if it’s there at all.

They don’t tell you about the gut churning nausea you’ll feel about turning on your email and watching wave upon wave of hate-mails come in.

They don’t tell you about the dick pics and come ons.

They don’t tell you that even when you can explain yourself to your friends, you’ll have to make sure they know not to speak up on your behalf because it won’t help.

They don’t tell you that you can make it worse by being outspoken.

They don’t tell you that crying will make people feel they’re right.

They don’t tell you that people won’t even consider that their words cut you to your very bone.

They don’t tell you that even if a great many people respect you, it doesn’t make you feel any better.

They don’t tell you that someone will say ‘it’s all in your head.’

They don’t tell you that you will have to wait it out.

They don’t tell you that you will have to suffer.

They don’t tell you that the phrase “Just joking!” doesn’t ease the wounds.

They don’t tell you that even with all the support in the world, there are days you will feel absolutely, 100%, alone in your community.

All those good and wonderful things? They’re true. And I wouldn’t change the past if I could. Contributing to open source has enriched my life in many ways. It’s taught me more about myself that I could have imagined. It’s taught me how much I can stand and take though. It’s taught me that sometimes, somedays I will stand with my name and my work being spoken ill of, with my actions being second guessed and criticized, and I will have no succor or recourse.

I will have to stand there and take it and wait and say nothing and do nothing except the best I can do.

What’s the point of this? There isn’t one. This post isn’t a cry for help or a request for my friends to come to my defense. It’s a reminder for all of us that these things happen, and there will be days we feel worthless. Where we feel beaten down and angry and that we want to cry or do something and we just can’t because we know in our hearts it will make things worse.

But maybe the point is this.

I feel that way too. Everyone does.

So you’re not alone at all.

Comments on this post have been disabled.

9 September, 2016
Dog Shaming Disclosure

You’ve probably seen this. A dog with something around their neck saying “I ate the carpet.”

We think that it’s funny because the dog often has no real idea what they did wrong, and we’re embarking the absolute absurdity of the moment. At the same time, we’re terrible people because we’re mocking a creature who can’t understand what we’re doing. So we’re pretty shitty people.

This is not about any one specific company or group or person. This happens weekly. I see people tweet and post and point fingers in public well before they ping people privately or directly. I see people come into Slack and announce “This is vulnerable!” I see people post in forums the same thing. Some of these people don’t know any better, but worst is when they do know better.

While we bandy about the need for responsible disclosure of security issues, and the need for quick resolutions, I feel that we are often too quick to point and shame and accuse. We want to get the news out about a problem so fast, to get people’s eyes and attention, that we forget about the humanity behind the product.

Also we forget how hard we hit.

Public Embarrassment

When someone screws up in public, they are shaming themselves. Like the Olympic diver who belly flopped, or the hurdler who ran right into the first hurdle, when gaffs are televised world wide. They go on YouTube, they’re tweeted and pointed at for years. We will remember them for a long time. But that is embarrassment someone has done to themselves. People are people and release press notices too soon, push code early, and make mistakes. When someone does it to themselves, it’s galling and embarrassing, and they feel terrible. Their friends tell them it happens to everyone, and to learn from the mistake and do better next time.

Public Shaming

On the other hand, there is the ‘friend’ who publicly shouts that someone screwed up. They are metaphorically hanging a sign around someone’s neck and saying they suck. To the world. Now yes, they screwed up, but a human’s natural reaction to that is anger, pain, and a lack of desire to fix it because they’ll just screw up again.

To make this more simple, public shaming creates a bad environment. It discourages innovation with fear.

Responsible Disclosure

Two years ago, Andrew Nacin talked about how security is nuances.

There will always be individuals who want everything to be fully disclosed, and there are some great arguments for that. I’m not trying to sway you one way or the other. But if you’re trying to do the right thing — you’re doing full disclosure in the interest of users, possibly even providing a patch or steps to mitigate — working with the vendor is a good way to ensure you haven’t missed anything.

Unlike Nacin, I do want to sway you to one side. I want to sway you to the side of communication.

If you find a security hole in a product, the first reaction should be to reproduce it as best you can, write up exactly how it can be exploited with examples and Proofs of Concepts, and then contact the developers/vendors about it. Give them some time to reply. Ask them what they would agree a reasonable disclosure timeframe could be, talk and negotiate what would make sense for the product, the situation, and the developers. I want you to think about when releasing the information will harm the fewest people.

Being responsible means thinking beyond the simple “This should be fixed for people.” It means “This should not put more people in danger.” It means you have to look at the big picture. Is it reasonable to expect people to update right away and, thus, you can release full disclosure with the update, or is it more realistic that it may take a while? What about bundled products? Will they get the alerts timely or not?

Forget First, Embrace Most

But above all else, we have got to stop this behavior of ‘First!’ Because that’s what’s going on. People are in a rush to be the first to report a problem or an issue, and in doing so they forget who they’re doing this for. Forget being first. Start caring about the people you’re posting the information for. Is this helping the most people?

Publicly dragging someone through the muck, starting a witch hunt, just because they screwed up doesn’t help anything. It makes for an unhealthy developer community, and it makes for user base that cannot trust the developers.

22 August, 2016
Looking Back at MovableType

For the first time in years, I looked at Movable Type.

I walked away, like so many people, in May of 2004 when the restrictions and pay requirements were too much. I’d played with b2 before and WordPress, but that was when I fully moved to WordPress. While I’d remembered that the Open Source version had been fully restored in version 3.3, I forgot that when they released v6 in 2016, they ‘terminated’ the Open Source licensing option. Again.

In doing normal research of things, I ended up on MovableType.com, and was struck by how modern and out of date the site felt.

The site isn’t mobile friendly. Or at least not iPad friendly. It does this peculiar zoom in where the content is focused but it still has a sidebar. This means flicking down to read can causes my screen to wobble side to side as well. The zoom also didn’t work consistently, making me have to fix it over and over.

That said, it has a much nicer design and layout than I expected.

I have to say, that’s a much more modern front page than WordPress.org and less cartoony than the current WordPress.com pages. The same can’t be said of navigation, which was a little confusing. If you don’t know you have to purchase to download, seeing the Software License section without clarification is weird. That should be even more obvious, I think. I shouldn’t have to click on “Release Notes” and then see Install MT on the sidebar.

Once I ended up in the documentation, I poked around and had a laugh at the software requirements.

PHP 5.0 or higher (5.3 or higher is recommended)

Sounds familiar, doesn’t it?

The rest of the install direcrions are incredible weird and hands on. It has none of the simplicity I’ve come used to with WordPress. And please remember, I think that WordPress is far too complex for a new user, still, because WP’s NUX sucks. MT’s is worse.

What interested me the most is that, while you can’t get MT for less than $900, they have a public GitHub repo available.

Still, I didn’t install it. Instead I read the documentation to see what using it would look like, and was rather startling to read the author page on creating entries and see an interface that looked old.

It reminded me of WP 2.5. Which I guess is understandable since the documentation on how to import from WP to MT is very old. No, I’m serious, it has screenshots of what looks like WP 2.5 as their documentaion.

While I still think that MT lost out big time when they decided to separate from the Open Source community, their product doesn’t draw me in. It doesn’t look fun or nice to use, and that’s probably a reason it’s not as popular as it could be. The GitHub page has 22 contributors. WordPress 4.5, led by my coworker and friend Mike, had 298. Even the official, but not really used like that, WP GitHub repo has over 30 contributors.

I wonder how the web would have looked if Six Apart had never made the license changes.

I wonder would power 26% of the Internet in that world.

15 July, 2016
Open Source Doesn’t Mean Public

Someone made a vague implication that my post about licenses were shots fired from someone who doesn’t ‘do’ but is only an ‘observer.’

This is quite inaccurate, though I don’t blog about it here and I don’t talk about it anywhere for one simple reason. I can’t. I signed a paper, years ago, that agreed the work I did for them would be private. I would neither reuse the code (which I can’t anyway) nor would I discuss it. In fact, I had to make a phone call to ask if I could blog about it in general. I understand why someone might assume I’m not speaking from experience, but that just makes an ass of you and me.

This isn’t about me refuting or dismissing allegations from someone who, for whatever reason, dislikes me and likes to make their hate public. No, this is about the interesting predicament about what happens when you can’t release information about your code.

Half Open

Here’s your scenario. The front end is an open system, a plugin say, that one installs on WordPress. It’s GPLv2 (or later) compatible because it’s distributed code I want to put on WordPress.org. That right there is a requirement. Alright, so I have one half of a product that is GPL and Open Source. The other half lives on a server somewhere in the world and does all the backend work. The plugin? It just passes API data too and fro as needed.

I just described Akismet.

You and I know very little about how Akismet works on the backend. And here’s the thing, that’s how it should be. We have a lot of information on how to interact with the Akismet API but none about how it actually calculates what is and isn’t spam on the back end. I repeat – this is the way it should be.

Look at what Akismet does. It magically identifies spam. While it’s all well and good to be open source, the very first thing that would happen if they opened up all their code is we would see spammers read it and subvert it.

But then again, we have things like SpamAssassin, an open source product I use on my email servers. Does this mean SpamAssassin is too dangerous to use? Does it mean it should be avoided? No, absolutely not! While it’s far from perfect, SpamAssassin does a phenomenal job at catching and stopping spam. But at the same time, it’s imperfect and being public, it’s more likely to be subverted by clever spammers. Thankfully the things it checks for are parts of email that a clever server admin can protect from and, all in all, it’s useful.

Half Closed

If we accept the fact that having a code base open or closed actually has very little impact on it’s usability, then why do we lock down our systems? That’s easy. Security and profit.

Profit is the easy answer. If a system is closed then you can’t download it and install it for yourself. This means if you want to use it, you have to pay. Again, we can look at Akismet and VaultPress, which I would wager actually are built on open source code, as examples. They don’t have to be free, after all. There’s nothing wrong with being closed, either.

By making a system a closed system that no one sees the backend code for, we create a product where only people who have access to the source code can easily infiltrate. This, of course, offers no assurance that it will never be hacked, only it raises the bar and makes it harder to deal with when it does get hacked. But at the same time, it is harder to hack an unknown than a known, and it does make things somewhat safer.

Of course, if I told you all the ATM code in the world was not only open source but freely distributable and it was out there right now, how would you feel? That probably filled you with a little dread, thinking about how much trouble we already have with card skimmers and ATMs. If we have people who already know how to jack in, how much worse could it be if they knew how to encode software into the fake cards they make, and use them to backdoor your accounts?

Have Your Cake And Eat It Too

Just because the code you work on is open source doesn’t mean you can talk about it in public. Just because the code is closed doesn’t mean you can’t.

I’m not talking about licenses here, though, I’m talking about contracts. I signed a paper about certain code I’ve written that prevents me from discussing it. So while I’d love to tell you everything about everything I’ve worked on, I can’t. But that’s not a bad thing. I’ve been privileged to work on the open and the closed, and it’s given me a greater appreciation and understanding of when we should and shouldn’t open our work. And this comes down to understanding the nature of the risks involved.

Things like ATMs, financial trading, and mortgages should be secured and private. Why? Because the risk is much too high. A license? Well a worst case scenario is that someone figures out how to backdoor a free license for themselves. Another is they figure out how to use someone else’s license to gain access to their information. Those are pretty bad. So if you want to make your license API open but the code behind it not, I support that call.

But. I do think you should have a way to manage your licenses and updates. That’s just business sense.

4 May, 2016
The Despair of Licensed Updates

I am a massive proponent of people making money off of plugins. I think they can and should find a way to create a business in this ecosystem we’ve created.

There’s a problem with the approach of some of these products, and in a way we created it ourself, and it hit WordPress 4.5.

There is a plugin, it doesn’t matter which one, that’s a premium plugin. It’s not available for free on WordPress.org. You have to buy it, get a license, enter the license into the plugin, and in that way get updates. That’s fine. But there’s a complication. Actually a couple.

Licenses Expire and People Aren’t Informed

That’s a big ‘no kidding’ moment, but they do expire. And people don’t always notice that their license expired. Even if you post a big sign on the dashboard and email them.

Worse, people don’t know they have license. One of the major problems with software, when purchased for a company, is ownership. If I buy an app on the company dime, it’s their app. But when I buy an app for someone I’m building a site, and I pay for it myself, even if I charge them for it, who owns it? Who keeps the license? Who has the information for running a site?

This is an aspect of WebDevelopment where we collapse, regularly. Not just WordPress, every single person who builds websites for someone has screwed this up at least once. Either the information isn’t clear, or it’s not there at all. Regardless, what happens in the end is you have someone who lacks the information they need to keep their company going.

The Plugin Is Often Bundled in Themes

This is worse than you think. The official directions for this says that if your theme bundled it, and you need an upgrade, you need to wait for the theme to upgrade or you need to buy a license yourself. That’s perfect, to me, except for the problem I mentioned before. People don’t know. I’m not sure how they should know. But those bundlers, they’re so very problematic because they remove users one more step from the information.

If I buy a theme, and it has a library inside it, it’s the job of the theme developer to update that theme regularly, test it with WordPress before the new version comes out, and push fixes. If I buy a plugin, ditto. When the stream cross, though, is where we have the drama. Because I know I bought the theme, but I do not know that I bought this mystery plugin, hiding deep inside. Now it’s the theme owner’s job to update and make sure I get the information right away.

Pretty Much No One Gets It Right

Not even people I respect get this right all the time.

Let’s say you’ve written a plugin and have decided to handle all the updates yourself. I buy it, install it, and it works, everyone’s happy. What happens when I stop paying my license? Well I stop getting updates, that’s for sure. But do I still get notifications about them? Do I get an email? Do I even get an update?

There are some plugins that are free from pay-walled sites, but if you don’t have an active license for that free plugin, you will not get updates. At first I thought it was strange, since if I had a free plugin why wouldn’t I put it up on WordPress.org, right? But then I realized they’re creating the relationship. Once you ‘buy’ the free plugin, you have an account and information in their system. If it’s free, you’re the product.

All that aside, it comes back to the problem of what happens if that license, free or not, lapses? You could be annoying and pop up on the settings page “Hey! The license expired!” but people hate that and ignore it. You could email, but they ignore that too. There really isn’t a great way to remind people that (a) the license expired and (b) there are updates available.

Or Is There…?

What if the updater kept checking, license expired or not, and when you clicked to upgrade it alerted you?

You license for Foobar has expired. Please renew it in order to upgrade.

What if you got this email?

Hey, you bought Foobar back in 2014 and that license lapsed. Normally I’d never bother you, but today I’ve pushed a major security fix. Since this is a security release, I’m offering you a discount. It’s already applied to your account, just log in and you can buy the upgrade at 50% off. If you’re not using Foobar anymore, click here and I’ll have your account flagged so we don’t bother you about this again.

How happy would you be to find out someone saved your soy bacon?

This would require the original developers to have your information, which they probably do, and some way to track those two things. That is, did your license lapse and do you care? That’s all they need to track and only one is an ‘extra’ since I’m reasonably sure everyone tracks the license.

Make It Easy

If you make it easy for someone to know “This has been expired, here is one click to pay” people will pay. Yes, we love free, but we love easy even more. If you make it easy to pay, people will renew and pay. If you inform them of security issues, they will pay and upgrade. If you push them, the good way, about your updates, and make sure they know, they will be safer.

And then, when WordPress upgrades, your users won’t hate you.

20 April, 2016
Dependency Disaster

Over the last few weeks and months, the nightmare that is WordPress plugin dependency hell has waxed and waned with the ire of a thousand burning suns. It flared up when I, perhaps naively, posted a reminder of a rarely called upon guideline to not submit Frameworks for hosting on WordPress’s official plugin repository.

This brought up the perfectly valid arguments that these repositories are useful as they allow for deployment and updates that were hitherto unavailable when rolled up into one package. And at its heart, I understand their point and agree with them as to the benefits. But since WordPress core doesn’t have true plugin dependencies at this time, it’s exceptionally complicated and a hassle to include them.

Personally, I feel that the NPM or Composer style development of plugin is the way to go. Development. Not deployment. With few exceptions, I feel the best way to release a plugin is all in one, rolled up together. The exceptions are, of course, plugins that are add-ons to others, like a plugin that adds a new email integration hook to MailChimp, or a new payment gateway for WooCommerce.

The rest of our plugins should be self contained, reliant on naught but ourselves. I have two plugins which contain the same AWS SDK libraries, written in a way to check if the library is already loaded and to make sure it only loads what’s needed. Why did I do that? Because then someone can have one or the other or both without conflicts.

The user doesn’t have to care about dependancies. They are invisible. That is as it should be. Users don’t have to care.

But there’s also a danger with dependancies, as recently came to light in the JS world. Azer Koçulu liberated his modules from NPM after the threat of a trademark based lawsuit had NPM remove one of his projects.

Sidebar: Open Source has no right to impinge on trademark law. Period. However some lawsuits are frivolous and daft and should be contested. Sadly most communities (NPM, WordPress.org, etc) do not have the money or resources to fight that battle for a developer. If you chose to fight, please contact the EFF.

As is his right, Azer pulled all his packages from NPM. The fall out from this package removal is that a lot of automated builds failed. This has to do with the way Composer is often bundled. Instead of a wrapped up package like an exe or a dmg, it’s a stub that reaches out and downloads all its requirements on the fly. Just like the TGM Plugin Installer. Right? And what happens when those requirements are missing? The build fails.

Perhaps worse, by unpublishing the name slugs used can be taken over by anyone else, and used to push more nefarious code. This did not happen. NPM checked everyone and verified they were as decent as one can before handing over the old names to new owners.

My first thought was “Could this happen to WordPress?”

Yes and no. First up, we don’t reuse names. If you have the plugin ‘foobar’ and ask to have it closed, the name is still reserved. In extremely rare cases we’ve turned over names to trademarked owners (like how Facebook owns the facebook slug) but always with communication of both parties and always with awareness to how many users might be impacted.

But could we pull a plugin for trademark infringement and screw up package dependancies? You bet your ass.

We’ve been lucky that all legal parties involved in similar arguments have been accepting of the ‘grandfathered’ ruling. That’s why we still have plugins with slugs like ‘google-analytics-by-joe’ out there. But it’s also why we don’t allow any more. And yes, when a plugin with a unique name is submitted, we do take the time to check if it’s already trademarked. To spare people this drama.

But yes. It could totally happen. And since we have to name our dependancies and rely on those slugs, there’s no easy way out.

I suggest reading the Hacker News thread on the matter. They weigh both sides of the issue, and show you how the pros and cons make this even more complex.

28 March, 2016