In 3 Steps to Developing an Effective Open Source Governance Process we introduced the use of request/approval workflows and scanning. In this article we will explore the strengths and weaknesses of these mechanisms and how they can compliment each other.
A request/approval workflow forces the engineers developing the application, or product, to request approval for any open source components before they are added. These requests are generally reviewed and approved by a licensing compliance group. The licensing compliance group's primary role is to ensure that the open source policy is being followed so that inappropriate open source software packages are not introduced into the application. Once the engineer is informed of the approval they then add the component to the application and continue development. Sometimes this process can even piggy back on existing architectural request/approval processes.
It is simple. This process is basically just a form to be completed by the developers and then checked by the compliance team.
It reduces rework. The request is made before the open source component is used. This means that if the request is denied no engineering work will need to be redone.
It causes delays. This process requires that work stop on the feature that prompted the request until it is approved. This will inevitably slow down development.
It introduces perverse incentives. This process sets up incentives that drive engineers to use less open source, there by increasing the cost of the application, and/or to ignore the process and use open source without requesting it first.
The data collected is unreliable. A completely manual process like this will always have a high level of error. People are fallible, they will fail to make requests when they should and they will request things they don't actually end up using.
Source code scanning is an after the fact compliance solution. With scanning, an open source software usage policy is developed and engineers are empowered to use any open source components that they believe conform to the policy. Applications are scanned on a regular basis to discover what open source is being used. Applications must, at a minimum, be scanned immediately before each release but the more often they are checked the less effort is required.
The output is reliable. Scanning does not depend on engineers having super-human discipline. Even if they are unaware that open source is being added the scan will detect it.
It does not delay development. Scanning does not intrude on the process of developing features. Engineers never have to stop work on a feature to wait on some other team.
It boosts morale. By treating people like the honest adults they are, you can engender a great deal of enthusiasm which will translate into more productivity.
It makes the cost of compliance more visible. This approach makes it possible to measure the actual time spent dealing with compliance, which makes it easier to manage.
It increases rework. The post hoc nature of scanning means that sometimes open source will be used that is not acceptable under the policy. When this happens rework will be required to remove or replace the unacceptable open source component.
Engineers must be educated on compliance issues. In order to make decisions about what open source to use engineers must have a basic understanding of open source licensing and the specific policy of their organization.
As you can see neither approach is perfect. Which you choose will depend a lot on the risk tolerance of your organization. Here at OpenLogic we use a scanning only approach. We are a well educated, agile organization which values rapid feature development over preventing rework. Many of our customers choose a pure request/approval process because it is easy to understand and implement. For them, preventing rework is more valuable and they are willing to accept the legal risk of the data being less than completely reliable.
The two approaches are not mutually exclusive. Some of our largest and most sophisticated customers use a hybrid. Applications are automatically scaned on a regular basis. When new open source is detected a new request is automatically created and run through the approval workflow. This is probably the best approach for large organizations. It allows engineers to get on with the work of developing features, but any addition of open source is detected fairly quickly, vetted for acceptability and added to the list of licenses to be complied with. By catching unacceptable open source early the cost of rework is minimized without introducing artificial delays in the development process.
Allowed tags: <a> link, <b> bold, <i> italics
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.