Open Source Provisioning Strategies Can Help Achieve the Promised ROI

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.