There’s as much enthusiasm for open source now as ever. In its 2020 State of the Octoverse report, GitHub noted that individual developers made 25 percent more contributions to open source projects this year than in 2019. From an enterprise vantage point, 95 percent of IT leaders surveyed in Red Hat’s 2020 State of Enterprise Open Source report said open source was strategically important, and three out of four expect enterprise open source to continue growing.
[ New to open source software? Check out What is open source? at our sibling site, Opensource.com. ]
This sounds like a good thing, but what if the overall energy around open source isn’t translating to individual or organizational results? It might be time to revisit your open source strategy and look for opportunities to reboot it.
5 ways to improve open source strategy
We asked several open source experts for their advice on improving your strategy in 2021 and beyond, from the perspective of creators, project communities, and the growing number of organizations consuming and contributing to open source technologies. Here’s what they had to say.
1. Set (and reset) goals
Like any long-term initiative, an open source project should have a strategic plan. You should also revisit it annually or on some other regular cadence that works for you. This is important for sustainable projects themselves, and just as much so for companies that use and/or contribute to open source technologies.
“Just like we tend to set individual and corporate goals at the turn of the new year, it is important to set goals for the enterprise’s engagement with the open source community – which can and should be an extended arm of the enterprise’s technology innovation team,” says E.G. Nadhan, chief architect and strategist, North America, Red Hat.
Nadhan shares some example questions you can use as a framework for thinking about your organization’s open source strategy at this early point in the calendar year:
- What are the open source projects the enterprise is engaged with today?
- What are the projects we should be engaged with in 2021?
- Where do you want to see the relevant projects be in one year? In two years?
- What can you do to get there?
- Who should the enterprise be collaborating with to drive and sustain its growth and adoption?
[ Read also: 8 advantages of using open source in the enterprise. ]
2. Actively root out neglect
The absence of proactive planning leads to one of the biggest underlying problems that open source projects face.
"There are many reasons why open source projects can languish, but the primary one is neglect,” says Jonathan Katz, VP of platform engineering at Crunchy Data and a core team member of PostgreSQL Global Development Group.
Times change and technologies change. Think of the broad impacts of cloud and cloud-native, for example, and their massive relationship with open source. 83 percent of IT leaders surveyed in Red Hat’s 2020 State of Enterprise Open Source report said that enterprise open source has better enabled them to take advantage of modern cloud architectures.
If you’re ignoring sea changes in the industry, or simply letting a tool and its community languish, then it’s more likely to lose value. And that’s true even if and when the community decides the technology is fully baked.
“It’s important to continue maintaining an open source project and adapting it to the current software trends for the ecosystem you’re targeting,” Katz says. “Even if it is considered feature-complete, an open source project will still require bug fixes and interface upgrades as the technology around it evolves. Having plans on how to continue to maintain, if not evolve, an open source project can help it to continue to thrive."
Enterprises that adopt open source technologies need to be similarly vigilant, says Emily Brand, chief architect, Red Hat.
“Conduct regular reviews of the open source communities you consume from, [whether self- or vendor-supported], to ensure active development,” Brand says. “If development is waning or engagement is decreasing, start to either inject life and talent into the community or start conducting reviews of alternative technologies and budget for the modernization ahead of time.”
3. Dust off that README file
If you do find development or general community engagement is waning, open up your README file and look for cobwebs: unclear language, outdated info, or a general impression that this project is a ghost town. Just like the tool itself, the README shouldn’t be written once and never revised.
“First impressions count, so take a look at the README for your project’s GitHub repo,” says Liz Rice, VP of open source engineering at Aqua Security. “This is often the first thing that a potential user might see, so it needs to make it very clear what this project will do and how it’s going to solve a problem. It also needs to give clear instructions on how to install and run the tool.”
Here’s a writer’s advice: Put yourself in the mind frame of someone who has zero knowledge of your project or what it does. Will they be able to clearly grasp the fundamentals from your README intro and instructions? Could they explain it to someone else in plain terms? If not, it’s time for a reboot.
4. Ask for feedback
Here’s more writing advice, which translates quite seamlessly to engineering: Get feedback! There’s often a gap between the technical or creative ambition of an idea and its execution once you start tapping away at the keyboard.
That’s applicable to your README and also to the tool itself, Rice says. If you feel something’s off about a project or your overall open source strategy, seek out feedback from people who will share honest input.
“Ask some folks outside your organization to take the project for a spin and get their feedback,” Rice says. “Even just getting one or two people to give you their impressions will teach you a lot about how you might be able to improve it.”
This is also a stepping stone to generating word-of-mouth when things start to click: “If they really like it, ask them to share the link to your project on social media,” Rice says.
5. Build a culture of psychological safety
Open source intersects so regularly with cloud, DevOps, and other mainstays of modern IT because its success depends upon similar fundamentals, especially from a people and culture standpoint. Developers aren’t going to get excited about contributing to a project if they’re worried about the response to those contributions.
“Gene Kim, author of The Phoenix Project and The Unicorn Project, says high-performance teams need to work in a psychologically safe environment to share ideas [and] learnings, but also in practical terms like exposing their source code to the rest of the organization without fear of ridicule or embarrassment,” says Michael Cardy, Red Hat’s chief technology strategist and director, solution architecture, Canada.
That sense of safety and the collaboration it fosters must be cultivated. If your project or organizational culture is negative or downright toxic, it’s also in conflict with open source principles.
“Leaders have the burden of creating safe environments through their symbolism, rewards, incentives, and vision, according to Ronald Westrum, an American sociologist who studied high-performance cultures,” Cardy notes. “The culture has to treat failure as an opportunity for learning, and failure is only bad when lessons are not sought and shared with the rest of the organization.”
[ Want to learn more about open source and Kubernetes? Get the free O'Reilly eBooks: Kubernetes Operators: Automating the Container Orchestration Platform and Kubernetes patterns for designing cloud-native apps. ]
