Send it upstream!
It’s no wonder that enterprise adoption of open-source software is rising steadily.
Companies across the world are favoring open-source solutions over their proprietary counterparts for benefits ranging from speed of innovation to reliability and security. And all of that without adding a dime to the cost of their products and services.
Given this success story, the development of open-source software surely isn’t the domain of hobbyists anymore? Actually, open-source projects have largely relied on contributions from talented engineers and (computer) scientists from the beginning. The fact that may surprise you is that paid contributions to open-source projects are on the rise at a much faster rate than adoption is. This year’s Future of Open Sourcesurvey indicates that 64% of companies involved in software development are already contributing to open-source projects, and that this corporate participation is increasing by 14% each year.
So why would companies be so eager to give away the fruits of their developers’ hard work for free? The first reason is quality assurance: code contributions to established projects are often reviewed thoroughly, and by people with diverse specialties. This can reduce the need for internal code review, and at the same time offers developers an opportunity to learn from talented people outside of the own organisation. Learning from detailed feedback and edits to one’s code requires a level of engagement that is not so easily reproduced in artificial settings, such as in workshops and seminars.
Through contributing bugfixes and additions to various projects, we, the developers at Stamkracht, have benefited through improved code quality as well as learning. A good example of how such a process ideally plays out can be seen in our addition to django-reversion. At other times we have had a chance to learn from alternative implementations that had advantages over our contribution, as in django-rest-frameworkand variety. Either way, reporting an issue together with a proposed solution is, in our experience, much more effective for getting the problem solved than to merely state what is wrong.
Another advantage of upstreaming (i.e. to contribute improved code to the original source repository) is that the maintenance burden is shared by the participants in the project. Central to this is the role of automated test cases in quality open-source projects. Existing tests lower the barrier for contributing to a new project by reducing the need for a new contributor to understand the full code base. Good tests will tell you when you break something, and thus make it easier to try out a modification without having to know beforehand about the unintended consequences that may arise elsewhere in the code.
In recent years self-testing code repositories have become commonplace, which is of course good for reliability, but it also gives a powerful position to those who contribute tests to a project. When developing a new feature on top of open-source software, a company is faced with the choice to keep the improvement for itself, or to upstream it back to the project. In the first case, an additional effort is required whenever upstream updates break the improved code. The alternative is best illustrated by an example of our contribution that added concurrency support and session wrapping to mogwai, a graph database client for Python. By writing extensive test cases that ensure that the functionality added by us is functioning properly, future contributors to the project will need to make any changes compatible with ours. A smaller example of contributing tests is given by our extension of xtas.
A third advantage to letting developers contribute to open-source projects is the chance to participate in acomedy of the commons. At Stamkracht we have taken our culture of cooperation as a starting point, and found it echoed back to us in various open-source ecosystems. When participants think of each other as reciprocal beings instead of selfish actors, it is easy to foster a culture in which issues are swiftly addressed (django-rest-swagger, django-denorm, and rexpro-py) and knowledge is shared (haystack/elasticsearch).
Altruism might be an underlying motivation for such a culture, but in our experience it does not occupy the minds of developers much. Issue reports can be a wonderful medium to build shared knowledge, for instance motivated by the desire to think alongside more experienced minds (acora), to set things straight (rexster and mongodb), or to bring the most convincing arguments to light (mongodb).
Larger corporations that are able to make sizeable investments in their own (branded) open-source products, find this to be a significant help in finding and attracting the engineering talent that they need to grow their business. For instance, when a project like LinkedIn’s Kafka receives voluntary contributions that rival those of their internal developers, their HR department almost certainly follows up on this. And even if new recruits have been non-contributing users of a corporate-sponsored open-source product, they still come to the job with valuable experience that they couldn’t have had with a proprietary product.
This scenario is still far out for Stamkracht, but we have made our first steps down this road by starting a project to compute semantic relatedness between concepts and named entities.
We are looking forward to your pull requests!