It seems like every other day another study or research paper comes out declaring the new record-breaking numbers of open source users or components. It’s still a reality: open source is everywhere.
As open source software continues to eat the world, industries and organizations - from automotive to government, to telecom, fintech, health services, and everything in between, are adopting more open source components and integrating them into their platforms and products.
Industry giants like Google, Facebook and Microsoft have become enthusiastic fans of open source development and usage, sharing and contributing to the open source community in many ways.
Open source components provide an accessible and efficient ways for DevOps teams to build a product that will answer their customers’ needs within an easily manageable DevOps lifecycle, and open source software and products often provide organizations with products that are popular, free and customizable.
However, it’s taken a long time for organizations to learn that while open source adoption and integration has many obvious advantages – working with open source components requires its own set of policies and practices.
In our last webinar with Microsoft and Forrester, we polled a group of nearly 200 R&D opinion leaders and influencers from a variety of tech organizations about their open source practices and concerns. The results we found tell us a lot and also raise quite a few questions about where tech leaders and management are regarding their adoption of open source components into products, their concerns regarding open source usage, and the DevOps processes put in place to manage open source usage in their organizations.
How Much Open Source Components Do You Have in Production?
Was the first question we asked our participants. Results show that exactly half of all responders estimated that 25% of software in their current projects are open source.
A little over 28% estimated their teams use close to 50% open source components, nearly 18% said they use close to 75%, and a mere 3% said that their future products are composed of nearly 100% open source code.
These estimates by industry management are surprising when compared to GitHub’s recent survey of the open source community. In the GitHub survey, 72% of participants said that they always seek out open source options when evaluating new tools. That’s a very different figure than the 25% that the managers participating in our survey estimated. How could it be that managers think that their development team uses approximately 25% open source components while 72% of developers admit to seeking out open source solutions first? Which number is more accurate?
These questions are something managers and team leaders need to think about. Today, there are automated DevSecOps tools that can easily integrate into development stages and platforms in order to give development teams an accurate picture of their current open source usage and help them manage it.
When Working with Open Source, What Are You Most Concerned About?
Next, we asked participants what most concerned them about using open source. Here, the results were more consistent with other recent surveys. Nearly 53% said they worry about security issues, 38% said licensing was most concerning, and merely a little less than 9% admitted to worrying about quality.
The concern over security is quite understandable. Ransomware is continually on the rise - the recent WannaCry ransomware attack hit an alarming number of end-points and countries, and almost brought health services, telecommunications, public transport and automotive industries to their knees. Open source vulnerabilities came into the spotlight three and a half years ago, with the notorious Heartbleed vulnerability, and in many ways lessons are still being learned. It’s good to see that application security, prevention, remediation and forensics are on everyone’s mind.
However, it’s not clear why quality is overlooked or underestimated by so many industry leaders. Does this mean they have complete faith in the open source development community? Or, in their teams’ ability to locate and identify the best open source component? With all the open source repositories out there, containing ever-growing amounts of code - how many developers can really discern the quality of the open source component that they are using without any input from an expert, or even better – from a group of experts? One of the great things about the open source community is the shared knowledge. Automated DevSecOps tools can aggregate the knowledge accumulated about the quality of a component and report it to users before they attempt to figure it out themselves, the hard way: in the late stages of production.
How Are You Managing Your Open Source?
Here, participants were asked to choose all of the open source management methods that they are currently employing. and here are the ratings:
- About 34% of participants said that they scan their code once in a while
- Only 19% said that they use a continuous management tool
- nearly 25% said they use Excel, and
- a troubling 19% answered: that they don’t manage open source
- 25% answered “other”
Considering the answers to the first two questions, it’s surprising that only a third of the participants scan their code – sporadically, and so few use a continuous open source management tool.
It is well known in the industry that open source components might have vulnerabilities that require tracking and remediation processes that are different than those used for proprietary code.
This group of participants admitted that their products contain a considerable amount of open source code, and many of them admitted to being concerned about application security.
While code-scanning has been around for a relatively long time and is still popular, today there are automated and continuous open source tracking tools that integrate into the DevOps lifecycle. Why are less than 20% of industry leaders using them?
As companies continue to adopt open source components, it’s important that they also integrate policies, processes and tools that ensure they are not open to vulnerabilities and compliance issues, that they are using the best quality of open source code in production, and that open source components are integrated seamlessly into their DevSecOps processes from the earliest stages of the SLDC, so that they can make it to an easy and issue-free release, right on time.