Does your company help steer the open-source projects it relies on? Would in-house software projects benefit from outside contributors? Is there somebody in the organization responsible for answering those questions?

These days, admitting that open source is a viable software-development model isn’t enough. Companies also have to set open-source strategies that make sense for their technical and business goals.

Cheryl Hung, VP of ecosystem at Cloud Native Computing Foundation, heads up the foundation’s community of users and advises startups about their open-source strategies. Often, she told me, companies’ open-source programs are entirely bottom up, with individual developers taking the reins. That’s not a bad thing, but more organized programs can help companies make the most of developers’ time — and the available open-source tools.

Some company leaders will take enthusiastically to open-source programs, others won’t. Either way, here are seven components to a strong proof of concept for a new or expanded open-source program.

Read This NextOpen-Source Contribution: The Ultimate Guide

It Helps Support Developers

Open-source programs frequently begin as individual developers contributing ad hoc to projects that benefit them at work. By creating some processes around open-source contributions, managers can jumpstart more coordinated efforts to improve critical open-source tools. This also helps devs avoid unpaid evening and weekend time contributing to projects.

It Improves the Company’s Reputation Among Technologists — for Recruiting and Marketing

When it comes to hiring tech workers or selling to other tech companies, a company’s tech brand is paramount. Companies with outdated tech stacks or a poor understanding of open-source ecosystems will find themselves with fewer options all around, Hung said, while a strong grasp of the benefits of open source opens doors.

Form3, a cloud-native banking platform, learned this firsthand, Hung said. Much of its B2B marketing focused on features and other in-app advantages. Then it realized many customers weren’t choosing its product for those reasons, but for its modern, cloud-native technology stack.

“Even though their primary job is not really selling cloud native, they still want to present themselves as a technology-first company, because it helps drive the business value and then attract new customers,” she explained.

Plenty of other companies, such as Netflix, work hard to brand themselves as cutting-edge tech organizations akin to Google or Facebook. That might look like “building in public,” or sharing blog posts and other content documenting a team’s open-source journey and contributions.

“Talk publicly — through blog posts and meet-ups and conferences and podcasts and everything else — about the work that your engineering team is doing.”

“Talk publicly — through blog posts and meet-ups and conferences and podcasts and everything else — about the work that your engineering team is doing, so you can present yourself as this modern technology company with a modern tech stack that’s friendly towards open source,” Hung said. “Because if you’re competing for the best developers, those are the kind of companies they want to work at.”

It’s no secret that skilled developers can be tough to find and recruit. And using the right technology is key to attracting them. According to Adobe Workfront’s 2021 State of Work report, there was a 12-point increase in 2020 in the number of survey respondents who reported turning down a job because the company’s tech was out of date. And G2’s 2019 State of Software Happiness report indicated that 52 percent of respondents had become dissatisfied at work due to non-performant software.

When faced with the choice of working at a company with a robust open-source program or one without, most developers will choose the former, Hung said. It’s more fun, better for their careers and more likely to align with their personal learning goals.

Influencing Critical Projects Should Be Part of Company Goals

More than 90 percent of the code in enterprise software is open source. And if an organization relies on a particular open-source library — especially for key business goals — it makes sense to be as involved with the project as possible.

“If you’re already relying so heavily on open source, then you should probably have a stake in those projects so that you can be certain that those projects are going to be there for the next five to 10 years and go in the direction you want them to go in,” Hung said.

That might look like identifying helpful additions or changes to the project and lobbying for them to be added to the product roadmap. Companies can also set up some communication protocols, so developers can work together to identify the most helpful ways to contribute. Some companies even launch “open-source program offices.” (Change Healthcare and U.S. Bank are both currently hiring for open-source program managers.) And, often, larger companies look to get involved with the governance boards of critical open-source projects.

“If you’re already relying so heavily on open source, then you should probably have a stake in those projects.”

As smaller companies adopt these same strategies, CNCF has seen the rise of what Hung calls “end-user-driven open source,” in which organizations that rely on CNCF projects dedicate their own engineering teams to contributing, instead of relying on vendors such as Red Hat to contribute on their behalf and develop the features they need.

“Companies say, ‘You know what, it’s better for us to keep expertise within our own engineering teams, and we want to up-skill these people. Then it becomes a long-term competitive advantage for us to have, you know, three individuals who are very highly regarded and have contributed a lot to this open-source project, instead of having Red Hat do it,’” Hung said.

It follows that this thinking will influence hiring decisions — but open-source projects can help with that, as well. If a company uses a particular JavaScript framework, for instance, it’s simple to keep tabs on key contributors to that framework and reach out to them when positions open, Hung added.

It Helps Innovate Faster — and Gives Some Proprietary Products an Edge

The more contributors a project has, the more ideas it benefits from. Companies must be careful not to miss opportunities to harness the open-source groupmind.

Take Spotify. In 2014, before the existence of big-name container orchestration systems, the company decided to build its own in-house system called Helios. Google did the same: Kubernetes.

The rest is history. Both companies open sourced their projects, but Kubernetes went on to become the poster project for cloud-native technology, while Helios didn’t see much adoption outside Spotify. In 2018, the music-streaming app realized it was unsustainable to continue building Helios with just a small team of internal developers, so it switched to Kubernetes.

“[Spotify] had to then rip out all the stuff they’d been building internally and switch to [Kubernetes], which was moving faster and getting better support and just innovating faster than they could,” Hung said.

“The fact that we made everything around the product open source meant that people could contribute to that, and they could write their own integrations for it much faster.”

Similar stories have played out at big-name companies like Netflix and Lyft. Netflix dumped its proprietary interservice communication stack in favor of open-source gRPC when the former got too complicated to maintain. Lyft, meanwhile, chose to open source its infrastructure-monitoring solution Envoy so it could benefit from a broader community of contributors, while still paying employees to work on Envoy and guide the project’s direction, Hung said.

Even companies with no interest in moving away from the proprietary software model can benefit from open sourcing certain product components.

“In my last company — which was a vendor sending storage products — we made all of the documentation, all of the tutorials and all the integration points open source, while keeping the core of the product itself proprietary,” Hung said. “And the fact that we made everything around the product open source meant that people could contribute to that, and they could write their own integrations for it much faster.”

That, she explained, gave the product an advantage over competitors that were entirely proprietary.

You Can Learn From More Technologically Advanced Companies

“Every company is on some stage of its technical journey,” Hung said. “And the only way to stay ahead of where you are today is to learn from other people.”

For companies with intentional open-source strategies, that learning is easy to do, she explained. Their technical leaders and contributors frequently rub shoulders with people who are six to 12 months ahead of them on the same technical “journeys.” That creates opportunities to examine more advanced companies’ decision-making and ask critical questions like:

• What technical challenges did you face?
• How did you respond to them?
• Would you make the same decision if you could do it again?

Open Source Is Less Risky Than Legal Departments Think

One of the first steps for a company looking to formalize its open-source participation is usually getting a green light from the legal department. Company lawyers will want to know the legal ramifications of:

• Employees contributing to codebases maintained by third parties.
• Third parties contributing to codebases maintained by the company.

With most common open-source licenses, neither poses a real issue. The Apache Contributor License Agreement, for instance, grants companies the “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable” right to use code contributed by outside developers.

“I was just like: ‘Well, of course we’re not going to sue you. It’s an open-source project.’”

But that also means companies won’t “own” their employees’ contributions to most open-source projects — and won’t be liable for how the project is used.

“If someone contributes something to Kubernetes, and Kubernetes is used to run a nuclear power station, and that power station blows up, it doesn’t mean they can go and sue [that contributor’s] employer,” Hung explained.

(Some people, like members of the Organization for Ethical Source, think contributors should have more input into what their code contributions can be used for. For a more in-depth guide to some legal questions surrounding open source, check out this resource from GitHub.)

Read this nextHow to Use Open Source to Progress Your Career

It’s Free. (And People Aren’t Going to Make Fun of You.)

Although open-source development has enjoyed exploding popularity in the last decade, it’s “100-percent” accurate that plenty of companies are still hesitant to get involved, Hung said.

“I’m thinking of a conversation I had recently with a company who said: ‘We want to use some of this CNCF project. Do we have to pay CNCF to become a member, and that means that you won’t sue us?’” Hung recalled. “And I was just like: ‘Well, of course we’re not going to sue you. It’s an open-source project.’”

In more traditional industries especially — like banking and oil and gas — understanding and adoption of open-source technology has progressed more slowly. Other companies worry that if they put proprietary software out there in a public git, people will be quick to criticize and discount it. As time goes on, though, Hung is confident open-source adoption will become a given at more organizations.

“I think this is a cultural change, a cultural shift, more than anything else,” she said. “I find especially younger people who are earlier in their careers are more relaxed about releasing stuff as open-source projects.”