In my previous post I wrote about how the changing situation around open source management has pushed the need for an exception based review process for open source. In my opinion, it's the only process that really works. And by “works,” I mean scales across a large enterprise in which the use of open source is common. Exception based is a key element in the “fast & simple” approach.
Defining Policy and Processes
Black Duck has been espousing a form of this for years when helping companies define their policy and processes. We used to call it “use-case driven” policy. By that, we meant define the use cases in which open source is:
- not acceptable, or
- potentially acceptable on additional review.
Customers defined workflows with approval steps and route requests to use components through that workflow. Some companies implemented form based approvals that required manual input from developers to provide additional information (for example, the purpose of the software or support considerations). When possible, those approvals were automated with use-case based rules determined by the information provided.
For many companies, approval workflows with rules worked — it provided the appropriate controls to manage risks and track open source. Or, at least it worked initially. But many users had issues with this approach. One issue is that a workflow based approval is hard to scale when the number of components going through the process increases exponentially, even with automation. There is a significant difference between an application with 40 open source components and one with 1000 components when evaluating the amount of effort involved. This introduced bottlenecks in the use of the open source software and the release of products. Often, the engineers didn't like the process and wanted a simpler way to accomplish their approval goals. This led to the exception based process that Black Duck recommends today.
So What's an Exception Based Review Process?
The exception based review process differs from the approval based process in one key way. For exception based, an enterprise needs to define the situations in which open source is unacceptable or needs additional review. All other use cases are permitted. This contrasts with “we review everything eventually, but hey, at least we can automate some of them.” It is a subtle difference, but it can have a tremendous impact on the scalability of the process and on how well your engineering team conforms to it. In addition, exception based processes are, by their nature, simple processes and very developer friendly. They concentrate on managing the important risks, such as license risks or security risks. Exception based programs are typically easier to implement and can provide the appropriate level of risk management without stifling innovation or adding additional bureaucracy to the teams developing your software.
How Much Process Is Too Much?
If you have a multi-step approval process in place today, I highly recommend you examine that process and determine if it is the right amount or perhaps too much process. For example, do you really need that manager sign off step or that architecture review step? Do the attorneys need to look at every usage, even for well known licenses? Is it a requirement that you do a risk analysis on every open source component that you intend to redistribute? Do you need to make the developers create a detailed support plan for the open source? Do they need to research and document alternatives to this component?
Designing the Best Processes
All those steps I just listed are actual steps I have seen companies employ. I am sure that they are often well intentioned. Their goal is the reduce risks, reduce the total cost of ownership around open source use, and ensure compliance. But they end up creating a lot of work and sometime resentment in the software development organizations. Fast, simple, accurate, and integrated are the characteristics of a process that works. The best ones are also made by engineering and for engineers, with consideration and respect for the needs of other stakeholders (particularly the legal team). Granted, engineers need to conform to corporate policies, but the methods we use to enable compliance needn't be overly restrictive.
Famous architect Ludwig Mies van der Rohe stated “Less is More” to describe his approach to design. I don’t think this phrase always applies, but regarding reviews of open source, I believe it is absolutely true.
So, how does a company do more with less? In summary:
- Evaluate your previous approvals. Do you really need them?
- Define the business modules that the exception based process must support. Do you have distributed applications under commercial licenses? Do you distribute/provide open source? Are you a SaaS vendor? Are your applications only used by internal people in your enterprise?
- Define the areas of concern for which open source must be reviewed.
- Legal Risks – What are the licenses for this component? Can we use it the way we intend? If you are a tech company who redistributes open source, this may be your primary concern.
- Security Risks – Does this open source have reported security vulnerabilities? Are they applicable to your usage? Security is typically the primary concern of enterprises, and vulnerabilities can introduce more business risk than licenses.
- Operational Risks – This broad term can cover many factors. However, typically this refers to the age of the component and the health of the open source community for that component. Is that important to you?
- Decide the unacceptable conditions for the areas you choose to evaluate.
- Legal – Which licenses are not OK? Do you need to review all licenses prior to use or can you set rules based upon broad classifications (for example, permissive licenses or strong copyleft licenses).
- Security – What types of vulnerabilities trigger components for rejection or additional review?
- Operational – Do you have age requirements you want to enforce? Or is this an area in which you just want to inform developers of potential risks and let them decide?
- Implement a system (typically a scanning solution such as the Black Duck Hub) that can collect all the information in an automated, integrated fashion. This might be tied to a development event (e.g., a software build) or an operations event (e.g., deploying a container). The key is that it is integrated. If you can, do not implement a system that requires manual review and input for each component. Concentrate on data that can be collected automatically.
- Decide how to manage exceptions or those items that need additional review. Do you kick them out to a workflow system or an engineering ticketing system (for example, Jira) for additional review?
- Design your process to check final compliance before shipping/deploying your final product. Are all your vulnerabilities managed? Are all your license obligations met, especially if you distribute your product? What checks will you need to insure this?
- Implement the appropriate metrics and reporting structure so you can tell your company is doing across product lines, divisions, business units, and enterprise-wide.
Remember, “less is more.” A well-crafted, simple process supported by integrated tools will lead to the best results. I’ll go into more details in upcoming blog posts, but in the meantime, remember that Black Duck is here to help.