Having an open source program
In today’s digital landscape, open source software plays a pivotal role in driving innovation and cost-effective solutions across industries. However, using open source software also comes with some challenges and risks, such as license compliance, security vulnerabilities, and operational issues. Fixing these issues is not always straightforward, as many of the open source components are dependencies of the components we choose, and according to the Systems Sciences Institute at IBM, the cost of fixing a defect may rise 100-fold if late detected (fixing a defect in design vs. maintenance). An open source management program helps organizations mitigate these risks while minimizing the cost of addressing issues. This is why it is crucial to recognize the significance successful implementation of an Open Source management program. Nothing kills a management program faster than poor adoption.
A typical open source management program
A typical open source management program consists of three layers: policies, procedures, and guidelines. These layers work together to establish a framework for effectively managing open source software within an organization.
Policies serve as the foundation of the program, defining general mandatory boundaries. such as what licenses are acceptable. However, for policies to be effective, they must be complemented by procedures that outline specific steps to be taken. These procedures provide clarity on how to implement the policies in practice. For example, what actions must be taken when encountering a new and unreviewed license.
In some cases, the outcome of a particular situation involving open source software may not be clear-cut. This is where guidelines come into play. Guidelines offer soft, optional steps that allow users to exercise discretion and make informed decisions based on the unique circumstances they encounter. An example of such a guideline can be assessing the health of an open source project where multiple factors come into play and each has its weight in the overall decision.
Common Pitfalls
Drafting an open source management program is not an easy task. It is typically drafted by policymakers within a company and requires input from various stakeholders such as legal and security experts, developers, and managers. However, most of the program participants who implement the program do not take part in the drafting process and may not understand or agree with it. This can lead to problems when it comes time to implement the program.
In many cases, policies are written in a legal language that can be difficult for non-lawyers to understand. Procedures may not take into consideration existing workflows and technologies that are already in use within the company and may create unnecessary burdens or conflicts. Guidelines may be missing altogether or outdated and do not reflect the current best practices or industry standards.
Using existing Frameworks & Program Pilot
To avoid these Common Pitfalls and ensure a successful implementation of an open source management program, organizations should draft their open source management program according to well-established open source management frameworks, such as the OpenChain Specification and Security Assurance. The specifications are free and can be implemented with or without the assistance of a professional OpenChain partner (like FOSSAware).
From our experience, it is recommended to pilot the open source management program before full-scale adoption. A pilot program involves testing and refining the policies, procedures, and guidelines in a controlled environment. Typically, the pilot is conducted in a low-risk area of the organization, allowing for the identification and resolution of potential issues and setbacks.
Pilot programs are usually equipped with additional resources and support to assist participants during the testing phase. Clear and measurable goals are established for the pilot, which are different from the goals of the management program. The pilot does not aim to achieve full compliance or security but rather to test the program itself. Compliance becomes a measurement tool rather than the main goal.
By conducting a pilot, organizations can identify and address issues or gaps in an open source management program before rolling it out to the entire organization. From our experience with many of our clients, a well designed pilot can help improve the policies, procedures, and guidelines, to make them clear, relevant, and practical. It can also help increase the awareness and acceptance of the program among the program participants. Ultimately, this can lead to a successful implementation of a full-scale open source management program.
