Note: Phil Odence is VP of Corporate and Business Development for Black Duck Software. He is responsible for corporate development activities and all of Black Duck’s partnerships. He is a frequent speaker at open source industry events, including LinuxCon, IBM Innovate, and OpenWorld Forum. Phil chairs the Linux Foundation’s Software Package Data Exchange (SPDX) working group and participates on the GENIVI marketing team.
An organization needs to be fairly mature in its views and practices with respect to open source before it will be comfortable giving back to the community, but such engagement is essential to gaining the full benefits of open source. There’s a good argument that it’s the right thing to do, and developers tend to “get it.” But most companies that contribute to projects have taken some time to get there and are doing so because it makes good business sense. Developers can help involve their companies by understanding the journey required and the arguments in favor of contributing.
Organizations need to climb a learning curve in their adoption of open source. Black Duck’s consulting arm uses a maturity model to help clients navigate and ultimately to derive maximum value from the cultural shift. In most companies, open source use starts grassroots with developers bringing in and consuming components ad hoc. Then, often, those developers create local, informal guidelines. “We’re good if we don’t use GPL in products we will distribute,” for example, might be a reasonable starting point. “If you have a question, ask Joe. He knows about this stuff.” Eventually, organizations tend to realize that to manage the risks that come with all the great benefits of open source, they need a corporate policy as well as processes and tools to support it.
Most companies are able to get their heads around the benefits of using code written by others, but fully participating, i.e. giving away code they have paid developers to write…that’s an even bigger leap. If you want to do that, you better have some damn good reasons.
Some damn good reasons:
Forking is a chronic pain- Part of the beauty of open source is that you can modify it to suit your needs. But what happens in the next release? When that new version comes out, presumably with some valuable additions and fixes, in order for you to take advantage, you need to re-implement your modifications. Not impossible, but it takes non-value-added time and effort and certainly gets tiresome after a few releases. However, if you can contribute your changes back to the project, they automatically show up in the next and future releases.
Maintenance stinks- Everyone wants to work on the hot new stuff; nobody wants to maintain legacy code. But business critical software needs to be maintained, so you have to pay someone to do it…or do you? If other organizations are using the same code, you can spread the maintenance burden around and often have other people fix problems you care about. Numerous companies have used this to justify, open sourcing parts of their proprietary code.
You have play to play- Being a passive user of a component doesn’t give you the right to steer the development of that component in directions that make sense for your company. The currency of open source is effort and credibility. So, you need to engage if you want the benefits of influencing the agenda of a project. But the potential for leverage is great; you might need only suggest a feature in order to make it magically and often quickly appear.
They key for companies in working out how and how much to contribute to open source projects is to understand what they do that’s unique and what’s non-differentiating. Every organization has its secret sauce, but much of software is just plumbing. When was the last time you thought about the operating system or web server behind a web app your using? That’s why hardware vendors have long abandoned proprietary operating systems. For the parts that don’t matter, organizations are better off not owning the code as long as they can use it for free.
Starting at the bottom of the stack, many companies are enjoying the benefits of contributing to open source. Over 75% of the active Linux kernel developers are paid by about 200 different companies. And, commoditization seems to be creeping up the stack. Engine Yard, for example, has had a rich history of sponsoring developers to contribute to open source projects such as Rubinius, JRuby and Lithium. Across many industries, projects are popping up that bring arch competitors together to cooperate. Everyone benefits from spreading the development burden and thereby being able to focus limited resources on the features that really matter.