OSS Governance - Use Case Approach

Once a good corporate policy is in place to support open source consumption and or contribution for your organization, it is time to think about how to implement governance processes consistent with policy goals.

I prefer a use case based approach to set up a good decision making framework.  While communication and workflow processes will vary with the administrative infrastructure of an organization, the basic use case parameters should be fairly consistent.  My recommendation for the core focus areas of each use case is as follows:

1. OSS component technical evaluation - First and foremost open source components or applications should be a good technical solution for the business problem at hand. They should also fit within any established enterprise architecture frameworks established as a strategic direction for the organization. 
2. OSS component security evaluation - The prospective component should be scanned or otherwise evaluated for risk factors which might introduce an undesired vulnerability into your organization. 
3. Method of use - Will the component be used  exactly as received from the community?  Or will modifications be necessary to achieve desired results?  Can it be isolated/abstracted from internal code or must it be directly embedded in existing projects to be effective?  Sometimes this last distinction is discussed in terms of dynamic or static references.
4. Method of distribution (if any) - Will the component be used internally only?  Will it be hosted on a company web site or deployed to an internal cloud?  Will it be installed at a third party (customer or hosting facility)?  Will it become part of a standard distribution package (shrink wrapped or via electronic delivery)?
5. Applicable license terms - The answers to the use case questions above must then be analyzed through the lens of the license(s) involved.  As noted in earlier posts about license types, certain license types are more permissive while others can be very prescriptive in the obligations imposed on the consumer.

I like to think of the first four use case parameters as the input needed from the requestor.  Depending on the use case, the requestor might be an internal product software development organization or perhaps just a business unit desiring to use an open source word processing application.

The licensing parameter is where a good OSS attorney can add value by providing advice on how to avoid unnecessary risks while still taking full advantage of the benefits open source has to offer.

Up next, I will discuss different types of licensing obligations found in open source and suggestions for compliance strategies.