Open source software and frameworks form the backbone of the tech sector. The reality is that every IT department is using some element of open source in its portfolio. This could be in the form of a JavaScript UI framework (think React or Angular), an operating system (think Android or Linux), or CI/CD tools (think Jenkins or Argo).
Bruce Perens: Open source licenses “aren’t working” but we can fix them
There are a number of benefits associated with choosing an open source solution, from a strong community of engineers examining the code and suggesting fixes through to the benefits your internal engineering teams can get from working with these tools – it’s easy to see why they’re so widespread.
“Having your engineers interact with a technical community, follow their standards and industry best practice creates a significant growth opportunity and a window into the market,” says Chris Astley, head of Connected Engineering at KPMG. “If those engineers are afforded the time to contribute back to the projects, it can raise the profile of your organization as a technology leader and benefit the community by giving back to the tooling you’re using.”
On the other hand, becoming dependent on open source frameworks, solutions, and tools means that your business relinquishes having full control over its software.
“Take feature request prioritization,” says Chris Condo, principal analyst at Forrester. “If you’re the only business requesting a certain feature, it might always be pushed to the background. Sure, you might be able to do the enhancement yourself and submit a PR to have it added to the project, but there’s no guarantee it will be accepted.”
Open source adoption: Key concerns for readiness
When to choose an open source solution and how to adopt one should be assessed on a case-by-case basis. IT leaders should use a strategy that combines business and technology factors, using the following questions to ascertain whether it’s the right choice for a specific project. Key questions to ask oneself include:
- Does the software meet the needs of your business?
- Does the software have a license approved by your business?
- Is the associated open source ecosystem healthy, with a regular flow of updates and a good number of committers?
- Does your business have the necessary talent to maintain these tools, or will it need external assistance?
- How embedded will the open source software be in your overall solution, and how important is that solution to your business?
Open source adoption: Ensure you’re not breaking license terms
Not all open source software falls under the same license. Because there are so many open source licenses and variations thereof, it’s of the utmost importance that any IT decision maker identifies which will be compatible with their intended use and how this fits into their wider business approach to open source.
If you plan to embed an open source tool into something you’re taking to market, for example, you must first confirm you aren’t breaking any terms in doing so.
“If you’re building a product that’s a search engine and you’re using Elastic Search’s engine, then you might be violating the terms of that license,” explains Condo. “But if you’re using it internally, then it’s perfectly fine to use as open source.”
Open source adoption: Address security concerns
Regarding security, it’s imperative to remember that no solution, whether open source or proprietary, is 100% secure. What’s different with open source is who takes responsibility. Therefore you need to make sure the business is capable of monitoring threats in-house and has the skills to make patches itself if you choose an open source path.
“Despite security concerns, the open source community is usually out-front reporting vulnerabilities and providing users with a fix. It’s only when IT departments ignore or don’t bother to monitor their open source packages that these bugs turn into hacks that cause harm,” Condo notes.
When evaluating an open source solution, it’s not sufficient to simply look at how popular and widely used it is, as you don’t know the risk appetite or recency of those users. Projects can come and go, so if you plan to invest time and effort into one you want to make sure it’s got the support to last and most importantly remain secure, advises Astley.
Without adequate support leaders potentially open themselves to open source software attacks, in which attackers compromise open source supply chains to manipulate widely-used open source libraries. Software supply chain attacks are growing and can form the jumping point that attackers need for huge attacks, as in the case of the Log4Shell vulnerability.
Open source adoption: Know your skillsets
A lot of organizations choose open source because they think it’s cheaper – and in most scenarios it is – but Amanda Brock, CEO of OpenUK, says that it’s important to remember that there will be a cost of usage, which includes making sure that it’s well maintained. Therefore, when contemplating an open source solution, IT leaders need to look inward and consider whether their staff have the skills to manage these tools and technologies.
If the answer is no, this isn’t a deal-breaker, but you will need to look at purchasing from a vendor that can offer support, such as Red Hat and GitLab, which provide enterprise service plans. You’re still likely to save on overall costs, but this shouldn’t be a deciding factor.
Open source adoption: Combine proprietary and open source
As part of their overall governance strategy, leaders should ensure their business’ software policy addresses both proprietary and open source. Brock points to a project called Open Chain, run out of the Linux Foundation, as a great starting point. This offers free templates and policies and has had input from many compliance, governance and legal professionals.
“You can then begin asking questions like are we ok with every license? Do we think about how we integrate this with our own software? If we’re open sourcing, what can we open source? That’s how you make your risk decisions.”
From there, IT leaders should set out clear guidelines and considerations for making a choice on how to solve a given problem. Sharing this with the business enables the engineers close to the problem to make a suitable, informed decision on when to choose open source, which will be verified and backed by the guidelines and processes you’ve put in place.
