Four reasons why your business should contribute to the software you use

A main reason to pick open source over proprietary software is that you can participate in its development. But many businesses wonder why they would spend money, time and effort on this! There are four good reasons why it is worth the investment.

The story of Google, Android and Linux

But let’s start with a story, the story of what Google bumped into when developing Android.

Google is probably by now worlds’ largest IT company. But they could not keep up with Linux development and had to spent enormous effort in getting their code integrated after failing to invest in that early on.

When Google started Android, they took the Linux kernel and built on it. They added a lot of smaller and larger features they needed and adjusted others to fit their requirements. As they wanted to get to market quick and collaboration with the Linux community is slow, this made sense. But over time, the growing pile of changes to the kernel became harder and harder to apply to newer kernel versions. Whenever Linus Torvalds released a new version, changes were all over and that would break what Google did so their engineers had to go in again and again to adjust or even rewrite portions of what they did. More over, the Linux community added some of the features and capabilities Google used in Android but in ways that were not compatible with Google’s needs, causing even more problems.

Costs mounted and at some point the kernel versions in Android devices lagged years behind the mainline kernel, exposing users to bugs and security issues long fixed in the official kernels. When Google realized this they put a significant amount of engineering effort in integrating the changes and improvements they made but often faced a lot of opposition: they had tied themselves to specific implementations which were frequently not deemed very well thought out by the Linux engineers. In the end, changes had to be made both on the side of Android as well as, at great cost, on the Linux side to make things fit. Until today, there is a gap between the ‘official’ kernel and Android, though it is closing slowly.

If you’re interested in what happened and how it has been coming along, you can read blogs like this from Greg KH about dropping the Android features from Linux-next, LWN articles like: Android and the kernel mainline (2012), Status of Android upstreaming (2012) and The LPC Android microconference (2015). Linaro has an Upstreaming wiki page.

1. You won’t have to maintain the changes

This story should tell you something: going at it alone is expensive. Of course, not all projects move as quickly as the Linux kernel does with its thousands of contributors and dozens of patches merged every minute.

But if you have developed extra features or made changes to existing ones, you will always be confronted with the costs of merging them in new versions of the project you built on and that is work that you could spent on doing something that actually helps your business move forward… The costs are cumulative over time and over a few years you will spent more resources needlessly porting your changes to new versions than you ever did developing them in the first place.

If you would invest in getting the changes upstream shortly after or during development, you will not have this burden: the project will maintain the code.

2. You improve quality

One of the reasons Google had so much trouble integrating their code in Android is because the high standards in Linux kernel development. Linus has a golden rule: never break backwards compatibility. This means that any new feature developed will have to be of extraordinary quality and, ideally, written in generic rather than use case-specific way to avoid a proliferation of similar interfaces in the kernel which would create an impossible maintenance burden. This also means that if your company wrote code to do something it needs, that code might not have an easy way in. Often, your developers will be challenged to think about the wider implications and opportunities of their feature while the code itself will be scrutinized not only for bugs but also style, efficiency, security and maintainability.

While this means the cost of getting code in the kernel is significant, it also means that you can expect code which gets merged to be of higher quality than what you would usually use or ship to customers! And that is, of course, a plus in the long run.

3. You speed up development

Now obviously, by participating in development, you bring in code and features and thus contribute to the speed of development. But there is a benefit beyond the code you brought in: it might very well be that the capabilities you needed are also developed by other contributors to the project. By doing this work, you not only contribute your own code but you also get to benefit from what others write instead – something that just might be unexpectedly useful!

4. You steer development

Last but not least, by contributing, you ensure that new features and functionality fits with your needs. This goes beyond the code your own engineers write; by participating and building up a reputation, they will be able to give input on and influence the development done by others, guiding it in a direction which benefits your organization.

This isn’t only true for direct contributions by you. If your vendor contributes to an open source project, you benefit from the influence they wield over its direction!

Today

Contributing to the software you use or built upon is not a default yet. 21% of employers explicitly forbade their employees to do it, 40% did not give time in a 2015 survey among embedded Linux developers. Considering the lesson from Google, you’d think they learned a bit faster. There is a real competitive advantage to be had from being close to the technology you use and contributing is one way of doing that. Either you grab that benefit, or someone else will!

A rising tide lifts all boats and this is a core component of the success of open source. The more actively you participate, the more you get out of it! Find some tips about contributing to an upstream project from a company in this CIO.com article and this opensource.com tweet Q&A. If you’d like to get involved in Nextcloud, see here how to get started or talk to your account manager about opportunities!