[2] is is about Apache project. Since the Apache Group members are working in geographically decentralized work spaces, all information on Apache Group is recorded three archival sources of data, namely Developer email list (EMAIL), Concurrent Version Control archive (CVS), and Problem Reporting Database (BUGDB).
Apache Project team began by solve the process issues first before the development began, because:
"..it was clear from the very beginning that a geographically distributed set of volunteers, without any traditional organizational ties, would require a unique development process in order to make decisions."
Apache Group member sets requirement for people who are interested in Apache developement:
"Each Apache Group (AG) member is volunteer who contributed for extended period of time..., and are nominated for membership and then voted on by existing members."
The AG member has the privrige to "vote on the inclusion of any code change, and has write access to CVS". A "core developer" is active in 4-6 developments in any given week. Each Apache developer iterate the following action through the course of Apache development:
"...discovering that a problem exists, determining whether a volunteer will work on it, identifying a solution,k developing and testing the code within wheir local copy of the course, presenting the code changes to the AG for review, and committing the code and documentation to the repository"
When an AG member has discovered a problem in the development, the AG member can report it in EMAIL, BUGDB and the USENET Apache newsgroups. Then, developer, who has experience to specific type of problem, will be a volunteer to work on the problem. Noted that "developers tend to work on problems that are identified with areas of the code they are most familiar." The Apache is divided into parts and the developers are assigned the "code ownership" of parts of the server that they are know to have created or to have maintained consistently. Developers can forward their possible solutions to the mail list for group to review in order to develop the solution. Once solution is identified, the developer tests and makes the changes to the Apache source code. Noted that “…all of the core developers are responsible for reviewing the Apache-CVS mailing list to ensure that the changes are appropriate.”
[3] has also mentioned Apache releases management as following:
“When the project nears a product release, one of the core developers volunteers to be the release manager, responsible for identifying the critical problem that prevent the release, determining when those problems have been repaired and the software has reached a stable point, and controlling access to the repository so that developers don’t inadvertently change things that should not be changed just prior to the release.”
[3] mentions that Mozilla Project maintains a roadmap document that specifies what will be included in future releases, as well as dates for which releases are scheduled. Mozilla applies Bugzilla problem-reporting mechanism for bug reporting and enhancement request process. Bugzilla allows bug reporters to see the most recent bugs to avoid bug report duplication. The development community can browse Bugzilla to identify bugs or enhancements they would like to work on. Fixes are often submitted as attachments to Bugzilla problem reports.
Both [2] and [3] are trying to find quantitative results for the following questions to understand how the Apache/Mozilla came to exist:
Q1: What was the process used to develop Apache/Mozilla?
Q2: How many people wrote code for new Apache functionality? How many people reported problems? How many people repaired defects?
Q3: Were these functions carried out by distinct groups of people? Did large numbers of people participate somewhat equally in these activities, or did a small number of people do most of the work?
Q4: Where did the code contributor work in the code? Was strict code ownership enforced on a file or module level?
Q5: What is the defect density of Apache code?
Q6: How long did it take to resolve problems? Were higher priority problems resolved faster than low priority problems? Has resolution interval decreased over time?
With the quantitative results, the Apache project and Mozilla project shares a number of hypotheses:
“Hypotheses 1: Open source development will have a core of developers who control the code base. This core will be no larger than 10-15 people, and will create approximately 80% or more of the new functionality.”
Hypothesis 2: For projects that are so large that 10-15 developers cannot write 80% of the code in a reasonable time frame, a strict code ownership policy will have to be adopted to separate the work of additional groups, creating, in effect, several related OSS projects.
Hypothesis 3: In successful open source developments, a group larger by an order of magnitude than the core will repair defects, and a yet larger group (by another order of magnitude) will report problems.
Hypothesis 4: Open source developments that have a strong core of developers but never achieve large numbers of contributors beyond that core will be able to create new functionality but will fail because of a lack of resources devoted to finding and repairing defects in the released code.
Hypothesis 5: Defect density in open source releases will generally be lower than commercial code that has only been feature-tested, i.e., received a comparable level of testing.
Hypothesis 6: In successful open source developments, the developers will also be users of the software.
Hypothesis 7: OSS developments exhibit very rapid responses to customer problems.
The above hypotheses are for both Apache project and Mozilla project except there are alternative hypothesis 1 and hypothesis 2 for Mozilla project as specified in [3]:
Hypothesis 1a: Open source developments will have a core of developers who control the code base, and will create approximately 80% or more of the new functionality. If this core group uses only informal, ad hoc means of coordinating their work, it will be no larger than 10-15 people.
Hypothesis 2a: If a project is so large that more than 10-15 people are required to complete 80% of the code in the desired time frame, then other mechanisms, rather than just informal, ad hoc arrangements, will be required in order to coordinate the work. These mechanisms may include one or more of the following: explicit development processes, individual or group code ownership, and required inspections.
Finally, it is feasible to perform “hybridized process of commercial and OSS practices”. Personally, I think the OSS process can be applied to the commercial software, but the restriction and closeness of commercial software team might reduce the effectiveness of OSS development.
REFERENCE
[1] The Cathedral and the Bazaar (Raymond)
[2] Mockus, A., Fielding, R. T., and Herbsleb, J. 2000. A case study of open source software development: the Apache server. In Proceedings of the 22nd international Conference on Software Engineering (Limerick, Ireland, June 04 - 11, 2000). ICSE '00. ACM, New York, NY, 263-272. http://doi.acm.org/10.1145/337180.337209
[3] Mockus, A., Fielding, R. T., and Herbsleb, J. D. 2002. Two case studies of open source software development: Apache and Mozilla. ACM Trans. Softw. Eng. Methodol. 11, 3 (Jul. 2002), 309-346. http://doi.acm.org/10.1145/567793.567795
No comments:
Post a Comment