10 elements of open source governance in your organization

Print Friendly, PDF & Email
Rate this post

At the Open Source Business Conference (OSBC) this year I did a presentation called “Asking the hard questions about open source software.” One of the areas I touched upon was open source governance:

Do you have proper legal controls and business processes in place to deal with open source software?

  • That is, what is your open source governance strategy?
  • Five years ago, it was not uncommon for that strategy to be defined as “you shall use no open source software.”
  • You need to understand the legal risks and responsibilities for any software you use, and weigh those against the business value.
  • Work out a plan that specifies what business and legal controls are in place to approve use of open source in your organization or in your products, and make sure you have a well defined escalation path.

Open source governance means how you control the flow of open source code into and out of your organization; how it is used in your products and services; how it is used to run your business; and the business and legal processes around all of this.

Here are some elements you need to know and understand to have good open source governance.

  1. All projects to which your employees or organizational members contribute, the free and open source licenses being used, and the intellectual property commitments those contributions make upon your company or organization.
  2. All use of open source code within internal processes, product development, and services engagements.
  3. All open source code that goes into your hardware products, software products, web-delivered services, or are given to your customers as part of consulting and services engagements.
  4. The location of all open source code repositories used in development, with strict rules about what code with which licenses can be combined (or not).
  5. Uniform cross-organizational rules and policies about the use of open source, with the ability to audit adherence.
  6. Tools to determine code provenance (from which original bodies of open source code did your current codebase derive?).
  7. Balanced policies to weigh the business and legal benefits and risks in using open source code.
  8. Education for all employees, with special sections appropriate for users, contributors, developers, and distributors of open source code.
  9. Clear processes defining when decisions about open source can be made locally and when they must be made centrally, with paths for escalating decision making up both the executive and legal chains.
  10. An aggressive policy for contributing to the various open source communities from which you benefit in your company or organization.

The Whole Series