Open source software opens the way to a reuse strategy that combines the best elements of in- house application development and commercial packages, according to a study for the Council of European Professional Informatics Societies, of which the BCS is a member.
However, IT teams need to look closely at the community working on their target software components and at the maturity of their programs.
"Developing internal components for reuse is the most flexible approach, because the components can be designed from scratch and their functionality is tailored to suit the company's needs. However, the disadvantage is the high initial development investment," said researchers Christoph Breidert and Christian Neumann.
"The great need for modularity, quality and documentation means costs can be significantly higher than if the same functionality is developed for a single application only.
"Choosing commercial off-the-shelf software requires no initial investment apart from the licence, but there are several disadvantages. Flexibility is limited, as components cannot be adapted to meet special needs: additional functionality must be realised in wrappers.
"There is a risk of undetermined internal behaviour, which may lead to incorrect results or unreliability of the whole application. This means many tests are needed, leading to higher integration costs. Another problem is maintenance, as users depend on suppliers. The frequency and number of updates can be uncertain, making it difficult to maintain the overall application.
"For these reasons the additional costs can equal or even exceed those of custom software development."
Adapting existing open source components combines the best of in-house development and commercial packages, because the code is already available, it can be extended to provide extra functions, and it can be tested and amended to cut the risk of unexpected behaviour, said Breidert and Neumann.
There are costs of getting familiar with the code and adapting it, but maintenance costs are low because maintenance is done by the open source community.
Even so, care is needed. "Availability of source code does not necessarily mean good programs. A program is only as good as its programmers, so look at the community's activities in terms of the number of contributors, the project's maturity and the frequency of releases," the researchers said.
"Integration of early releases should be avoided, as these components may be buggy, or future changes in design or functionality may require additional integration effort.
"Only projects with several contributors, a high degree of programming activity, and well-defined roadmaps are worth using. Projects that only have a handful of contributors or where the contributed work is highly concentrated may die or remain unstable. In this case any benefit is lost, because there is no community to maintain and evolve the product."
Open source software components should be examined for factors such as their reliability, conformance with standards and potential for adaptation, extension and upgrade. However, this can be a problem, said Breidert and Neumann.
"Addressing these issues means taking a deeper look into design and architecture, but many open source projects suffer from bad documentation. This makes it difficult to learn or extend the components, making their integration and in particular their extension or adaptation difficult. Good documentation is indispensable for fast and cost-effective integration," they said.
Development teams, especially in software companies, need to be aware of open source licence arrangements, said the researchers, because these can mean that a firm does not hold copyright, and any changes to open source software must be contributed to the community.
This has implications for software products based on open source components, because customers can in effect share them with the community.