Open Development
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.
Here is a proposal in that sense, from http://feather.planetapache.org/2006/03/08/should-osi-redefine-the-label-open-source/
Description
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§ion=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§ion=Ar#A2)
More Information
Managing Open Source Software
- 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."