From friction to open source strategy
Photo by Bernd 📷 Dittrich on Unsplash

From friction to open source strategy

A collaborative and sustainable way to adopt open source

Like many, my first experiences with open source began with Linux. In my case, back in the mid 2000s. Back then, open source was still seen as a hobbyist project. Fast-forward to today, and the vast majority of technology is built on open source. This is echoed by the latest Linux Foundation research, which shows that 55% of organizations use open source operating systems, 49% use open source for cloud and container technologies, and 46% use open source web development frameworks. But the same research shows that organizations rarely manage open source strategically. This inevitably results in some friction. While dev teams worry about development speed, code quality drift and maintainability, security teams worry about vetting components and ensuring regulatory compliance.  Not to mention operations teams who have to deal with stability issues that arise from constant updates and non-standard environments. It can be draining to work like this. 

In this article, I’ll explore the benefits and challenges of open source adoption. I’ll also provide guidance for organizations looking to embrace open source collaboratively, and at scale, based on what I’ve learned from conversations with team leaders and open source experts. 

The case for open source adoption

When evaluating which technologies to adopt, organizations tend to weigh up two main factors: flexibility and costs. In many cases, open source is the clear winner. 

Let’s compare flexibility first. Unlike most proprietary solutions, open source technologies can be customized more easily to meet an organization’s specific needs. Features can be extended, often by using other open source technologies. In cases where the company is looking for technology that is more adaptable and differentiated, it makes sense to use open source. 

Cost is the other vital factor that businesses prioritize. Very often, proprietary software comes with steep licences, but you can often avoid these steep licensing fees by switching to open source. In fact, 59% of OSS users believe that OSS lowers the cost of software ownership, and 54% believe the benefits of OSS outweigh its costs. The same research found that 61% of respondents believe using OSS leads to more productivity, 72% believe engaging in open source projects makes them more competitive, and 74% believe OSS helps them attract technical talent.  

Understanding the benefits behind open source adoption is the first step to get your team on the same page, and get buy-in from key decision makers. The second step is taking a cold hard look at the challenges of open source adoption. 

Breaking down barriers and solutions

The primary obstacle for OSS adoption is almost always support: 36% of respondents in the Linux Foundation’s research say that lack of technical support limits their use of OSS. A third (31%) want expert troubleshooting assistance, and most organizations still struggle to apply security fixes. IDC research shows that 70% of teams using OSS spend more than 6 hours per week on security patching but they are increasingly dissatisfied with the results. Then there’s the fear of uncertainty:  in many cases, organizations don’t really understand licensing and legal implications in OSS.

One of the ways organizations address this is by hiring experts to govern the use of open source software and provide internal education, often setting up dedicated open source program offices (OSPO). OSPOs are responsible for establishing guidelines and best practices around open source usage, licensing, and contribution, and for collaborating with security teams to set up policies around vulnerability management and software provenance. Research shows that only 26% or organizations have actually established an OSPO. If you decide to start one, I recommend reading Arun Gupta 's book on Fostering Open Source Culture, which has practical tips and case studies from companies that have successfully set up an OSPO. 

Another way to adopt open source is to rely on specific vendors to provide open source components with guaranteed security maintenance and support. Over half of organizations expect Long Term Support guarantees in cases where they rely on an OSS provider, and 47% expect fast patching and updates.

There’s also a hybrid approach: engaging both open source vendors, and building internal governance frameworks and skills. For a more detailed look at these approaches, I highly recommend reading this article by open source ambassador Tara Stella , who brilliantly explains the different types of open source consumption and vendor cooperation. Tara delves into active participation in open source projects, and more passive consumption – where most of the work on both supporting and influencing open source projects is left to the vendor. 

In most cases, this hybrid approach appears to be the most effective. It ensures you have a trusted partner who can supply the open source software with security and support guarantees (and free up your team for more value-creating work), while you develop internal talent and governance frameworks to make your investment in open source sustainable long-term. If you choose to work with a supplier, there are a few things you should look for to maximize your chance of success. 

Considerations for choosing an open source vendor

Close synchronization and feature parity with upstream projects 

Look for vendors that keep their distributions and products as aligned with upstream projects as possible. This will minimize your dependence on a single vendor over time. 

Long term support

Research shows that most organizations prioritize stability over constant upgrades. To be precise, over 50% of organizations prefer to keep their in-production OS or application in service until new features are needed, or until the asset stops receiving free security patches. If this is the case for your team, look for vendors that provide long term support. 

Diverse support offering

A wide breadth of coverage is also helpful if you plan to adopt open source across different layers of your stack. Companies like Canonical, for instance, provide support not just for the operating system layer, but also for toolchains, infrastructure solutions like OpenStack and Kubernetes, and databases like PostgreSQL. 

Reliable security maintenance 

Security patching is a key concern that tends to drain teams’ energy and focus. Take one example: a large game developer based in Europe that was struggling to maintain older versions of PHP. This time-intensive work was taking their developers’ focus away from creating new features and content for users. Working with Canonical enabled them to offload vulnerability management, patching and testing, and focus their company’s energy on more value-generating work while they developed a migration plan. 

Extensive documentation

Open source projects need up-to-date and readily available documentation to thrive. Good documentation enables quick adoption, faster problem-solving, and should ultimately provide a clear path to contribution. In open source, documentation is also critical to make processes and decisions in software development transparent for users.

A collaborative approach

Last but not least, if your organization is interested in building internal skills and shaping open source projects, it’s better to look for vendors that take a collaborative approach towards open source. By this I mean vendors that actively support open source projects and support your own team’s development. 

Support for open source projects can be through foundations, code contribution, feedback, funding, donations or other forms of sponsorship. Working with vendors who nurture the community, and harness customer feedback as input to improve open source technologies is not just beneficial for the organization adopting open source but for all users as a whole. 

Support for your own team’s development comes in the form of consulting, training programs, and diverse support options. For instance, it’s not uncommon for companies to rely on Canonical initially to manage their open source private cloud and then move towards self-managed offerings with support when the company’s team has built the necessary skills. 

The Ubuntu way

Those who know Canonical and Ubuntu will likely recognize the circle of friends logo. I like to think of this circle as a powerful way to adopt open source: contributors, organizations, and end users supporting each other in a virtuous cycle of collaboration. Each element benefits the others, driving innovation and success. Contributors get support for their work, organizations benefit from composable and cost-effective solutions, and end users benefit from free and open source software, with an organization like Canonical providing the security assurances and reliability the ecosystem needs. 

One of the most powerful examples I’ve heard from customers is told in this great video featuring the European Space Agency. Working with Canonical enabled ESA to adopt Kubernetes-based infrastructure and use their existing hardware more efficiently, while future-proofing their technology stack to adopt AI. For them it was critical to choose a vendor who could support them in their adoption journey, and in operations, while contributing back to open source projects. 

In sum

Adopting open source comes with challenges and these challenges are only compounded when there isn’t a clear adoption strategy and process for open source use. Organizations that want to overcome these challenges can do so by investing in building up their team’s skills, setting up ground rules for open source usage, and working with a trusted vendor who can speed up and support their adoption journey. 

Good reads I refer to above


Hack23 Open Source policy https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md , did lead OSPO at Wirelesscar & Polestar some experience before started Hack23 😎 🎖️ 1) Security Posture Evidence All repositories MUST demonstrate security excellence through public badges and metrics: 🏆 Required Security Badges OpenSSF Scorecard: Supply chain security assessment ≥7.0 score CII Best Practices: Open source maturity at least "Passing" level SLSA Level 3: Build provenance and integrity attestation Quality Gate: SonarCloud or equivalent showing "Passed" status 📊 License Compliance Badges FOSSA Status: License scanning and compliance verification REUSE Compliant: Clear licensing information for all files License Badge: Clear display of repository license

To view or add a comment, sign in

More articles by Gloria Quintanilla

  • A checklist for book translations

    This blog post was originally published on the Peecho blog One of the benefits of publishing your work online is the…

    1 Comment
  • Top 10 Marketing Tools for Digital Publishers

    This post was originally published on the Peecho blog. Starting a new digital magazine or looking for ways to boost…

Others also viewed

Explore content categories