In this post, we discuss the challenges with open source software, and how an SMB can, with reasonable effort, succeed with their use of open source software.
Open source software (OSS) adoption is increasing, and the pace is not slowing down. To be competitive, innovative, and efficient, OSS has become a main priority for many organizations. While the tech industry is still leading the adoption, the public sector and education are coming strong. With OSS, organizations can re-use code that has undergone scrutiny and has already been tested in production environments. This is both cost-efficient and time-efficient since there is no need to re-invent the wheel for basic functionality used across a large number of applications and services.
Open Source Challenges
At the same time, open source software comes with a set of challenges that need to be handled within the organization. Just picking a piece of software and going with it may work well for small hobby projects. For larger projects or commercial software, you need to think about what OSS you are using, how you are using it, and what implications the usage might have for your organization, your software, and your customers.
Some of the main challenges with OSS include:
- Security – New vulnerabilities are discovered frequently. Are you affected and how should you patch the software?
- License compliance – Depending on the license and your usage, there might be specific restrictions or obligations that you need to fulfill.
- Choosing OSS components – Once you choose, it might be difficult to switch to another OSS component due to lock-in effects. You need to choose the right one from the beginning.
Combating these challenges has recently turned into a top priority for large organizations. This is both due to the increase of supply chain attacks targeting OSS and affecting products and services depending on this software, but also due to the recent vulnerabilities found in widely used OSS. The Log4Shell vulnerability discovered in late 2021 can been as the primary example of such a vulnerability.
The Open Source Program Office (OSPO)
To handle the challenges with open source, many organizations have formed an Open Source Program Office (OSPO). The specific tasks of this program office will vary with the organization’s need, but the goal is similar, namely to have dedicated support for how to use, contribute, and thereby succeed with open source. Its overall role is to coordinate and manage all open source activities within the organization. In particular, the OSPO can provide the following advantages:
- Make sure that decision makers are up-to-date, understands, and support the open-source initiatives. The collaborative philosophy of open source software can be different from normal operation and buy-in from management is crucial for a successful program.
- Set policies for selecting open source components. Such policies can include which metrics to consider when choosing a component. Continued support and development, security and development practices, and compatibility are examples of areas in which metrics can be considered.
- Set policies and procedures for contributing back to the open source communities. Contributing to OSS will allow the organization to form the future of the product, add new features, and get community help in improving those features.
- Training developers. Developers need training to understand the OSS community and to align with the development models. This will make using and contributing to OSS more efficient.
- Ensure legal compliance. By having legal experts on, or affiliated with, the OSPO, license risks can be better understood. Violating licenses can be very expensive, both in time, money, and in the end, reputation.
- Set priorities and track performance. Like other business operations, defining and tracking performance metrics is key to success.
As we can see, the OSPO has a wide range of tasks that ultimately will help the organization succeed with open source.
Defining and formalizing processes can remove much guesswork and finger in the air decisions. Taking advantage of the knowledge, resources, and collected experience provided by the TODO group is a step towards both an effective and a resource efficient management of open source software.
OSS management as an SMB
As a small, or perhaps even medium size company, it might not be feasible to have a dedicated OSPO. Still, even small companies will still surely come in contact with OSS in some way. Implementing the processes around OSS is still just as important, but the spotlight on prioritizations and cost-efficiency becomes even more emphasized. The need for security and compliance is still there, but the budget is tighter.
A virtual OSPO
A lightweight process embracing the ideas of an OSPO can still bring several advantages. For smaller organizations, a set of knowledgeable individuals that commit only a few hours per week can still make a huge difference. With proper tooling, it is possible to reach high efficiency even with just moderate effort. These individuals will typically be spread out in the organization, under e.g., the engineering, marketing and legal departments. All will have their dedicated OSS tasks that aligns with their specific expertise.
As the organization grows, a head of open source can be appointed to centralize the management of open source. The head of open source will then oversee the efforts, streamline the processes and make sure that the individuals in the teams follow the policies. This can be seen as a virtual OSPO, since much of the functionality can be set in place, but there might e.g., not be a dedicated budget for the OSPO.
Other than the head of open source, there will not be people that are fully dedicated to the OSPO, but are instead devoting a small percentage of their time to meet the OSPO goals.
Making it work
It is not only the OSS usage itself that present challenges. Also, the management of open source, e.g., the virtual OSPO, will present its own challenges. In order to make it work well, and to allow it to be scaled efficiently as the company grows, there are several aspects to consider. In “A Deep Dive Into Open Source Program Offices” by the Linux Foundation, a set of OSPO practices to combat challenges have been identified. Though these target OSPOs in general, and not particularly for SMBs, there are still lessons to be learned from them.
Bridging the gap between the traditional software development practices and the OSS development practices might not be frictionless. Embracing OSS release practices, transparency, and defining success metrics that can be followed up can help reducing friction.
Code policies that limit the possibility of quick upstream contributions should be streamlined. Here, adapting the internal review processes to the code complexity can help efficiency. In general, reducing policy complexity will not only make them more efficient, but also easier to follow.
The tools used within the organization must support effective use of, and contributions to, OSS. This includes, e.g., the possibility to communicate with the OSS community, development tools that support the use of OSS, and tools for knowledge sharing within and outside the organization. A tool for software composition analysis (SCA) will help collecting and visualizing necessary information regarding the OSS.
OSS is constantly evolving, and maintaining continuity in relation to the OSS landscape is critical for successful open source management. The continuity include staying aligned with the OSS landscape, keeping momentum in case of disruptions, and continued executive support for the OSS initiatives in the organization.
Training for management, developers, and others is an important ingredient in staying up-to-date with the evolving landscape and achieving and maintaining compliancy. Both trainings regarding open source licenses, cybersecurity training, and training on the latest open source technologies need to be conducted.
Using an SCA tool
Though there are many things to consider when adopting and embracing OSS in an organization, it is possible to start small and scale from there. The security, license compliance, and choosing open source challenges can be efficiently handled by integrating with an SCA tool. If you want to better understand how to choose and evaluate an SCA tool, you can see this blog post.
Debricked provides an SCA tool that is ideal for SMBs. It is easy to use, integrates effortlessly with source code managers, and keeps you on top of security and license compliance by scanning your code continuously at every commit. All OSS dependencies are matched against a large database of vulnerabilities, and vulnerabilities can easily be immediately remediated. Moreover, the license, together with the license risk, for each dependency is provided for your repositories.
Debricked’s tool will also allow you to define your policies regarding vulnerabilities and licenses and have the tool alert you when policies are violated. Don’t want to bring in new dependencies that contain high severity vulnerabilities? No problem, the tool can fail your pipeline, send a pipeline warning, email someone, or trigger a webhook in order to warn you if it happens.
Debricked also provides an open, free-to-use database of millions of OSS libraries called Open Source Select. It can be used to search OSS, see quality metrics for each library, and compare different libraries before deciding which one to use. The provided metrics are based on a large number of features, all which are detailed in the documentation for transparency. Currently, metrics for popularity, contributors and security can be viewed and compared.
Soon, the defined policies can even be combined with the Open Source Select database. In this case, you will know if a chosen library will violate any of your policies before you bring it into your project. Since all functionality is provided within the same tool, such crossover information can be used to make your development process even smoother, saving time and headache, while keeping your projects secure and compliant.
Managing your OSS can be complex, but you can start out small and scale with the size of the organization. The first step is to recognize the importance of OSS. If you have not done that yet, don’t worry. You will, and now is certainly a good time.
Once you have that done, create a virtual OSPO by engaging a few knowledgeable people and define what policies you want to set for using open source. Sign up to a free Debricked account, integrate it with your source code manager, e.g., GitHub, and enter your policies. Then off you go. Debricked will take care of overseeing new vulnerabilities, licenses, and to align with your policies.
After that, as you scale in size, look at the TODO resources and learn from the collected experience, start contributing back and train your organization in OSS best practices.