Open Source Software is defined not just by the type of licenses, but also by a certain kind of development and governance that is open to the community of developers.

Description

Diomidis Spinellis at http://www.re-public.gr/en/?p=97

"Instead of a management hierarchy dictating how and on what each developer works, volunteers find tasks that interest them and work when they find time. Instead of having the software’s source code (essentially its design) hidden as a company’s proprietary secret, the open source programmers publish their code on the internet for others to read, learn, experiment, modify, improve, and reuse. Instead of erecting organizational barriers to control their development process and their turf, the open source development model brings all its artefacts in the open: discussions between developers and users, problem reports, the historical record of changes made to the software, even results of failed tests. Under this model transparency and self-regulation nurture each other, fostering organic growth and taming complexity." (http://www.re-public.gr/en/?p=97)

Characteristics

Gianugo [1]:

"I would rather see the OSI, or an entirely new entity, patronise this concept, which should be fairly easy (though not trivial) to protect as there might be some objective criteria to tell open development from plain Open Source. A first stab at what these criteria could be:

1. an Open Source license, of course;

2. a non-discriminatory access to the developer’s community;

3. a well-defined and stated process for people to get involved;

4. a neutral and self-elected governing body;

5. (more difficult, could mean having a preferential lane) a neutral party such as a foundation owning the code.

The OSI (or its spinoff, or whatever) would assert whether a community deserves the status of “open development”, much like today the OSI is approving licenses. The process could be standardised by providing “open development processes” in terms of bylaws and charters which could then be just applied via find/replace much like what happens today with licenses. The specific authorization to use the “brand” should be temporary and subject to arbitration if someone complains about a community not respecting the self-inflicted rules." (http://feather.planetapache.org/2006/03/08/should-osi-redefine-the-label-open-source/)

Typology

Peter Hoddinott and Tony Bailetti [2] define four possible scenario’s mixing open source code with an open or closed process of developing it:

“the production of the code lacked key open source characteristics such as:

• No external contributors: all code was developed in-house prior to being published on the Internet

• No visibility of who developed the code and when they developed it

• No mechanisms were available to the general public for

(i) contributing to the production of the code prior to its release in Sourceforge.net or

(ii) participating in the governance structure of the organization that produced it

In short, the code was open, but the process used to produce it was closed. There was no public community behind the production of the code, and no accommodation for such a community.

Our discussion then turned to the ambiguity in the usage of the word "source". Does source mean the computer code written in a recognized programming language, or the process used to produce the code, or something else? If we allow source to mean two different things:

(i) the process used to produce the code, and

(ii) the computer code, four cases are possible:

1. Open process and open computer code

2. Closed process and open computer code

3. Open process and closed computer code

4. Closed process and closed computer code

We surmise that many use the term open source with case 1 in mind. For example, the Eclipse code is licensed under the OSI approved Eclipse Public License (EPL). The central repository for the code base is available and the general public can, with ease, track the pedigree of the code. Release dates are known and published. The general public is encouraged to contribute to the organization itself, to define projects, and to write code. Moreover, the governance structure used to manage all the Eclipse projects is transparent.

Case 2 was outlined above, and it characterizes what our software professional called "open code" but not "open source". A fundamental contradiction seems to exist when an open source asset is developed using a process controlled by a single party. For example, the Open Office project has been criticized. for encouraging a development culture that differs radically from the open-source norm The majority of the contributors to the Open Office project work for Sun Microsystems.

Case 3 includes instances of organizations and individuals that produce a reference implementation of some standard to accelerate that standard's adoption. The code of the reference implementation is typically produced using open processes but the code itself may not be released under an open source licence. The reason is straightforward: releasing the code under an open source licence would potentially weaken the purpose and authority of the standard by facilitating the ease by which deviations of the standard may be introduced.

Case 4 includes instances which are typically referred to as proprietary or closed software. The process used to produce the code is closed, and the software is released using a non-open source licence. This case includes instances where several organizations create a consortium to produce code that only those with membership within the consortium have visibility and access to. Typically, such consortiums have a tiered membership that stipulates the members' rights with respect to the code.

It can also be argued that the use of "source" does not distinguish between the three types of code, any of which could be open or closed. Source can mean:

(i) the code used to implement a system or component,

(ii) the interface where what we open is the application programming interface (API), or

(iii) the data underlying the implementation where most any application or system creates value from the data underlying it.

It can also be argued that source is not limited to computer code. One could extend the four cases described above to combine open and closed processes with hardware schematics or documentation, two examples of assets which are increasingly being considered as open.” (http://www.osbr.ca/archive.php?issue=10&section=Ar#A2)

Discussion

The four factors of openness

Peter Hoddinott and Tony Bailetti [3]:

“we had occasion to find ourselves struggling as we tried to make sense of instances of the word open in the context of community code. For example, we found instances where open meant that releases of the code were made available to the general public (i.e., non-members of a consortium); however, releases to the general public were delayed 12 months from the time it was available to the members of the consortium. We also found instances where what open meant depended upon the level of membership. The more expensive memberships provided these members more privileges to participate in and influence the processes, for example with veto power. In these examples, open is not equated with full access; instead, open is a matter of degree and that degree is metered out in a distinctly defined hierarchy of privilege.

This seeming confusion and differences about what is open and what is source and the use of open source to refer to phenomena that fall well outside the OSD, led us to conclude that we need to better understand the characteristics of the systems in which open source assets are produced, used and distributed.

We conceptualize any such system as being comprised of four components:

1. Network: the network of individuals and organizations that produce, use and distribute an asset

2. Processes; the processes, approaches, rules and understandings that lead to the production, use and distribution of an asset

3. Governance: the governance structure of the organization and the projects within the organization

4. Value: value created through collaboration and value appropriated through competition

We observe that a healthy open source system is required to compete with a strong proprietary system; that is, an open source system cannot compete by virtue of the distribution license alone.

What one would generally agree upon as being an open source system could be expressed in terms of the health of its four components. Such a definition would not be static, but would arguably be more accurate and useful in determining the true value of an open source system. For example, one could speak in terms of a system not having reached the status of being open source until it is deemed to be healthy. And an open source system may subsequently cease to be an open source system if its health deteriorates beyond some point. This line of inquiry could then further leverage health of the four components as a means for distinguishing other types of systems such as closed systems and community systems.

Our initial suggestion as to what is relevant for assessing the health of each of the four components of a system is as follows:

1. Network: Large, distributed and diverse: We distinguish between an asset produced by a well developed network from an asset produced by a small number of collocated producers who have similar characteristics. A general reference model for an open source asset would be one that is produced by a well developed network that is able to integrate, test, and quality assure contributions from a large number of diverse individuals and organizations dispersed throughout the world

2. Process: Includes meritocracy where one is recognized for the quality of their contributions; transparency in communications and guidelines; recruitment and promotion methods; and mechanisms for dealing with difficult people

3. Governance: Includes participation; relationship between contribution and the influence that can be asserted; membership's influence over a project, influence over the overall system governance, and ability to alter the governance structure

4. Value creation and appropriation: Usefulness of the asset; how free-riders are addressed--if it is too easy to appropriate value no one would pay for a membership or undergo an apprenticeship to move from being a developer/contributor who writes code or documentation to a committer with write access to the codebase; access to the asset by virtue of the license.” (http://www.osbr.ca/archive.php?issue=10&section=Ar#A2)

The Role of Community in Development

Nelson Ko [4]:

"Understanding the nature of the community that produces the open source software is a critical part of evaluation that is often overlooked by users who are new to open source software. Unlike closed source alternatives, key support options for open source software include non-commercial channels provided by an extended community. Therefore, important criteria that should be considered when evaluating open source software include the size and vibrancy of the community, the availability of online documentation, and access to support via mailing lists, forums, and IRC (Internet Relay Chat). One source for such information is statistics on sites such as SourceForge and Ohloh. However, both sites focus on the contribution of developers and it is important to note that contribution to an open source community is more than just commits to the codebase. As in commercial software, production of good open source software also requires documentation, testing, support, training, and the incorporation of user feedback. An understanding of the maturity of the community can help to answer questions such as "what support mechanisms are available if we roll out this software?" and "how difficult will it be to install and use this software?"An evaluation of an open source community should also consider the broader ecosystem in which it exists. An environment in which open source is prevalent results in consumer choice that is arguably unparalleled in closed source ecosystems. Open source software has a clear advantage in some domains, for example, in the area of wikis. Freely downloadable open source solutions are plentiful and comparable in terms of quality to their expensive, closed source counterparts.

A deeper understanding of the nature of the community is also critical in determining the nature of support that will be available for an open source software. It is important to consider the nature of the resources the community has to offer in relation to the capabilities of your organization. For example, the Tikiwiki and Drupal communities have a large number of highly technical members who can provide support at a high level of technical sophistication. On the other hand, another popular content management system Joomla, has a relatively smaller team of technical experts combined with a larger community of less technical but more design oriented individuals such as graphic designers and web designers. Largely as a result of this structure, the Joomla support forums tend to become somewhat overwhelmed with questions of a "how-to" nature. Discussions over more complex technical issues are therefore less prominent. On the other hand, it is much easier to find consultants that are able to make low cost design customizations for Joomla than it is for Drupal or Tikiwiki. Another benefit of open source software like Joomla that is exposed to a wider swath of mainstream users is that they tend to be more user-friendly, although this usually comes at a price of reduced functionality." (http://www.osbr.ca/archive.php?issue=10&section=Ar#A6)

Six Limitations of the current model

Felix Stadtler [5]:

"Six Limitations to the Current Open Source Development Methodology

The "Open Source Approach" to develop informational goods has been spectacularly successful, particularly in the area for which it was developed, software. Also beyond software, there are important, successfull Open Source projects such as the free Encyclopedia, Wikipedia; collaborative sites writing/publishing projects such as koro5hin.org; and the Distributed Proofreading Project, attached to the Gutenberg Project.

However, particularly outside the software domain, the Open Source projects remain relatively marginal. Why? Some of it can be explained by the relative newness of the approach. It takes time for new ideas to take hold and to be transferred successfully from one context to another. But this is only part of the story. The other part is that the current development model is based on a number of specific, yet unacknowledged conditions that limit its applicability to more diverse contexts, say the music distribution or drug research.

The boundaries to the open production model as it has been established in the last decade are set by six conditions characterizing virtually all of the success stories of what Benkler called "commons-based peer production." The following list is a conceptual abstraction, a kind of ideal-type. The actual configuration and relative importance of each condition varies from project to project, but taken together they indicate the boundaries of the current model. In this elaboration, I draw from examples of free and open source software, but it would be simple to illustrate these limitation based on open content projects.

1) Producers are not sellers

The majority professional, i.e. highly-skilled, programmers do not draw their economic livelihood from directly selling the code they write. Many work for organizations that use software but do not sell it, for example as system administrators. For them the efficient solution of particular problems is of interest, and if that solution can be found and maintained by collaborating with others, the sharing of code is not an issue. For others employed in private sector companies, for example at IBM, the development of free software is the basis for selling services based on that code. The fact that some people can use that code without purchasing the services is more than off-set by being able to base the service on the collective creativity of the developer community at large. From IBM's point of view, the costs of participating in open software development can be regarded as 'capital investment' necessary for the selling of the resulting product: services.

For members of academia (faculty and students) writing code, but not selling (often explicitly prohibited), contributes to their professional goals, be it as part of their education, be it as part of their professional reputation-building. For them, sharing of code is not only part of their professional advancement, but an integral part of the professional culture that sustains them also economically,. in form of salaries for the faculty and stipends for the (graduate) students.

Last but not least are all those who use their professional skills outside the professional setting, for example at home on evenings and weekends. Having already secured their financial stability, they can now pursue other interests using the same skill set.

2) Limited capital investment

Particularly the last, and very important group of people, whose who work outside the institutional framework on projects based on their own idiosyncratic interests, can only exist due to the fact that the means of production are extraordinarily inexpensive and accessible. Materially, all that is needed is a standard computer (often even a substandard one would already suffice) and a fast, reliable connection to the communication forums of the community. Of course, the computer and the network rely on a level of infrastructure that cannot be taken for granted in large parts of the world, but for most people in the centers of development, they are within relatively easy reach.

Once this access to be means of communication is secured, the skills necessary to participate in the development of code can also be acquired collaboratively, free of charge. The number of self-taught programmers is significant. Since no expensive diplomas are necessary to become active, the financial hurdle is, indeed, extraordinarily low.

3) High number of potential contributors

Programming knowledge is becoming relatively common knowledge, no longer restricted to an engineering elite, but widely distributed throughout society. Of course, truly great programmers are rare as truly great artists are, but average professional knowledge is widely available. This has a quantitative and a qualitative dimensions. Quantitatively, the number of able programmers is in the millions, and rising. Qualitatively, the range of people capable programmers is also unusually wide, not the least because the material hurdles are so low and the learning can take place outside of institutions with entry exams and tuition fees. This large and diversified pool of talents makes it possible to create the critical mass of contributors out of only a fraction of population.

4) Modularized Production

A large software program consists of many smaller code segments (libraries, plug-ins etc.)This makes it possible to break down the production process into many small steps which can be carried out by distributed contributors. If the act of integration is relatively straight forward, it allows to keep the amount of work that each has to contribute highly flexible and also make use of smaller contributions (bug reports, patches). Furthermore, the modularity of the production process allows a high number of people to work in parallel without creating significant interferences.

5) Producers Are Users

According to Eric S. Raymond, a good open source projects starts with a programmer scratching his own itch and finding out in the process that there are many others with the same problem. Wanting to use a program is a great motivation of contributing to developing it. Often, it's much more efficient that waiting, hoping that someone will write and sell a program that will address one's particular need.

6) No Liability

Last, but not least, software has no product liability. Paragraph 11 of the GPL states, similar to most other licenses, that "the copyright holders and/or other parties provide the program 'as is' without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose" (GPL, v2). The absence of liability makes it possible to produce a program without having to assign clear ownership, or other markers allowing to determine liability, to it.

The space delimited by these condition is large and still not fully explored. We can expect that the current open production model will find additional niches in which it can thrive. Few could have predicted the success of Wikipedia only three years ago, even though Open Source Software had already been very successful at the time. However, it is also clear that many information goods fall outside of this space. Not always are the means of production inexpensive and readily available or the production process modular. Sometimes, the number of potential producers is small, more often than not are the producers not the users of their own products, and, in many cases, product liability is desirable.

This does not mean that the "open source model" cannot apply to, say, the production of literary works, music, or medical drugs. What it means, however, is that to make it viable, another round of social innovation is required. This is slowly happening. The growth of "Open Access Journals" or discussions around "compulsory licensing" are good, though very early examples." (http://amsterdam.nettime.org/Lists-Archives/nettime-l-0308/msg00043.html)

Key Book to Read

Code Quality: The Open Source Perspective. Diomidis Spinellis. Addison Wesley, 2006. ISBN 0-321-16607-8.

More Information

Managing Open Source Software

-Linux - Governance

- A Highly Efficient Waste of Effort: Open Source Software Development as a Specific System of Collective Production by Jochen Gläser (Research School of Social Sciences; The Australian National University)

"It appears to be very difficult to capture the distinctness of open source software production in a general theoretical framework. The only theoretical framework that compares alternative modes of collective production is transaction cost theory, which is an economic rather than sociological approach to the organization of work and therefore tends to neglect the problem of coordination. This paper describes open source software production in a sociological framework of collective production, i.e. in a framework that emphasizes the actor constellations and the systems of actions that characterize modes of collective production. A generalized sociological description of open source software production is derived from published empirical studies. On the basis of this description, open source software production can be compared to the known systems of collective production, namely markets, organizations and networks. The comparisons reveal necessary conditions for the functioning as well as specific advantages of producing communities."

- Study on Management of Open Source Software Projects

"The ideology of open source software development is spearheading a shift in the way we approach the process of software development. Not only is it changing the perception of costs associated with projects, but also the management aspect of these development processes. The management of open source projects is very different from a traditional project due to the inherent nature of the objectives, team structure and the benefits involved. Several studies have examined various issues related to the management of these projects. However there is a lack of a study that puts together all the findings so that the interrelationships between these findings can be explored. This study tries to overcome this shortcoming and present the findings of other studies in a comprehensive manner and at the same time look at the entire process from a bird' eye point of view."

Open Development

Contents