Development - for those who want a little more!

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 want to maintain consistancy throughout and so the standards that we are what we want to work with. 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 problem with this approach, especially if they are using the product themselves.

Design Manual - This is a document that contains information about the architecture of the project and how to create plugins among other things. It opens in a new window with ots own navigation.

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 coming 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 during 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.