Open Source in 2010

Author: Eric Petri, Sogeti USA LLC

July 2010

This article discusses two main points:

1.) Addressing a common question: Is the Open Source trend dying off?
2.) And, providing an outline of a method known as the Qualification and Selection of

Open Source software
Is the Open Source trend dying off or just evolving?

The Open Source trend has been around for about fifteen years now and people are starting to ask questions such as: Is all the hustle and bustle around Open Source coming to an end? Do ‘real’ businesses even consider using Open Source solutions anymore?

To the contrary, Gartner Research reports that 85% of businesses already used some sort of Open Source solution in their technology stack and that the remaining 15% plan to follow [1]. Surprising, only 31% of the businesses surveyed by Gartner had formal procedures and methods for evaluating, selecting, and obtaining Open Source solutions and identifying possible intellectual property risks that can stem from its usage [1]. Survey respondents attributed Open Source adoption to a few of the common competitive advantages: lower total cost of ownership, no vendor lock-in, and fast prototyping. By not having these procedures in place, a business can possibly become liable for violations of the licensing agreements that are attached to Open Source solutions. This can serve as a significant barrier deterring the adoption of Open Source. In addition, another common barrier is the lack of understanding of the different license types and the variety of Open Source business models.

Summary of the Method: Qualification and Selection of Open Source Software
The Qualification and Selection of Open Source software (QSOS) is a method outlined at qsos.org. Obviously, QSOS is a method designed specifically with Open Source in mind to qualify and objectively select an Open Source solution to meet a precise business need. QSOS analyzes a solution from several different dimensions – stability, robustness, support level, enhancements and customization, management of issues. The QSOS method is a process of four steps:Definition, Evaluation, Qualification, and Selection. The method allows for an iterative approach where each step or set of steps is repeatable to further refine the results.

Definition:
The purpose of this step is to outline ‘frames of reference’ that will be used by the later three steps. The method focuses on identifying software families, license types, and types of community groups. Software families are created based upon the software’s functional offerings. Also, common license types and community groups are classified. Common license types are classified by ownership, virality, and inheritance. Classifying by ownership determines if any modified or additional code can become proprietary. Classifying by virality determines if any linked code is also subjected to the parent license. Classifying by inheritance determines if the new code forcibly takes on the parent license or if additional limitations can be placed.

Behind each Open Source project is some sort of community group. The following are types of community groups that are currently observed: sole developer, informal group of developers, organized group of developers with established roles, a legal entity that oversees the community and project, and a commercial organization where additional services are offered such as support and extensions.

Evaluation:
In this step, an evaluation of a solution is conducted. An ‘identity card’ and an evaluation sheet are created during this time. The ‘identity card’ is a list of factual data about a solution and aids in the process of scoring a possible solution. The card covers
information such as the following:

• Name and author of the solution
• Project’s website
• Brief description
• Licenses that are attached to the solution
• Operating Systems that solution is compatible with
• Documentation available
• Technologies used and specific functionality that is made available
• General development trend & roadmap

An evaluation sheet is created for each solution and for each release of a solution. Beyond the identity card, this sheet aims to provide more insight into properly analyzing each release. The evaluation sheet scores a solution amongst functional coverage, risks to the user, and risks to the business. The functional coverage is measured based upon the solution’s software family. A score is assigned for each functional element, ranging from 0 for not being covered to 2 for being fully covered. Risks to the user are measured across the following categories: intrinsic durability, integration, industrialized solution, technical adaptability, and strategy. Risks are outlined
in an attempt to measure the amount of risk for a user to adopt an Open Source solution. QSOS provides score cards to aid in scoring each category’s criteria from a score of 0 to 2. The following lists each category and the individual criteria in each of those categories.

• Intrinsic durability measures maturity, adoption, development leadership, activity, and independence of developments
• Industrialized solution measures services available, documentation and quality assurance
• Integration measures compatibility and exploitability
• Technical adaptability measures modularity and by-products such as code extensions and modifications
• Strategy measures licensing, copyright owners, management of code revisions, roadmap, sponsor, and independence.

Risks to the business measure the level of commitment that is required to maintain the solution. QSOS provides score cards to measure maintainability and code understanding using a score from 0 to 2. The score cards that QSOS provides have three distinct levels of categories that can be measured. The method allows for an iterative approach if all scores cannot be obtained. Once scored, the weighted average of the first two levels is taken into account for further review.

Qualification:
During the qualification step, the business’ needs and required functionality are given context and translated into filters. These filters are used during the selection process to further narrow the selection. The qualification initially begins with filtering based upon the ‘identity card’. This filtering eliminates solutions based upon needs not being met and/or compatibility issues. Filtering then takes place with respect to functional coverage, risks to the user, and risks to the business. Each functional element is assigned as required, optional, or not required. Risks to the user are accessed as non-relevant, relevant, or critical. Risks to the business are determined and service agreements are established which outline the level of commitment required. In the following step,weighted scores are given to the identified functional elements and user risks.

Selection:
In the selection step, the software solution which meets the user’s requirements the best is selected and/or scored. In this step, two options are available: strict selection and loose selection. Choosing to follow the strict selection will remove a solution from consideration when it fails to meet any of the filters outlined during the qualification step. This type of selection can lead to no ideal solution being found. If loose selection is used, a solution is scored based upon its coverage of functional requirements and user’s risks. For each functional requirement, a score of 3 is assigned to required functionality, a score of 1 for option functionality, and a score of 0 for functionality that is not required. For each risk to the user, the risk is assigned a score of 0 for being non-relevant, -1 or +1 for being relevant, and -3 or +3 for being critical. The positive and negative signs are equivalent to a positive or negative impact to the initial list of requirements. The weighted averages that have been calculated from previous steps can be plotted on a spider graph (see above) to aid in drawing a final conclusion upon which solution should be selected.

Gartner Research.
http://www.gartner.com/it/page.jsp?id=801412