Open Source Provisioning Strategies Can Help Achieve the Promised ROI

Posted by Jesse Hood on February 6th, 2012 in Open Source Trends, Scanning & Provisioning

Open source literally is a gold mine for enterprises in 2012+ and as the amount of choices increase exponentially so does the need for a provisioning strategy.

Webster’s basic definition for provisioning is to supply someone or something with provisions. Thanks Webster, I can always count on you to cut to the chase. Since we are not really writing about supplying food, water or clothing rations I had to find a more appropriate and up to date definition.

This one from webopedia describes provisioning as: The process of providing users with access to data and technology resources. The term typically is used in reference to enterprise-level resource management.

That’s pretty good, but let’s dig a bit further into the nature of open source to consider the implications of effectively and safely provisioning it for an enterprise. Three of the largest open source repositories in the world publish the following data about the amount of code available:

Sourceforge.net - 324,000 unique OSS projects with over 4 million downloads each day

Github.com – Hosts over 2 million different repositories with over a million end users contributing to the active development of OSS

Googlecode – Hosts over 250,000 different OSS projects

That’s a whole lot of open source, and these are just three major repositories. What about the seemingly infinite amount of other community sites, individual authors hosting their own projects, or corporate sponsored websites that exist to download open source from? It’s a daunting task to even consider how to efficiently and safely provision from that much code let alone do it in compliment to a corporate policy.

By establishing some general provisioning criteria and minimum requirements, that the development communities and their open source products have to meet, enterprises can start to narrow down the choices to some very meaningful selections.

An even more progressive open source provisioning strategy might state the following:

Open source community projects must be vetted, determined to be safe, and valuable by the enterprise open source review board before the download can be considered.
End users and developers must first explore and consider existing internal code repositories before considering external acquisition of new open source products or versions.
The origin of download for any new open source product must be directly from the project homepage hosted by the original authors/community.
End users and developers must record the point of origin and date associated with the download if there is not an open source management system in place that automatically tracks the information for them.

Understanding the point of origin when downloading open source is critical to mitigate for potential unknown modifications in the code, unknown changes in license type, the potential for virus, trojans or malware, or intentionally placed malicious code. These potential concerns are rare but the fact is they do exist and the implications of one mistake could be costly. Some enterprises have taken this strategy a step further and regularly empower developers with the knowledge of why using specific open source libraries and repositories may be a very good idea while simultaneously cautioning teams as to why others may not be acceptable.

The OLEX repository has completed much of this initial legwork by providing a centralized repository that already includes a high level evaluation of open source communities and license types. Much like the regularly scheduled safety inspection on your car OLEX includes a 42-point certification criteria process that is completed before any code can be provisioned from the repository.

Mature open source policies include an assigned internal risk rating of open source products, pre-approved package and license types, prohibited licenses or packages, enterprise architecture team preferences, open source review board recommendations, and pre-configured stacks that developers might want to consider first before building their own from scratch. All of these ideas build off of understanding and realizing the value and importance of accurate, efficient, and safe provisioning practices. In some of my previous articles I’ve described how provisioning strategies and regular use of scanning tools are a really great compliment to a successful long-term open source software strategy.

Now its reader poll time: If you were part of (or if you are part of) an open source software review board for your company what rating on a scale of 1-10 (10 being top priority) would you give to the provisioning phase for the ongoing adoption of open source software?