Three Steps to Gaining Influence in an Open Source Project as a New Enterprise Contributor

Don’t do fly-by contributions. Choose the right project, assign developers to consistently contribute upstream, and start to realize real influence and value from your open source investment.

When The Linux Foundation started OpenDaylight, our first networking project, nobody that I was working with had ever done open source before. Four years later there has been a significant shift in the entire networking industry. And we’re watching this transformation happen from one industry to the next.

In those four years, I’ve also witnessed many large organizations with significant engineering investments blunder their way into open source. For example, they might just fly in and drop 20,000 awesome lines of code into a project and then get upset that nobody actually picked it up.

The reality is that no matter how big and important your organization is, code doesn’t get picked up if you have no reputation in the open source community. The community must believe that the organization will actually be around to help support that and continue to evolve the code.

So if you want to be part of the industry transformation occurring now with open source — and your company’s future does depend on it — here are some basic steps for organizations new to open source to gain influence within an open source community.

Getting Value out of Open Source

First, let’s talk a little about why you want to gain influence in open source projects in the first place. There are three different tiers of value that individuals and organizations get from open source code.

1. Take it and use it. (Great value.) It’s free, right? And there’s great value in that because you didn’t have to write the code. A lot of this software has been around for a long period of time, so you know it’s stable and it’s reliable, so it’s just a great resource.
2. Customize it for your specific needs and contribute those changes back to the project. (Higher value.) You can continue to evolve with that project, pulling in changes that others have made that give great benefit to you as well. (See our guide to Participating in Open Source Communities for more.)
3. Recognize this transformation occurring in your industry and rely on the platform that everybody in the industry is working on together. (Highest value.) When you start to lead feature sets and activities in those projects, you have a tremendous influence on what’s happening next.

The way we write these applications and the way we choose to implement them ultimately becomes the foundational aspects of our systems that we’ll be using for the next five, 10, 15, 20 years. To get the most value from open source within your organization, you want to help influence the direction of these foundational technologies.

Steps for Gaining Influence in Open Source

So the first step in building influence is: Pick the right project. Start by asking yourself, do I need to modify this code and what license is this code under? If it’s under a license that you can’t use in your particular situation, that code is not going to be applicable to you.

Next, if you need to modify the code (and often you don’t) and want the codebase to evolve with your changes, it’s very helpful to actually work with a community that would take your changes. You’ll need to look at who controls the project, what’s the governance, and who owns the copyright. Look at the project’s charter documents, join their IRC channel and their mailing list. Propose to do something and see what kind of a response comes back. Do the triage to figure out if it’s a project that’s going to work for you or not.

There are some communities that, even though it’s under an open source license, you have to assign your copyright over to some commercial entity, and only individuals from that organization are actually allowed to be committers. There are a variety of ways that projects can be structured that significantly inhibit your ability to make contributions. Understand if those hurdles exist and avoid projects that operate that way.

Everything within The Linux Foundation is structured in a way that allows for diverse contributions. We do that because we’re trying to get an industry to work together collaboratively to address an industry-wide challenge or opportunity.

But today, there is a certain amount of “open-source washing.” Some organizations will say “Hey, we’re going to put this into open source,” but it’s a significantly debilitated version of what they’re really trying to sell you in a commercial environment.

Now, at the same time, there are projects that are started by individual organizations where they really are trying to build a community and a collaborative environment. So just because the individual organization is sponsoring that activity doesn’t mean you shouldn’t engage, but you need to investigate.

Once you have chosen the right project, you will need to assign talented developers to work upstream. Very often when companies get into open source for the first time, they’ll create an entire group, 10, 15, 20 folks that are taking the code and doing stuff with it to augment it for their internal project and they’re not contributing anything back to the project. That invariably will get you into trouble six to 24 months down the road as the upstream open source project continues to evolve. The delta that you have created with your internal version becomes significantly disparate from the mainline code. Every time a new version comes out from the upstream, your team will spend more and more time actually back-porting their modifications into the upstream as opposed to doing new and meaningful development.

Put developers on the core of the project. So many organizations want to add new features that are going to be important to them, and that’s great. But if the core isn’t stable, reliable, and scalable then your features don’t really matter. Also, consider putting developers in support and infrastructure roles such as testing and release management or release engineering.  

Gaining Influence Through Credibility

All of this will help your organization gain credibility in the project community so that when your organization wants to do something down the road that might be a little off the wall, you end up having more influence and the ability to do that. It’s more likely that when you submit that 20,000 awesome lines of code the community will look at all this great work that your organization has done for this project and say, “Let’s support them in what they’re trying to do as best we can.”

Don’t be that organization that does fly-by contributions. Choose the right project, assign developers to consistently contribute upstream, and start to realize real influence and value from your open source investment.