Tag: open source

Is This A Good Idea?
I’ve joked about this a few times, that I should go into business telling people if their web idea is a good one or not. The prices would be simple.
- $25 – A quick yes or no.
- $100 – I’ll tell you if it’s dangerous or possibly illegal.
- $500 – Details of everything.
While I doubt anyone would ever actually pay for that, let me tell you some things I think are bad ideas for the web, and why.

Obvious Bad Ideas

Excluding the whole “Facebook but for pets!” and “Uber but for Pizza!” ideas, and dismissing every single ‘disruptive’ concept out there (seriously, no they’re not), some ideas are really easy to point at and say ‘this is a bad idea.’

If you’re thinking about making something new for WordPress, before you start coding, please use google. Because the first kind of bad idea is the idea that’s been done before, ad nasueum. For example, sliders, snowfalls, BMI calculations (actually ANY sort of calculators including loans), ‘simple’ contact forms, and Google Analytics.

These are bad ideas because they are overdone.

If it’s been done more than 10 times, and you’re not introducing something totally new (this includes the fellow who made a ‘login logo slider’ – no, it wasn’t new), then file it away as a good experiment. Write the code, but don’t publish it.

Illegal/Dangerous Ideas

Depending on how often you hear me rant, you may or may not be surprised to find out how often people write code that’s illegal.

Now hold on. Before a single one of you says “But the GPL!” let me remind you. The GPL doesn’t make things magically legal just because it’s open source. You can use GPL code to break laws (like, say, make a child porn website), and while that’s fine for the GPL, it’s still illegal.

On a less creepy but still illegal note, the Yahoo! finance APIs aren’t actually legal for you to use in your code. Yes, I am well aware of the number of people who make packages for it. I’ve actually spoken to Yahoo about this and the way they explained it was this. Their Finance API is for your personal use. You’re not meant to use it to retrieve data for apps (and yes, plugins are apps) or any third-party usage (again, plugins). Also they do make it pretty clear with this comment:

By accessing the Yahoo! site, you agree not to redistribute the information found therein.

A lot of public APIs have these restrictions, including Airbnb and even some Google APIs (finance again). And using them without checking the terms of use and verifying they’re allowed to be used in your situation puts you at risk for breaking the law and that is dangerous because, in the case of a plugin, it’s not just you who pays the price.

Ignorant Code

Really the magic of everything, the answer to all ‘is this a good idea’ questions can be found in this. Did you bother to do the research first? And no, I don’t mean did you do market research (though that’s a good idea too).

Did you check if the idea existed already? Did you check if the tools you want to use permit that kind of use? Did you read the terms of use of any service? Did you listen to your gut or not?

Think first. Look before you leap. And above all, please don’t make yet another snowflake tool. No one actually likes them.
1 September, 2017
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