Project35 Design Manual - for Developers

We've worked with various developers in the past and have found it to be enormously beneficial. We've decided that instead of hiding away our code as some people choose to, we are very open about how it all works. If you think you'd like to get involved in some aspect, let us know. We would ask that you have a look at the way the code is formatted for things such as variable naming and layout before you do though. We would expect you to use the coding conventions we have adopted to ensure a high level of consistency in the code base. You would also be responsible for the initial testing of any modules and we would expect you to provide documentation for your work. It might sound like a lot but we have found that most developers have no problems with this approach, especially if they are using the product themselves.

Some of the aspects of the development section may be a little long so we have divided them into sections linked to from the list below.

Project philosophy towards development

The project began as an effort to provide free software tools that could help support activities in the developing world. The main motivation for doing the work came from humanitarian rather than commercial interests. We already earn a living from other software jobs we do. One of our main development goals is to make a small suite of robust tools that do simple things well. The other main development goal is to produce software that people can adapt without being forced to rely on us. Our experience is that open-source software has the greatest appeal when the people who use it no longer have to depend on the people who made it. We want people who use this to make it their own.

Normally it is difficult to maintain a large, complex software application without a significant and continuous source of resources. However, there are aspects of our development philosophy that make it possible for us to manage this project:

Perhaps the most important aspect of our philosophy is that we assume projects or requrements may outgrow the software. Project35 has well defined development goals and we know when we would like to stop feature development. We want to rapidly stabilise the code base for two reasons. First, we want developers to feel confident that the software won’t change much for the duration of their own projects. Second, we want to support having the learning materials written in multiple languages.

Eventually, your needs may go beyond what the software supports. In these cases, you can either make your own version of it or reduce your dependence on it. To help you stop using the application, we have designed Project35 to support different levels of “buy-in”.

Keywords: "Project 35", "open source", XML, "data modelling", "data entry", ontology, Java, "Tablet PC", Garwood.
Copyright © 2008 Christopher Garwood and Kevin Garwood.