5.2. Process by which Kbase will be implemented. The implementation of Kbase will follow an open development process that encourages and values community contribution.  Community contribution is the primary attribute of the implementation process. Science is by its very nature an open process whereby discoveries are shared openly within the community. To be successful, we believe that the development of Kbase cannot take place any other way. Open source communities have mastered this philosophy during the development of the Linux operating system and many subsequent systems.  Our approach to the implementation makes use of the same paradigm. Licenses will be embraced that promote unrestricted access to, use of, and distribution of system code. Community developers will be given these rights coupled with the responsibilities of building, enhancing and maintaining the system source code.  Transparency and accessibility are at the core of the process and hold the potential for great accomplishments.

Many examples of successful open source development processes exist making the job of defining such a process for the Kbase project easier. The Apache Foundation is one example and much of this plan is based on that model. As stated on the Apache Foundation home page, “… Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field“. It is this model that has the most promise to ensure a successful implementation of Kbase.

There will be several ways to get involved. Members of the DOE systems biology community will be encouraged to use the products of various Kbase projects and provide feedback. Using the products, asking (and later answering questions), reporting bugs and making feature requests are critical roles in the project community. User feedback strongly drives the projects and the technologies. Members of the community can join a user mailing list, download releases, report bugs, and request new features. Beyond these activities, members of the community can get further involved by joining in the discussions on the development mailing lists, providing patches for bugs or features and improving documentation. Members of the community can become a committer. Committers actually have full access to the source code repository enabling them to commit changes. Project managers are committers and have a significant technical investment in the subsystem. Each of these roles is defined further in the following paragraphs.

Board of Directors - The Kbase Community members periodically elect a Board of Directors to manage the organizational affairs of the Community, as accorded by the Kbase Community Bylaws. The Board, in turn, appoints a number of officers to oversee the day-to-day operations of the Community.  The Community‘s goal is to build and sustain the environment in which open-source software projects are based.

The Kbase Community Board of Directors provides organizational support for a broad range of open source software projects with DOE support. The Board will provide an established framework for intellectual property through open source licensing. Through a collaborative and meritocratic development process, the Kbase projects will deliver much needed community driven systems biology data and analytical resources.

Project Manager- Each high level component of the system (see architecture diagram for components, also called subsystems, an example can be workflows or) will have a designated project manager (PM).

•       A project manager for each component.

•       Maybe the same person is project manager for more than one component, but each component will have one.

•       Project manager is technically active and engaged.

•       Project manager decides which of the community requests are implemented.

•       Project manager is selected by the Board of Directors based on technical contributions to the component.

The project manager holds a great deal of responsibility in that he/she serves as the subsystem architect and configuration control board. It is expected that decisions on change requests, requests for new features, and bug fixes will be vetted among the committers (committers described elsewhere but these developers have commit privs to the code repository). The ultimate decision authority, however, will rest with the subsystem PM.

Committers – This group of people are Community Members with privileges to commit source code to the code repository. These individuals are given Committer status from the PM based on their contributions. Users use the system and suggest changes and new features to the system.  Some users will be silent users in that they are not active in communication forums and are not formal Community Members. Other users will provide feedback on the usability, need for new features, bug reports and  

Community Members - We will establish a membership based Kbase Community to ensure that the Kbase projects continue to exist beyond the participation of individual contributors. Individuals who demonstrate a commitment to collaborative open-source software development, through sustained participation and contributions within the Community’s projects, will be eligible for membership. An individual is awarded membership after nomination and approval by a majority of the existing members. Thus, the Kbase Foundation is governed by the community it most directly serves -- the people collaborating within its projects.