In my last two articles, I have summarized some reasons customers of all shapes and sizes impact a corporate open source software policy. Today, we explore some ways to ensure customers have no, or at least very little, influence on your open source software policy and policy rules.
Develop an effective open source provisioning strategy.
By documenting all open source software usage, version information, and license information at the time the open source enters an organization, your company is prepared to confidently and quickly answer a customer’s request to disclose this information. Depending on your industry and who your customers are, you may or may not choose to provide this information, but at least you have an answer ready with a baseline inventory of open source software assets. Provisioning records can be created via a simple manual process and tracked on a spread sheet, or by using a provisioning management tool to automatically track open source downloads from designated code repositories.
Empower developers to continue using new open source by implementing a request and approval process.
Creating a simple request and approval process requiring certain information be recorded by open source users in your organization is really not that different from other types of successful project management. Most organizations that effectively manage open source usage streamline this process by having three categories that apply to open source products and license types: 1) pre-approved for use, 2) prohibited from use, and 3) requires conditional approval for use. Active communication is the key to any successful initiative in small, medium, or large groups. In this case, communication needs to focus on the organization having a common interest in continuing to leverage open source: technical, legal, and business stakeholders all need to initiate these discussions proactively.
Confirm that you really do know what you think you know by using a scanning tool.
A common theme in our blog, and in this industry, is to create an open source culture of “trust but verify." If you are actively documenting usage during the stages of open source provisioning, and in the request approval process, then it makes sense to confirm those records are accurate. To use an analogy from one of my first blog articles: if I am going to succeed in something as simple as A) making money, keeping it in a bank account, and spending money out of the bank account, then I need to regularly B) double check where the money came from, know how much money is in the account, and make sure that I know where the money ends up when it leaves my account. By regularly using an open source scanning tool or, even better, by automating scanning and integrating the scans into a development environment, you will be able to easily cross reference the scan results with provisioning records and request and approval reports to verify your policy management process.
Hold regular Open Source Review Board meetings
Companies with a mature open source policy management strategy hold OSRB meetings at least once a month. The agenda for these meetings likely includes:
- Review open source provisioning or download reports for policy rule violations and security vulnerabilities
- Review outstanding open source requests to determine approval or denial status
- Potentially write new OSS policy rules based on findings from provisioning reports and outstanding request approval decisions
- Review all OSS scan results for policy rule violations and security vulnerabilities
- Potentially write new OSS policy rules based on scan result reports
- Review all OSS scan results for license compliance action items
- If compliance actions are needed, or if security vulnerabilities are found, assign ownership for internal remediation to be completed
Hopefully this article helps you begin implementing these processes in your open source management strategy this year!