Paper:FOSS Development Processes and Development Environments
From Wiki
Open source projects are often characterized by the technology infrastructure on which they are built. Programming languages, application frameworks, database layers, and server technologies are some of the attributes used to differentiate and contrast different software offerings. Collectively, these technology components are referred to as the “application stack” for a project. In addition, the set of tools used in the course of software engineering—development environments, bug trackers, automation and testing tools, and documentation systems—are referred to as “development stacks”.
The projects at Good to Great FOSS spanned a range of technologies and approaches with both similarities and substantial differences in their stacks. The following section enumerates the essential technology traits of each participating project, including details about the respective application stacks as well as some of the development tools and processes used by each team.
Contents |
OpenMRS
The OpenMRS application stack is based on the MVC (Model-View-Controller) pattern for software design. In OpenMRS, the view, or presentation layer, is based on JSP (Java Server Pages) containing HTML and Javascript. The model, or business layer, is written in the Java programming language, accessed through the reusable OpenMRS Java API. The database layer is based on the Hibernate technology to persist OpenMRS' Java objects to database tables. OpenMRS is served using the Tomcat application server, with the Apache Server acting as the front-end content web server; traffic is redirected by Apache to the Tomcat server.
OpenMRS has a modular architecture; modules are written to extend the functionality of the core OpenMRS code. The module architecture is custom for OpenMRS, but is very similar to Firefox and Eclipse extensions. Modules can be implemented to extend either the model or views of the application. The project has developed a "module repository" to aid people in locating and utilizing modules for their installation.
OpenMRS development stack uses a range of tools to support their development process:
- Trac is used for project management and bug tracking. The process is that anyone can self-create an account and then create a ticket.
- Mediawiki is used for all documentation about the project, and anyone can self-create an account and add/create/edit pages. The wiki also serves as the homepage of www.openmrs.org, so it is the entry point for developers and others new to the project. The wiki also serves as a hub for collaboration; a range of discussion take place on the wiki's “user” pages, such as what each user is currently focused on. As part of the process, discussion items are migrated to Trac tickets if feature requests emerge, or bugs are identified.
- Subversion is used for the source code repository and code version control. Subversion allows new code to be committed to the database, tracks changed files and their histories, and manages the unique number assigned to each “build” of the code. Subversion accounts are linked to Trac, and users are given permission to commit code based on several criteria. “Core team” developers have full commit access, whereas new developers that request accounts are only given the ability to commit to their module. New developers can submit small bug fixes to the alpha/trunk, but new features are developed in branches before being merged into the main trunk. Patches to address bug fixes and other code changes are attached to Trac tickets and submitted to Subversion by a "core" developer.
- Eclipse is the code development environment of choice; it is one of many options for Java Integrated Development Environments (IDE). Eclipse was selected because of available plugins for integration with Trac, Subversion, and reporting tasks. Mylar is the plugin used for integration between Trac and Eclipse. The IDE also supports integration with JUnit for testing.
- ANT is used to automate nightly builds and manage periodic releases.
- JUnit is used for testing the software, though test coverage is limited at the current time. Many OpenMRS implementations are running alpha code.
Project communication takes place in several primary channels. Two mailing lists, one for developers and one for implementers, are utilized for both notification and discussion. Real-time chatting is done using Internet Relay Chat (IRC) in the chat room #openmrs on irc.freenode.net. Discussion forums are used for focused asynchronous dialog on a range of topics, from general discussion to data models, the code base, usability and modules. Finally, weekly phone calls allow project members to be in direct dialog and discuss pending issues.
Management of the OpenMRS development process is done by categorizing and prioritizing three types of requests. “Project” requests, which are usually proposed by one of the developer, address significant changes to the overall platform, and usually involve large time requirements. “Feature” requests, which are more straightforward additions or enhancements, require less time than a project. Such features are usually engendered as posts to one of the forums or mailing lists, and are then converted to Trac tickets to formalize the request. Bugs, which entail small fixes to current code features, can begin as a post to a forum or list, or may be entered directly into a Trac ticket.
AVOIR/Chisimba
The heart of Chisimba application architecture is the modules. In the Chisimba application stack, each module has its own model, view, and controller objects; the application architecture can be envisioned as building blocks (See attached image). In addition, Chisimba modules are completely “skinnable”, meaning their appearance can be customized on a number of levels. Templates for content and layout can be specified, and each element has IDs and classes for each CSS (Cascading Style Sheet) customization. Version numbers are managed by developers manually. In addition, the generalization of the view layer means that Chisimba applications can run on any device, not necessarily just web.
The Chisimba development stack includes the following tools:
- Eclipse is the IDE, in part because it allows for plugins for code completion, integration. It also supports built-in CVS commands to allow committing from within the IDE.
- CVS is used for code version control. It offers online tools for viewing what is happening on different branches/modules. In addition, it can be accessed using the command line from within Eclipse.
- ANT is used to automate the build process, for nightly builds and monthly releases
- PHPUnitTest is used to support the testing model for the Chisimba core, but is not required for modules.
- Mantis is used for tracking bugs, where they can be added, tracked, committed, and commented on. Statistics are generated per-developer on bug counts, severity of bugs and bug fixes.
- Ohloh is used to publicly show statistics and information about Chisimba, information which is automatically generated by scripts on Ohloh.
In terms of documentation, the Chisimba project has found that community members can't stay online long enough to edit the wiki, so documentation is done by editing offline and then committing documents to CVS. In addition, the “master documentation document” is also stored in CVS.
Communication is done primarily on mailing lists. The developer mailing list handles questions from developers about access and development, as well as posts from developers about new updates to modules. The implementers list is used by those who are deploying Chisimba applications.
DrumNet
The DrumNet Application stack is Java-based. Tomcat is used as the application server, and Spring is used as the application framework. Database components are managed by Hibernate, and JSP is utilized for user presentation. In addition, because communication with cell phones is a fundamental part of the DrumNet application, there is an SMS Gateway with a generic communication module,where messages come in through a mail server, and out through either HTTP or SMS.
The DrumNet development stack includes the following tools:
- NetBeans is the IDE, with plugins that support code completion and integration .
- ANT is used to automate the build process, with periodic builds and on-demand releases.
- JUnit is used for testing the core code.
Project documentation falls into two categories. User documentation is authored in OpenOffice and distributed PDF format. Code documentation is done using the Java-standard JavaDoc.
DrumNet code is not currently under version control.
Bugs not currently tracked in an automated fashion, but BugGenie is the anticipated tool when bug tracking is undertaken.
Project communications are done using a single developer mailing list.
Project Development Summary
The following tables summarizes the tools, languages, and other attributes of the projects described in this paper.
| Aspect | OpenMRS | Chisimba | DrumNet |
|---|---|---|---|
| Wiki (document sharing) | mediawiki used extensively | Use openoffice docs in CVS to share knowledge | Documents via email and server |
| Version Control | Subversion | CVS | n/a |
| Mailing lists | yes, 2 main | yes, 2 main | 1 developer mailing list |
| Forums | yes, used occasionally | Yes, rarely used | n/a |
| Bug tracking | trac, for openmrs specific problems, implementations have their own bug tracking, etc | mantis, for Chisimba specific problems. installations have separate locations | BugGenie |
| IDE | Eclipse | Eclipse | NetBeans |
| Modular architecture | yes | yes | no |
| Server | apache/tomcat or just tomcat | apache or litehttp | tomcat |
| Language | java/jsp | php | java/jsp |
| Testing | junit for both core and module, not required, not always done | core tested with phpunittest, required for core, not required for modules. | junit |
| Usability | working on it | Yes, had a lab for it. No progress recently (lost funding) | no |
| Load testing | No | Yes | no |
