We love to complain, and Twitter has just made is so much easier. By merely including a handle or keyword of some company or product, we can attract the attention of those we’re moaning about and have them run to try and solve our problem. The speed at which they run is proportionally direct to the number of followers we have or the ‘people we know’ (I have 10 followers but my best friend is a celebrity with 300K followers and RT’s anything I ask him to). Apparently it’s called Social Media Damage Control.
When it comes to software products, we’re quite good at it too. After all, that’s why we pay for software, to have someone to hear our roar on the other end of a phone, a forum or a twitter handle.
But that only applies to commercial software.
When it comes to OSS however, it seems different rules apply. Specially when it’s free. Complaining about OSS is often viewed as ungrateful behavior. Numerous times I’ve seen reactions from OSS developers, contributors or merely a simple passer by, responding to a complaint with: submit a patch or well if you can do better, write your own framework. In other words, put up or shut up.
We’re not all Einstein's
It’s not always a patch they are after. At times, when you find a bug, an OSS team member can ask you for a failing unit test. Now granted that we all strive to unit test and promote unit testing, feeling that every developer should know, understand and practice unit testing, the reality of the matter is that it’s not all green pastures out there. For one reason or another, not everyone has that knowledge, the ability or the opportunity to. So often, sending a failing unit test can seem daunting.
Of course, coming back to patches, there’s the added issue of figuring out how to work with the given source control the project is using, get the right unit testing frameworks to run, creating new unit tests, making the necessary changes, submit them and wait for your pull request to be accepted. And that’s if the project is using a DVCS and you can figure out what Pull, Push, Clone, Fork and Checkout mean. All this doesn’t even take into account that you need to figure out how the actual code-base works. And we all know understanding other people’s code isn’t easy.
For someone that is merely using an OSS project, all this can be overwhelming, not to mention intimidating at times.
Lowering the barrier to adoption
The OSS community often complain how big “Enterprise” and “Microsoft” shops don’t buy into OSS. It seems they go for commercial software in order for their legal departments to have someone to sue in case things go wrong. A little far-fetched of course, but nonetheless something you hear often. These shops also go for commercial software because it provides them with someone to call, someone that won’t tell them to submit a patch or provide a unit test. Someone they can call when they need support and not be judged (or at least not humiliated publicly on a forum or mailing list). Of course, the somewhat sad irony of this is that often, the support provided on OSS projects outdoes commercial products by a long shot, and that’s not to mention OSS projects that offer the possibility of commercial support.
However, we need to look at ourselves and see how much of this low adoption of OSS that we’re so passionately fighting for is our fault. If we expect all the users of our projects to know how to work with our source control or compile the source and deal with dependencies, submit patches or work with our testing framework, all we’re doing is raising the entry barrier to OSS.
Before shouting that I’m stereotyping OSS projects, I’m not. I’m well aware that there are amazing projects out there with beautiful and thoughtful teams and communities around them that make many commercial support alternative envious. However, I’ve seen the submit a patch attitude often enough, over the many years I’ve been involved in OSS to warrant mentioning it.
What about me? What about my time?
Now there is the opposite side to all this. You. The Project Lead. The Core Contributor. The guy that has spent several years of his life giving to the community, contributing to OSS projects, helping others. Why should you, despite having given so much, take more of your time to help others. The minimum, that someone that is using your project (for free might you add), owes you, is a failing unit test. No? Not just some lousy steps to reproduce…
Here’s the thing. If you’re working on OSS, you’re doing it because you are benefiting from it. You benefit because you enjoy it. You benefit because you learn. You benefit because you potentially can rise to fame (albeit a micro-celebrity), and you benefit because it can ultimately provide you with potential consulting and training opportunities.
Nobody owes you anything for working on OSS!