Understanding Open Source Software Development Process

Abstract:
As the assignment requirement, we selected eclipse, Linux kernel and commercial software from the corporation of one member. It is the regret that we had not enough time to collect all statistics by ourselves, and instead of that, papers and blogs are the main resources for open source part in this document. The open source software is introduced before the commercial one.
Keywords: development process, code ownership, defect density, bug lifetime

Background:
Linux Kernel

In April 1991, Linus Torvalds, a 21-year-old student at the University of Helsinki, Finland started working on some simple ideas for an operating system. He started with a task switcher in Intel 80386 assembly language and a terminal driver. On 26 August 1991, Torvalds posted the following to comp.os.minix, a newsgroup on Usenet:
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since April, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
After that, many people contributed code to the project. Early on, the MINIX community contributed code and ideas to the Linux kernel. At the time, the GNU Project had created many of the components required for a free operating system, but its own kernel, GNU Hurd, was incomplete and unavailable. The BSD operating system had not yet freed itself from legal encumbrances. Despite the limited functionality of the early versions, Linux rapidly accumulated developers and users.

Eclipse

Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written mostly in Java and can be used to develop applications in Java and, by means of various plug-ins, other programming languages including Ada, C, C++, COBOL, Perl, PHP, Python, Ruby (including Ruby on Rails framework), Scala, Clojure, and Scheme. The IDE is often called Eclipse ADT for Ada, Eclipse CDT for C/C++, Eclipse JDT for Java, and Eclipse PDT for PHP.
The initial codebase originated from VisualAge. In its default form it is meant for Java developers, consisting of the Java Development Tools (JDT). Users can extend its abilities by installing plug-ins written for the Eclipse software framework, such as development toolkits for other programming languages, and can write and contribute their own plug-in modules.
Released under the terms of the Eclipse Public License, Eclipse is free and open source software. It was one of the first IDEs to run under GNU Classpath and it runs without issues under IcedTea.

Digital Asset Commander (Commercial software of Halliburton)

Digital Asset is a grand and new service aimed at establishing a real time, collaborative environment to model, measure and optimize the asset for oilfield services provided by Halliburton (a global oilfield service company headquarters in Houston, America). The Commander tool integrates Geosteering and Stimulation workflows together, and draws on the entire spectrum of our unparalleled expertise, technologies and downhole tools to realize the full potential of Halliburton’s real-time capabilities.

Data Sources & References: Linux Kernel: a. Linux Kernel Development--2010 b. Measure of software quality—a study of open source software c. The referenced website : http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary d. Bugzilla Eclipse: a. Eclipse Platform Technical Overview b. Predicting eclipse bug lifetime c. Wikipedia d. Eclipse official website e. Bugzilla

Digital Asset Commander a. Team Foundation Server
Team Foundation Server (TFS) is the collaboration platform at the core of Microsoft’s application lifecycle management solution that automates the software delivery process and enables organizations to effectively manage software development projects throughout the IT life cycle. b. Visual Studio 2008 Team System
Visual Studio Team System is a suite platform for software development process. And it provides the team explorer component connecting to Team Foundation Server, which bridge the team collaboration. c. Project Plan
The project plan summarizes and lists all the features developed and those ready to be developed in a single release.

Questions:

Q1: What were the processes used to develop open source software?

Linux Kernel

Development Model
Linux kernel development proceeds under a loose, time-based release model, with a new major kernel release occurring every 2-3 months. This model, which was first formalized in 2005, gets new features into the mainline kernel and out to users with a minimum of delay. That, in turn, speeds the pace of development and minimizes the number of external changes that distributors need to apply. As a result, distributor kernels contain relatively few distribution-specific changes; this leads to higher quality and fewer differences between distributions.
One significant change since the initial version of this paper is the establishment of the linux-next tree. Linux-next serves as a staging area for the next kernel development cycle; as of this writing, 2.6.36 is in the stabilization phase, so linux-next contains changes intended for 2.6.37. This repository gives developers a better view of which changes are coming in the future and helps them to ensure that there will be a minimum of integration problems when the next development cycle begins. Linux-next smooths out the development cycle, helping it to scale to higher rates of change.
After each mainline 2.6 release, the kernel’s “stable team” (currently Greg Kroah-Hartman) takes up short-term maintenance, applying important fixes as they are developed. The stable process ensures that important fixes are made available to distributors and users and that they are incorporated into future mainline releases as well. The stable maintenance period lasts a minimum of one development cycle and, for specific kernel releases, can go significantly longer; some stable update statistics will be provided below.

2.6. X Kernel Tree
The kernel tree is in the charge of Linus Torvalds, here is the development process:
Once a new kernel is released, a period of two weeks is open for other maintainers to deliver Linus important enhancement patches, which had saved in –mm kernel for a while. Usually the patches are committed with GIT (Find more information, please refer to http://git.or.cz) as well as more general patches. After that, one fresh –rc1 kernel would be published, and then only patches do not increase new features for the kernel will be added in taking stability into account. However, if the changes were independent, wouldn’t affect other code in regression test, they would be adopted. After the release, the patches should be sent to Linus by GIT as well as uploaded in public e-mail list for censorship.
If Linus confirmed that the current GIT tree was under the reasonable wholesome status for testing, the new -rc would be released, and aiming at release once a week till the kernel are generally recognized, the whole period lasts about six weeks.

2.6.X.Y – stable Kernel Tree
The version embraces four digits is a table one, which has included some relative minor but significant fixes. These fixes focus on security issues or important regression update in one specified 2.6.x kernel version.
It is the version recommended for those users who want to apply the latest stable kernel and have no interest in helping improve developer/test release. Without 2.6.x.y, the 2.6.x should be the most stable one. The 2.6.x.y version is maintained by the “stable” team and released once a week. The file called “stable-kernel-rules.txt” describes the acceptable changes for stable tree as well as the release workflow.

2.6.x GIT patches
Being current status, these are daily snapshot for Linus kernel tree managed in GIT and published each day. The patches are more experimental than –rc kernel, because they are generated automatically, nobody even glance at it to check the status.

2.6.x –mm Kernel Patches
These are experimental kernel patches published by Andrew Morton. He obtains all kernel trees and patches from sub-systems as well as the ones from the mail list of linux-kernel, and then combines them together to form a tree that demonstrates the value of new features and patches. If one patch was verified itself in –mm tree, it would be passed on to Linus by Andrew or sub-system maintainers on the purpose of being merged into main kernel. It is strongly recommended that each new patch be tested in –mm tree before delivering to Linus. However, the kernel with such kind of patches does not match the steady system, for it would induce much more risks. Differ with other kinds of kernel, and there is no constant release plan for –mm kernel. However, the –mm releases still come out during the break of every two –rc releases.

Version Control:
Version Number Regulation: Previously, for the no. with four separated digits, take 2.6.32.9 for example, the second digit 6 is an even number, which means the version is a stable one. But for now, there is no such kind of thing; both even and odd number would stand for a stable version. If a version is followed with rc (Release Candidate), that means this one should be gone through test for stability.

Here we also stick one stanza from Wikipedia about the revision control.
Revision control The Linux kernel source code used to be maintained without the help of an automated source code management system, mostly because of Linus Torvalds' dislike of centralized SCM systems.
In 2002, Linux kernel development switched to BitKeeper, a SCM system which satisfied Linus Torvalds' technical requirements. BitKeeper was made available to Linus and several others free of charge, but was not free software, which was a source of controversy. The system did provide some interoperability with free SCM systems such as CVS and Subversion.
In April 2005, however, efforts to reverse-engineer the BitKeeper system by Andrew Tridgell led BitMover, the company which maintained BitKeeper, to stop supporting the Linux development community. In response, Linus Torvalds and others wrote a new source code control system for the purpose, called Git. The new system was written within weeks, and in two months the first official kernel release was made using git. Git soon developed into a separate project in its own right and gained wider adoption in the free software community.

Maintain:
Linux kernel is maintained by Linus Torvalds, varied from FreeBSD, which is maintained by specified people (the one had been determined two years ago by selection). But as the kernel has matured, Linus has delegated maintenance for older stable versions to others, while he continues development the latest “bleeding edge” release. As of 27-May-2002, the following kernel versions are maintained by these people:
David Weinehall tao@acc.umu.se
Alan Cox alan@lxorguk.ukuu.org.uk
Marcelo Tosatti mtosatti@redhat.com
Linus Torvalds Torvalds@osdl.org
For other maintainers, it can be referred to wiki.

Eclipse:

These paragraphs are excerpted from eclipse official website. And the well-organized description depicts the detail development process of eclipse from initiation to release.

1 Mentors
New Proposals that intend to do a Release are required to have at least two Mentors. New Proposals that will only Release code as part of a parent Project's Release are not required to have Mentors. Mentors must be members of the Architecture Council. The Mentors (including name, affiliation, and current Eclipse projects/roles) must be listed in the Proposal. Mentors are required to monitor and advise the new Project during its Incubation Phase, but are released from that duty once the Project graduates to the Mature Phase.

2 Project Lifecycle
Projects go through six distinct phases. The transitions from phase to phase are open and transparent public reviews.

2.1 Pre-proposal
An individual or group of individuals declares their interest in, and rationale for, establishing a project. The EMO will assist such groups in the preparation of a project Proposal.
The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.

2.2 Proposal
The proposers, in conjunction with the destination PMC and the community, collaborate in public to enhance, refine, and clarify the proposal. Mentors (if necessary) for the project must be identified during this phase.
The Proposal phase ends with a Creation Review, or withdrawal.
The Proposal may be withdrawn by the proposers.
The EMO(ED) will withdraw a proposal that has been inactive for more than six months.

2.3 Incubation
The purpose of the incubation phase is to establish a fully-functioning open-source project. Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience - the incubation phase is not about changing those successful practices, but rather it is about developing the additional practices that create an open, transparent, welcoming, and predictable open-source project.
After the project has been created, the purpose of the incubation phase is to establish a fully-functioning open-source project. In this context, incubation is about developing the process, the community, and the technology. Incubation is a phase rather than a place: new projects may be incubated under any existing Project.
The Incubation phase may continue with a Continuation Review or a Release Review.
Top-Level Projects cannot be incubated and can only be created from one or more existing Mature-phase Projects.
The Incubation phase ends with a Graduation Review or a Termination Review.
Designated Incubator Projects may remain perpetually in the Incubation phase; no reviews are required.
Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience. This document attempts to define a process that is sufficiently flexible to learn from all its participants. At the same time, however, the Incubation phase is useful for new Projects to learn the community-defined Eclipse-centric open source processes.
Only projects that are properly identified as being in the incubation phase (including designated Incubator Projects) may use the Parallel IP process to reduce IP clearance process for new contributions.

2.4 Mature
The project team has demonstrated that they are an open-source project with an open and transparent process; an actively involved and growing community; and Eclipse Quality technology. The project is now a mature member of the Eclipse Community. Major releases continue to go through Release Reviews.
Mature phase projects have Releases through Release Reviews.
A Mature Project may be promoted to a Top-Level Project through a Promotion Review.
A Mature Project that does not participate in a Release in given year may continue through a Continuation Review.
Inactive Mature phase projects may be archived through a Termination Review.

2.5 Top-Level
Projects that have demonstrated the characteristics of a Top-Level Project (e.g., consistent leadership in a technical area and the recruitment of a wider developer community) can be promoted to Top-Level Project status. This promotion occurs through a Promotion Review. Upon the successful completion of a Promotion Review, the EMO(ED) may recommend that the project be promoted to the Board of Directors and ask that its Charter be reviewed and approved.

2.6 Archived
Projects that become inactive, either through dwindling resources or by reaching their natural conclusion, are archived. Projects can reach their natural conclusion in a number of ways: for example, a project might become so popular that it is absorbed into one of the other major frameworks. Projects are moved to Archived status through a Termination Review.
If there is sufficient community interest in reactivating an Archived Project, the Project will start again with Creation Review. As there must be good reasons to have moved a Project to the Archives, the Creation Review provides a sufficiently high bar to prove that those reasons are no longer valid. It also ensures that the original or updated project goals are still consistent with the Purposes and Roadmap.

3 Reviews
This iteration of the document removes the notion of a "review call" in favour of a "review period" during which the community is given an opportunity to comment. This acknowledges the reality that the optional review calls required by the previous version of this document never actually occurred. Given that there will be no review calls, references to "slides" have been removed.
The Eclipse Development Process is predicated on open and transparent behavior. All major changes to Eclipse projects must be announced and reviewed by the membership-at-large. Major changes include the Project Phase transitions as well as the introduction or exclusion of significant new technology or capability. It is a clear requirement of this document that members who are monitoring the appropriate media channels (e.g., mailing lists or RSS feeds) not be surprised by the post-facto actions of the Projects.
All Projects are required to participate in at least one Review per year.

For each Review, the project leadership makes a presentation to, and receives feedback from, the Eclipse membership.

A Review is a fairly comprehensive process. Gathering the material for a Review and preparing the presentation is a non-trivial effort, but the introspection offered by this exercise is useful for the Project and results are very useful for the entire Eclipse community. In addition, Reviews have a specific relationship to the requirements of the Eclipse IP Policy.
All Reviews have the same general process: 1. Projects are responsible for initiating the appropriate reviews. However, if a Project does not do so and the EMO believes a Review is necessary, the EMO may initiate a Review on the Project's behalf. 2. A Review then continues with the Project's Leadership requesting that the EMO(ED) schedule the Review. 3. Prior to the start of the review period, the Project leadership provides the EMO with review documentation. * The review documentation material always includes a document that describes the review. The minimum contents of the document are specified by the individual Review types. * The presentation material must be available in a format that anyone in the Eclipse membership can review. For example, Microsoft Powerpoint files are not an acceptable single format: such files may be one of the formats, but not the only format. Similarly for Apple Keynote files and Microsoft Word files. PDF and HTML are acceptable single formats. * The presentation material must have a correct copyright statement and license. * The presentation material must be archival quality. This means that the materials must be comprehensible and complete on their own without requiring explanation by a human presenter, reference to a wiki, or to other non-archived web pages. 4. The EMO announces the Review schedule and makes the documentation available to the membership-at-large.
The criteria for the successful completion of each type of Review will be documented in writing by the EMO in guidelines made available via the www.eclipse.org website. Such guidelines will include, but are not limited to the following: 1. Clear evidence that the project has vibrant committer, adopter and user communities as appropriate for the type of Review. 2. Reasonable diversity in its committer population as appropriate for the type of Review. Diversity status must be provided not only as number of people/companies, but also in terms of effort provided by those people/companies. 3. Documented completion of all required due diligence under the Eclipse IP Policy. 4. For Continuation, Graduation and Release Reviews, the project must have a current project plan, in the format specified by the EMO, available to the community. 5. Balanced progress in creating both frameworks and extensible, exemplary tools. 6. Showcase the project's quality through project-team chosen metrics and measures, e.g., coupling, cyclomatic complexity, test/code coverage, documentation of extensions points, etc.
The Review period is open for no less than one week and usually no more than two weeks of generally accepted business days. 1. The Review begins with the EMO's posting of the review materials at the start of the Review period 2. The proper functioning of the Eclipse Development Process is contingent on the active participation of the Eclipse Members and Committers, especially in Reviews, thus each Review has an EMO-designated discussion and feedback communication channel: a forum/newgroup, a mailing list, or some other public forum. 3. If a Committer election is required for a Review (for example, for a Creation Review), then it is held simultaneously with the Review period. Thus the election and the Review will end at the same time, allowing quick and efficient provisioning of the resulting Project. 4. The EMO(ED) approves or fails the Review based on the public comments, the scope of the Project, and the Purposes of the Eclipse Foundation as defined in the Bylaws. 5. The Review ends with the announcement of the results in the defined Review communication channel (the EMO(ED) will request that the Project Lead make this announcement).
If any Member believes that the EMO has acted incorrectly in approving or failing a Review may appeal to the Board to review the EMO's decision.

3.1 Creation Review
See guidelines and checklists about Creation Reviews.
The purpose of the Creation Review is to assess the community and membership response to the proposal, to verify that appropriate resources are available for the project to achieve its plan, and to serve as a committer election for the project's initial Committers. The Eclipse Foundation strives not to be a repository of "code dumps" and thus projects must be sufficiently staffed for forward progress.
The Creation Review documents must include short nomination bios of the proposed initial committers. These bios should discuss their relationship to, and history with, the incoming code and/or their involvement with the area/technologies covered by the proposal. The goal is to help keep any legacy contributors connected to new project and explain that connection to the current and future Eclipse membership, as well as justify the initial Committers' participation in a meritocracy.

3.2 Graduation Review
See guidelines and checklists about Graduation Reviews.
The purpose of the Graduation Review is to confirm that the Project is/has: * a working and demonstrable code base of sufficiently high quality * active and sufficiently diverse communities appropriate to the size of the graduating code base: adopters, developers, and users * operating fully in the open following the Principles and Purposes of Eclipse * a credit to Eclipse and is functioning well within the larger Eclipse community

The Graduation Review is about the phase change from Incubation Phase to Mature Phase. If the Project and/or some of its code is simultaneously relocating to another Project, the Graduation Review will be combined with a Restructuring Review.

3.3 Release Review
See guidelines and checklists about Release Reviews.
The purposes of a Release Review are: to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the Principles and Purposes of Eclipse.

3.4 Promotion Review
The purpose of a Promotion Review is to determine if the Project has demonstrated the characteristics of a Top-Level Project, e.g., consistent leadership in a technical area and the recruitment of a wider developer community. The Project will already be a well-functioning Mature Eclipse Project, so evidence to the contrary will be a negative for promotion. Top-Level Projects, both through their existence and their Council memberships, have substantial influence over direction and operation of Eclipse, thus it behooves the membership to grant Top-Level status only for merit: for demonstrated service to the larger Eclipse ecosystem.

3.5 Continuation Review
The purpose of a Continuation Review is to verify that a Proposal or Project continues to be a viable effort and a credit to Eclipse. The Project team will be expected to explain the recent technical progress and to demonstrate sufficient adopter, developer, and user support for the Project. The goal of the Continuation Review is to avoid having inactive projects looking promising but never actually delivering extensible frameworks and exemplary tools to the ecosystem.

3.6 Termination Review
See Termination Review "How To" for more information.
The purpose of a Termination Review is to provide a final opportunity for the Committers and/or Eclipse membership to discuss the proposed withdrawal of a Proposal or archiving of a Project. The desired outcome is to find sufficient evidence of renewed interest and resources in keeping the Project or Proposal active.

3.7 Move Review
A Move Review is considered to be a special type ofRestructuring Review.

3.8 Restructuring Review
The purpose of a Restructuring Review is to notify the community of your intent to make significant changes to one or more projects. "Significant changes" includes: * Movement of significant chunks of functionality from one project to another; * Modification of the project structure, e.g. combining multiple projects into a single project, or decomposing a single project into multiple projects; and/or * Change of project scope.
A Restructuring Review may include the movement of significant chunks of code. A move is considered significant if it has an impact on the community (i.e. if segments of the community will notice that the code has moved). This may include entire projects, bundles, and features, but likely excludes small fragments, code snippets and individual files. The IP Log of all moved code must be reviewed prior to the start of the review period (this, typically, is a subset of the project's IP Log). If all of the code is moved out of a project, a Termination Review for that project can be combined with the Restructuring Review.
Note that, regardless of whether or not a review is required, moving code from one Project to another is subject to the Eclipse IP Policy.
A Restructuring Review may necessitate the construction of one or more new projects. This tends to occur when an existing project is decomposed into two or more projects. In this case, a Restructuring Review is similar to a Creation Review. Any new projects that are created as part of a Restructuring Review must have their scope explicitly specified as part of the review. The scope of any new project must be a subset of the scope of the original project. Likewise, the set of committers assigned to a new project must be a subset of the committers of the original project (additional committers can be elected to the new project after it is created). Any new projects that fall outside of the scope of the original project, or wish to establish a different set of committers, must undergo the full project creation process.
Committers can be moved along with code into a new project as part of the project provisioning process. Committers cannot be moved along with code into an existing project. In this case, the existing project must elect the new committers into the project.
A project is expected to socialize pending changes using established communication channels prior to initiating the review. A Restructuring Review must provide the community with at least one week to review and respond to the changes. Prior to the start of that review period, the community must be provided with (via the EMO) completed review documentation that describes in specific terms what will be changed as part of the restructuring.
This may include: * Name, description, scope, and committer lists of new projects that need to be created; * Source and target locations for moves of source code directories; * Reorganization of builds and downloads; * Contribution questionnaires (CQs) that need to be moved or piggy-back CQs that must be created; * Location of the approved IP Log; and * Other information that helps the community understand the change.

3.9 Combining Reviews
This section has been modified to explicitly allow multiple projects to participate in a single. It is possible, for example, for a project and its descendants to engage in a simultaneous Release Review.
Reviews can be combined at the discretion of the PMC and EMO. Multiple Projects may participate in a single Review. Similarly, multiple review types can be engaged in simultaneously. A parent Project may, for example, engage in an aggregated Release Review involving itself and some or all of its child projects; a consolidated Restructuring Review may move the code for several projects; or a Release Review may be combined with a Graduation Review. When multiple reviews are combined, the review documentation must explicitly state all of the Projects and types of reviews involved, and include the required information about each.
It should be noted that the purpose of combining reviews is to better serve the community, rather than to reduce effort on the part of the project (though it is fortunate when it does both). Combining a Release and Graduation review, or aggregating a Release Review of a Project and several of it's child Projects generally makes sense. Combining Release Reviews for multiple unrelated projects most likely does not.

4 Releases
(Most of this section is borrowed and paraphrased from the excellent Apache Software Foundation Releases FAQ. The Eclipse community has many of the same beliefs about Releases as does the Apache community and their words were already excellent. The Apache Software Foundation Releases FAQ is distributed under the Apache License, Version 2.0.)
Releases are, by definition, anything that is distributed outside of the Committers of a Project. If users are being directed to download a build, then that build has been released (modulo the exceptions below). All Projects and Committers must obey the Eclipse Foundation requirements on approving any release.
(Exception 1: nightly and integration builds)During the process of developing software and preparing a Release, various nightly and integration builds are made available to the developer community for testing purposes. Do not include any links on the project website, blogs, wikis, etc. that might encourage non-early-adopters to download and use nightly builds, release candidates, or any other similar package (links aimed at early-adopters and the project's developers are both permitted and encouraged). The only people who are supposed to know about such packages are the people following the developer mailing list and thus are aware of the limitations of such builds.
(Exception 2: milestone and release candidate builds)Projects are encouraged to use an agile development process including regular milestones (for example, six week milestones). Milestones and release candidates are "almost releases" intended for adoption and testing by early adopters. Projects are allowed to have links on the project website, blogs, wikis, etc. to encourage these outside-the-committer-circle early adopters to download and test the milestones and release candidates, but such communications must include caveats explaining that these are not official Releases. * Milestones are to be labeled x.yMz, e.g., 2.3M1 (milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version 2.3), etc. * Release candidates are to be labeled x.yRCz, e.g., 2.3RC1 (release candidate 1 towards version 2.3). * Official Releases are the only downloads allowed to be labeled with x.y, e.g., 0.5, 1.0, 2.3, etc.
All official Releases must have a successful Release Review before being made available for download.
(Exception 3: bug fix releases with no new features)Bug fix releases (x.y.z, e.g., 2.3.1) with no new features over the base release (e.g., 2.3) are allowed to be released without an additional Release Review. If a bug fix release contains new features, then the Project must have a full Release Review.
Under no circumstances are builds and milestones to be used as a substitute for doing proper official Releases. Proper Release management and reviews is a key aspect of Eclipse Quality.

5 Grievance Handling
When a Member has a concern about a Project, the Member will raise that concern with the Project's Leadership. If the Member is not satisfied with the result, the Member can raise the concern with the parent Project's Leadership. The Member can continue appeals up the Project Leadership Chain and, if still not satisfied, thence to the EMO, then the Executive Director, and finally to the Board. All appeals and discussions will abide by the Guiding Principles of being open, transparent, and public.
Member concerns may include: * Out of Scope. It is alleged that a Project is exceeding its approved scope. * Inconsistent with Purposes. It is alleged that a Project is inconsistent with the Roadmap and/or Purposes. * Dysfunctional. It is alleged that a Project is not functioning correctly or is in violation of one or more requirements of the Development Process. * Contributor Appeal. It is alleged that a Contributor who desires to be a Committer is not being treated fairly. * Invalid Veto. It is alleged that a -1 vote on a Review is not in the interests of the Project and/or of Eclipse.
A variety of grievance resolutions are available to the EMO up to, and including, rebooting or restarting a project with new Committers and leadership.

Digital Asset Commander 2.0 & 2.1

* Roles and Responsibilities
These versions were the transplantations from JAVA to .NET platform. For there was no integrate specific requirement, we all had to comprehend and figure out the features as well as business logic by venturing the old version thoroughly at first. Everyone has equivalent responsibility to the software quality

* Identifying, Assigning and Performing Work
Development process was extended under the SCRUM mode. The project manager discussed with leaders for the coming features to accomplish at the beginning of the new iteration, maybe one or two weeks. The developers and the tester evaluate working time, and all began conceiving the technical details or basic test scenarios according to the iteration features analyzed by manager, leader and the stake owners. The features would be pre-defined or anything newly created. Because we just embrace the changes.
If needed, we would present our quick understanding in a meeting and double-check in order to enhance the correctness and diminish inconsistent comprehension about business logic between us.
And then, developers and testers work separately on their own. During the concurrent development, TFS and VS 2008 played the role of CVS. The developers wouldn’t check in their code until the features in charged were fully developed. Even before that, they would shelve the new code for code review by the development leader.
Test would be implemented once the software was workable with a few even only one new feature after unit test. And bugs were recorded in TFS, which integrate the whole bug life cycle functions, so that we all could track defects in it. Since we accumulate the software quality with each small step on, and don’t proceed until no road block and critical defects were eliminated. Hence the software wouldn’t be bothered by critical crash induced by different modules integration.

* Inspecting and Managing the release
The stake owners would inspect the software periodically, and if he thought all features pre-conceived were accomplished, the software should be able to release that time. But actually, we still have one or two leaders with most experience got involved in controlling the final code check-in at real release moments.

Q2: How many people wrote code for new functionality? How many people reported problems? How many people repaired defects?
By now, we haven’t found the specified data about people who wrote new functionality for open source software, but the number of people who contributed changes to them from some papers.

Linux Kernel

For this question, we found a paper named “Linux Kernel Development” from The Linux Foundation. And here’s the picture from that. Take the example of version 2.6.32, we can see that there were 1248 developers who committed the code and the contributors dedicated increased by each version.

（Page 11 in passage lf_linux_kernel_development_2010）

The Linux bug tracking system is Bugzilla. By using it, we can track the bug status, and generate graphs.
However, it is hard to objectively accumulate the number of people who report or fix defects from Bugzilla. And search this data is not realistic in such period of time.

Eclipse

Each Project has a Development Team, led by the Project Leaders. The Development Team is composed of Committers and Contributors. Contributors are individuals who contribute code, fixes, tests, documentation, or other work that is part of the Project. Committers have write access to the Project's resources (source code repository, bug tracking system, website, build server, downloads, etc.) and are expected to influence the Project's development.
Below table is the statistics of changes submitted from 2004 to 2011 on the website.

Digital Asset Commander 2.0 & 2.1
There were 4 developers wrote code for new functionalities. One tester reported problems, and team leader also participate and play this role sometimes. All developers were responsible for the defects appeared in their own code.

Q3: Did large numbers of people participate somewhat equally in these activities, or did a small number of people do most of the work?
For this part, we just referenced various papers for statistics on the two open source software.

Linux Kernel
This excerpt is from page 11 of lf_linux_kernel_development_2010.

Despite the large number of individual developers, there is still a relatively small number who are doing the majority of the work. In any given development cycle, approximately 1/3 of the developers involved contribute exactly one patch
I just statistic the data, and figure out the proportion of first 10 developers who submit the code took the proportion of 1.3%+1.2%+1.2%+1.1%+1.1%+1.0%+1.0%+0.9%+0.8%+0.8% = 10.4%, 17.4% for the first 20 developers’, and 22.6% for the first 30 developers’.

So, it could be inferred that it was indeed a small number of people doing most work. However, no single developer did the large quantity of work.

Eclipse

There are did a small number of people do most of the modify work, such as correct the problem, and write new function, now I just list some people in the View

The picture shows the developer percentage in eclipse.

Digital Asset Commander 2.0 & 2.1

Yes, there was a core developer who did the most of the work, appropriate 55%. That proportion mainly depended on the coding ability and their familiarity with business logic at first. The developer that
The chart below shows features distribution.

52 out of 90 features were developed by the core developer, who was in charge of the main parts and the whole framework style design.

Q4: Was strict code ownership enforced on a file or module level?

Linux Kernel

The file “MAINTAINERS”, can be found in the top root directory after distracting kernel source code. Below it exhibits some content of it, which list regulations for testing, committing code and code style.

Please try to follow the guidelines below. This will make things easier on the maintainers. Not all of these guidelines matter for every trivial patch so apply some common sense.

1. Always _test_ your changes, however small, on at least 4 or 5 people, preferably many more.
2. Try to release a few ALPHA test versions to the net. Announce them onto the kernel channel and await results. This is especially important for device drivers, because often that's the only way you will find things like the fact version 3 firmware needs a magic fix you didn't know about, or some clown changed the chips on a board and not its name. (Don't laugh! Look at the SMC ether power for that.)
3. Make sure your changes compile correctly in multiple configurations. In particular check that changes work both as a module and built into the kernel.
4. When you are happy with a change make it generally available for testing and await feedback.
5. Make a patch available to the relevant maintainer in the list. Use 'diff -u' to make the patch easy to merge. Be prepared to get your changes sent back with seemingly silly requests about formatting and variable names. These aren't as silly as they seem. One job the maintainers (and especially Linus) do is to keep things looking the same. Sometimes this means that the clever hack in your driver to get around a problem actually needs to become a generalized kernel feature ready for next time. PLEASE check your patch with the automated style checker (scripts/checkpatch.pl) to catch trival style violations. See Documentation/CodingStyle for guidance here.PLEASE CC: the maintainers and mailing lists that are generated by scripts/get_maintainer.pl.The results returned by the script will be best if you have git installed and are making your changes in a branch derived from Linus' latest git tree. See Documentation/SubmittingPatches for details. PLEASE try to include any credit lines you want added with the patch. It avoids people being missed off by mistake and makes it easier to know who wants adding and who doesn't.
PLEASE document known bugs. If it doesn't work for everything or does something very odd once a month document it. PLEASE remember that submissions must be made under the terms of the OSDL certificate of contribution and should include a Signed-off-by: line. The current version of this "Developer's Certificate of Origin" (DCO) is listed in the file Documentation/SubmittingPatches.
6. Make sure you have the right to send any changes you make. If you do changes at work you may find your employer owns the patch not you.
7. When sending security related changes or reports to a maintainer please Cc: security@kernel.org, especially if the maintainer does not respond.
8. Happy hacking.

From regulation No. 6 and 7, we can figure out that for Linux kernel, there is no strict code ownership. Everyone involved in Linux kernel is encouraged to contribute meaningful changes without consider too much about who initiate the files and code. However, the rules vary between commercial and open source. If the changes were marked with company rights, changes might not be authorized sent to community.

Eclipse

Yes, it was. We excerpted one paragraph from internet. By reading it through, we can find the answer.
What do we want to achieve by explicit code ownership?
Integrity of the Design: The owner is responsible for a solid extensible design. People other than the owner can make bug fixes, but please let the owner know. Don't make design-breaking changes without letting the owner know. Typically, there is a single owner for each function. Multiple "two-in-a-box" owners are only possible if they work very closely together. There may be a backup person for an owner, in case the owner is out-of-office.
Timely Bug Triage: The owner is responsible for reviewing (and probably reassigning) bugs of his area in a timely fashion. He helps dispatching new bugs to component owners first. Ownership can be for functionality that spans multiple packages (if functionality is seen by user as a single entity).
Credit for Quality through Visibility.
Owners of a component should be publicly visible, so they can get the credit for good work.
Ownership of Copyright and Intellectual Property (IP) issues.
Component owners are responsible for keeping the IP of their component clean.
The table below shows the Eclipse ownership of explicit person.

Code Ownership Table Owner | Area | Plugin/Package | Backup owner | Dave Dykstal
(IBM) | RSE Persistency | org.eclipse.rse.core/persistence org.eclipse.rse.core/src/org.eclipse.rse.core.filters (persistence aspects) org.eclipse.rse.core/src/org.eclipse.rse.core.model (persistence aspects) org.eclipse.rse.core/src/org.eclipse.rse.core.persistance org.eclipse.rse.core/src/org.eclipse.rse.core.references (persistence aspects) org.eclipse.rse.core/src/org.eclipse.rse.internal.references (persistence aspects) org.eclipse.rse.ui/filters (persistence aspects) org.eclipse.rse.ui/model (persistence aspects) org.eclipse.rse.ui/subsystems (persistence aspects) org.eclipse.rse.ui/systems (persistence aspects) | Xuan Chen | | RSE password prompt | org.eclipse.rse.core/src/org.eclipse.rse.core.subsystems (credential aspects) org.eclipse.rse.ui/src/org.eclipse.rse.core.subsystems (credential aspects) org.eclipse.rse.ui/UI/org.eclipse.rse.ui.dialogs (credential aspects) | | | RSE logging | org.eclipse.rse.logging - all packages | Xuan Chen | | RSE message support | /org.eclipse.rse.services/clientserver/org.eclipse.rse.services.clientserver.messages org.eclipse.rse.ui/UI/org.eclipse.rse.ui.messages | | | RSE filtering | org.eclipse.rse.core/src/org.eclipse.rse.core.filters org.eclipse.rse.ui/filters org.eclipse.rse.ui/UI/org.eclipse.rse.ui.propertypages - classes for filters | | | Dialog Accessibility / UI Controls | org.eclipse.rse.ui/UI/org.eclipse.rse.ui.Mnemonics org.eclipse.rse.ui/UI/org.eclipse.rse.ui.widgets.InheritButton org.eclipse.rse.ui/UI/org.eclipse.rse.ui.widgets.SystemHistoryCombo org.eclipse.rse.ui - accessibility aspects | | | RSE Documentation | org.eclipse.dstore.doc.isv org.eclipse.rse.doc.user org.eclipse.rse.doc.isv | Martin O | | RSE JUnit tests | org.eclipse.rse.tests org.eclipse.rse.tests.framework org.eclipse.rse.tests.framework.examples | Xuan Chen | Dave McKnight
(IBM) | RSE dstore | org.eclipse.dstore.core org.eclipse.dstore.extra org.eclipse.rse.connectorservice.dstore org.eclipse.rse.dstore.security org.eclipse.rse.services.dstore org.eclipse.rse.subsystems.files.dstore org.eclipse.rse.subsystems.processes.dstore org.eclipse.rse.subsystems.shells.dstore | Xuan Chen | | RSE services | org.eclipse.rse.services.files org.eclipse.rse.services.processes org.eclipse.rse.services.search org.eclipse.rse.services.shells | Xuan Chen | | RSE core model | org.eclipse.rse.core org.eclipse.rse.core.filters org.eclipse.rse.core.model org.eclipse.rse.core.subsystems org.eclipse.rse.subsystems.files.core org.eclipse.rse.subsystems.processes.core org.eclipse.rse.subsystems.shells.core | | | RSE views | org.eclipse.rse.ui.view org.eclipse.rse.ui.view.monitor org.eclipse.rse.ui.view.scratchpad org.eclipse.rse.ui.view.search org.eclipse.rse.ui.view.team org.eclipse.rse.ui.widgets org.eclipse.rse.ui.widgets.services | | Kushal Munir, Xuan Chen
(IBM) | RSE Archive Handlers | org.eclipse.rse.services.clientserver.archivehandlers | | | RSE core comm | org.eclipse.rse.core.comm | | | RSE search | org.eclipse.rse.files.ui.search org.eclipse.rse.ui.view.search | | | RSE file encodings | (multiple) | | Uwe Stieber
(Wind River) | RSE New Connection Wizard | org.eclipse.rse.ui/org.eclipse.rse.ui.wizardsorg.eclipse.rse.ui/org.eclipse.rse.ui.wizards.newconnection org.eclipse.rse.ui/org.eclipse.rse.ui.wizards.registries | Kushal Munir | | | | | Martin Oberhuber
(Wind River) | | | | | RSE ssh | org.eclipse.rse.connectorservice.ssh org.eclipse.rse.services.ssh org.eclipse.rse.ssh-feature org.eclipse.rse.subsystems.files.ssh org.eclipse.rse.subsystems.shells.ssh | | | RSE local | org.eclipse.rse.connectorservice.local org.eclipse.rse.local-feature org.eclipse.rse.services.local org.eclipse.rse.subsystems.files.local org.eclipse.rse.subsystems.processes.local org.eclipse.rse.subsystems.shells.local | Kushal Munir | | RSE examples | org.eclipse.rse.examples.daytime org.eclipse.rse.examples.tutorial | Dave Dykstal | | RSE content assist | org.eclipse.rse.shells.ui/org.eclipse.rse.shells.ui.view | Dave McKnight | | RSE nightly builds,
Legal docs (about files, licenses),
Update Site, build notes | org.eclipse.rse.build org.eclipse.rse.core-feature org.eclipse.rse.dstore-feature org.eclipse.rse.efs-feature org.eclipse.rse.examples-feature org.eclipse.rse.remotecdt-feature org.eclipse.rse.sdk org.eclipse.rse.sdk-feature org.eclipse.rse.releng.infocenter org.eclipse.rse.updatesite | Ted Williams,
Dave Dykstal | | Third Party Libs
(Jakarta Commons Net, ORO) | org.eclipse.tm.core/thirdparty/* | Dave Dykstal | | RSE manual tests | org.eclipse.rse.tests.manual | | | | | | Javier Montalvo
(Symbian) | Discovery | (org.eclipse.tm.core) discovery/* | | | RSE ftp | org.eclipse.rse.ftp-feature org.eclipse.rse.services.files.ftp org.eclipse.rse.subsystems.files.ftp | Dave McKnight,
Martin Oberhuber</tr> | Michael Scharf
(Wind River) | Terminalview | (org.eclipse.tm.core) terminal/* | Ted Williams | Ewa Matejska
(ACCESS) | CDT Remote Launch | org.eclipse.rse.remotecdt | Martin Oberhuber | Radoslav Gerganov
(ProSyst) | WinCE subsystems | org.eclipse.tm.core/wince/* | Martin Oberhuber | Anna Dushistova
(MontaVista) | RSE terminal subsystems | org.eclipse.rse.terminal.* | Martin Oberhuber |

Digital Asset Commander 2.0 & 2.1

The survey from our developers indicates that once new features were added, some common configuration files and framework files affected had to be modified reciprocally. Also the common DLL for public usage may take the proportion of 15% around, which part was always exposed to all developers for modification if needed. For the core developer had constructed the main part structure, the others who were designed to add new features would confront recomposing the corresponding files. These symptoms exhibit the project was not enforced on strict code ownership overall. However, the team still advocated not changes others’ code unless there was no work-around.

Q5: What is the defect density of open source software you studied?

Linux Kernel

Here is the list for open source software bug density. The picture is from the open source quality report generated by Coverity Inc., a software vendor based in San Francisco.

The table makes it obviously, Linux bug density is 0.335.
The statistics should be somehow authorized. And these defect density statistics stands for defect numbers divided by per thousand lines of code, the bug number is induced by adding per thousand lines of code. Coverity Inc. established a baseline for security and quality in open source software based on sophisticated scans of 17.5 million lines of source code using the latest research from Stanford University’s Computer Science department.

Eclipse

We found one paper that calculated defect density by using the method of Lines of Code (LOC): Total lines of code in the selected scope. Only counts non-blank and non-comment lines inside method bodies. It lists the pre-release and post-release bug patterns introduced by developers

Pre-release failures by developer

Post-release failures by developer

Digital Asset Commander 2.0 & 2.1

For this project, testers only use the functionality testing method and couldn’t get the exact code lines for feature changes, and it was hard to calculate the defect density per thousand lines of code. So we use features number multiplied with weight instead of KLOC.
The Commander contains about 30 important features weighed by 5, and 40 medium significant ones weighed by 2, and other 24 less critical ones weighed by 1.
Sum feature size: 30*4+40*3+24*1=264
The total defects found during functionality testing are about 300. The priority of defects ranges from 1 to 4. I also consider the bug number should be weighed and then plus. For p1 defects, the weight should be 4; for p2 ones, the weight should be 2, and for other issues, it should be 2 and 1 respectively.
So, bug number with weight: 30*4+65*3+100*2+105*1=620

So the defect density per feature should be 620/264=2.348.

Q6: How long did it take to resolve problems?
The picture shows the life cycle of a Bugzilla defect. Generally speaking, most defect life cycle can be exhibit in this way. Differences are minor in various bug tracking systems. Especially mentioned, the bug status could be customized in Team Foundation Server as end users’ personalized habits. However, for this question, the overall time of resolution is the key point.

Linux Kernel

As it referred to two passages, it could be obviously concluded that open source software bug life cycle is somehow shorter than the commercial one.
Here is the link of part of the investigation from Evans Data Corporation (EDC) on open source software development. http://www.evansdata.com/reports/viewRelease.php?reportID=7 And the other link on commercial developers. http://advice.cio.com/esther_schindler/enterprise_developers_programming_speed_check_time_to_fix_bu gs_not_so_much

For open-source and Linux
As it happens, Evans Data Corporation (EDC) just finished its twice-yearly report, which is a survey related with several hundred open-source software and Linux developers (with some managers, but primarily folks-who-code). The EDC numbers are somewhat different. The average time between discovery and solution of a serious bug, for 36 percent of open-source developers is under 8 hours. For enterprise developers and software vendors
According to a survey commissioned by BMC and conducted by the consulting division of Forrester Research, the average time to resolve an application problem is 6.9 days for enterprise developers and 6.7 days for software vendors. “Ten percent of those problems take 10 days to solve”, says the report. Developers spend just over an hour documenting the problem; and, if given that hour back, they'd use it to create enhancements to the application they are working on.

Reasons for the difference:
One difference between the results may be the survey respondent. The developers on the ground, writing the code, are likely to have different opinions than do their managers. For example, managers have a different idea of proper process (or, depending on viewpoint, CYA requirements); in the Forrester/BMC study, 45 percent of respondents required more than an hour to create a problem report. In the open-source community, a bug report could be a casual conversation in an IRC channel with the developer responsible for that code module.
Another issue is the granularity of what's considered a problem. Developers, by nature, think tactically and with great specificity ("the calendar doesn't display right in IE; the fields are overlaid instead of in an ordered list") compared to a manager's strategic viewpoint ("transaction speed slows down when the database has over 100,000 records") or the users' vague view when passed through a manager's translation mechanism ("Accounting says it doesn't work right; please fix").

Eclipse

The specified bug could be tracked from Bugzilla. By summing up the time of each status from “New” to “Closed” or “Resolved”, the bug resolution period can be figured out.
But it is obviously a huge amount of work to find out so many details manually. Some paper introduced the tool called “Weka” for data mining. It can either process the local data file or from a link to access SQL database (using JDBC).
The table below is the result by that way for eclipse.

Digital Asset Commander 2.0 & 2.1

Agile development project has the characteristics of sequential iterations, so the critical defects that affect software work normally would be fixed immediately found, usually it took less than 6 hours. And others would be resolved until the developers were freed from new features development in next iterations. Despite those hard to identify and new enhancement, all defects had been resolved in two or three iterations since they were reported.
The chart below shows the relationship between bug fixed number and its life time from the status of “New” to “Closed”. The data is accumulated from Team Foundation Server.

Conclusion
This document collects information of the whole process of Linux, eclipse and Digital Asset Commander. By comparing these, it is not hard to observe that the open source software development process is well-organized in spite of large number of participants. However it’s not a unique flash point, the quality of open source software is also competitive with many commercial ones. Every coin has two sides. Due to the huge organization and part-time participants of the open source software, it might take some more time to fix bugs and release. And the work styles are not so flexible to frequent requirement changes comparing to the agile development model. Nonetheless, the open source software attract so many technical person involved, for its appealing meaning of sharing and disseminating the knowledge. Each participant is driven by his own interest and longing for technical knowledge. The purpose is more pure, hence more enthusiasm is stimulated inside. That should be the explanation of the prosperity of open source software.