Do you need an Open Source Review Board? Tech companies share real-life best practices.

In yet another resounding vote of confidence for open source software, several of the world’s technology giants recently announced that they were joining together to explore tools and best practices to better secure it, with Microsoft’s CTO, saying in a blog that “open-source software is core to nearly every company’s technology strategy.”

As open source software becomes “core to every company’s technology strategy” (by many estimates, 80% of software is made up of open source components) what is your company doing to put processes in place that instill confidence, both internally and with your customers, in products that are built with it?

One way is by forming an Open Source Program Office (OSPO) or an Open Source Review Board (OSRB). Both of these organizations are essentially tasked with the development, communication, and operationalization of an open source strategy for their organization. The OSPO is comprised of key stakeholders in legal, engineering, product and security. They work to define a framework and process for either using open source software as part of their development work (inbound use case) and/or contributing code to the community via open source projects (outbound use case). The main charter of these teams is to define governance that mitigates risks borne of technical and functional security issues while balancing the need for organizations to innovate quickly. But they’ve also found their role has evolved to become the experts on open source internally and evangelists of the technology and its use.

“We’re in the middle of the supply chain,” said one global technology powerhouse on the importance of their board’s work. “We’re like the nervous system of our customer’s products. We have hundreds, if not thousands, of open source components for them to be aware of.”

Three Revenera customers talked about their Open Source Review Boards, sharing best practices and advice gleaned from years of running these programs.

Establish the purpose.

Open Source Review Boards can:

  • Create and continually refine the process by which engineering teams incorporate open source and other third-party code into products and projects.
  • Establish the process by which they contribute open source code and projects to the community.
  • Do both.

While the end game is different, both are attempts to get away from an ad-hoc process and ensure everyone understands and abides by the framework put into place. Smaller companies might have boards that review both inbound and outbound processes for projects, while larger companies may have separate teams.

Keep everything documented and easily accessible.

Keep processes and documentation in an internal central repository, including information on the status of requests and all the prior approvals. This allows interested parties to see components that have previously been approved (or rejected) without having to go through the approval process again.

Spend time on training and evangelizing open source processes.

One Open Source Review Board leader described his job as “kind of a marketing role.” Communication to educate the organization and building awareness and competency in the process is a huge part of the board’s job. Dedicating time to educate every department on recent changes in process, as well as the overall benefits of open source is also critical to the success of the program. This not only allows the teams to push information across the organization, but pull input from teams like sales and marketing that may not be represented on the board.

People need to understand what is expected of them. Consider putting in place training exams for the engineering organization in order to build competency in the processes as well as ensure employees remain up to date on recent changes.

Don’t set “boil the ocean” type compliance goals.

Think and manage the overall risk vs. individual efforts. One leader shared that in his organization of 40,000 engineers, it’s impossible to track everything. That’s an unrealistic goal for compliance.

Consider developing a Software Bill of Materials as part of the process.

While not a hard requirement yet, more customers are asking for a Software Bill of Materials as part of contractual agreements with software providers. One software development leader considered it a competitive advantage for their business. Companies want a list of open source components to trust that open source governance, compliance and security are a strategic focus for their technology providers. This is especially important when it comes to the ensuring the functional safety of products.

OpenChain is a good specification by which to design an OSRB’s framework.

Pursuing certifications in open source specifications like OpenChain sends a strong message to your users about your commitment to open source governance. It also gives your own people confidence that the organization is producing high quality artifacts. OpenChain, for instance, requires:

  • A written policy that has been communicated to the company
  • Training programs
  • Well-defined roles and responsibilities
  • Basic processes in place to produce an open source bill of materials
  • Basic processes in place to make sure you’re preparing the proper compliance artifacts for customers
  • A policy in place to contribute to the open source community

Balance the need for speed and risk

With a major value proposition of open source being time to value, a key objective of these boards is not to slow things down. One leader gave the example that there is one IP analyst looking at code for every 300 developers, and each analyst is managing eight to 10 products at a time. They aim for a 48-hour review time.

“We’re never bored,” said one Revenera customer of his board’s work.

Leave a Reply

Your email address will not be published. Required fields are marked *