We like to say that the ‘customer’ is always right. But when it comes to open-source products, the line between customer and developer is blurred. I joke that I’m not the owner of code, I’m the custodian, and by fielding questions from users and other developers, I turn that into a better product. There’s more and more calls for people like me by the way. A non-insignificant number of companies ask me “Is there someone else like you who would want to work for us?” because giving good support is hard, it’s a weird skill set, and it requires the ability to tell someone “I’m sorry, but that’s just not correct.”
Yes, I tell people they’re wrong a lot. When I say it, I try to couch it in more friendly terms like “I understand why you’d think that, however because of XYZ the product chose to do ABC.” Or maybe even “That would be great, but historical support forces us to do that in a way that would remain backwards compatible. It would suck if we broke everyone going forward, right?” See the point here is that you’re not right but you’re not exactly wrong either, you’re just isolated in view.
Tunnel vision is something that happens to all of us. We look at the world from our perspective (yes, I was Captain Obvious there, I know), which means when most people remark that a project needs something, what they really mean is they need it. This is the part of passion that escalates into angry and vitriol remarkably fast, by the way, so if you’ve ever seen someone go from zero to abusive in three comments, that’s often what’s going on. They really want something to the point that they see red and can’t get out of their tunnel.
Getting back to the rational world is hard, especially if you don’t really understand what it means to develop open source. You may think the developers are ignorant of their users, or out of touch, or don’t care. After all, if open source allows anyone to contribute, why doesn’t a project do everything?
Well besides the fact that it can’t do everything, there are four main reasons a project doesn’t do things the way you it to. This doesn’t mean you’re right or wrong. Being wrong doesn’t mean you are wrong. It’s pretty hard to ever hear ‘wrong’ and not take it a little personally, though. Just keep in mind the reality that most Open Source developers are way more in touch with their users than people behind iOS or Microsoft Word. They just move at a different pace.
Support
The people who write the code have to support the people who don’t (or can’t). If they don’t want to support certain code, they shouldn’t have to. After all, what if they don’t feel confident that they can!? If you ask a developer to put in a feature they don’t use and don’t really understand, what happens when it breaks? I always tell people “You can’t support what you don’t know, and you can’t know what you don’t use.” This is why everyone who’s been through my WordPress training is pushed to actually use WordPress. Supporting something is so much easier if you use it. Thankfully all WordPress developers use the product every single day, so they know what it’s like.
Complications
The code is something everyone wants, but it’s too damn hard to code and remain backwards compatible, which is a huge deal for WordPress. A good example of this kind of thing would be WordPress Multisite’s shift from using /blogs.dir/ to /uploads/ for storing uploads. Doing this allowed us to dump MS Files and speed up WordPress because we’re no longer routing images through PHP (lots of benefits there). It came at the cost of losing the ‘hide’ effect of the /files/ URL, but you weren’t really fooling anyone about that anyway. Point being, we had to do this in a way that didn’t break everyone on an older design of WP! That took a lot of time!
Time
It takes a lot of time to get code right. So maybe they’re actually working on it, but it’s going to take a long time and it’s not done yet. Open Source moves at the speed of imagination and passion, so if a developer has the time and the itch, things get done. Some tasks are pure drudgery, which brings us to …
Feelings
If you’re stuck between writing code you like to do a feature you want and writing code someone else wants and you don’t have an investment in, you’re probably going to do what you want. This is the reason that’s hardest to understand, and it’s the one most people call ‘unprofessional’ because it boils down to “Oh you don’t like something so you’re not doing it?” If this was iOS or MS Word, yeah, you’d get fired. But this is Open Source, and the rules are a little different here. We make what we make out of that same passion you have to see what you want to see.
So … why not what I want?
Because not yet. Maybe never. But WordPress was built to be extendable, not to be everything for everyone all the time. And that’s the beauty of it. But that’s another post altogether.



There are a lot of you guys who use WordPress (probably that’s my fault) and like me, you bash your head in when a news source makes a video embedable, but only if you use their code. Why is this a problem? Most of us like using WP’s visual editor, and that means we have to switch to text mode, paste this in, and then never ever ever visit that page in the visual editor again:
Oh, in the short term they’re helping you by giving you something for free. They’re getting you further in your site development than ever before. However that help ends at the provisioning level, because you aren’t paying for support from these resellers, you’re paying for product. That’s okay, so long as you know what you’re paying for, and a lot of people don’t. If people did know what they were paying for, they wouldn’t use nulled themes with base64 backdoors in them.
So back to this whole “I’ll take your paid software and give it away” thing.



Every time I hear about someone trying to find the quick and easy way around content creation, I shake my head. There isn’t a quick way, there isn’t an easy way, and there isn’t a simple way. Unless you like writing and think that it’s any of those things. But even then, you can’t just write and expect magic to happen. You have to write, and customize, and care, and water, and fertilize your website.



