Contributing to Open Infrastructure: Everybody Wins, So Let’s Get Started

During the 10th Anniversary celebration of OpenStack last month (what a great huge milestone for the community!), the OpenStack Foundation celebrated some remarkable achievements made during the last decade, not the least of which was the number of code contributions made by the global OpenStack community:

500,000+ changes merged
8,000+ individual developers authoring those changes
Every day, 900 changes are proposed and 18,000 tests are run to evaluate them

In fact, based on code contributions, OpenStack ranks as the one of the three most active open source projects in the world, along with the Linux kernel and Chromium (the upstream code base for the Chrome browser).

Those metrics are pretty impressive, but they don’t tell the whole story. For starters, they don’t include the growing number of code contributions to other open source projects supporting by OSF, like Airship, Kata Containers, StarlingX, and Zuul. Nor do those metrics include all the other forms of contributions—beyond code—that are made by the community in support of open infrastructure.

It’s important to remember that ‘contribution’ entails more than technical contributions. There are many ways to make valuable contributions to the open infrastructure community: sponsoring and hosting events, serving on working groups and committees, leading meetups, presenting at conferences, contributing to mentoring and diversity efforts, donating to scholarships, voting in elections, serving on the board, just to name a few. Each of these contributions plays a critical role in helping our community thrive and make progress.

City Network comes to mind as a company that contributes extensively in non-technical ways. City Network is the organization behind OpenStack Days Nordic and leads the public cloud group within OpenStack. Johan Christenson, the founder and CEO of City Network, is a member of the OpenStack Foundation board of directors and has volunteered to spearhead an outreach effort to encourage more upstream contributions.

“City Network has been a non-technical contributor to the community for many years, but recently we have been making a concerted effort to become more involved as a technical contributor as well, making some modest code contributions to Stein, Train and Ussuri,” said Johan. “We have been inspired by those who have shown that if you contribute technically, you learn the code and become a better operator. Plus, we believe companies like ours who are making money by using OpenStack in a serious way should be contributing more ourselves.”

Johan also described a collaboration City Network has formed with VEXXHOST.
“One of the companies that we admire for its technical contributions to the community is VEXXHOST,” explained Johan. “Mohammed Naser and his team have been ‘teaching us the ropes,’ helping us to get started on the technical side.”

So, I reached out to Mohammed, and I asked him to let me share some best practices with the broader community as well. Here’s a bit of our conversation:

So, Mohammed, how long have VEXXHOST employees been contributing upstream?

Mohammed Naser: The first time some of our code merged was in 2011, so we’ve been contributing to OpenStack for a long time.

What is your organizational philosophy about contributing upstream to OpenStack?

MN: We don’t believe in keeping “fixes” in our internal team notes. We believe in fixing it upstream. I consider OpenStack to be a core part of our business, so contributing not only helps make OpenStack better for others but helps secure our future as well.

What impact has contributing upstream had on your team’s experience actually using and deploying the software?

MN: Our “upstream-only-first” approach pays dividends for us, because we’re essentially getting free code review from the people who are most knowledgeable about OpenStack. That’s true business value. The reviewer can give suggestions or give assurance that you’re doing the right thing. Or the reviewer might actually find a better solution and explain why and how we should be doing it differently. If you’re making changes on your own, there’s no way you’ll get a cleaner solution. You don’t have to hire someone to evaluate the code. That’s kind of how open source works.

Also, by being heavily involved in upstream, we have a bigger familiarity with the code. We can fix bugs and identify issues more easily, because we can reach out to the community and ask how to fix something. Conversely, by being in close relationship with upstream, we don’t waste time isolated on an island building features that aren’t really needed or won’t be accepted—features that we’ll then end up having to support and maintain by ourselves. Community means we can get valuable feedback before wasting time and resources on coding no one besides us finds valuable.

I can give you many examples of indirect value, too. For instance, there’s a kind of “Contributor’s Karma”—you develop a close relationship with upstream, and they keep you in their thoughts and reach out to you as an operator to get your input. A lot of developers on these projects reach out to us and ask for advice. “Will it make your life easier or harder? Are we doing the right thing here? Can we make it better?” You definitely have a voice that’s heard, even if you are not the one writing the code. It’s a win-win for everyone because we’re building better software by working with each other.

What are some of the biggest obstacles to contributing upstream?

MN: On a corporate level, I think the biggest obstacle is when the management of companies don’t prioritize upstream work. Developers tend to want to contribute, but they can find it difficult to participate when management doesn’t prioritize or encourage it.

On an individual level, it can be intimidating to push up code, especially when you are new to the community, because you’re worried about how people might perceive you or judge you on your code. I truly don’t see that happen much in OpenStack, but I’ve seen that kind of reticence among young developers in general.

What advice would you give to organizations who use OpenStack and who are not currently contributing?

MN: My advice is to have some internal policy that is strict on the fact that you won’t run any local patches of OpenStack. That’s Step 0. If you commit to that, you’ll become an upstream company. You have no choice but to always ship things upstream and get it merged in order to put it in production. If you’re running a fork with local patches, your code is not going to get any performance improvements. It’s going to sit stale and start “bit rotting” with time. By contributing everything upstream, you are no longer maintaining any technical debt, you’ve got a whole community evolving and improving your code, and you’re ready to run on release day.

What’s a good way to get started?

MN: Here’s a practical suggestion: Pick one day every month or two, and call it the day where we all go upstream. Just find a bug and fix it, almost like a hack-a-thon, then everyone shares what they did upstream at the end of the day. You dedicate a whole day to this task, incentivize it, and, this way, no one feels like they are wasting their employer’s time by going upstream.

You might also start by unrolling all of the different local patches you’re maintaining in OpenStack. Document the work-arounds and submit bug fix reports. Start getting rid of your technical debt by pushing that upstream. If you’re a few releases behind, you might discover that some of those bugs are already fixed.

And, finally, if you just use OpenStack as is and it does everything you need it to, you can contribute by sponsoring or funding another company who is doing upstream work. That’s also a fair way to do it.

My thanks to Mohammed for sharing his thoughts. I agree with Johan that VEXXHOST is a great role model for contributing upstream, and we need more companies to follow suit.

I’m particularly pleased that Johan is willing to be the standard bearer for a concerted effort to get more folks involved.

“We have a huge community that relies on our collective efforts,” Johan says. “So, here’s the message we need to get out: ‘If you are a developer, please contribute. If you’re a DevOps manager or CxO, instill upstream contributions in your corporate culture.

“And to everyone in the Open Infrastructure community, I’d appreciate your help in spreading the word about the value of contributing. Let me know if you have ideas, questions, or would like to share your story about how contributing upstream has benefitted you and/or your organization.”

You can reach Johan at [email protected]. I hope you’ll reach out to him today.