skydivers in the air

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.


The Linux operating system was created some 26 years ago by a young Finnish engineer, and it now powers the global economy. Not only has Linux survived for more than quarter of a century, it continues to grow its influence and dominance.

Not all open source software projects thrive, however; many promising projects die untimely deaths. So, what’s unique about projects like Linux that thrive where others fail? What’s the secret sauce that sustains one project over others? Is it the community? The license? The code? The organizations backing it?

We talked to open source veteran Brian Behlendorf, co-founder of the Apache Software Foundation (ASF) and current Executive Director of the Hyperledger project, for some answers to these questions. Here is an edited version of the interview conducted at Open Source Summit North America in Los Angeles.

What are the core components of sustainable open source projects?

Brian Behlendorf: By definition, any open source project that is still alive needs some critical mass of developers contributing to it.  The Linux kernel is 25+ years old, and it still sees 5,000 new lines of code every day. It’s still such an incredibly active project.

In my book, that means you need this body of maintainers and contributors who are willing to continue to nurture the project even as it goes into adolescence and later life.

For me, the only way to more or less guarantee that happens is to see that there are companies out there who are making money off of open source software. They have embedded it at the core of their business. And even if it’s not what they do as a business, it’s still something that they need. So they’ll provide feedback, contribute, and continue to invest in shepherding it forward.

So, having companies use and contribute to your project and in return inject resources does help. What role do non-profit organizations like The Linux Foundation and ASF play?

Behlendorf: What The Linux Foundation, I think, has figured out, is how to identify these technology spaces, bring companies together around them, and then help them make money from it and profit from it.

But it’s not the only viable model. The Apache Software Foundation model is entirely volunteer driven, with developers even doing things like running the books or doing marketing.

There’s an incredibly empowering side to that, but it doesn’t always work. There weren’t enough developers who showed up around OpenOffice, for example, for that to work for the Apache OpenOffice community.

It’s almost hard to say if any model is better than the others. They’re all very unique for the kind of software being built and the developers who are attracted to that software.

You talked about commercialization of open source, yet we have seen that some open source communities are averse to the idea of any commercial or corporate links.

Behlendorf: I don’t think there was really ever a truly long tradition of a battle between open source developers and commercial interests. I think many of the people I know who were contributing to open source even before me were building businesses on top of it. Michael Tiemann built Cygnus on top of the GNU compiler suite. So this template, and every ISP, every web business is building on top of open source web components.

I think the real battle might have been between proprietary software and free software. And the real question was, did we need to vanquish proprietary software in order for free software to flourish?

Do licenses play any role in sustainability of open source projects?

Behlendorf: I tend to think of companies that have played games with licensing. There’s not a lot of successful examples out there. Why don’t we just put these kind of games to the side? Let’s build the software we need together, and go out and build great applications and great websites and great other things on top of that.

And this is what we carried forward in the Hyperledger project as well. All the Hyperledger code is under an Apache license. All of it is designed to be embedded inside of other people’s products and services.

We want to see lots of cloud hosts running Hyperledger technology. We want to see a lot of application developers embedding this inside and, say, putting it inside of cars or IoT sensors or those sorts of things. The less time that we have to spend with lawyers and with MBAs explaining to them how and why they can make money with this code, the better off we all are.

Diversity is necessary for the survival of organisms, can the same be said for open source projects?

Behlendorf: If your community doesn’t look like the global community, then something’s wrong. 

The blockchain movement is a great example of diversity. India and China and Europe have been running as fast with this technology as anybody in the United States. We are constantly looking at what countries are we visiting. Where are our companies based? How do we go and empower those companies in a country like China or a country like India, to go and be champions of what they’re doing, of the technology that they’re building?

What about culture?

Behlendorf: I’d say the final thing I’d throw out about sustainability is if your project isn’t comprised of people who are nice to each other, it’s not going to be very sustainable. Even the smartest people, even the most enthusiastic people will burn out if the dynamic in the community is very harsh, or if every time a good idea is brought up you hear crickets or somebody talks it down. You need to be nice to each other on an open source project in order to have any hope of being sustainable.