Paper:FOSS Community Processes
From Wiki
An essential component of vibrant and sustainable open source projects is the community behind the code. Any organization or developer can release software under an open source license, but the relevance and lifespan of the project is usually determined by the participation of passionate users, developers and other stakeholders who take a role in using, testing, fixing, enhancing, and supporting the code base.
Open source community dynamics vary widely in the African context. This is due to a number of factors, many related to issues documented in the “challenges” section of this paper. Limited connectivity precludes the “always online” nature of open source communities collaborating in more developed contexts. With web access at a premium, online engagement is often limited to email, often precluding active participation in web-based communities such as SourceForge. African projects also face greater challenges in drawing attention to their work, and miss out on community engagement that would come with such exposure. And the limited number of available engineers in the region further compounds efforts to establish community.
That said, there are vibrant communities collaborating and developing code in Africa. And for these projects, the processes by which they govern, document, support and receive contributions from their communities is a fundamental indicator for both sustainability and success.
AVOIR Community Process
The AVOIR project describes their community process as lightweight. They draw a fundamental link between the architecture of product and the community process; a well-defined architecture makes governance easier because discussions, ideas and debates happen within that context.
They also make it a point to follow community process even when in same room, both to ensure consistency and to assure that those not present in the room enjoy the same access and transparency as they would as a result of purely virtual collaboration. There is an emphasis on well-defined guidelines at the process level, which in turn makes it easier for project members to interact with one another at the code level. An important lesson learned in the AVOIR community process is “keep it simple, don't have too many rules”.
Communication for the project is done primarily on mailing lists, which are relatively low volume. There are several mailing lists: one for the governing board, one for developers, and one for implementors who are installing and configuring the software in different environments. The developer list is active every day, with 50-60 messages/day from new students, proposal ideas, new business opportunities and other stuff.
The process for managing the project source code derives from the modular architecture of the platform. All code lives in 1 of 2 repositories, which archive the core platform and modules. AVOIR uses the CVS version control system. The community acquires new developers through one of several avenues, but many register through AVOIR's GForge site.
A striking point of process and philosophy is that all developers are given commit rights, meaning they can check in code they write. The underlying belief is that it is easier to roll back bad code that might get checked in than it is to decide who should and who shouldn't have write access to the repositories. Over time, this hasn't presented any problems; developers don't generally make commits on others' code. The project encourages people to commit often--“as soon as it runs”--and before going home at the end of each day.
A critical value in the AVOIR community is the importance of bug tracking, which proves particularly important in a geographically diffuse community, with developers separate from users. The project needs to be able to track both bugs and feature requests, and follow set processes regarding feature additions. AVOIR uses Mantis. The current process is an important improvement over past models.
AVOIR also uses their bug tracking tool for project management. For paying customers, a project manager is hired, so it depends on the nature of where the development comes in.
OpenMRS Community Process
The OpenMRS Community is an unusual hybrid. In addition to the usual user and developers, there also community nodes per-installed-site. Most of the developers are also users of the system, or work for companies that use OpenMRS. In addition, there are multiple versions of the software extant, such as the version deployed for Partners in Health.
The community started out small, with 3 to 4 developers, as well as a “primary user” who provided great feedback and tested new releases. Things stayed that way for 2 years, and then Google Summer of Code brought in 10 new developers. It was a challenging process to get them integrated into the project, and up to speed on the development environment, but it catalyzed a maturation of both the project and the community process.
OpenMRS uses a wiki to store and maintain all the project documentation for the platform. Expanding the community required the project to revamp and redesign the front-facing page so visitors knew where to go; the redesign took a couple of months, but the net result was that the project evolved to support an external developer community.
The project also utilizes RSS as a communications tool. Feeds have been created to allow people to track changes and code commits, as well as posts to lists and forums, and posts to both the general and developer blogs. The feeds model has centralized the acquisition of information, and enabled both the core team and new developers to understand what is going on with the project.
For version control, anybody that asks to commit is given rights. The platform is modular, and new modules are welcomed. Core code contributions are reviewed before being applied, and when things break, changes are rolled back.
One important evolution of community communication involved the establishment of a separate mailing list for implementors. Developers exposed to routine implementations were getting bogged down. The implementation list works as a helpline. People can post questions and get answers, and the group learns each others' work patterns. This is helping the project to establish a bigger footprint in Africa
For project management, OpenMRS uses Trac, combined with the wiki. Trac manages tickets and features, and discussions take place in the bug tracking section. The project doesn't work on the basis of hard deadlines.
In terms of recruiting developers, they often start out as implementors. They need a feature, and the modular architecture allows them to build the need functionality and add it with minimal politics. The policy it to “take whoever comes”, and universities often yield connections. Promotion of OpenMRS is often done by word of mouth,and the yearly conference serves as a focal point. Project members attend other technology conferences and to present OpenMRS and solicit feedback, but they consciously refrain from “selling” the product.
Community process for other projects at Good to Great FOSS
Other projects at the event were not in a position to comment on their community process for a range of reasons. DrumNet is still in an early development phase, and have not yet distributed the code under a FOSS license. Tradenet has not made any decision to distribute any FOSS code. And Mifos did not participate in the community process discussion.
