Keywords

1 Introduction

Software developed by communities using the open source methods espoused by Raymond [1] is increasing in popularity [2]. While exact usage figures are uncertain, some studies have put usage levels as high as 85 % [3] and in some specialist fields, close to 100 % [4]. Open Source Software (OSS) usage had previously been the preserve of programmers and software experts [5, 6], but this ‘second wave’ [7] of OSS adoption by businesses and non-technical users has led to greater press and academic attention [8]. However, much of this attention has focused on OSS development methods and processes [9], with studies of adoption being under-represented [10–13]. This paper aims to partly address this gap through the achievement of the following objectives:

  1. 1.

    highlighting that most previous OSS adoption studies are not cognizant of the staged nature of the adoption process;

  2. 2.

    showing that where such studies are stage aware, that the models used to classify adoption are incomplete;

  3. 3.

    showing that existing staged adoption models do not identify all progression pathways;

  4. 4.

    and proposing a model to remedy shortcomings in existing models.

2 Literature Review

2.1 Technology Adoption

Adoption is defined as “choosing something for one’s use or practice” [14]. The adoption of technology is a long standing area of academic research [15], but the focus has largely been on the individual as the unit of analysis [16]. While personal technology adoption may be a near-binary state, organizational adoption is a complex process [16] and will naturally follow a more structured and tentative path. This path may be non-linear [17], as options are explored, barriers uncovered and priorities identified.

Two broad classifications of adoption theory exist: process based and factor based [18]. Numerous factor based theories have been proposed to aid in understanding the adoption of technologies, such as Technology Acceptance Model (TAM) [19], TAM2 [20], Unified Theory of Acceptance and Use of Technology (UTAUT) [21], Technology Organization and Environment (TOE) model [22] and Innovation Diffusion Theory (IDT) [16]. While there are numerous examples where these theories have been applied to studies of technology adoption (see [23] and [24] for OSS specific examples), there has been some criticism that this application has become formulaic, leading to a degree of stagnation [15]. Despite this criticism, there are few studies of OSS adoption [10–12], and this is an area where understanding remains limited [25].

While factor based theories allow the classification of drivers and barriers, as well as the ability to identify causality, they do not explain how the unit of analysis reached the observed level of adoption [18]. Such single-epoch methods have been criticized as too simplistic to capture the full complexity of adoption [26], leading to a loss of processual detail [27]. Of the above theories, only IDT, with its commensurate Innovation Decision Process (IDP) [16] fully acknowledges a process view of adoption.

Staged adoption models are one method by which an adoption process can be more richly documented. Figure 1 shows an existing staged adoption model used by Glynn et al. [28]. From this, it could be argued that an organization at any stage of this model, other than awareness or interest, could be said to be an adopter. Yet the commitment and maturity of the deployment for those in the evaluation/trial stage will differ greatly from those classified as a general deployment. Only if adoption studies classify their sample by stage can the level and commitment to that adoption be determined and stage specific barriers and drivers identified. A study that does not classify its sample risks missing stage significant factors due to heterogeneous sample composition and potentially limits comparability and generalizability.

Fig. 1.
figure 1

Levels of OSS adoption (redrawn from Glynn et al. [28])

Full size image

Examples of the application staged adoption models to information technologies can be found dating back to the early days of mass-market computing (e.g. [29]). However, while existing studies of OSS have sought to examine drivers and barriers to OSS adoption (e.g. [23, 30, 31]), few have identified at what stage adoption is within a unit of analysis [32]. When staged adoption models are used in OSS studies, critique of the models is limited, even where shortcomings have already been identified in their native field [33]. This paucity of use and critique contrasts with practice in similar literature, such as the adoption of e-business systems. This field has benefited from numerous staged adoption models [34, 35], with this pedigree leading to critique and the development of more complex contingent [33] and latterly hybrid models [36].

2.2 A Critique of Existing OSS Classification Models

Table 1 illustrates staged models used in previous OSS adoption studies, aligned to the more generic IDP [16] and Fichman and Kemerer’s models [37]. It can be seen that there is generally good agreement between these generic models, and those of Glynn et al. [28] and Fitzgerald [38] used in previous OSS studies. This similarity is perhaps not surprising, as these models have been adapted from the work of Fichman and Kemerer.

Table 1. Existing staged models used in OSS studies [28, 38, 39, 41, 42] aligned to the IDP [16] and Fichman and Kemerer’s [37] models
Full size table

Looking at the differences, the models of Fichman and Kemerer, Glynn et al. and Fitzgerald show that the software lifecycle used by Shaikh and Cornford [39] is incomplete, with early stages relating to awareness and exploration of possible solutions omitted. Likewise, it can also be seen that the IDP lacks resolution at the implementation stage, where software is commonly deployed in several phases of ‘roll out’ [40].

The models of Kwan and West [41] and Miralles et al. [42] appear classificatory of an organization, rather than explanatory of the adoption process. Many stages appear to be absent compared to alternatives and as such these have been discounted as the basis for the new model and are presented only for completeness.

OSS adoption can fail [43, 44], a fact acknowledged in OSS specific models by Fitzgerald alone. None of the models used in existing OSS studies classify cessation of use, despite this being a feature of both the IDP and Fichman and Kemerer’s model. This decomposition of cessation is important. Early rejection will leave little or no legacy data and an essentially unchanged business process. This contrasts with late-stage discontinuance, which will leave behind legacy data and the need to restore old systems, or seek new ones.

Despite some categorization, the IDP and Fichman and Kemerer’s model are also incomplete with regard to cessation of use. Late stage discontinuance may arise as a natural evolution of the business as the process supported by the software is retired. In other cases, use of the existing software may be discontinued in favor of a new solution or upgraded to a newer version of the existing product. No model fully acknowledges these nuances and as such omits data that may be valuable to the researcher.

Many organizations are unaware of OSS, a factor cited as hindering adoption [45]. None of the models used in OSS studies have a stage acknowledging this, perhaps explained by their lineage. All have been adapted from generic technology adoption models, perhaps suggesting that such a stage was previously unnecessary due to widespread awareness of the technology in their native field. Another possible explanation is that they have been primarily used to classify existing adoption, and not map the whole adoption process per-se.

Many of the existing models imply a linear progression between stages, with Fichman and Kemerer being explicit about linearity in their work. However, this may not always be the case, something staged models from other disciplines [35] and the IDP do note. The path taken through the adoption process, and thus any representative staged model, may have an impact on success or the barriers encountered. For example, a deployment that omits a limited trial may encounter numerous deployment issues which could have been identified and avoided without omission of this stage. However, for certain smaller deployments, it is likely that stages may be safely omitted or combined [34] with a successful outcome maintained, or that experience of similar products allows valid short-cuts to be made [25].

This lack of focus on the adoption process has been previously highlighted as a weakness in OSS adoption studies [10] and is something that any new model should attempt to address.

3 Proposed Model

The review of literature has highlighted that existing staged adoption models are incomplete when applied to the field of OSS. The authors therefore propose a hybrid staged model [46] for classifying OSS adoption (Fig. 2) built upon the foundations of the IDP and Fichman and Kemerer’s models to address the concerns highlighted in the previous section. While many of the stages of Fichman and Kemerer’s model are adopted here, the commitment stage is not as the authors believe this represents a transition pathway, not a stage.

Fig. 2.
figure 2

Proposed OSS staged adoption model

Full size image

The model has a general element of linearity, proceeding from the top, to the bottom, as indicated by the green arrows. A contingent approach was considered and rejected; the authors being unable to identify evidence to suggest OSS adoption is anything other than progressive. However, it is conceivable that some stages may be skipped [25, 34], with orange and red arrows showing pathways that allow stages to be omitted. The color coding indicates the expected increase in risk of failure based upon the deployment following that pathway, with green least risk, orange intermediate and red the highest.

Unlike the OSS specific model of Miralles et al. [42] and how Fichman and Kemerer used their model, the individual OSS package, not the organization, is used as the unit of analysis. This means an organization may occupy many stages at any one time if multiple deployments are proceeding in parallel [47].

3.1 Explanation of Stages

Unaware – this new stage indicates that the potential adopter is unaware that OSS is an option. This allows the model to fulfill the criteria defined by Morgan and Finnegan [45]. The only progression pathway is into the awareness stage as a potential user must become aware of OSS before they can progress with adoption.

Awareness – an adopter proceeds into this stage when they become aware that OSS is a potential solution to their real or perceived need. This is analogous to the knowledge stage of the IDP and the awareness stage of Fichman and Kemerer. There is only one progression pathway from this stage, where a potential solution can be explored to progress to the knowledge stage.

Knowledge – at this stage a potential adopter has identified one or more potential solutions and have sufficient knowledge to form a favorable or unfavorable opinion. This knowledge is unlikely to be complete and may be based upon their own perceptions (which may be biased) [48], what their competitors may be using [42], opinions of existing users within the organization [49], or those promoting the solution [50]. This matches the persuasion stage in the IDP and evaluation/trial stage of Fichman and Kemerer.

There are four progression pathways from this stage. The two paths of least risk are a positive outcome which leads to the evaluation stage and rejection based upon a perceived inappropriateness. The two remaining pathways, in order of increasing risk, are a jump to limited deployment without evaluation and an even riskier jump path to general deployment. Both of these are likely to lead to a greater chance of failure due to the software being a potentially inappropriate fit to the business needs or incompatible with existing technologies.

Evaluation – this stage involves some form of trial and/or evaluation. The ease of trialling an innovation has been found to promote a positive adoption outcome, both generally [16], and in OSS specific studies [45, 51]. The trial can range from installation on a single machine for formal or informal testing, to a more structured evaluation process. This is analogous to the IDP’s decision stage and the evaluation/trial stage of Fichman and Kemerer. Even though the software may be being used to some extent by a member of the organization, this may not be an objective evaluation [17] and this use may only be fleeting.

Due to the limited investment of resource needed to achieve this stage rejection is still a relatively low risk option. Transition pathways from this stage include rejection, or progression to limited deployment if the evaluation proves successful. A jump path to general deployment is available, but this increases the risk of failure as many lessons about avoiding deployment issues can be learned via a limited deployment.

Limited Deployment – here a solution has been selected to carry out a business process in a limited way (e.g. the ‘germ cell’ deployment for the City of Munich [40]). This may be limited to one department, or a limited use throughout the organization. This is an ideal opportunity to identify deployment barriers and usage issues, while the limited scale renders them easier to mitigate or correct. This stage is identical to Fichman and Kemerer’s stage of the same name and a sub-division of the IDP’s deployment stage.

Transition pathways include a low risk progression path to general deployment if the limited deployment proves successful. At this stage, there is still limited commitment to the software, so exit pathways are still a relatively low risk option. Direct rejection is not a possibility as there will be a small amount of legacy data that needs to be dealt with and business processes will require amendment if use is ceased. The exit pathways are therefore retirement, upgrade or migration (which are discussed in detail later).

General Deployment – in this stage the solution is now deployed such that it impacts large numbers of users or widely impacts upon business critical processes. Despite being widespread, the deployment is still immature with problems being encountered and resolved, but these will relate to the larger scale of implementation. This matches Fichman and Kemerer’s stage of the same name, and is a subdivision of the IDP’s deployment stage.

Successful continued use will allow progression to mature deployment once all deployment issues have ceased. There will be an increasing amount of business data stored in the system, so exiting use is increasingly challenging, but still possible. The exit pathways are therefore retirement, upgrade and migration.

Mature Deployment – in this new stage, the solution has been in general deployment for some time and a great deal of resource has been invested over a lengthy period. It is considered ‘the’ way the business process is carried out by staff. Few issues will be discovered at this stage, as the organization has a legacy of support and deployment for the solution. There is likely to be a large amount of data stored in the system making direct abandonment at this stage too costly to consider. The only pathways from this stage are retirement, upgrade and migration.

3.2 Exit Pathways

As already discussed, models previously used in OSS studies do not classify the ceasing of software use [39]. In their model, Fichman and Kemerer offer some classification, but as categories [37] (it is not fully clear how these differ from a stage in their model). Here it is proposed that cessation is not thought of as a stage, but a pathway to another stage. This model proposes the following exit pathways:

Rejection (blue arrow) – where a yet to be implemented OSS solution is no longer deemed suitable during the evaluation or awareness stage it can be rejected. This is analogous to the descriptions used in the IDP and by Fichman and Kemerer. There is little cost to this pathway as it will leave no residual business data and there is no culture of acceptance within the organization to resist removal. The pathway will result in an exit to the awareness stage, as a new solution will need to be sought.

Discontinuing use after deployment is more complex and, as such, there are three pathways discussed in order of increasing risk of failure:

Retirement (black arrow) – software will be retired when the business process it supports is no longer utilized. The data from this software is therefore likewise redundant and may be archived in some form for record keeping purposes. No replacement software is needed, so the process enters the awareness stage as the organization is aware that OSS is a potential solution should a similar need arise in the future.

Upgrade (orange arrow) – if the business process is still relevant, the software may be upgraded to a newer, more functional version. This may be a trivial upgrade or a major new version, but in any event, the new version and the process needed to deploy it will need evaluating prior to widespread use. For this reason, this exit pathway terminates in the evaluation stage.

While there is some risk that the upgrade will fail, this is less likely than if an entirely new solution is implemented. Unless the upgrade involves a significant change in functionality or user interface, it is likely that this will cause minimal disruption to the organization and that there will be little chance of rejection.

Transition (red arrow) - a decision is taken to adopt a completely new solution. This is the highest risk option in terms of potential failure as the new solution may be incompatible with existing systems, practices and data. This pathway terminates at the awareness stage as the organization will be seeking a replacement but must already be aware of OSS to be on this pathway. Careful analysis during the awareness and evaluation phases will be needed to ensure it is well fitted to business processes and any legacy data. Data may need to be migrated to the new system; a time consuming, expensive and sometimes inexact process. Users are likely to require retraining and may oppose the transition, potentially leading to rejection or further transition.

4 Conclusion and Contribution

Hauge et al. [13] exhorted OSS researchers to focus upon topics relevant to organizations, with Aksulu and Wade [10] specifically highlighting the lack of understanding of the organizational adoption process. This paper has attempted tackle this gap by discussing the importance of a staged adoption process and has cited evidence to suggest models of such are poorly utilized in existing OSS adoption studies (objective 1). Without classification and awareness of adoption stages, adoption studies risk conflating dissimilar situations leading to inconsistent conclusions and limited generalizability.

While there have been several staged adoption models used is OSS studies, none have fully addressed all needs identified by previous literature and there has been little critique compared to related fields. This appears to be the first paper to evaluate existing staged adoption models used in OSS studies and propose a new OSS specific model to address apparent issues. Issues identified include: implications of linearity, missing stages, insufficient resolution at the implementation stage, a lack of detail regarding ceasing software use and a lack of focus on the adoption process (objective 2). A new model is proposed that builds on the theoretical foundation of Rogers’ IDP [16] and the model of Fichman and Kemerer [37] to address these issues.

The proposed model appears to be the first to utilize a stage where the organization is unaware of OSS and to fully decompose discontinued use into four distinct pathways (rejection, upgrade, transition and retirement). In addition, three stages are used to indicate deployment based upon the maturity and spread of the software, with the aim of increasing classificatory resolution of deployment scale and the degree of acceptance. This contrasts with the one stage used by the IDP and two offered by Fichman and Kemerer. The model makes use of defined transition pathways, classified according to risk. These have the additional benefit of allowing the model to be used to track the adoption process as well as classify its current state. Both linear and non-linear paths can be followed through the model and allow adoption to be tracked on a pathway basis to allow successful and failed adoption to be potentially linked to omitted or truncated stages (objectives 3 and 4).

5 Future Work

The proposed model is a theoretical construct based upon issues identified from the literature. Future work will involve:

  • Testing the model to validate stage descriptions and transition pathways. Data will be gathered from field studies to verify the presence of each stage and confirm entry and exit pathways, and criteria.

  • Applying the proposed model to classify data from existing studies to potentially resolve inconsistencies related to heterogeneous sample composition. This may allow the resolution of issues where apparently similar studies have led to inconsistent results.

  • An analysis of adoption paths through the model for different categories of software (e.g. infrastructure, end user software etc.) in a variety of environments (e.g. differing organizational size, sector etc.) to explore success strategies and pathways that commonly lead to failure.