Enterprise open source engagement is as strong as ever. According to Red Hat’s 2022 State of Enterprise Open Source report, 82 percent of IT leaders are using open source in their organizations.
That doesn’t mean everyone feels as sure-footed as they’d prefer when it comes to the best way to do so. As with most technology decisions, adoption alone doesn’t predict success – it’s a nuanced landscape that requires strategic planning and execution.
“Enterprises will find a lot of strategic value in serving as good open source citizens and actively improving the OS software projects that their businesses depend upon,” says Anil Inamdar, VP and global head of data solutions at Instaclustr. “That said, there’s a subtle art to engaging with open source communities and contributing code to projects that CIOs should be attuned with.”
[ Get more fodder for your open source strategy: 4 articles CIOs should read about open source in 2023. ]
So what are some of the best ways to tap into the thriving work of open source communities – and what missteps should you take care to avoid? We asked a variety of experts and IT leaders to weigh in. Here’s what they had to say.
Leverage the power of open source: 8 do’s and don’ts
Do: Realize that open source is as much about what you give as what you receive
One of the biggest overarching misnomers about open source is that it’s simply free software. (In fact, the “free” part is itself often a myth – but hold that thought for now.)
Open source software is indeed “software with source code that anyone can inspect, modify, and enhance,” to excerpt a fuller definition and primer from our sibling site, Opensource.com. But as that suggests, it depends on people and organizations contributing to the project – not just using it.
“An important aspect of tapping into the power of open source communities is to make it a two-way street,” says Gordon Haff, technology advocate at Red Hat. “It’s not just about using code that communities create but also participating in projects that are important to you.”
That spirit is shared more or less universally among open source proponents.
“The key to success with open source is to work together with the community and continue to contribute back to your projects and foundations,” Inamdar says. “No contribution is small. Appreciate the freedom and flexibility that only open source can achieve and offer a fair give-and-take of contributions that result in mutual benefits across the community.”
Contributions can take a variety of forms, from code commits to financial support to marketing and communications and other work that keep a project not just afloat but thriving.
“Do consider contributing back to open source software (OSS) projects if your organization is deriving benefits,” advises Rory Blundell, CEO of Gravitee. “It’s an implicit code of conduct for OSS to thrive, but also a good way for your organization’s developers to build personal brand and career growth. Contribution can be assisting others in the community or contributing back to the code base.”
Don’t: Be exploitative or domineering
The flip side to all of the above is trying to extract value from open source without creating any in return – or worse.
“Don’t bring an exploitative mindset to open source projects and community engagement,” Inamdar says. “Open source communities are rightfully wary of nefarious influence.”
This can happen unintentionally, too, if you haven’t thought through how your objectives line up (or don’t) with a particular open source project – something we’ll cover more below.
“Make sure your contributions match the project’s own goals,” Inamdar says. “Contributions that plainly steer a project toward an enterprise’s own self-serving agenda will earn the distrust and pushback they deserve.”
Do: Make sure you understand the project and are aligned with its goals
Open source doesn’t mean easy. It’s also not risk-free. Yet its very openness – and its fundamental difference from proprietary technology – might trick people into thinking that they don’t need to do as much due diligence before diving in. It’s just that the homework might look a little different than when evaluating proprietary vendors.
“CIOs and their teams do need to invest the time to thoroughly understand the open source project they’re using or considering, the governance model in place, and the expected roles of project leaders, maintainers, and contributors,” Inamdar says. “They need to fully understand the contribution process and existing guidelines before diving in, and probably should start with relatively smaller contributions to test the waters.”
One leading indicator here is to take stock of the general velocity of and enthusiasm for a given project. If there are tumbleweeds rolling through the community, that might be a red flag.
“Place significant emphasis on the strength of the open source community when evaluating open source solutions,” Blundell says. “A thriving community is indicative of a number of trends: It indicates whether it’s an active project to ensure you’re not adopting stale technology, it provides a level of confidence that support is available, and ultimately provides confidence that the risk of adopting an open source solution is mitigated.”
Don’t: Skip this step
If you’ve heard someone complain about open source code before, there’s a reasonable chance they didn’t do their homework. While there are common principles that guide true open source communities, no two projects are quite alike – and sometimes the fine print can vary quite a bit.
Blundell breaks this down into a few specific “don’ts” to avoid:
- Don’t skip reviewing the OSS license terms – not all licenses are created equally.
- Don’t ignore the governance of [the project].
- Don’t skip reviewing the number of contributors and frequency of contributions as a measure of the community’s enthusiasm and commitment.
Do: Embrace the good ‘selfish’ benefits
Open source can be about the greater good and about business value and individual growth. Matt Ray, senior community manager for OpenCost, encourages CIOs and their teams to get involved with projects like his, “both to understand best practices but also to help share knowledge and lessons learned back into the community.”
But there’s an added value: Doing so can mean you’re able to customize a tool or code to your organization’s needs faster than if you’re waiting on a proprietary provider to respond to a change request.
“Open source allows organizations to tailor solutions to their specific needs without waiting on their vendors,” Ray says, noting that Grafana Labs made upstream contributions to the OpenCost project (for Kubernetes and cloud-native cost tracking) to support their internal usage of the tool.
Self-interest isn’t all bad, as long as it’s balanced with the success of the overall project.
“[Contributing to a project] not only helps you develop greater expertise in the code base but can also give you influence in the project’s direction,” Haff notes. “It’s increasingly common to see end-user companies participating in open source projects and foundations that create software that’s important but isn’t a particular differentiator for any one company.”
Open source engagement can even help with hiring and retention because many IT pros see the value for their own career development and growth – they want to work for organizations that use the tools and technologies that other organizations use, too.
Don’t: Fall for the ‘free’ trap
The dictionary doesn’t lie: “Open” and “free” don’t mean the same things. But open source software, at least when stacked against proprietary tools that have a visible price tag, sometimes gets misunderstood as such.
“Don’t assume OSS is free and skip accounting for cost,” Blundell says. “While license costs may not be present, there are indirect costs that should be accounted for including support costs and custom development costs.”
Do: Consider commercial open source solutions where valuable
Not every organization or team wants or needs to adopt, integrate, secure, and support raw open source code on its own. There are many scenarios where the most efficient or ROI-centric approach to open source may be to leverage a commercial solution built on top of the underlying project.
Blundell, the Gravitee CEO, notes that commercial solutions may be a good fit for organizations that have requirements around service-level agreements (SLAs), indemnity, or enterprise-ready production features, among other examples.
When you do look at commercial open source vendors, Blundell suggests looking for a healthy balance between technology questions that are answered by the vendor and the broader community.
“A good balance indicates a healthy community and vendor relationship and provides more confidence in your issues being addressed,” Blundell says.
Don’t: Presume you’re off the hook for security
Even when you tap into the most engaged, enthusiastic open source communities – Kubernetes is one of the most prominent examples at the moment – you shouldn’t presume someone else has already figured out security (or related matters like compliance and governance.)
“Don’t think you can skip doing your own penetration testing or security scans, believing that ‘the community’ has taken care of that,” Blundell says.
[ Also read Kubernetes in 2023: 7 predictions for IT leaders. ]
Strong governance is needed to ensure the security of your overall software supply chain. Blundell says it’s also a good idea to have an exit strategy when integrating new software into your overall stack, in case a project declines or no longer aligns with your goals in the future.
Even when you leverage a commercial solution with robust security features and support, it’s rarely a good idea to offload security responsibility entirely to outside parties. Yes, reputable cloud platforms and cloud-native technologies invest heavily in security; that should be a source of confidence, not an absolution of responsibility.
In fact, that’s one of the top misunderstandings about enterprise open source: That you’re punting security to someone else. Enterprise open source can absolutely bolster your security posture and help with things like patching and updates and can give you a leg up in the fast-moving world of CVEs and other threats. But you’re still ultimately in charge.
Here’s how Haff put it last year: “You can offload the security of supported enterprise open source products to a certain degree. That said, IT departments’ responsibility is still to perform risk assessments and make use of the updated software in an automated way.”
[ Want to learn more about Kubernetes APIs and migrating to Kubernetes? Get hands-on tips and instructions: Migrating to Kubernetes. ]
