3. Basic FLOSS adoption models
From SME Guide
Within a company, the value that comes from FLOSS can derive from several different areas:
- basic substitution/migration: the use of FLOSS in the IT infrastructure, frequently in substitution of a proprietary software
- new deployment: the introduction of FLOSS for a new project internal to the company (adoption)
- selling services based on FLOSS
- selling products that contain FLOSS as a significant component
In this sense, a company may find useful FLOSS from a tactical point of view (FLOSS is cheaper to implement, with less constraint from a traditional vendor, or may help in introducing products in a reduced time to market) or a strategic point of view (creation of new markets, adoption of different business models). To be sustainable, a company must adopt a business model that provides a way to turn the FLOSS adoption into lower costs or increased revenues, and must also take into account the fact that at least a part of the participant community may be out of control of the company (as it commonly happens in large scale FLOSS projects, most contributors are not working for a single company).
The FLOSS adoption ladder
These different areas corresponds to individual steps in the FLOSS adoption ladder, that can be summarized as (modified from [Car 07]):
In the first stage ("use") there is simple adoption or migration, usually without any additional contact with the community, of one or more FLOSS packages. This adoption is in many cases started in a grassroots way, directly by employees, and it is performed with the specific target of exploration or reduction of costs. Many examples of adopted packages in this area are related to desktop applications, like the Firefox web browser or the OpenOffice.org personal productivity application; in some cases, small single-purpose application servers are introduced, like mail servers or web servers for introducing web-based applications. At this stage, usually there is no or very little contribution back to the community, that in many cases is not even perceived as a peer in the potential interaction. However, most companies that started adoption of FLOSS for the internal IT infrastructure are actively extending it; for example, a [CIO 07] survey found that of those adopting Linux, 65% of companies are planning to extend its use, while only 1% plan for a use reduction. These positive results tend to increase familiarity with FLOSS in general and with the underlying collaborative model, and facilitate the upgrade to the successive steps.
In the second stage ("contribute") there is an active involvement by the company into the development of the adopted FLOSS project. This contribution may come directly in terms of code, or through participation in events, indirectly by sponsoring, or simply by acting as promoters of the project. This step requires an explicit support from management, and provides positive returns both for the project and for the company (that reduces the cost of having functionalities implemented, by sharing the development cost with the community); there is also an explicit recognition of the participation and activities of internal developers and their interaction with FLOSS projects. An example of company in this stage is Apple (as OSX leverages more than 340 different FLOSS projects).
In the third stage ("champion") the company is basing a significant part of the underlying business model on FLOSS projects, and as such devolves a significant effort in the participation activities. The basic support activities of the contribution stage is strengthened and extended, to make the company a key management point that manages not only internally-produced contributions, but external developers as well. This turns the company into a part of the much larger project ecosystem, and provides increased business opportunities thanks to this enlargement.
The fourth stage ("collaborate and redefine") is characterized by an extension of the cooperation model, from a disjoint collection of individual projects to a coordinated effort to influence the market and the customer's perception of the environment. Not only the company changes most of its internal structure to accommodate open development practices, but also encourages the creation of a network of partners and independent projects, that are perceived as potential enlargements of the business ecosystem (even if some of those same projects can become potential competitors).
The cost and activities that are specific of each stage can be synthesized as:
| Stage | Main cost centers |
| Use | Identification of potentially interesting software, adoption, migration, training |
| Contribute | development time, sponsorship |
| Champion | development time, sponsorship, community interaction, support to third parties |
| Redefine | development time, project and ecosystem coordination |
It may surprise the fact that among the main cost centers of the first stage ("use") the identification of applicable software is prominent. This is confirmed by independent studies, like the EU COSPA migration project. Using data from [COS 05], we find that the "searching process" (that involves both searching for software and searching for documentation) is responsible for around 40% of the support costs, in some cases even surpassing the overall training costs of a large scale migration.
