Friday, March 31, 2017

Open Source Contribution Policy Considerations

I have addressed Open Source Policy as a need for any organization which intends to consume from or contribute to the Open Source Community.  Such policies are critical to form the foundation upon which good governance processes can be constructed and put effectively into daily operation.

I thought it might be helpful to further discuss the policy needs as it relates specifically to the contribution side of the equation.

There are many reasons why an organization may consider becoming an active contributor to one or more open source projects:
  1. Cost efficiencies - contributing simple bug fixes and feature enhancements needed by the organization back to the community edition can save enormous time and resources in the long run
  2. Quality - a vibrant community supporting a project will most always result in a better project since every consumer is also a tester
  3. Security - contributors have a vested interest in secure code.  They take great pains to ensure their contributions follow best practices and reduce attack surfaces and vulnerabilities wherever possible in order to keep a project viable and a good long term investment.
  4. Reducing technical debt - every software platform or architecture decision comes with a certain level of commitment and open source is no different.  Active contributors ensure they have a voice in a project's direction and longevity ensuring the maximum return for their efforts.
This is by no means an exhaustive list but it is enough to justify the creation of a solid contribution policy for an organization to build upon in order to realize these and other benefits of open source.

So, here are my suggestions for how a good open source contribution policy should be crafted:

  • State objectives explicitly in the policy.  This will help guide process development for policy implementation.  The four reasons listed above are a good starting point and there are always others which may be specific to your client.
  • Don't lay out specific governance processes or procedures in the policy.  This will not allow for the normal evolution required in such a dynamic area.  Instead, list the subject matter which the policy expects to be covered by governance and implementation.  Here are few examples:
    • Evaluation of OSS license compatibility to business goals
    • Evaluation of patent/trademark questions
    • Quality controls including security issues
    • Criteria for evaluating a community compatible with business goals and culture
  • Clearly articulate who or what team is accountable to implement the policy, make final decisions on governance, and grant exceptions when necessary.
  • Set up clear expectations for artifact record keeping, including where process definitions, instructions and training materials will reside.
  • Include a definitive statement for policy applicability.  For example, does it apply to contractors as well as employees?
  • Indicate a time schedule for policy review to ensure updates are considered as needed.

Policy drafting is often viewed as less than useful, but if done with thoughtful input from those impacted it can enable clients to reach their open source goals.

No comments:

Post a Comment