Paper:Best Practices for FOSS in Africa

From Wiki

The following represent best practices for FOSS development in the African context, as shared by participants at Good to Great FOSS. This enumeration focuses primarily on practices critical or unique to the African context, or which vary from conventions in developed country contexts.

Community Development: Central to the long-term success of any FOSS project is the ability to grow the involved community by recruiting and retaining new developers and other contributors. The following were called out as critical to successful community development:

• Active engagement: Just making project source code available will rarely draw in developers; there are too many interesting projects extant for code alone to be the primary attraction. Project principals must actively engage interested parties and find ways to honor their interest. In addition, contributions and other efforts should be acknowledged in a fashion that is visible to the project community.

• Transparent process: A differentiating factor in FOSS projects is the degree to which project decisions and management are done in a trackable and publicly visible fashion. Having well-defined processes for decision making, planning, and project management encourages new participation, and empowers all project members to understand and contribute to project evolution. An important corollary for processes that guide distributed collaboration is to follow those same processes even when meeting in the same room.

• Well-defined entry points: Projects need to make sure their online presence is friendly and inviting to the uninitiated. A well-designed project home page that summarizes the project, provides latest news, and conveys a sense of community activity is essential to recruiting new community members. In addition, for those wanting to get more involved, information about how to do so is critical in order to engage developers and other contributors in their moment of interest.

• Accessible Documentation: While documentation is the bane of many programmers' duties, projects with good documentation and documentation processes have a better chance of engaging new community members. The ability to browse project architecture, features, and processes can help in convincing new members to get involved. An important decision projects in the African context need to make involves online versus offline document management processes. While wikis provide a powerful, collaborative way to keep shared knowledge current, they are more bandwidth intensive. Projects like Chisimba opt to follow an offline documentation model, where OpenOffice is used to author and maintain documents, which are then checked in to the version control system along with source code.

• Offering intangibles: While it is difficult for new or small projects to do so, there are “intangible” benefits that can draw in developers and new community members. Two in particular are worth noting: “fame” and “buzz”. FOSS developers are often motivated by a desire to grow their reputation in the FOSS world; projects which can provide developers with high visibility or public acknowledgment of their contributions have greater appeal. Projects with substantial and growing user bases have the additional ability to offer developers a chance to see their work enjoyed by a larger audience. In addition, projects focused on “hot” or “buzz” markets or emerging technologies are more likely to draw in new community members. An example of “buzz” technology in the African context is the integration of internet and cell phones; such a bridge is at the cutting edge of communication in Africa, offering both compelling technological and social benefits in bridging digital communication divides.

Communication and collaboration: Staying in contact is often a challenge for FOSS projects in Africa, owing to limited internet access. A multi-channel approach was recommended at Good to Great FOSS, in part to account for varying degrees of connectivity by different project participants:

• Email: Because it is more bandwidth-friendly than the web, email should usually be the core communications channel for important project discussions and notifications. Email messages should be distributed via mailing lists (as opposed to individual addresses and “cc” lists), both to give recipients control of how messages are received as well as so that archives are generated which then allow new project members to browse and review project history. A common convention for Good to Great FOSS participants was to manage a pair of mailing lists, one for developers and one for those implementing or deploying the actual software.

• Internet Relay Chat (IRC): A valuable synchronous counterpart to asynchronous email is IRC. IRC allows for rapid response to questions, as well as quick turnaround on decision making. While not accessible to those for whom a full-time internet connection is not possible, IRC is low-bandwith and uses minimal resources on the client machine. The host irc.freenode.net is a popular venue for establishing and maintaining an IRC channel for many FOSS communities.

• Discussion forums: Web-based discussion boards can be used for focused asynchronous dialog on a range of topics, from general discussion to data models, the code base, usability and modules. But owing to the higher bandwidth needs of HTTP-based discussion pages, critical messages and conversations should be handled or mirrored on primary email lists.

• Rich Site Syndication (RSS): Projects like OpenMRS use RSS to provide feeds documenting changes in all aspects of the project, from wiki page updates to bug fixes. RSS is a bandwidth-friendly and efficient way to let project members track project goings-on without necessarily spending lots of time loading web pages.

• Telephone: Where feasible, weekly or regularly scheduled phone calls allow project members to be in direct dialog and discuss pending issues, and greatly enhance community energy. Where bandwidth and usage agreements permit, VOIP (Voice over Internet Protocols) tools such as Gizmo and Skype can enable such conference calls to be done at no charge to participating parties.

Outreach and marketing: In parallel with active community engagement, FOSS projects must make themselves to visible to the larger FOSS community. Projects should register and be discoverable on several key sites:

• Sourceforge.net: the de facto standard for hosting FOSS projects, SourceForge is an import online venue in which to establish a project identity, even if code is archived elsewhere.

• Freshmeat.net: FreshMeat is the web's largest inventory of FOSS and Unix/Linux software.

• Ohloh.net: Ohloh is a new entry in the global FOSS landscape, but it offers compelling value. Ohloh tracks very specific project details, including lines of code, number of developers, and rate of development. Projects registered on Ohloh can convey their level of activity and community growth.

Projects should also make sure entries on these sites are well maintained, and convey the sense of an active and vibrant project community to those who encounter them.

Code architecture and Management: At the heart of any FOSS project is the source code itself. Decisions and practices established early in the lifecycle of a code base can influence the sustainability, relevance and attractiveness of a FOSS project. The following are guidelines which were discussed at Good to Great FOSS:

• Manage code through a version control system: The use of Subversion or CVS to archive and manage source code is an essential trait of successful FOSS projects. Such systems control who has permission to edit which files at any given time, track version history for each file, and support naming and marking to denote which version of each file was used in a given build or release. These repositories also make possible truly distributed development by coordinating changes from various contributors, and supporting “rollbacks” when code checked in by one developer breaks or inhibits functionality in other parts of the code.

• Leverage an established stack: Build new projects on software stacks which themselves have strong communities and mature, stable code bases. This approach has a range of benefits; documentation and support are in greater supply, maintenance of such components happens in a consistent and timely fashion, and project developers are able to focus more exclusively the code they are actually developing, rather than what they're building upon.

• Use design patterns: The use of design patterns to create well-architected, well-factored code is essential to maintenance and scaling of code bases. In particular, the MVC pattern (Model-View-Controller) enforces code discipline that separates “business logic”, which models the problem space of the application, from “presentation logic” that renders the user interface and interacts with the user. This separation, mediated by “controller” classes, insulates the model code from evolutions in front-end technology and conventions. An additional benefit of such design patterns is that business logic can be repurposed and utilized on a range of client devices, from traditional computers to cell phones and other handhelds, not to mention gizmos which have yet to be invented.

• Employ modular architecture: Code base design informs the architecture of participation for any FOSS project. Projects with monolithic code bases run into scaling issues as more developers become involved, because incremental changes made during new feature development need to be integrated into the central code base, but are often out of sync with changes being made by other developers. Modular architecture, where a smaller central “core” code base is extended in functionality by the addition of modules which “plug in” to the core, is a more sustainable and scalable coding approach. Not only can development happen in parallel on a number of modules without adversely impacting other module development, but platforms implemented in this way can be deployed in different configurations for different needs and varying resource constraints.

• Release early and often: Developers should resist the instinct to hold out for “big” releases, and instead get code in the hands of users and other developers as quickly as possible. This establishes tighter feedback loops, and keep the project more in touch with its ultimate audiences.

Tools: While a complete enumeration of development tool sets required in FOSS projects is beyond the scope of this paper, several specific tools bear mentioning for their essential nature in properly supporting and automating FOSS projects:

• Project management: Projects need a central tool for managing tasks, assignments, and timelines. While FOSS project management processes vary widely, the need for effective and usable project management is without dispute. In addition, such tools greatly aid in transparent project management, providing a dashboard of “who's doing what” and allowing newcomers to both comprehend project dynamics and more easily get involved.

• Bug tracking: Sometimes lumped in as part of project management, and other times deployed as a stand-alone application, bug tracking tools are the immune system of FOSS projects, tracking what's broken and what has priority in pending fixes. Tools like Trac or Mantis span the features of both bug tracking and project management.

• Build automation: A critical indicator of a code base's ability to scale is its ability to be built from scratch on a “clean” machine. Build automation tools such as ANT automate the process of “pulling” source code from a central repository and assembling the requisite components to generate an executable version of the code. In addition, such automation tools allow builds to be done on a daily or regular basis, which enables developers to quickly identify when new code has “broken the build” and requires mitigation.