By Anne Thomas, Distinguished VP Analyst, Gartner
Over 90% of organizations that responded to a Gartner Research Circle survey use open-source software (OSS) in their enterprise, including for mission-critical workloads. Organizations choose OSS expecting it to be cheaper, more customizable and of higher quality than commercial counterparts. Yet organizations may find that the expected benefits don’t materialize or are cancelled out by new risks.
Security risks rank high on the list of concerns. Additionally, a lack of commercial support options and the potential disappearance of the OSS community can raise financial risks. Team members who participate in open-source projects can also create legal risks that reach beyond the domain of IT. Effective, cross-organizational governance policies can help organizations proactively manage these issues.
Governance policies and processes are key to protecting your organization from these risks, and to ensure the longevity of the software products your teams build. They help you manage and control where and when OSS can be used, and under what circumstances team members are permitted to contribute to or create OSS projects. An effective governance policy defines the people, policies and enforcement practices around OSS usage.
1. Form a governance committee
OSS governance is best tackled by a cross-functional team that has clear responsibility for defining the OSS governance policy and defining processes that ensure compliance.
Committee members should represent a span of relevant organizational areas. Governance isn’t any one individual’s full-time job, nor do the different aspects of governance reside entirely in one area of the organization. The committee therefore should include representatives from as many affected parts of the organization as is feasible.
Committee membership often starts with a core group made up of software engineering or enterprise architecture leaders, combined with other stakeholders from IT operations, security and risk, finance, and legal and compliance, to name a few.
Committee membership is not a prerequisite for stakeholder groups to contribute. Committees should, however, define and document levels of involvement for committee members and non-committee stakeholders. A RACI chart offers one method to categorize involvement as:
• Responsible: In charge of the outcomes for a specific policy issue.
• Accountable: Involved in defining and ensuring compliance with a specific issue.
• Consulted: Provides feedback and insight on a specific issue.
• Informed: Kept apprised of decisions related to a specific issue.
Given its cross-functional nature, the committee should answer to the executive leaders responsible for corporate policies, although it may report directly to the chief counsel, chief information security officer (CISO) or the CIO, depending on organizational structure.
2. Craft a governance policy
Effective policies define what is allowed and who has decision-making authority related to the use of OSS. The policy also documents the required processes and procedures for compliance, as well as the consequences for noncompliance. The policies will achieve greater buy-in if they are explicitly connected to the organization’s defined goals for OSS adoption, as well as its tolerance for risk, decision-making criteria and rationale for adopting certain constraints.
From that foundation, the policy addresses three different levels of OSS engagement:
• Consumption. What kinds of OSS technologies can be used? Are there different rules for different license models, for products vs. libraries or for OSS embedded in other products? Who approves usage? Under what constraints? Etc.
• Contribution. Are developers permitted to contribute to an OSS project? If permitted, do they contribute as representatives of the company or as private individuals? Can they do so on company time, and if so, how much? Etc.
• Creation. Does the organization want to open source its own software? Can a developer launch an open-source project? Who gets to approve an open-source project? Who is responsible for an open-source project? Etc.
3. Set the conditions for policy compliance
For many organizations, forming a committee and crafting a governance policy are relatively simple and straightforward. The real benefit of a governance policy comes through adoption and compliance, however. That requires committee leaders to:
• Socialize the OSS governance policy. Share the governance policy with all employees who interact with OSS technology. Leverage existing organizational systems and processes to disseminate the policy and solicit feedback on it. Different media should be used to inform employees about the policy and the expectations for compliance. They could include town-hall-type meetings and Q&A sessions, as well as learning materials and certification tests. The committee should publish all materials in an accessible location, and have a system for updating or expanding documentation when the policy changes.
• Implement compliance processes. Design the processes required by the policy so that they are simple, clear and efficient to execute at scale. Without effective process design, people applying for permission will ignore them and committee members responsible for approvals will get bogged down in minutiae, rendering the policy ineffective.
• Automate processes: Leverage automation tools to make the process both easy to use and hard to bypass. The OSS governance committee can develop a workflow application, for example, that makes it easy for product teams to submit OSS product requests. It can also build automation into the DevOps toolchain to prevent developers from including unapproved OSS code and libraries in their products by, for example, mandating the use of software composition analysis (SCA) tools.