Figure 1 - NetBeans Project Architecture
Web-based OSSD communities provide unique and interesting opportunities for process modeling based on hypermedia documents in the community’s Web information space. These hypermedia documents serve as artifacts of development that encode information about the agents, activities, resources, and tools in, of, and used by the community to tell a story- the story of how they develop software. By examining the artifacts of development, we can tease out the development process. This paper describes the techniques used in our ongoing efforts to discover and model the software requirements and release process of the NetBeans open source community. Not only do we model the relationships between the hypermedia documents of the community Web, but our models, themselves, are navigable, nonlinear hypermedia expressions of the process selected, as well. Our belief is that the richness provided by interactive hypermedia models will facilitate, enhance, and expedite understanding and analysis of the process we examine as compared to static linear models.
It has been asserted that the way in which open source communities develop software is fundamentally different than their corporate counterparts. Though open source software development (OSSD) projects still require some semblance of system requirements acquisition and a release process, the extent of explicit definition of these varies widely from community to community. Our investigation focuses on analyzing this process in the NetBeans open source community. We explore how new functionality (and non-functionality) proposals are formulated, negotiated, and adopted into NetBeans development, and how these ideas are transformed into a release. In the course of this investigation, we determine modes of communication and collaboration in devising and revising module and release proposals, the factors affecting its acceptance into the community development scheme, and how developers join in contributing to a module's development. We hope to provide a better understanding of the aspects involved in open source community development processes such as those used in the NetBeans community that have allowed them to persist competitively with closed source development by modeling them through hypermedia.
Studies that have been previously done on open source projects have presented a high level overview of the open source development process, as if all open source communities use the same process. However, such is not the case. This study provides an in-depth analysis of the NetBeans open source community's requirements and the release process and serves as evidence of one way that the traditionally asserted process paradigms of so-called “corporate” and “open source” organizations can be successfully merged with the resulting process falling between these two extremes.
Our work is motivated by the potential for insights from software processes used in successful open source projects to leading to a better understanding of the process context in which key factors of this success reside. This understanding, may, in turn lead to insights into management of other loosely coupled, geographically distributed teams. Work has already been done in understanding how software development can be supported in virtual enterprises [30], but it does not highlight how software is developed across organizational boundaries, as is becoming ubiquitous in modern development. With the evolution of software development business models, it has become essential to study examples that have a demonstrated viability in a geographically distributed cross-organizational environment. If the processes, themselves, are also open source artifacts, other they may seed the foundation and incubations of future communities, and guide process configuration and refactoring in existing organizations.
A secondary purpose of this study is to compare current best practices in the “cathedral style” [31] of software development with those of open source communities. Though such studies have been done already, many do not reflect the gamut of communities existing today. The NetBeans community, for example, has been often referred to as a cathedral by its own members as a result of the high degree of influence of Sun. This, in turn, begins to question the very definition of what constitutes an open source community. We want to look at the similarities and differences between the tools, resources, roles, and activities that are being used for development between NetBeans and traditional best-practice closed source development organizations as a way of exploring this question.
In this study, we look at process in terms of what roles are being played in the community, artifacts of development, such as documentation, code, and feedback, the activities in the process, and the tools they use to complete them. In this paper, we will present our findings. We will set the stage with a detailed description of the community as it relates to the requirements and release process. We will then present the process model in terms of the aforementioned roles, tools, and artifacts associated with them, as well as a visualization of this process. Having modeled the process, we offer a semi-formal, structured view of the process, and a sequence of use-cases to interrelate the tools, resources, and actions of the process. We continue with a prototype and by casting our findings into a formal description of the process and conclude with a discussion of our findings.
2. Problem Domain Characterization
NetBeans is an open source community backed by Sun Microsystems [29], devoted to creating both a “world-class” software development environment (IDE) as well as a platform for development of other software products. Originally started as a student project in 1996, the NetBeans project was acquired in October 1999 and subsequently released in June 2000 as an open source community by Sun, whose NetBeans team includes many of the community's core developers. The NetBeans community started when Sun released the code base from Forte for Java Community Edition under an open source license. With the growth of community, the NetBeans code base is now used by Sun to develop the descendent of Forte, the Sun One Studio, a commercial product, in similar fashion to the way Open Office serves as the basis for Sun's Star Office package. NetBeans is divided into two projects - the NetBeans integrated development environment (IDE) and the NetBeans platform. As shown in Figure 1, the IDE is composed of the platform along with the IDE modules. IDE modules include support for a wide array of development technologies including Java, C, and C++, hypertext markup language (HTML), modeling tools for the unified modeling language (UML), XML, database development, refactoring, source and build management, testing. The platform on the other hand has services for user interface management, configuration management, file and storage management, among others.
Figure 1 - NetBeans Project Architecture
With the support of Sun, several dozen third-party corporations, and individual un-sponsored developers, the NetBeans community has been able to meet the requirements of its users and stand up technologically, to the competition in the open-source IDE and platform markets. NetBeans is available for use under the Sun Public License (SPL) by way of Joint Copyright Assignment (JCA), which complies with the open source definition [28]. Although many believe that open source software development is a largely unstructured and unconventional activity conducted by self described "hackers" working at obscene hours of the night, such is not the case with the NetBeans community. On the contrary, with well-defined community standards such code formating and how to submit source to the code repository, the maturity of the NetBeans community is enough to rival many of its strictly corporate counterparts. The challenge, then, is to determine whether the process is followed as asserted, and further, discover the process fragments that have not been asserted, and which may have emerged implicitly, rather than by explicit agreement from the community.
3. A Traditional View of the Software Requirements and Release Process
In this section we describe a view of the traditional, or cathedral, software processes that we examined in the NetBeans community. The traditional requirements and release process typically includes a requirements acquisition phase and a deployment phase. Note that the style asserted here as “traditional” is not necessarily followed as given by all or any corporate. Furthermore, the traditional approach is subject to some variation depending on the needs of the system. This may be as trivial as selecting one of several models for a particular system attribute (e.g. data flow analysis in place of event sequence analysis), or by determining that a particular attribute need not be modeled, analyzed, etc. (e.g. real-time analysis need not be done on a system without real-time operation constraints). Moreover, new, less formal approaches such as extreme programming and other agile methods are being well received. Together with the open source movement, these suggest a shift in what we consider “traditional,” and the success of which may recommend a review of what we consider “correct” software engineering.
A typical requirements engineering process for a high quality, reliable product consists of the following phases as mentioned by experts [40,41,42].
Software developers begin by eliciting requirements, whereby engineers identify all the stakeholders, their goals, needs, expectations and limitations, if any. This activity generally consists of conducting interviews, gathering data through questionnaires, documentation review, focus groups and (driving most commercial product development) market analysis.
The next step in the process of requirements engineering is creating a requirements specification. This document is an attempt to record the functional and non-functional operations and constraints of the system. The functional requirements are often captured in the form of state transition diagrams by identifying states, events, input/output and data. The input and output data (or resources) are sometimes captured in a data specification. The data specification may include data sources, data objects, user displays and so forth. Functional requirements also merit the depiction of the flow of data in the system. The non-functional requirements, on the other hand, specify the constraints on the system. Non-functional requirements might also specify certain goals (performance or otherwise) or capabilities of the system.
Once the initial specification is completed, it must then be analyzed for qualities such as consistency and completeness. Such validation may merely consist of informal sanity checks or comprehensive formal analysis for deadlock, state reachability, simulation and so forth. Functional usability may also be explored at this stage depending on the needs of the customers and foci of the developers. Once the specification passes through this process, it is declared “frozen” and used as the basis for traceability throughout the development lifecycle. Ideally, once the specification is frozen, no major changes may be made, however, in practice (and depending on the level of detail of the specification) revisions are often necessary as new considerations arise during development.
Traditional product development methodology dictates that as development proceeds, system builds are released in three stages. The highly unstable alpha builds are usually released for testing purposes by the developers. These builds usually fully implement the functional requirements of the system and little more. As errors are eliminated the builds stabilize and the system gains the polished look it will have when it is finished. During this beta phase, the system is made available to the client and/or end users to ensure that it meets their needs. In both alpha and beta phases, the system may be subject to several series of automated tests, which often perform boundary checking of input, among other properties. As bugs are corrected, regression tests are performed to ensure that the changes to the code have not created new problems. Eventually, the system is deemed acceptable for use and the release is declared final. Having established a basis for comparison, we will now take a look at the NetBeans community requirements and release process.
4. NetBeans Requirements and Release Process Overview
In this section, we present a high-level overview of the NetBeans requirements and release process. This process is divided into two subprocesses. The requirements subprocess describes the tasks enacted in determining what features should be present in the release, if and what the theme of the release should be (e.g. improving speed, quality, usability), and assigning people and deadlines to project milestones. The release subprocess describes the sequence of events associated with stabilizing and deploying the source. We begin with the requirements subprocess.
The NetBeans NetBeans developers aim to make frequent releases with a current medial release (e.g. 3.x) cycle of approximately nine months as shown in the development roadmaps in Figure 2a and 2b. The first step is to establish a goal date and theme for the release. Based on this theme, and in conjunction with input from the feature request reports filed in the IssueZilla database and incomplete items from the previous release, developers will draft a release plan. From this date, developers can create dates for each milestone of development. These milestones include the feature freeze date, beta, the first release candidate, and final release. This is usually done by the previous release manager, or the more active and politically influential members of the community. Since most releases have been led by Sun's NetBeans team, their marketing and technical experts typically are the community members who assert the theme and goal milestone completion dates. In the event of a non-Sun led release, the more active community members will come to a consensus that a release is necessary to provide what functionality and fix what problems. These members will also be the ones to draft a release plan.
Figure 2a - The NetBeans Roadmap circa 1999-2003
Figure 2b - The NetBeans Roadmap circa 2003-2004
The release plan details the features to be implemented in an upcoming release and their completion status, and target milestone dates. New features are listed by module by priority. Additionally, features descriptions include the expected duration for completion, completion status (updated as development proceeds), impact on the user, dependent features, and individuals responsible for the feature's development. This development plan is then submitted the community for feedback. Such feedback occurs on the nbdev and nbdiscuss mailing lists. Once a consensus is reached, the proposal is revised and resubmitted. While this is a potentially iterative process, a release plan is eventually asserted.
Once a release proposal is asserted, a leading member of the community, historically, the release manager for the previous release, sends out a notice to the mailing lists that the new release has been planned and that the community is in need of a release manager to coordinate development efforts. Following this, a few, usually one, community members volunteer or are nominated by their peers for the job. For a release highly motivated by Sun, a member of Sun's NetBeans team may be volunteered by Sun management. If the individual volunteered is willing to take on the role, he will send a notice of acceptance to the nbdiscuss mailing list, which is then forwarded to the development and announcements mailing lists. Once the release manager has been established, module maintainers for non-core modules are solicited for inclusion in the upcoming release. This is also done by sending an announcement to the mailing lists. Module owners then respond back requesting inclusion in the release. In doing so, they verify that development of their modules will be completed by the feature freeze date, after which only those source submissions that are bug fixes and patches are allowed. This feature freeze date thus marks the end of creative development and the beginning of stabilization of the source. At the same time, developers assign themselves to the tasks associated with each feature listed in the release plan of the modules they are interested in. This is done in three ways. Developers may be assigned to tasks by their management, in the case that they are employed by a third party organization. Similarly, module managers may assign tasks to the developers who have chosen to associate themselves with a particular module. Alternatively, community members may volunteer for such work. Since most community members highly involved in development have been community members for a considerable period of time, most have carved out an area of development they are interested in, making task assignment a straightforward procedure. Following task assignment, development proceeds, with status updates to the release plan, as needed, until the feature freeze date is reached.
The release subprocess is a stabilization phase, which consists of a build, deploy, test, debug cycle. While anyone can take the sources and conduct a continuous build, there are a series of automated build scripts that compile the sources each night on the current versions of code in ongoing development of the next major (e.g. x.0) or medial release. Nightly builds on the CVS trunk are run on every business day at 01:00AM GMT and from release branches at 02:00AM GMT. During the nightly build process, the continuous build is temporarily stopped. The primary difference between continuous and nightly builds is that the nightly build is published on the community Web and is publicly available to all users. Continuous builds serve developers by testing that the source base is not broken by their contributions. Also the nightly build is available to all users as a binary or source package with extra third party binaries, whereas a continuous build is not publicly available, although logs from build are available through mailing list. After this is done, the binaries are packaged with release and platform specific installers and compressed into the “tar” format where appropriate. As suggested, these builds are then made available to their associated audiences. For publicly available releases, deployment is done via the community Web's download page.
The testing process has several forms, as well. Builds are subjected to automated testing scripts such as “XTest” and “JellyTools.” These test frameworks allow developers to perform unit and integration tests against the build. After testing is completed, the tools generate a report listing qualities such as the pass rate, where exceptions were found and what exceptions were thrown, and so forth, which are then published on the community quality assurance section of the community Web. Though these tests are theoretically done on a nightly basis, in practice, published results are provided on an uneven basis.
Additional testing is performed by the quality assurance (QA) team through the Q-build program. A NetBeans nightly build (Q-build candidate) is labeled a Q-build if it passes a series of manual and automated testing performed by the NetBeans quality assurance (QA) team, comprised mostly of Sun NetBeans members. Though they aim to perform Q-build testing on a weekly basis, like the automated testing mentioned above, results from such tests are provided sporadically. Nevertheless, bugs in the test results are categorized into three groups based on five levels of severity, from critical malfunctions (labeled “P1”) to minor annoyances (“P5”) as given by the bug priority guidelines (see http://qa.netbeans.org/processes/bug_priority_guidelines.html):
1. Critical bugs, showstoppers, data losses (typically considered “P1” bugs)
2. Highly visible bugs, malfunctions, major annoyances (“P2” bugs affecting the user)
3. Minor issues, minor annoyances and usability problems (“P2” bugs with low impact on the user, minor “P3” bugs and those of lower priority)
Issues from the first category are called Q-stoppers. The candidate build cannot be promoted to Q-build status until all Q-stoppers are fixed. Issues from the second category do not prevent the build from being promoted, but need to be addressed soon. If those bugs are not fixed within a single week (or more appropriately, by the next Q-build, they automatically become Q-stoppers for the next candidate. QA produces a report with lists of bugs in both categories.
If there are no bugs in the first category, the candidate is promoted as a Q-build. If there are any Q-stopper bugs in the QA report, the release manager asks the responsible developers to fix the bugs on a separate CVS branch. No other changes except the Q-stopper fixes are allowed on the branch. When all fixes are available (which make take several days), a new build is created. The release coordinator makes sure that the fixes are adequately tested and if everything is fine, announces a fixed Q-build on the nbdev and nbusers mailing lists.
Additionally, community members are encouraged to download development builds and file issue reports to the IssueZilla database when they encounter functional deficiencies. A fourth mode of testing is conducted by the user interface (UI) team, who conduct usability studies of the platform/IDE. The UI team was founded after feedback from users both in the community and those who have switched to competitors' tools indicated that the NetBeans products were too difficult to use, and received a strong push from Sun Microsystems. However, in part a result of miscommunication and a lack of collaboration with the rest of the community, UI improvement efforts have been a monumental failure. Nevertheless, UI defects discovered by the UI team are dutifully submitted to IssueZilla for consideration.
Each week, defects reported to IssueZilla are tallied and published to the community Web. Shown below are a charts demonstrating the number of open defects and enhancements in IssueZilla, weighted in terms of their impact (e.g. P1, P2, P3) in figure 3 and a weekly delta chart of the number of new, resolved, and fixed defects in figure 4.
Figure 3. Defect Rates
Figure 4. Defect Deltas
At a certain point, as defined by the release schedule, the development enters a high resistance stage. At this point, all patches and bug fixes must be reviewed by another developer before they are submitted. Any objections to the patch are then noted with the bug report in IssueZilla, and in extreme cases (e.g. involving design decisions significantly impacting the remainder of the source), brought to attention in the newsgroups. If there are no objections after twenty four hours, the code may be submitted to the current branch of the code repository. At this stage, ideally, all P1 and P2 defects are corrected. As this is done, the build is labeled a beta, and then a series of release candidates until one week passes without a new P1 or P2 defect is filed, at which point the release candidate is declared final. With each progression, a message is sent to the newsgroups and posted on the community Web announcing the new status and a new branch is created in the CVS repository to store the requisite source.
5. Process Modeling and Visualization
5.1 Software Process Architecture for NetBeans
5.1.1 Agent Roles
From the NetBeans governance page [2],
“The NetBeans project has a very flat, lightweight governance structure…
In the case of an irresolvable dispute, there is a governance board. The board consists of three people, who are appointed for six month terms. Two of the members are appointed by the community, by consensus or vote on the public mailing lists. The third is appointed by Sun Microsystems, which started the project and funds the web site and a large number of developers who work on NetBeans full-time. The board is a voting body, but in practice, a dispute that cannot be resolved and needs its intervention is extremely rare.”
Though they claim to have a flat governance structure, such is not the case in practice. Ignoring internal Sun (and third party) structure, there are five observable layers of the NetBeans software development hierarchy. Community members may take on multiple roles some of which span several of these layers. At the bottom of the scale are users, followed by source contributors, module-level managers, project level managers (i.e. IDE or platform), and finally, community level managers (i.e. NetBeans IDE and platform). As the community has evolved, several implicit roles (e.g. module manager, CVS manager, and release manager) have been made explicit, though in some cases, the significance of such a title (particularly module manager) has been called into question as module development activity fades/intensifies or is taken over by others.
Users of the IDE download builds and, from time to time, submit bug reports to the IssueZilla bug repository. Though most users only download final releases, it is not uncommon for enthusiastic or impatient users to download release candidates or, in extreme cases, release candidates and in some cases, Q-builds (discussed later). IDE users write and build software using the tool, possibly even systems based on the NetBeans platform. Platform users develop systems using the NetBeans windowing system and file system framework. In both cases, users are code developers, themselves. Users are encouraged to report any bug and to propose new features or suggestions to the NetBeans community via Issuezilla. What separates them from contributors is that this code does not add to the functionality of the IDE or expand the platform.
There are two types of source code contributing members in the NetBeans community: “developers,” who write module code and submit bug fixes and patches, but do not have CVS check-in access, and “contributors,” who have been granted CVS check-in privileges. Developers submit code to the module mailing lists or module IssueZilla database. This code is then evaluated by contributors with CVS check-in authority and is either included in the CVS source tree or referred back to the developer for revision. After proving themselves through insightful patch and code submissions, module owners may offer to upgrade developers to contributor status by granting CVS check-in access to developers.
The role of the module manager (sometimes referred to as the module “maintainer,” module “owner,” or module “leader”) is, theoretically to coordinate the efforts of all the developers working on the module. This would nominally include planning the features of the module, designing the module, creating and maintaining its website, and the code and issues submitted by developers and contributors. In addition, the module manager has the authority to grant CVS access to developers, thereby increasing their status to contributors. When an upcoming release date is announced, the module manager must declare the module's readiness for inclusion with the rest of the build by the feature-freeze date in order to be included in the release build. By this time, all development on the module must be completed, leaving only stabilization in the forms of patches, and bug fixes to be completed when including the module code in the source build branch. A contributor may become a module manager by suggesting (and subsequently being granted community web/CVS branches for) a new module or by taking over module management responsibilities from a current release manager. In practice, module operations are often much less structured than this. As the foci of the developers and contributors fluctuates, the module's development liveness. It is, therefore, not uncommon for modules to die off or become abandoned (as many open source projects do) is cases such as when the problem is too hard, uninteresting, or there is simply not time to devote to it. Likewise, it is not uncommon unusual for a contributor other than the official module manager to assume the role thereof. This happens when a module manager vacates the position either explicitly or implicitly through a lack of involvement, or, for example, when a powerful entity such as Sun or a third party dedicates a team of their own developers to take on an project that they deem vital to an upcoming release. Even at that, there is still uncertainty regarding the authority and role of the module manager. Practice seems to indicate that the module manager has as much authority that the developers and contributors of the module are willing to give him
Rising to the project level, the CVS manager is responsible for maintaining the integrity of the source tree. Additionally, the CVS manager is also charged with creating access accounts and managing the authority of contributors to the community. Thus, when a new release manager is announced, the CVS manager is tasked with the job of granting access to the release manager to create a new branch in the tree for the upcoming release and removing that authority when the release manager relinquishes the post. Likewise, the CVS manager also creates CVS branches for new modules and instructs the contributors on how to access the branch. When a poorly crafted patch or bug fix is submitted to the three, the CVS manager may roll back the code to a previous point in development to eliminate the issue. The CVS manager also ensures that the community tracking software is able to access the tree and monitors the statistics of code submitted.
The quality assurance (QA) team has several jobs. They conduct manual testing on nightly builds approximately every ten days. The QA team performs sanity checks both in terms of manual and automated tests. The results of the tests are summarized into several build reports with a wide variety of statistics, including identifying the errors discovered and where they were found, major bugs that need to be repaired before the following Q-build, open issues and bugs, and cautions for using the build. If during the test a critical bug appears, the development build will not be promoted to “Q-build” status. The Q-build is an intermediary build that has been verified to be of acceptable quality (i.e. lacking showstopping bugs) designed to ensure that critical bugs are fixed in a timely fashion. This vision is enforced by designating that serious (but not fatal) bugs found in a Q-build are promoted to critical status if not fixed by the test date for the next Q-build candidate. The whole list of bugs encountered is then added in Issuezilla and taken care by the developers and module managers. In addition, the QA team manages the set of automated testing scripts and testing software that the builds are run against. They then take these results and compile. Additionally, the QA team establishes criteria for stabilization of modules and project builds.
The release manager’s job is to coordinate all efforts on the project with the end-goal of releasing a product in line with the project vision statement and roadmap. The call for volunteers for the release manager position is generally issued once the release feature freeze date is assigned. Historically, the release manager has usually been a Sun employee in the community, but non-Sun driven releasing has also occurred (sometimes referring to a release “coordinator” in this case). Once a release manager has been established, he must create a new branch for the upcoming release in the source tree and solicit module owners for inclusion of their modules in the release. From then on, he acts somewhat like the community whip, keeping the community aware of the status of the release and ensuring that all requirements and quality issues critical to the release have been assigned and resolved on time. After the release is done, the release manager’s final tasks are to lead a post-mortem discussion, analyzing the process and the product, and lastly, sending out the request for the next release manager.
Moving up to the community level, the web team maintains the templates for all web pages within the community to ensure that there is a unified look and feel throughout. They also define the structure of the web. All of this is done using CollabNet’s SourceCast development environment. Like the CVS manager, they also grant access to contributors to create and modify content within the web.
The marketing team’s goal is to further the community around the world. Their mission is two-fold. First, they seek to ensure that NetBeans releases are top-tier quality development products. Secondly, irrespective of the quality of their products, they must build the user and developer base to stay competitive in the market. Much of this is done behind the scenes by Sun, however efforts have been made to make such processes more transparent to the remainder of the community. Due to stiff entry barriers for contribution, most developers wishing to assist are encouraged to begin by creating translations of the web content, adding “how-to” guides and other documentation, and suggesting content for the weekly and monthly newsletters (the NetBeans Newsletter and Sprout respectively). Other concerns of the marketing team are maintaining relations with third party developers and universities, and, in more extreme cases, shifting the focus of development and/or roadmap in order to maintain quality and competitiveness with other leaders in the market.
Implicit in nature, the community manager’s role is to serve as a technical guru and to see that all issues brought up in the mailing lists are addressed. Though he does not participate in a decision-making fashion, he advises other developers on the tradeoffs of approaches to solving technical issues.
The user interface team measures and maintains the usability of the NetBeans IDE. They conduct studies of how easy it is to carry out common functions, note where problems arise, and provide recommendations for their resolution. Additionally, the NetBeans UI team also creates and maintains a set of guidelines for designing interface features of the system. In the past, UI team efforts have been a monumental failure due that can be attributed to a lack of coordination with other developers despite strong backing by Sun. New efforts to improve IDE usability are receiving moderate success as it has been declared a central point of release version four resulting in renewed efforts at collaboration.
The governance board is composed of three individuals and has the role of ensuring the fairness throughout the community by solving any dispute. Two of the members are elected by the community, and one is appointed by Sun Microsystems. The board is, historically, a largely superficial entity whose authority and scope are questionable and untested. While it has been suggested that the board intercede on a few rare occasions, the disputes have dissolved before the board has acted. Nevertheless, board elections are dutifully held every six months [12].
5.1.3 Tools and Network Infrastructure
We've identified three categories of tools being used in NetBeans Requirement/Release Process: communications, configuration management and code development.
5.1.3.1 Communications tools
5.1.3.1.1 Mailing List Management and Archiving
Two open-source mail tools -- anzu and eyebrowse -- provide powerful, scalable functionality to administer, moderate, customize, and archive module mailing lists. The mailing lists are a primary medium of communication for developers and other interested parties to communicate with one another and to receive module-related announcements. Such communication includes users posting feedback such as bugs found and feature requests, and developers settling important technical issues. While anzu, a mailing address management system, handles creation, updating, and deletion of addresses in the mailing list, EyeBrowse stores and indexes list messages, and provides a web interface for accessing project and component list archives.
5.1.3.1.2 Tunneling with SSH
SSH is a flexible and more secure replacement for telnet and rlogin. SSH is one of the more preferred methods of accessing the CVS server. Data sent through the tunnel is encrypted thereby reducing the risk of password snooping attempts, which could result in implanting of malicious code into the source tree.
5.1.3.1.3 CVSWeb Source Code Browsing
CVSWeb is a browser-based interface for CVS repositories that allows developers and contributors to browse the CVS source tree through the community Web portal. In addition to viewing the source code, itself, CVSWeb also allows community members to view the revision history for each file. Each revision includes a link to display color-coded differences between that revision and the previous one.
5.1.3.1.4 SourceCast
Each individual module in NetBeans project is hosted on SourceCast web portal. SourceCast, developed by CollabNet, provides simple, powerful web interfaces for version control, issue tracking, discussions and decision-making, automated build, automated testing, module management and knowledge management. Module owners can configure these tools within each module and grant roles to module participants to fit the needs of the project.
5.1.3.1.5 IssueZilla Issue Tracking Repository
A variant of BugZilla, IssueZilla is a customizable open-source tool for reporting, tracking, and managing all module tasks, defects, features enhancements, and patches. Each hosted module on this site has it's own issue database. All registered users can query, view, and report issues using the tool. Module members have the additional abilities within IssueZilla to modify and reassign issues, as well as generate reports. Module members are notified automatically by email whenever issues are assigned to them or there is activity on issues affecting their work. Developers may wish to enter the tasks they plan to work on as issues. This helps them devise and follow a work plan. Because everyone is aware of each module member's area of work, they can avoid duplicating efforts and even assist in development or offer feedback to other module members.
5.1.3.2 Configuration management tools
5.1.3.2.1 CVS source code version control
The concurrent versions system (CVS) is a widely used version control tool for tracking all modifications to module source code files. Developers can work on the same files and coordinate their contributions through a common repository. CVS facilitates multiple developers can edit their own working copies of files simultaneously, then and manages combining all the changes and notifies developers when there are conflicts. The CVS repository is maintained on a web server; clients run on users' machines and connect to the server via the Internet. Clients are available for nearly all platforms including: Unix, Windows, Macintosh, and any Java-based platform. Module members can obtain, modify, and submit module files from virtually anywhere. In addition to IDE and platform source, the CVS repository is also used to manage the community Web.
5.1.3.3 Code development tools
5.1.3.3.1 NetBeans IDE
Much of the NetBeans code development and compilation is done through the NetBeans integrated development environment, itself, resulting in a tightly coupled developer-user experience common in many open source projects. As a side effect, developers become power users of their product. While this affects the product by inspiring creation of heavy-weight tools to extend the environment, this also means that novice users of the IDE also face a steep learning curve, as seen in the presence of many of its most desirable features available only as keyboard shortcuts, which are often overlooked by its userbase (see Vincent Brabant's weblog at http://weblogs.java.net/pub/wlg/684). This is reflected in the “insider's club” atmosphere that NetBeans has been fighting through the last several minor releases, and contributing to its relegation as (at best) second-place in the open source market to IBM's Eclipse IDE/platform.
5.1.3.3.2 Text Editing
Many NetBeans developers utilize a wide array of tools for development aside from IDEs, including simple text editors such as emacs and vi. While they can theoretically edit any source using NetBeans, itself, developers often have built up great familiarity with certain general application tools that allow them to increase their development efficiently.
5.1.3.3.3 Ant
The Ant build tool hails from the Apache Foundation, as an alternative to “Make,” but “without Make's wrinkles” (http://ant.apache.org). NetBeans IDE developers are encouraged to make a build with Ant, which has been incorporated into NetBeans as a module, further supporting the philosophy of developing the product with itself. Ant is, itself, written in Java and driven by XML build scripts, making it highly platform independent, and therefore well suited to NetBeans distribution. In the case when a new build is not necessary, developers just add patches to an existing IDE installation.
The above tools are basic across the NetBeans community. In addition to these tools, each module team has an additional set specific to their domain. The QA team, for example, has an extensive tool set for testing the code, including the XTest script-based automated testing facility, scripts for producing test reports. There are also build scripts that automatically generate nightly builds. The Web team has scripts that update certain portions of the community Web with automatically generated content, and so forth.
5.1.5 Activities
Activities are performed within the context of a relationship between agents performing some task using certain tools to manipulate certain artifacts. As such, we choose to represent them in terms of use cases, thereby encoding the agent, tool, and artifact information into the task description. Though often thought of in terms of the unified modeling language (UML), our selection supports a different purpose: process modeling using a rich hypermedia, as described below. Here, we describe the use case activities in detail.
5.1.4.1 Propose Module/Feature
New modules and features are proposed in several fashions. But, the two most common are either driven by management to fulfill a gap in the project not being met through the current track of development or in grassroots fashion. Grassroots efforts begin as bug/issue reports submitted by an enthusiastic user or developer. If the proposal is simple enough to implement, a developer may merely code it up and submit it to the source tree. Most proposals never gain enough interest to be coded up. However, those that demonstrate a significant omission or feasibly realizable value eventually gain momentum on the message boards and a developer or group of developers will volunteer to work on its development, the most verbal of whom becomes the module manager. The prospective module manager sends an email to the message board requesting the creation of the module space both on the CVS tree and in the community Web. If this is approved, the CVS manager and Web administrators will create the corresponding directories in the CVS and community Web trees and provide the module owner with the appropriate permissions to manage that module. In the case of a management driven proposal, the issue is added to the IssueZilla archive, a development lead (module manager) is assigned, and CVS and Web space given as in the grassroots case.
5.1.4.2 Create module Web page
After a new module is approved, module managers are given web space on the NetBeans website for hosting their work and providing information about using and developing the module. The standard module Web page template includes information on issue tracking for the module, module related files, a member directory, documentation, module news, and source code, as well as administrative features for managing development. Module managers may use any tool they wish to create content as long as they adhere to this template. Once the module Web is completed, it may be uploaded to the site's SourceCast Web portal using a variety of file transfer tools.
Send Release Proposal
The release manager uploads the release proposal to the release planning Web site and sends an email to developers via the mailing list to inform them that it is available. Discussions are then held on the mailing list regarding the contents (and lack thereof) of the release plan, focusing on three points- the changes in the proposed release, the time schedule of the release, and who will do what work. This is also an opportunity for module managers not already listed in the release plan to announce their intention to bundle their module with the release. Taking this feedback into account, the release manager will then revise the release proposal using his choice of content editing tools and repost it to the release planning Web page and send out another announcement stating its availability.
Select feature to Develop
Developers in the community can browse through the project pages of the NetBeans project and decide on what module or project they wish to work on. These features could either be bug fixes that have been reported or it could be a new feature of the project. Paid developers are usually assigned a feature, bug, or project to work on by their organization. New unaffiliated developers select their contribution by what interests them, background knowledge, or association with other developers. After becoming an established member of the community, developers may be asked to contribute to areas where their help is needed by other members, often in terms of claiming responsibility for a certain area of development. In the same sense, as a member increases his presence in the community as a developer, the community may begin to form implicit expectations of his performance and ability to meet deadlines.
Download NetBeans
Three agent groups download NetBeans. Users typically download only the latest stable binary release, however, enthusiastic users who desire to live on the “bleeding edge” of technology may download unstable development builds (i.e. release candidates, beta releases, Q-builds, continuous and nightly builds), and in some cases, source code. Members of the quality assurance team download the most recent nightly build to conduct their testing on, declaring it a Q-build if it meets the proper criteria, as discussed above. Lastly, source developers and contributors download the latest source code from the CVS repository. Interestingly, much of the NetBeans IDE development is done using NetBeans, itself. In this way, developers can catch many of the bugs in the IDE through their own extensive use, using a range from the last stable release to a custom build of their own, and the bleeding edge. NetBeans source and binary distributions are available at the community's download page (see above). Additionally, NetBeans has an update feature allowing users to check for new binary releases of individual modules and download and update their own build in piecewise fashion.
Respond to Technical Issues and Unresolved Questions
The community manager patrols the message boards to ensure that all questions asked and issues raised have been addressed in a timely fashion. If a query has not been responded to, he will either respond to it himself, or refer the inquirer to the community member who can.
Create Branch for Current Release
The release manager is tasked with creating a new CVS branch for the upcoming release once the feature freeze milestone has been reached. The steps involved in creating the new branch are as follows.
The release manager before doing this task should warn the developers' mailing list about the particular date when the branch will be created so that the developers get enough time before the actual feature freeze to plan ahead.
The release manager should also check if the build is usable, i.e. it has no exceptions or bad messages when running. If the build cannot be fixed trivially then the branching should be delayed.
The base tag for the release should look like releaseXY_base where X.Y is the version of the release
The next step is mapping the Java modules into the branch; a Sun employee should do this task. This involves mapping of the not-open-source modules (javac etc).
Remove web pages from the branch
Check out the newly created branch
A binary list of the tag should be made and it should be checked out by a Sun employee.
Make a complete build and run sanity checks on the same. This step is carried out to ensure that the IDE is usable.
Make a branch tag from the base tag; this is also carried out by a Sun employee.
Set up a continuous build process by assistance from Sun release engineering.
Fix any version-related problems with the files in the branch.
Version numbers of specifications have to be increased by one. For a trunk it has to be increased by 1 e.g. 1.5 to 1.6 and for a branch it has to be 1.5.1. The version numbers of the dependencies do not have to be increased
The existing branch has to be mentioned in the documents.
IssueZilla should contain the new release number as the version in all affected modules. This might be done by QA Team.
All open issues have to be migrated to this particular release number for the affected modules
Announce the creation of this branch to the developers' mailing list
Start creating nightly builds for this particular branch
Release RC1
Before making a final release the release manager must complete several steps. Releasing the first release candidate is one of them. The release candidate is chosen after the beta has been released and all the module leaders identify their module as stable according to the stability criteria. This phase of releasing the first release candidate is taken only after stabilization phase is completed, i.e. all the known p1, p2, p3 types of bugs have been fixed. A checklist needs to be followed by the release manager for performing a release; the steps to be followed are
File a list of all known issues in coordination with the QA team into a README.html file.
Synchronize all the changes from the previous release into a CHANGES.html file
Based on all the contributors (groups, companies, individuals) for the particular release include a file CREDITS.html
Sun Release engineering is responsible for making the final build of the release
Release Engineering or Webmaster makes these releases available on the website for download.
All issues related to this current release in IssueZilla have to be migrated to reflect the current release. This task is generally done by the quality assurance team.
Release RC2
After the release of the first release candidate, if there are any major bugs (e.g. P1, P2, and, in some cases P3), they are fixed and a second release candidate (RC2) is released, following the same steps as in RC1. Further release candidates may be released in this same fashion until a final release is declared.
Do Final Release
The release manager along with the module managers decides when to declare a release candidate a “final release”. A release candidate is generally declared final after at least a week has passed since deployment of the release candidates without any report of new major issues. Once the release manager, declares a release final, he sends an announcement to the message boards and on the front page of the community Web with the news. As with every release deployment, the splash-screen for the system (and rolled up into the distribution) and the banner graphics on the community Web are updated to reflect the release status. The binaries are made available on the community downloads page.
Release Post Mortem
After a final release has been deployed, the release manager conducts a discussion on the developer mailing list providing a critique of the release process, stating what the community did well and where they need to improve. This is also an opportunity for developers to voice their opinions the release process and how it was managed. This feedback may, in turn, lead to policy and process discussions aimed at improving the development lifecycle (e.g. process redesign) and development experience (e.g. community redesign).
Grant CVS Access
CVS access is granted by two authorities. The CVS manager grants access to module to their managers, who, in turn, grant it to contributors. This helps prevent the possibility of developers submitting source code to the wrong branch in the tree. The CVS manager also grants access to the entire tree to certain individuals, such as the release manager, who have demonstrated a need for writing to all branches of the tree and the capacity to do so responsibly. Contributors seeking CVS write access are advised (see http://www.netbeans.org/community/contribute/cvs.html) to obtain a high degree of understanding of their code, and that of others in the module they wish to contribute to, create and submit patches showing this understanding, agree to abide by both the Sun Public License (SPL) and Joint Copywrite Assignment (JCA) licensing agreements, create a NetBeans community account, and finally, add oneself to the module via the account Web page and contact the module manager requesting write access to the module's CVS branch. Developers seeking access to the entire tree are directed to write to the developer mailing list with their request, such that the developer community, as a whole may debate the request before it is granted.
Commit Code to CVS
Developers with check-in access to the CVS repository submit all implementation-related source code prior to the feature-freeze date. After the feature freeze date, only bug fixes are allowed to be submitted to the repository. The type of source that is being submitted depends on the nature of the source. For example, bug fixes from Q-build-discovered defects must be placed into a special branch of their own. However, several things must be done before the code may be checked in. First, it must be validated against the standard, ide, xtest, jemmy, and jellytools modules. The source must be built with these modules cleanly (i.e. built from scratch, without any precompiled components) with Ant, using the community's standard version of the java language. Once this is done, the developer then must run the build against the commit validation test suite to make sure that the new source code has been integrated without causing serious execution problems. This is followed by unit testing of the modules related to the source code introduced. Lastly, developers must make sure that the changes to the source match the alterations to the source and execute the check-in command, providing a brief, but meaningful message describing the changes made. Developers are also encouraged to add test cases to the validation suite when submitting source to the repository such that when other developers commit source to the repository, the regression testing in the validation suite will ensure that future changes do not disrupt the functionality of the source they are commiting. (The commit guidelines may be found at http://www.netbeans.org/community/guidelines/commit.html)
Release Information Updates
The release manager is responsible for keeping developers informed about issues relating to the release, including the changes to the release proposal and development milestones. He is also responsible for bringing major technical decisions that must be made during the release cycle to the forefront and driving them to a resolution. In addition, information updates consist of updates of the stabilization status of the release and requests for assistance on unresolved issues.
Test Builds
The QA team is responsible for ensuring the quality of the release before it becomes final. When performing semi-weekly testing on a Q-build candidate build, the QA team performs a series of manual and automatic tests, as well as some simple sanity checking to ensure correctness of the build. The issues discovered from these tests are then categorized into critical, highly visible, and minor issues and filed as such, as discussed above. Certainly, the automated test scripts cannot uncover every defect in the system, however, even with manual testing, there is no guarantee that every major defect will be found. Hence a constraint, somewhat inherently, of testing is that it is limited by the testing guidelines and scripts used.
Report Bugs
Both NetBeans uses and developers submit bug reports. The majority of bugs are reported shortly after a new beta, release candidate, or final release build is deployed and also after a round of testing is performed. Bug reports are submitted to the IssueZilla bug repository, though community members will sometimes email the message board to verify whether the phenomenon they are experiencing is a known issue or not before submitting a bug report. IssueZilla reports are created using the Web form interface on the IssueZilla Web page. Before a report is filed, issue submitters must first search the repository to ensure that the issue has not already been reported. Searches can be performed by issue type, component, subcomponent, status, resolution state, priority, platform, operating system, version, target milestone, and email address of community members responsible for the defect (http://www.netbeans.org/issues/query.cgi). If the issue has already been reported, the submitter then reads the comments on the state of the issue left by other submitters and, updates it, if necessary. If the defect has not been reported, the community member is then advised to file a new bug report. To do this, the submitter must first log in to his NetBeans account (registering as a community member if he has not already done so). Then, the submitter enters the issue information (issue type, component, subcomponent, status, resolution state, priority, platform, operating system, version, and target milestone) relevant, as well as the nature of the defect, how it was elicited, whether it was a reproducible bug, and any other information that developers may need in order to correct the problem.
Select Bugs to Fix
Developers select which bugs to fix by first examining the priorities of the defects submitted to the IssueZilla bug repository and selecting the bug with the most critical impact. In some cases, critical bugs may be further reaching than the particular module the developer is working on. These bugs may require a rearchitecture of one or more parts of the system. In this case, developers will consult the appropriate community members to decide how to handle the issue, either directly via email or via the mailing list inviting feedback from the community, at large. Once the developer (or developers) has determined how to fix the bug, he claims responsibility for the bug fix by annotating the issue report in IssueZilla (thereby avoiding duplication of effort by other developers), downloads the most recent source snapshot from the CVS archive, and implements the changes. Once he has tested the fix to ensure it has solved the issue reported and not created other problems, the developer uploads the source to the CVS repository and updates the issue report to reflect the fix. If a contributor lacking CVS access has fixed the bug, he will normally submit it to the development newsgroup or (more effectively) hand it off to another developer directly to upload and make the changes in IssueZilla.
Release Q-builds
A Q-builds is a build that ensures a certain level of quality in the product. This is the result of rigorous testing by the QA team. After testing the latest nightly build, The QA team proposes to release a Q-build if it no P1 and P2 type defects are found in the latest build. The builds are deployed by the site administrator (see “Deploy Builds” below). The Q-builds may be then used by developers for further enhancements or by the users desiring a bleeding-edge version or the source with a reasonable level of quality.
Deploy Builds
The Site Administrator is responsible for deploying the current builds on the website for download by the community. The builds are obtained by the website administrator from the CVS repository. He is also responsible for categorizing the builds based on what branch of the repository they come from and deploy them accordingly on the website. The general categories associated with the builds are, nightly builds, Q-builds, release candidates, and final releases.
Resolve Conflicts
The board is responsible for resolving any conflicts that arise in the community as a whole. To date, the board has not issued a ruling on any issue. However, as issues arise in the community, either regarding the technical or nontechnical directions the community is moving in, the board has been consulted, and in some cases petitioned for a ruling. In these cases, the board has served to drive the discussion towards an acceptable resolution for the parties involved. Recently, such issues have included changes imposed by Sun in the licensing of source and regarding Sun's role in the community.
5.2 Rich Hypermedia
Based on the rich picture of Monk and Howard [38], the rich hypermedia (see Figure 6) is a semi-structured model of the requirements and release process, showing the relationships between tools, agents, their development concerns, and activities that compose the process. Whereas Monk and Howard propose a static model, our rich hypermedia is interactive, including process fragments, captured as use cases (uncontained blue hyperlinked text) best known as a technique of the unified modeling language (UML) [1], though UML is not used here, and annotated with detailed descriptions of each tool, agent, and concern (represented with thought-bubbles). Each of these process entities is hyperlinked to its description (see Figure 6.2). Descriptions can, in turn, be linked to other data or multi or hypermedia resources. In this way, the modeler can define the scope of the rich hypermedia to include as little or as much information as the need requires. The rich hypermedia provides a quickly discernable intuition to the process without the burden of formalization.
Figure 6. Rich hypermedia model of the NetBeans requirements and release process
Figure 6.2. Hypermedia selection of a use-case in the rich hypermedia of Figure 6
Noticeably missing from the rich hypermedia are the UI team and the marketing team. The omission has not been done unconsciously- there simply was not space in the already busy model for these entities. To add more entities to the rich hypermedia would have reduced its understandability. This brings to light the inherent challenge of process modeling and a limitation of the rich hypermedia model: there is a need for abstract representations, which can be easily consumed, but of necessity exclude non-central data, as well as more formal models that provide such details as are necessary for operations on the data modeled. The rich hypermedia provides scope in depth, but is somewhat limited in terms of breadth.
5.3 Process Flow Diagram
The process flow diagram shown in figure 5 illustrates the flow of artifacts (represented as ovals) of development through a path of interaction with process agents (uncontained black text) and activities (rectangles). This workflow diagram allows us to tease out dependencies between artifacts and activities. It also provide an idea of which artifacts and activities are the most vital to development, by measuring the fan-in and fan-out of each. These artifacts are the most likely to be the cause of bottlenecks in the development process. Borrowing from Web modeling terminology, an artifact that is a hub for several activities will hold up development until it is completed. Likewise, an artifact that is a product of several inputs inhibits activities that require it. Additionally, we can also detect cycles of development, such as in the stabilization process and refining the release plan. While these insights can be captured in other means, this diagram, like the rich hypermedia, provides an executive summary of the process without being weighted down by the details of more formal models.
Figure 6.5: Process Flow Diagram
5.4 Formal Model
The formal model was developed with Protege-2000, following an ontology based on PML described in [32]. The work done here is identifying instances for all the meta-process components: process model, agents, resources, tools, actions and control flows. The formal specification is based on the process model and has 9 agents, 17 resources, 10 tools and 23 actions. One important part missing from the ontology used was defining of sub-processes of a certain process, such that the actions could not be organized to reflect the structure of the process. Nevertheless, Protege offers support for defining and managing the components of the process model in a manageable form. Defining the agents, resources, tools and the actions was relatively easy. The agents can be linked to the actions performed, the required and produces resources can be linked to actions as also the tools needed to execute a certain action. The facilities of modifying, saving and loading a certain formal specification make from Protege a good tool to manage formal process models visually. Also, the editors for all the elements of the model can be easily extended if the formal model needs to be more precise. Protege-2000's facilities for scoping of process entities (i.e. tools, actions, agents, and resources) in graphical rendering, allowing process experts to focus exploration on certain process entity relationships.
The formal model developed with Protege was exported to an XML format using an XML plug-in, and also a visual representation of the process was created using the Ontovitz plug-in. Such an portable format is important given the complexity of the processes rendered. While the graphical process rendering can be more intuitive than a coded textual format, the textual representation can be used as input to other process lifecycle activities such as enactment and prototyping.
Figure 7. The formal process
diagram generation
Figure 8. The formal process xml
generation
5.5 Prototype
Our process enactment prototype is a series of Web pages allowing process agents and potential community members to simulate carrying out the process without actually enacting it. While such an enactment prototype may be implemented in other media, implementation via Web pages gives the potential to easily transition from the prototype to a live transaction on the community Web. In doing so, we have been able to detect processes that may be unduly lengthy, which may serve as good candidates for downstream activities such as reorganization and re-engineering. It allows us to better see the effects of duplicated work. As an example, we have four agent types that test code. Users may carry out beta testing from a black box perspective, whereas developers, contributors, and Sun Microsystems QA experts may perform more in-depth analysis, and, in the case of developers and contributors, they will not merely submit a report to IssueZilla, but may also take responsibility for an issue and resolve it. However, is it really necessary to have so many people doing such similar work? While, in this case, the benefits of having more eyes on the problem may justify the costs of involvement (which is voluntary, anyway), in other cases, it may be less clear.
Prototypes are especially useful when implementing a process or altering a process in that these potential pitfalls may be discovered before they lead to project failure. With the prototype we are also able to detect where cycles or particular activities may be problematic for participants. Over the course of constructing and executing the prototype we discovered some of the more concrete reasons that there are few volunteers for the release manager position. The role has an exceptional amount of tedious administrative tasks that are critical to the success of the project. Between scheduling the release, coordinating module stabilization, and carrying out the build process, the release manager has a hand in almost every part of the requirements and release. This is a good indication that downstream activities may also uncover a way to better distribute the tasks and lighten his load.
The self-selective nature of open source software development community participation has many impacts on the development process they use. If any member wishes not to follow a given process, the enforcement of the process is contingent on the tolerance of his peers in the matter, which is rarely the case in more corporate development processes. If the community proves intolerant of the alternative process, the developer is free to simply not participate in the community's development efforts and perform his own build. So, while exercising a prototype may not provide open source community members with the same sense of empowerment that employees of more corporate/closed processes experience, since they are the ones that create the process in the first place, it seems not to be an issue. The Protege files for the NetBeans Requirements and Release process can be found here: the project file, the ontology file, and the instance file.
6. Discussion
A driving factor in the success of an open source project is its ability to develop and sustain a community. As the open source paradigm has gained ground in the software market, communities have experienced greater and greater influence from for-profit organizations in forms including paying employees to contribute to development, donating money, hardware, and software (both source code and binaries) to the project, and either hiring members of the community or paying their own employees to contribute in ways that gain them a stake in the political and technical direction of the project in order to further their corporate strategies. Thus, in open source communities, we see phenomenon where members contributing of their own volition doing so because they have an interest in releasing a quality product and suggesting features they want to implement, but we also see members providing their efforts because they are paid to. So, in communities like NetBeans, where the core development is supported by a for-profit organization, when a task needs to be completed and no one from the community has volunteered (and even in some cases when someone has), the benefactor may assign employees to carry out the task. This may create tension between volunteer participants and paid contributors. Similar tension inducing situations such as a lack in the transparency in the decision making process and diverging goals may lead to splinter groups forking the source tree. Consequently, a significant part of the success of a community relies on individual volunteers in the community, whether they are participating as a hobby-interest, to hone their skills or build their resumes or because they have an interest in the product.
Community consensus plays a major role in the decision-making process and hence communication tools are central to coordinating the efforts of individual developers working semi-autonomously. As a result of the communication must be public and persistent to the entire community (or, at least, the relevant sector thereof) lest collaborative efforts break down due to differing assumptions, or worse, lack of information about the direction of development. This problem has challenged the NetBeans community leading some developers to question Sun’s policy with respect to its own involvement in the community, prompting fevered discussion amongst developers both inside and outside Sun (see http://www.netbeans.org/servlets/ReadMsg?msgId=531512&listName=nbdiscuss) and tension of the type described above. Nevertheless, such feedback is critical to locating points of contention in the community and avoiding pitfalls in development.
Our study has led us to several interesting insights of OSSD processes. Based on the results obtained from discovering, modeling, and visualizing an open source process we have a better idea of the impact of certain development process styles (e.g. distributed development by semi-autonomous individuals, extreme programming, etc.) within the larger process structure. Traditionally software engineering has been thought of as an activity carried out in a single location with a small number of developers working in close coordination with meetings taking place whenever there is a need for communication. The open source paradigm suggested above varies dramatically from this view where developers are geographically apart and generally do not even know each other. The primary means of communication is email, which considering the sheer volume is huge. Even with the constraints imposed by such boundaries, these projects are fairly successful (criteria of success being the number of user involved in the community). Previous studies [33] have pointed out how these processes can be used for developing software in a distributed environment, but they have not actually provided a empirically grounded solution for the problem, what has merely been suggested is that these processes can be used. In this section we try to provide our analysis of using the open source process for betterment of the closed source development within an organization.
The main points to be noted from the process described above is the lack of a central authority and having people in charge of themselves. This involves creating a sense of responsibility within the community about their tasks. For example, the developers and module maintainers are responsible for their part of the project and they have to meet the deadline for the release dates (feature freeze, final release date etc.). But these developers are in no way forced by the release manager to complete their tasks, they are asked for their feedback and accordingly the schedule is decided. This serves as the single most important part of the OSSD process. This has also been pointed out by Fred Brooks in his classic paper "No Silver Bullet", where he mentions the insane schedules [34]. Thus by involving the developers in the planning phase lot of the schedule problems can be avoided and the developers have a feeling of responsibility to deliver by the proposed date.
Another important factor as also mentioned by Eric Raymond in [31], is the frequency of the release. In the OSSD release process, we have many different kinds of release; these include nightly builds, Q-builds, release candidates and the final release. By releasing more frequently we have a chance of detecting the bugs early and helps on improving the code. This again ties back to Brooks law of throwing one away [34], whereby the nightly builds are replaced every night after bugs have been fixed. There have been instances where the whole release candidate had to be scrapped due to lack of quality. This needs to be adapted to the conventional process where the trend is on building a final product from the very start.
There is also this trend of exploiting the open source projects by organizations for creating products that are closed source. For the NetBeans project, this is true as Sun Microsystems, the company that funds the project utilizes NetBeans for creating their own product, Forte for Java that is sold commercially. By engaging in such a practice, Sun is able to use the resources of the community in making commercial use of the product. This also enables in saving development time, effort and identifying bugs. This also leads to more people proposing new ideas that are useful and contributing to the code base.
7. Conclusions
This study investigates the NetBeans open source process of requirements and release. We began by characterizing the process as in the traditional form of software engineering and then presenting the version of the process followed by the NetBeans community by using various different forms of representation including rich hypermedia, visualization diagrams, process model diagrams and a formal model for the process.
Acknowledgements
The research described in this report is supported by grants from the National Science Foundation #IIS-0083075, #ITR-0205679 and #ITR-0205724. No endorsement implied. Contributors to work described in this paper include John Georgas, who tailored the Protégé tool for use in software process modeling. Mark Ackerman at the University of Michigan Ann Arbor; Les Gasser at the University of Illinois, Urbana-Champaign; John Noll at Santa Clara University; Margaret Elliott, Mark Bergman, and Xiaobin Li at the UCI Institute for Software Research; and Julia Watson at The Ohio State University are also collaborators on the research project described in this paper.
References
Contributing Modules to the NetBeans Community (http://www.netbeans.org/community/contribute/modules.html)
Roles within the NetBeans Community (http://www.netbeans.org/about/os/governance.html)
The Sun Public License (http://www.netbeans.org/about/legal/license.html)
The NetBeans Build Process (http://nbbuild.netbeans.org/nb-build-process.html)
The NetBeans Open Source Definition (http://www.netbeans.org/about/os/index.html)
Proposal of NetBeans release process (http://www.netbeans.org/servlets/ReadMsg?msgId=73741&listName=nbdev)
The NetBeans Roadmap (http://www.netbeans.org/community/planning/roadmap.html)
The NetBeans Vision Statement (http://www.netbeans.org/community/planning/vision.html)
Module Stability Criteria (http://qa.netbeans.org/processes/stabe_module_criteria_process.html)
NetBeans Release Experience (http://www.netbeans.org/servlets/ReadMsg?msgId=76022&listName=nbdev)
NetBeans Release Process (http://www.netbeans.org/community/planning/process.html)
Members of the Development Board ( http://www.netbeans.org/about/os/who-board.html)
Release 3.4 schedule ( http://www.netbeans.org/community/planning/34/index.html)
Release Proposal Version 3.4 ( http://www.netbeans.org/servlets/ReadMsg?msgId=234728&listName=nbdev)
NetBeans: The Definitive Guide ( http://www.netbeans.org/community/articles/NetBeanstheDefinitiveGuide.html)
Suggestion of Release Candidate ( http://www.netbeans.org/servlets/ReadMsg?msgId=76022&listName=nbdev)
Title Terminology and the Release Manager ( http://www.netbeans.org/servlets/ReadMsg?msgId=74564&listName=nbdev)
Request for Creation of Release Manager Position ( http://www.netbeans.org/servlets/ReadMsg?msgId=73732&listName=nbdev)
The Release Process and Release Manager's Checklist ( http://www.netbeans.org/servlets/ReadMsg?msgId=76761&listName=nbdev)
Q Build Program ( http://qa.netbeans.org/processes/q-builds-program.html)
Access source using CVS ( http://www.netbeans.org/community/sources/cvs.html)
Recent NetBeans distributions ( http://www.netbeans.org/downloads/ )
Issue report ( http://www.netbeans.org/community/issues.html)
Release checklist ( http://www.netbeans.org/community/guidelines/checklist.html )
Feature freeze ( http://www.netbeans.org/servlets/ReadMsg?msgId=141662&listName=nbdev)
Overview of hosted tools ( http://www.netbeans.org/docs/hostedtools.html)
USENET service ( http://www.netbeans.org/community/lists/index.html)
The Open Source definition ( http://www.opensource.org/docs/definition_plain.html)
Sun Microsystems ( http://www.sun.com/)
J. Noll and W. Scacchi, Supporting Software Development in Virtual Enterprises, Journal of Digital Information, 1(4), February 1999.
E. Raymond, The Cathedral and the Bazaar: Musing on Linux and Open Source by an Accidental Revolutionary, O'Reilly and Associates.
J. Noll and W. Scacchi, Specifying Process-Oriented Hypertext for Organizational Computing, J. Network and Computer Applications, 24(1):39-61, 2001.
A. Mockus and J. Herbsleb, Why not improve coordination in distributed software development by stealing good ideas from Open Source?, Proc. 2nd Workshop on Open Source Software Engineering, Orlando, FL, May 2002.
F. P. Brooks, "No Silver Bullet: Essence and Accident in Software Engineering". IEEE Computer 20(4):10-19, April 1987.
S. Bendifallah and W. Scacchi, Work Structures and Shifts: An Empirical Analysis of Software Specification Teamwork, Proc. 11th. Intern. Conf. Software Engineering, IEEE Computer Society Press, Pittsburgh, PA. 260-270, (May 1989).
A. Brown and G. Booch, Reusing Open Source Software and Practices: The Impact of Open Source on Commercial Vendors, Proc. 7th International Conference on Software Reuse, 123-136, Austin, TX, USA, April 15-19, 2002. Appears in, C. Gacek (Ed.), Software Reuse: Methods, Techniques, and Tools, LNCS 2319, Spring-Verlag, May 2002
T. Halloran and W. Scherlis, High Quality and Open Source Software Practices, Proc. 2nd Workshop on Open Source Software Engineering, Orlando, FL, May 2002.
A. Monk and S. Howard, The Rich Picture: A Tool for Reasoning about Work Context, Interactions , March-April 1998.
C.R. Reis and R.P.M. Fortes, An Overview of the Software Engineering Process and Tools in the Mozilla Project, Proc. Workshop on Open Source Software Development, Newcastle, UK, February 2002.
W. Scacchi, Process Models in Software Engineering, in J. Marciniak (ed.), Encyclopedia of Software Engineering (Second Edition), 993-1005, Wiley, New York, 2002.
W. Scacchi, Understanding the Requirements for Developing Open Source Software Systems, to appear in IEE Proceedings--Software, 2002.
W. Scacchi and P. Mi, Process Life Cycle Engineering, Intern. J. Intelligent Systems in Accounting, Finance, and Management, 6(1):83-107, 1997.
Fowler, and K. Scott, UML Distilled: A Brief Guide to the Standard Object Modeling Language. Second ed. Addison Wesley: Reading, MA. (2000).
Appendix
The diagrams for the Process Model.
Figure A.1 - The overall process model
Figure A.2 - The Requirements Sub-Process
Figure A.3 - The Release Sub-Process
Figure A.4 - Task for establishing timeline
Figure A.5 - Task for Establishing requirements
Figure A.6 - Task for stabilizing the release
Figure A.7 - Task for deploying the release
Figure A.8 - Task of establishing the release manager
Figure A.9 - Task of reporting bugs
NetBeans requirements and release process linked model files.
NetBeans requirements and release process PML specification.