Note: This is the first part in a series about creating a foundation that supports the needs of evaluating, adopting and integrating open source software.
One of the key strengths of open source software (OSS) is that it lowers some significant barriers of entry in terms of finding, evaluating and finally acquiring high quality software. The traditional model of contacting a vendor, arranging a demo/sales pitch, wading through marketing fodder, etc. has been replaced with a model that shifts the balance of power from the vendor to the end user/customer. This is a model that empowers that end user by essentially reducing the role of the author in the process of software acquisition. No longer is the vendor the sole keeper of the software, instead its role becomes more an enabler who provides access to the product along with the source code.
Overall, this empowerment has been welcomed, but one fact has been brushed to the side by all the novelty surrounding it: this new paradigm requires a more prepared and motivated end user/customer. Without an organized approach to handling the open source model, the newly gained flexibility of being able to acquire and use software free of cost is negated by not being prepared to leverage that benefit.
Creating a supporting foundation
The definition of the word foundation by the Merriam-Webster online dictionary is:
a basis (as a tenet, principle, or axiom) upon which something stands or is supported.
In order to succeed with open source software in today's business environment it is critical to have a foundation in place. The foundation will serve as the basis for the different policies, practices, and standards that are relevant during the life cycle of open source. Visually, the foundation can be thought of as being composed of three distinct layers that correspond to the main three aspects of open source software management. See the image below:
Evaluating on the way up
The bottom of the foundation consists of the evaluation layer. Currently, this happens to be the layer that is most often and most readily realized. A reason that can be traced to the fact that aspects of this layer are natural extensions of downloading freely available programs and using them under a trial license before deciding to either buy or choose another alternative (it has become rather intuitive to point and click to get, install and use software).
The key difference with open source software is that downloading, installing and use entails accepting the terms of a license that tends to contain more potential ramifications than the typical fair-use license common for most freeware. Sufficient time and effort should be invested in license analysis, not because open source software licenses are overly cryptic, rather due to the fact that they cover not only use of the software as an end product, but also use of the source code.
The analysis process involves understanding the intended use(s) of the product in both binary and source code form, alongside how the terms of the license affect the intended use(s). This step has been made significantly easier by the availability of free resources related to helping understand the dynamics of open source licensing.
Its open source, but we don't support it
Another important step within the evaluation layer is that of investigating the availability of 'enterprise versions,' which are different versions of the freely available software but are typically the only version for which a vendor will provide suitable support. This is a subtle difference because these versions are often distributed in the manner of proprietary software, i.e. for pay. Such provisions can be a bit complicated, because even if the source code is provided with the product, it is done under the terms of a proprietary license that can be more restrictive than most open source licenses.
It is a high priority to understand the exact support terms for a given piece of software, in line with any anticipated needs as revealed during the evaluation phase. For example, if the need to customize the software in order to run on a specific platform is uncovered, a concerted effort should be made to find out if a customized product maintains any previous guarantees regarding upgrades, patches/security fixes, and maintenance.
In situations where the purely open source version is not supported by the owning vendor, but is still the first choice of the end user, it may be prudent to seek out other viable third party support options available for the aforesaid. There can be a surprising number of individuals, companies, communities who are able to support an open source product due to the simple fact that the code is publicly available.
A simple, yet critical start
The evaluation in the open source foundation diagram is what serves as the basis for the others and their completion. A solid first layer is necessary to set the tone for the other layers and ultimately for the efficiency of the entire foundation. If the evaluation layer is done haphazardly the according adoption and integration layers will lack the proper support to be of any value. Therefore, it is critical that evaluation not be taken as a by-word for simply trying out for free, but instead treated as an integral part of establishing a foundation for effectively handling the entire open source software life cycle.
we are just confused with the idea.
Posted by: true religion jeans | March 28, 2011 at 01:38 AM
he let someone bit on that.
Posted by: oakley sunglasses | March 28, 2011 at 01:39 AM
Your tips are really great except the one suggesting to steal our competition articles haha . Nice tipps, thanks! http://www.cheapshoesjordan.com
Posted by: cheap jordans | August 28, 2011 at 07:23 PM