Working with software development

There are parallels in working with materials and working with the underlying software. For instance, the materials are public and available to modify, enhance and use. There are explicit and implicit working practices, the etiquette, where aligning your practices to the expectations of the various communities can make a massive difference to your effectiveness and to the progress you and the projects make.

Opensource projects

Virtually all the software we currently use as part of RACHEL is opensource software. The current exceptions include the embedded web server used by RACHEL for Android. Opensource fits well with a collaborative distributed way for volunteers, NGO’s, educational establishments, etc. to work effectively. Some governments, including the UK and USA are deliberately choosing to publish more of their software as opensource projects as it’s been paid for by their taxpayers and citizens.

Opensource means you have greater flexibility to work with the software, particularly in the longer term. The tradeoff is you’re expected (often implicitly) to be willing to do some more work yourself or to sponsor competent people to contribute on your behalf. Learning how to be effective can take longer than common software for Microsoft Windows for various reasons. For RACHEL, ka-lite, kiwix, etc the trade-offs are well worth the effort.

Opensource licenses

In brief, you need to be aware of, and comply with the relevant opensource license used by whatever opensource software you want to use, and potentially modify or contribute to. For the current projects used by RACHEL the licenses are unlikely to cause material restrictions.

See http://opensource.org/ which has a good overview as well as lots of much more indepth materials.

Popular software tools and locations

Most opensource projects now use Git as the source control tool of choice. The source code is stored in a Git Respository, and the commands used by developers generally start with ‘git’ together with some additional parameters.

The most popular locations for opensource projects include:

• github.com - used by ka-lite, this book, and many related projects
• sourceforge.net - used by kiwix

Some projects have their own location for their source code, and some project have several locations, some long neglected.

Finding information

• Stack Exchange web sites and particularly http://stackoverflow.com are excellent places to find answers to programming questions. You can also ask questions, participate, help others, etc.
• Development groups, mailing lists, etc. Each project typically has at least one central location for the developers to correspond. Some also use an old chat service called IRC where they ‘chat’ in real time.
• FAQ’s (Frequently Asked Questions) are written by the development team to help newcomers find answers to common questions rather than ‘bug’ the mailing lists, etc. They are unlikely to be all you need, however people expect you’ll have at least skimmed through the FAQ’s as a prerequisite to expecting a response to your question. In other words, if you’re asking a question where the project team believe you’d have found the answer in the FAQ don’t expect them to respond.
• Project Wikis, aimed at developers. Generally these are more complete, or in-depth answers than on an FAQ. ka-lite has a particularly complete wiki for developers.
• Bug reports and Feature requests: Someone else may have posted a similar problem, question request, or concern; so it’s worth reading the current bug reports and feature requests before filing one. They may also help you deal with your more general question such as whether something is expected to work or not.

Etiquette

People appreciate you demonstrating you’re polite, done your research, etc. and are able to clearly describe your situation & request or concern. Occasionally you may get a grumpy response, especially if you appear to be lazy or asking for someone else to ‘do your work’. Whatever happens, the best approach for you and the situation is to be calm, polite and humble. Sometimes others will respond more positively, especially if they can detect your good manners and attitude.

How you can contribute and benefit

Translations and localisations

Testing, bug reporting

Bug fixing and enhancements

Custom variations

Sometimes you’ll want to develop the software to do different things than the original project team. Provided you’re willing to accept the extra workload and burden of bringing another software project to life, opensource projects will permit you to create a derivative work (project) provided you comply with the software license agreement of the upstream project. One of the longer-term challenges will be managing and merging updates from the upstream project(s).