A lot of studies focus static accounts of OSS community organization which views OSS community as a role hierarchy. Starting from the top of the hierachy, there are core developers, maintainers, patchers, bug reporters, documenters and then users. Core developers often have the smallest population but hold very important role in the community:
Indeed several empirical studies have found that, in a large majority of cases, a small core group is often responsible for a large proportion of the work accomplished and a very large group of peripheral participants is responsible for the remainder.
However, there are still less studies on volunteer's motivation to participate the OSS project while there are more studies in the OSS community structures. Motivation starts from socialization of newcomers, which is an important ingridient to keep the project going. OSS community relies on online tools as "a central source of power and influence". However, the centralized online tools would face the follwoing problems:
First, and especially for those interested in using qualitative methods, it is extremely easy to fall prey to data overload. Indeed the number of messages exchanged in Open Source mailing lists is in the order of hundreds, frequently thousands of messages per week....Second, OSS research material can be quite opaque. Despite their centrality in the Open Source development process, tools such as CVS databases, for example, produce few immediately analyzable outputs to the untrained eye.
To analyse OSS project, the author has started OSS Project Browser project to study and analyse OSS movement. The author has proposed 2 theorietical attributes:
(1) The software must make the hybrid nature of a project visible by showing
the connections not only between people, but also between people and material artifacts.
(2) The software must offer a dynamic perspective on activities and allow observations over time."
The OSS Project Browser should facilitate the ethnographic observation of a OSS project:
(3) It must offer both aggregate views (to avoid data overload and facilitate the selection of interesting episodes of activity) and at the same time preserve access to the raw, untouched research material for qualitative analysis.
(4) Since my interest here is in the socialization of newcomers, there must be ways to track a participant’s trajectory easily.
The author experiments the OSS Project Browser with Python, and the following description explains how the OSS Project Browser works:
The topmost pane (1) is a graphical representation of (borrowing Latour’s (1987b) terminology) the hybrid network for a particular OSS project. Black dots are individual participants in the project. A black line connects participants if they have both responded to each other over email. The more they reciprocated, the shorter the line (as in Sack, 2001). Another important part of this representation consists of the artifacts for this project, namely software code. Code is represented as blue rectangles. When an individual contributes code to the project, he is connected to the corresponding artifact with a blue line. The more he contributed to this particular artifact, the shorter the line.
From the study in “Fred” case, the process to reach the status of developer in Python involves the following steps:
(1) peripheral monitoring of the development activity;
(2) reporting of bugs and simultaneous suggestions for patches;
(3) obtaining CVS access and directly fixing bugs;
(4) taking charge of a ‘‘module size’’ project;
(5) developing this project, gathering support for it, defending it publicly;
(6) obtaining the approval of the core members and getting the module integrated into the project’s architecture.
Identity establishing is important for one to become a developer:
First, one can actively contribute to PEPs and features discussion….Second, one can submit bug reports and, simultaneously (this is important), a proposed solution to fix these bugs.
The OSS browser can help the new participant in the following steps:
(1) A period of ‘‘lurking’’ to assimilate the project’s culture and identify the areas in need of new contributions.
(2) Enrollment of key allies in support of future work.
To summarize this paper, author lists the following limitations in Open Source research:
Open Source projects are dynamic entities, yet most of the current research has produced only static accounts of their activity.
Open Source projects are hybrid, multi-sited environments composed of a network of human and material artifacts, yet these dimensions are often considered in isolation.
The massive amounts of research data available tend to favor aggregate statistical analysis to the detriment of more qualitative, in-depth analysis of the activity in a project.
Open Source productions are often difficult to understand for non-developers; accessing and processing some of this data (e.g. CVS records) requires technical knowledge.
The author proposed 2 frameworks to understand sodialization in Open Source projects:
(1) as an individual learning process based on the construction of identities, and
(2) as a political process involving the recruitment and transformation of human and material allies.
In conclusion, the new comer needs to earn his identity and trust from the core developer in order to gain the full access to modify the source code. I think this makes sense in the way that it is logically the new comer needs to go through all the process to add one piece of code in the source code. In this way, the new code is bullet-proof and this will reduce the rate or error in the source code.
REFERENCE
[1] Ducheneaut, N. 2005. Socialization in an Open Source Software Community: A Socio-Technical Analysis. Comput. Supported Coop. Work 14, 4 (Aug. 2005), 323-368. http://dx.doi.org/10.1007/s10606-005-9000-1
No comments:
Post a Comment