Submit a patch

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!

4 thoughts on “Submit a patch

  1. Steven Robbins

    While I obviously can’t speak for every OSS author out there, usually when I respond with a (normally) tongue in cheek “we accept pull requests”, it’s because what the person is asking for isn’t currently a priority.

    Working on a semi-popular OSS project means you get a fair amount of bug reports and feature requests, some of them you’re already working on (or planning to shortly), some of which are impacting a lot of people so need looking at ASAP, and some are things that only affect a small number of people or have a very small target audience; it’s those last ones that are given the pull request response. Quite often that response turns into a user group discussion and if more people get on board then it moves up the “priority queue”.

    In a non-OSS project those type of issues would just sit in an issue tracker until the end of time, or just be closed as “will not fix”. At least with OSS you *can* have a go at fixing a bug or implementing a feature if the main project authors don’t see your problem as a priority.

    Or, it could just be you’re whining or the authors of the OSS software are a**eholes, there’s plenty of that too 🙂

  2. Michael Thuma

    It is a fundamental step for a business entity to decide for open source and of course to do the first step. Especially because of participating in a different kind of network serving a different purpose.

    Let me say it with a nice quote from BunnyBuddhism:
    Just one hop in the direction of bunniness sets the wheel of truth in motion.

    I don’t want to express that either the commercial or the OSS path is the preferred one. If one does believe in OSS, I think the believe in the concept of sharing, this is imo the basic motivation for such a step. One time decided for this way saying b) is inevitable and counts for both sides.

    The second point is quality. Assuming the most simple principle found in Masaaki Imai’s – Kaizen book is – ship quality to your successor in the process/value chain (call it process, sub process or activity). An inevitable fact and a second – Make sure that the result of your work is not broken on one hand and cannot be broken on the other.

    Assuming you talk OSS in fashion of a bigger or a more complex OSS ‘product’ – the user will have to have a good reasons and very likely the view in best case – ‘My time is (almost) priceless’ and participate in the network.

    In the end the concept of sharing is dependent on the believe. Share the same thought, share the same view – participate in the network, separated steps, have to be considered wisely. Share money with the vendor or share your time with another group of humans. These are the two basic and concepts currently competing.

    Commercial and well as OSS are different kinds of network, the problem starts, when someone does want to have the best of both worlds but neither invests money nor time, because it turned out – time is not priceless. The rude aware afterwards.

    The price for a product is the value the money represents for an individual to participate in the (vendors) network. The complaint from commercial perspective is less about the ‘bug’ it’s about a expectation not covered by the network’s potential.

    The fact that we experience commercial products to be expensive, does come from humans mixing up the valuation function of money and the ‘oil’ perspective, keep the real economy alive by flowing 4 times a year through our real economy system and the fact that money is a limited ‘good’ while it is still an abstraction of real value (today almost no value). If someone is aware that money does not represent real value and comparable to just water we fill into a bottle taken from a river then one will very like realize that it is the kind of participation and the kind of network he decides for that finally makes the difference.

    All these arguments, ‘Free has no value’, ‘Time is priceless’, ‘The more expensive something is, there more linear value I expect’ – are simply bullshit and a result of human being taught over decades a false view about the value and the purpose of money in most cases. Especially when mixing up, the value representation in order to exchange, it into a lot bigger investment the later point in time a human is in the position to store ‘water’ in his personal bottle during one cycle at the avg. flow speed with the real live things.

    My idea is, try to improve to overall quality of the network by investing work or what has been given to someone in exchange for work. Complaining does not help, it does not improve the network, it does not improve the result of what someone gets from the network and of course not being in the position to improve the result can be compensation by donating other developers, who do a better job. Never damage the network, it makes no sense. Of course if someone is in the position, maybe via a Blog or tweets to improve the overall standing by making oneself more trustful take the opportunity. This can be controversial too, if the aim to create emotions of find people that stand for the networks idea – Birds of the same feather tend to flock together.

    The demand for quality shipped is independent from the so called networks value. A system not working covers no ones demand or does not bring happiness to people. From this perspective every participant in a value chain should focus on adding value to the network and not tweet it to death but also those who supply have to focus on shipping something that makes others happy too.

    Sorry, for the long comment but the topic is not trivial and my thought here is a simple input maybe helping the one or other to see the network and the value and not the money and greedy participation in best of both worlds by not sharing money, talent and time.

  3. Michael Thuma

    Thank you, I hope it is understandable. I think the point is the separation of the network and the benefits, being and staying aware that all participants benefit from a network and on the other hand grow an understanding of the impacts from quality shipped to the participants and vice versa at every level. Finally the way participants interact with a network. Of course it is network driven view. When talking about communication talking about the underlying network and the way it’s built is required I think.

    The portion about the money has been more into direction – why do annoyances arise, why are thy often argued in a specific way but not focusing on a positive improvement of the overall ‘system’.

    Think of Forums and Newsreaders. OSS people took those instruments these days, because almost nothing else has been available … today we have better solutions in order to achieve the same and lot more via integrating the valuable from the input into our work environment which is a distributed today and a lot more focusing on collaboration or corporation in order to improve the overall value.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s