Increasing adoption of Open Source Software (OSS) in information system engineering has led to the emergence of different OSS adoption strategies that affect and shape organizations' business models. OSS adoption strategies can be operationalized by i* models describing the consequences of choosing each strategy. When an organization decides to adopt an OSS component, it becomes a part of the OSS ecosystem around this component. Therefore, OSS adoption strategy models need to be structured in the way to explicitly describe the role of the adopter organization within the OSS ecosystem, which may be quite different depending on the level of compromise that the organization prefers. Making visible the roles played by the different agents involved in the OSS ecosystem, the involvement of the organization in the OSS community arises naturally. This paper includes a set of roles that emerge in an OSS ecosystem and their responsibilities, and describes the issues behind the fact of using the i* role and plays constructs.
In the context of organizations adopting OSS components in their business
strategies and business models, [
The OSS adoption strategies models contain two actors: (1) the organization that
adopts the OSS component (OSS Adopter) and (2) the OSS community that produces
it. The adoption strategies are defined in order to describe the role of the OSS adopter
in the OSS Community, i.e. in the OSS ecosystem around the OSS component. The
rationale behind the elements inside the organization actor is identifying the goals and
activities that the company needs to achieve and perform connected to the role of the
organization in the OSS ecosystem. Most of the goals and tasks inside the
organization actor are included because the organization becomes part of the community. This
fact indicates that they should be in the OSS community actor in some way instead of
in the adopter organization. The OSS Community actor should be refined making the
different roles explicit.
Making these roles explicit, we would take advantage of the i* modelling language
highlighting the motivation for having some elements in the model. If an organization
(OSS Adopter) wants to contribute to the community (goal OSS community
contributed), it can do it for example producing code (Developer). Therefore, the task maintain
code must be included in the OSS adopter rationale (Fig. 1, left side). Using roles
would explicitly add the rationale for the presence of some activities, for example, the
OSS Adopter needs to maintain code only because the organization has decided to
contribute to the OSS community playing the role of Developer.
The OSS adoption strategies models catalogue presented in [
The remainder of the paper is organized as follows. Section 2 introduces the OSS
roles that characterize an OSS Community. Section 3 develops the main contributions
of the paper including the proposal of using i* roles in order to structure the OSS
adoption strategy models. Last, Section 4 provides the open issues to be considered
during the research in order to complete our proposal.
1 The names of the intentional elements inside the actors have been modified respect to the
names in the OSS adoption strategy models from [
In the context of the European Project RISCOSS, we have developed an ontology
for supporting risk analysis in OSS ecosystems [5]. Part of this ontology contains
terms for describing OSS projects. The activities and resources relevant for the
interaction between an OSS adopter and an OSS community has been used for creating a
set of models describing different strategies that the organizations can follow when
they need to adopt an OSS component [
When an organization decides to adopt an OSS component, it may have different
levels of involvement in the OSS community depending on its adoption strategy [
Next two subsections illustrate these two steps. 3.1
OSS Roles as i* Roles i* roles can be used to model the set of OSS roles described in Section 2 (see Table 1) and the relationships that exist between them. Fig. 2 represents these roles and their specialization (is-a) and aggregation relationships (is-part-of). To complete the roles definition, we add the activities that each OSS role performs represented as i* tasks in the corresponding i* role SR diagram (not shown in Fig. 2 for space reasons). For example, the role User has as tasks: learn using OSS, ask questions.
The complete OSS ecosystem model, including dependencies between roles, has been obtained by using an adaptation of the RiSD methodology presented in [6] for systematic construction of i* SD models for ecosystems. 3.2
Use of i* Roles and i* Plays for OSS Adoption Strategy Modelling Once we have the i* roles and their SR diagrams, the i* plays construct can be used to relate an agent representing the OSS adopter organization to them. For instance, if we have an OSS adopter whose adoption strategy is OSS Acquisition, which consists on having a minimum involvement in the OSS community meaning that it basically wants to use the component, this adoption strategy can be simply modelled by means of defining a plays relationship between the agent that represents the OSS adopter and the User i* role (no more role are played by the adopter in this strategy). Fig. 3 illustrates this case.
First, the implications of using the i* plays construct arise some questions over its related agents and roles that need clarification. For example: Does the agent that plays a role inherit all the dependencies defined on the role? Are the agent’s goals exactly the same as those of the role? May the agent have additional goals? May the agent get rid of some role’s goals?
Second, we have used the is-part-of relationship to relate, for example, the User
role and the OSS community role (see Fig. 2 and Fig. 3). Therefore, when applying the
adoption strategy model to a specific OSS community, e.g. the Eclipse community, we
would need to replace OSS community by Eclipse community in the model and, thus,
represent that the User role is part of the Eclipse community. However, this is not
straightforward, since the is-part-of relationship is required to relate only actors
belonging to the same type [7], and we have that User is a role while the Eclipse
community is an actor that seems more realistic to model as an agent than as a role.
Finally, not all the goals of an OSS adopter, according to the [