Free/Libre/Open Source Software

Free/Libre/Open Source Software builds on the general idea of open and available source code and, furthermore, reaches beyond it by being both a software development method and a software business model. It is further defined by the license used to grant users and developers additional rights to the code. FLOSS can be freely used, studied, and modified. Free software is not necessarily cost free as such and thusfree does not relate to monetary cost but to freedom or liberty (libre instead of gratis). Copying and redistribution is allowed as well but can be restricted by the license as it may require a need to grant the same rights to the modified versions as well.

The first definition of free software was formulated by Richard Stallman in 1986. In it free software is defined as any piece of software that grants anyone with a copy the freedom to run, study, redistribute or improve it.

That is, these are the four freedoms [40] of FLOSS, which are indexed from zero as a geek homage to zero-based numbering often used in computer systems.

0. The freedom torun the program for any purpose.

1. The freedom tostudy how the program works, and change it to make it do what you wish.

2. The freedom toredistribute copies so you can help your neighbor.

3. The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.

Open Source Software Communities

At the heart of FLOSS is the developer community – a social ecosystem on its own. The structure of the community is often depicted with a layered onion model [74] where the users of the software form the outmost layer and the most prominent developers and the leader of the project are at the core.

The model is a generic representation and the amount of different layers may vary from project to project [II].

Figure 5.1: Onion Model of Open Source Communities

Taking an ecosystem view on the topic, the key characteristics of a soft-ware ecosystem vary depending on the viewpoint. From the engineering per-spective, a software ecosystem provides the technology for implementation,

environment for the overall software project infrastructure, and a develop-ment methodology that is aligned with the goals of the ecosystem. Addi-tionally for the ecosystem to foster, social, legal, and business aspects must also be considered along the technological. Consequently, the ecosystem can be viewed as a business and governance model with marketing as one of the strategic advantages.

FLOSS presents solutions for each of the aspects needed in a growing, sustainable ecosystem. While commonly addressed with a single term ’open source’, the set of principles, practices, culture, and licenses of FLOSS com-munities differ from each other in various ways and bring diversity into the ecosystem [85]. For example, some communities are geared towards the busi-ness environment and companies, and make long-term plans, whereas there are communities that focus on individual contributors’ innovative ideas to make the community succeed. Furthermore, the license plays a major role as some open source licenses are permissive⁴[87] and as such introduce only mild obligations and constraints to the user/modifier or the redistribution of the product. In contrast the so called strong copyleft licenses require any derived work to contain the same rights. Nonetheless, the generally common aspects of FLOSS include the transparency of development and the freedom to build more complex systems out of readily available building blocks. These in turn provide the means to grow an ecosystem around such pieces of software and also have an ecosystem that benefits from the members’ open contributions.

Stakeholders

The onion community model for FLOSS focuses on the developer community alone. However, FLOSS – especially industrial FLOSS – forms an ecosystem involving many stakeholders that have their own objectives and whose in-terests may be in conflict with each other. Business and industrial partners and other similar interest groups are key participants in the ecosystem and have influence on the community while they are not a part of the core model.

Similarly taking different viewpoints offers divergent looks on the community as one community can contain underlying sub-projects.

The different stakeholders, including the end users of the software prod-uct, are the people element in FLOSS development communities. The three main groups are the publisher, the industrial partners, and existing open source communities andother individuals [I, 53] as shown in Figure 5.2.

Several factors like familiarity with the project, objectives, and availabil-ity of skilled resources affect the position of each of three groups of

stakehold-4http://en.wikipedia.org/wiki/Permissive_free_software_licence

Figure 5.2: FLOSS Stakeholders [III]

ers in the community whether within the onion or outside its scope. Com-pared to the other two groups, the publishing entity is most familiar with the software product and commonly most willing to invest in the process of fostering the community. Thus, an active role is essential for this stakeholder throughout the development lifecycle. It is the task of the publishing entity to make decisions on the proper project platform and infrastructure and set initial policies such as the open source software license. Additionally, deci-sions where both the software and the social ecosystem have influence, need to be made on the role and type of the developer community. As a com-munity policy, platform, and purpose element the publishing entity needs to evaluate which of the alternatives, company-based, volunteer, or mixed type [70] of community, would best suit the project and the ecosystem it will live in. In addition, attention needs to be paid to the governance model and the dynamics of the onion model structure (closed or gated). As a policy the selection of such a fundamental governance structure affects the entire com-munity as it has impact on motivation and participation [93]. The publisher also has the means to allocate the community of skilled developers to lead the development and to interact with the rest of the community.

When talking about industrial FLOSS, an ecosystem scope reaches be-yond the core community. It brings both enthusiastic and conservative part-ners into the community scope, and has influence on the place of the com-munity in the ecosystem. Enthusiastic partners invest in the success of the

community, and thus usually participate with developers. They contribute to the development of the software and stay close to its evolution, so the community gets developers that are closer to the core team and might have key roles. The conservative partners in turn are more likely to be just in-terested in the evolution of the software and the outcome of the community.

Nonetheless, they too may have their dedicated developers in the community.

The existing open source communities and other individuals are a vital element in the community growing process. The project coexists with other development projects as part of the software ecosystem they create. The individuals may not all be simply keen volunteers but could as well represent the interests of companies that are not partnering with the publishing entity.

This group also represents the pool of potential contributors who could join the project if they get interested and motivated.

The individuals participating in the projects in the ecosystem form a social ecosystem – the developer community. A well-defined developer pro-motion policy is needed as more people join the project, especially if an open core structure is chosen. It is possible that individuals joining the commu-nity do not have any earlier experience with open source projects. In any case, the newcomers typically join the community as passive users and then may take key roles as they show commitment and value, thus penetrating the onion structure inward from outer layers [16]. The community policies support this migration.

Legalities

Copyright and intellectual property rights issues can be a tricky business.

With development of industrial software through open communities the most commonly considered element is the legalities. While this is a broad topic and extends towards legal sciences, legal issues are one key element included in the policies of FLOSS communities. The license, furthermore, is an inseparable element of the developed product.

The Free/Libre/Open Source Software license is a permanent policy that affects the community throughout its life and can have influence on the will-ingness of developers to participate in the community. Yet, it is a policy decision often made before the community is even born. The choice of li-cense affects other developers’ access to the code. At least the type of the product, compatibility with licenses of related systems, the intended users and partners, possible need for other open source components, and the de-sire to provide the possibility of derived projects should be considered. Then, finally, matters of personal taste influence the selection of license.