Open Source Governance by Pull Requests

For the last two or so years I have had the opportunity to work with Skatteverket - @Swedish Tax Agency, on their “journey to cloud”, building an on-premise platform-as-a-service based on Red Hat OpenShift Container Platform. The journey involves many aspects of building a new architecture, and one of these aspects is a shift to significantly more pervasive use of open source software.

Using open source software has many advantages for an organization:

• it is readily available for immediate use, eliminating the commercial procurement process
• it is often developed and maintained by a collaborative community, and you can participate in the process if you choose to
• it is abundant and providing solutions for a massive number of problems or use cases
• it is available in source-code for everybody to inspect for bugs and vulnerabilities, that are often quite rapidly fixed
• it is free (unless you need an extra support to what the open source community provides)

These advantages mean that an organization can focus its development effort and budget on its own specific business needs, and use available open source software

• for common cross-cutting but not-so-much-differentiating functions (for example testing frameworks)
• while taking advantage of the collective innovation created by the the open-source community (for example application frameworks)

Any organization may also, and indeed probably should, opt in to contribute to the open source collaboration. In this article I focus on the use of open source, and leave the contributing part to another time.

However, “there is no such thing as a free lunch”, of course. 

The use of open source software also creates obligations and includes certain risks:

• an organization must understand and comply with the open source license attached to each and every open source project
• an organization is dependent primarily on the open source community to provide support and training, often available in form of online documentation and discussion forums
• an organization is dependent primarily on the open source software maintainer to fix bugs and vulnerabilities, even if everybody can suggest fixes and improvements
• open source projects can be “abandoned” or “replaced” at any time, for various reasons, outside of organization’s control
• there seems to be a “continuous churn” of new open source projects making it necessary to “continuously assess and select” which ones to use

It is therefore a very good idea to implement an appropriate governance around the use of the open source. And because the use of open source is so pervasive and providing so many advantages, the governance process must be

• robust - same or very similar for all kinds of technologies
• easily accessible and understandable - to all developers, architects, testers, application owners, etc...
• fast - decisions to use or not a particular open source software must be made as fast as the pace the business is expecting a delivery of new features, or bugs and vulnerabilities to be fixed

It becomes clear rather quickly that a tool to handle this kind of governance is needed. It is both about the volume of requests for use of various open source projects as it is about handling the requests in a collaborative way with full traceability of decisions. Many requests must be consulted with multiple stakeholders before making a decision.

We decided on using GitHub and the pull request process to submit, approve or reject requests for use of open source software packages. We set up a dedicated repository:

• where we describe the governance around the use of the open source 
• where we maintain the currently approved open source projects and packages; this includes description of intended use cases and if there are any constraints on use in our organization
• where anyone in the organization can submit new proposals - using the pull request process - motivating the proposal, but also following a checklist of evaluation criteria important for our organization
• where the designated stakeholders review, approve (or reject) the submitted proposals for open source projects; this sometimes includes inviting additional subject matter experts to the discussion
• each pull request must include a structured file (JSON) with metadata describing the open source project and all packages - for use in automated validations of our governance
• each pull request must include a README file with further information, designated use cases, constraints, code examples, etc...

The advantages of this approach are:

• using a tool that is already in place and used daily by development teams, no need for a new tool to buy or build, and no need for additional training
• GitHub and the pull request process is quite intuitive even for non-technical people that might need to approve, reject or comment on the requests
• it is easy to have discussions directly in each pull request
• decisions are logged and auditable
• the process is fast and transparent

The implementation of our “open source governance by pull requests” was quite easy and straightforward for pretty much everybody involved. We did not need to set up any new tools, we used what was already in place and used on a daily basis. No additional licenses or training needed.