A open source component framework has been presented in Chapter 5. That frame- work aimed at selecting reusable components for commercial software solutions. However, component reuse is a well known concept aiming at optimising software development. The components can be in-house made, COTS components, or OSS components. The last category is of primary interest in this chapter. However, in order to put the OSS component selection in a broader context it will be useful to start from a brief overview of component reuse in commercial organisations.
Land et al. [77] have provided an extensive review of commercial off-the-shelf software (COTS) selection methods. The review covered 17 component selection methods from 1995 to 2006. In addition to the component selection methods Land et
al. have conducted surveys, which included industry representatives, on the practi-
cally used selection methods. The results of that review provide a concrete industry point of view on the component selection. Lang et al. identified four processes in the selection methods, namely preparation, evaluation, selection, and supporting pro- cesses [77, p. 102]. The details of the processes were analysed and practical recom- mendations proposed, so that a custom selection process could be created. Finally, they provided four key recommendations that can be summarised as follows [77, p. 110]:
• different evaluation criteria should be used (i.e. functional, non-functional,
architecture and business related criteria),
• evaluation should be an iterative process,
• architectural context of the whole system should be considered for compatibil-
ity and cost evaluation, and
• criticality of the components should be taken into consideration in the evalua-
tion.
These findings based on COTS selection method review provide a good background for discussion of OSS component usage in commercial solutions. Moreover, the rec- ommendations on usage of various criteria are fulfilled by the proposed OSS eval- uation framework presented in Section 5.2. The framework utilises various criteria and sources of information, including open source community, available literature,
7.4. COMPONENT REUSE 83 and the organisation’s internal knowledge base in order to make a thorough evalu- ation. Naturally, evaluation of COTS and OSS components is not the same because the components differ significantly (e.g., in terms of offered support).
Additionally, Lang et al. have conducted a survey on component reuse in in- dustry [78]. They have investigated development practices with reusable compo- nents, without the components, and development of such components. Their find- ings show some differences in the different development cases. For example, they have found that requirement specification is more flexible and accepts more changes in the case of development without reusable components compared to development with such components. Furthermore, the survey findings indicated acceptance of code changes even at the integration stage when a system was developed based on reusable components [78, p. 155]. This fact indicates a higher flexibility of solutions based on ready-made components, including OSS components that are of interest in this chapter.
The usage of OSS components poses concerns specific to the nature of OSS. For instance, Ruffin and Ebert [108] discussed legal concerns relating to Intellectual Prop- erty Rights (IPR) and license issues and they provided a few recommendations on how to use OSS components in commercial solutions safely. Moreover, they listed a few risks and benefits of OSS usage. For example, as benefits they mention short update and correction time for mainstream OSS projects, or in the case of mature OSS communities it can be less likely that the project is discontinued than in the case of small commercial component vendors. Moreover, they indicate that security of OSS components can be greater than in the case of commercial components where the code is not available for review by the whole community. At the same time, they mention a few risks attached to OSS components, for instance, a risk of breaching the license terms if the OSS component is not used carefully, or possible legal risks related to third party IPR violated in the OSS component. One of the suggested rec- ommendations for reducing the legal risk was usage of packaging companies that shield the software development organisation from possible legal actions in the case of an OSS component breaching IPR. The evaluation framework presented in Sec- tion 5.2 also takes into consideration legal and licensing issues. Incompatible license for commercial use is one of the criteria in the No Excuses category that has to be fulfilled in order for the component to be even considered for use.
In more recent publications [32, 34] Christof Ebert revisited the subject of OSS in industry. The positives and negatives of using the OSS in a commercial con- text [32] are in line with those presented earlier [108]. An important addition made by Christof Ebert [32] is the analysis of different aspects of OSS that innovate soft- ware development in many ways, e.g., in terms of processes, technology, quality, architecture, standards used, and business model and marketing practices [32, p. 105-106]. However, organisations considering usage of OSS are still urged to con- sider their processes to be aligned with the nature of the OSS environment, e.g., fre- quent updates [32, p. 108]. Also other researches pointed out the importance of the context in which OSS is used. Ven et al. [129] presented results of a literature review and a case study based on 10 Belgian organisations. They have analysed five contra- dictory claims about OSS showing how differently specific aspects can be perceived. For instance, for organisations who only use the software, the access to the source
84 7. RELATED WORK
code may not be a clear benefit, especially if they do not have the competences to use it. Even though their focus was on infrastructure software, e.g., operating sys- tem, their findings showed the importance of evaluating OSS in the specific context of the business environment in which the OSS is used.
Ven and Verelst [128] studied a number of Belgian organisations in order to find out to what extent the organisations use external advice when adopting OSS. Also in this case the focus was on a general usage of OSS, rather than on a specific compo- nent reuse. However, the findings of the research showed that most of organisations use some form of commercial support. In this context methods for evaluating OSS in general are additionally important, especially if the company providing consulting services has the right tools for advising their clients.
The recommendations on considering the specific context for component usage [32, 129] are fulfilled by the OSS component evaluation framework (see Section 5.2) as the framework focus and used criteria are adjusted to a particular context in which the framework is intended to be used. On the other hand, the framework does not rely on any external help, as reported by Ven and Verelst [128], other than the available sources of information.
The effects of the availability of OSS components on software development have been discussed by Spinellis and Szyperski [119]. They note two important benefits generally associated with OSS components, i.e., the access to the source code and possibility to derive the developed code from the OSS. Additionally, they point out benefits of using OSS components, particularly the typically high quality of OSS components and the fact that they are potentially functionality richer than if devel- oped in-house. However, they mention possible problems with the varying qual- ity of different OSS components. For that problem, Spinellis and Szyperski suggest taking advantage of access to source code, mailing list archives, and bug tracking databases as indicators of OSS component quality and provided support [119, p. 30]. The concern of OSS component quality and ways of evaluating the quality based on OSS properties (e.g., the source code access) is particularly valid in the context of the evaluation framework discussed in Section 5.2. The quality of OSS compo- nents is the main focus of the framework as the evaluated components are to be used in commercial solutions. Moreover, sources of information that Spinellis and Szyperski [119] recommend, are included in the sources of information in the OSS evaluation framework.
Another interesting aspect of using OSS components was presented by Obren- ovi´c and Gaˇsevi´c, who discussed a problem of OSS component integration [133]. They addressed the integration problem of very heterogeneous OSS components by a middle-ware platform called Amico. The platform helped in quick integration of different OSS components using many standard interfaces and adapters, and a publish-subscribe way of communication [133]. This problem of component integra- tion is also an aspect that must be taken into consideration when selecting compo- nents to be integrated with a commercial software solution.
The economics of OSS component usage in commercial projects have also been studied. Ajila and Wu [4] have reviewed literature and conducted interviews with companies’ representatives in order to verify a few hypotheses about OSS compo- nent reuse. They concluded that a positive correlation between the OSS reuse and
7.5. SOFTWARE DESIGN CONSIDERATIONS 85