Trust and transparency go hand-in-hand. If you’re not transparent, how could I possibly trust you?
Why I Love Open Source
WordPress is an amazing platform, but not because of the features it offers. WordPress is amazing because of the community that builds it. The individual men and women who give their best work, give it away for free, and earn their daily bread elsewhere.
WordPress being open source means anyone can see the code that runs their site, make changes to the code, and distribute those changes to someone else if they want to. It’s an amazing principle that has irrevocably changed the software development landscape.
Why I Hate Open Source
At the same time, there’s a dark side to open source. Well, not to the idea of open source, but the actual practice. It’s a matter of noise versus signal.
Anyone who’s sat in a community development meeting can vouch for the difficulty of sussing out real contributions from noise and chatter and “me to!” throughout the meeting. As a result, it’s hard to know for sure what’s going on – so many project leaders will instead take the conversation off open tools like IRC or blogs or forums and move them to closed tools HipChat or Skype or Email.
I don’t care what you say, leading an open source project from behind closed doors is not transparent.
I understand why conversations are taken offline, but I don’t have to agree with that decision.
Critical Failure
Once upon a time I worked with a .Net-based forum application. It was powerful, used by thousands of sites, and fit my need perfectly. Added to that, it was open source, so I could make changes as necessary.
When I started at the company, I didn’t have a login for the forum. Actually, no one in the company had the super-admin login. The software had been installed by a previous developer who had long since left for a different job. In order to gain access to the site, I had to hack it.
Poring over the source code, I found a vulnerability in how feeds were generated – query arguments on the feed page were passed directly to the database without any sanitization. I built the query I needed to add myself as a super-admin, accessed the feed page, and voila!
My next step was to refactor the feed code to plug the vulnerability so no one else would compromise the site in such a way. I also took the liberty of preparing a patch and submitting it upstream to the security contact of the software vendor.
Thanks, but unless someone else complains or pays us for an audit, we don’t really care. Also, we consider this a huge ethical breach if we see you disclosing this vulnerability anywhere in public.
Behind closed doors, the vendor knew about the exploit. Further, they had a patch to fix the exploit. But they were so busy elsewhere – and I was the only report – that it was deemed trivial and ignored.
A Google search turned up 12,000 other sites running this vulnerable version of the software.[ref]The vendor has since released a new version that entirely replaced the DB layer with parameterized SQL queries. Everything is sanitized with the newer version, and the number of sites running the older, vulnerable one has dropped to below 1,000.[/ref]
Moving Forward
I love working with open source software because of the freedom it grants me. I hate working with open source software when the development and discussion of said software happens behind closed doors.
Openness is an ideal many open source projects are flat-out failing to achieve.
We can have thorough, open conversations about features and roadmaps. We can have clear lines for contributing new code, ideas, UX mocks, and usability critiques. We can have clear responses to – and documentation of changes from – security issues in software.
We can do better.