Shared Development

We aim to make collaborative, open source software development friendly and fun, while encouraging and helping members to follow some simple and effective best practices to ensure that the software is tested and used by as wide an audience as possible. We believe that the best software development practices are underpinned by communication and visibility.

Online, open public infrastructure is key to our strategy, we use:

  • GitHub for revision control and collaborative development;
  • Travis-CI for continuous integration, ensuring software is built and tested regularly;
  • a hosted Jenkins instance for running nightly quality assurance builds; and
  • a hosted Sonar server for automated code quality analysis.

Shared requirements

Open source software projects should not be driven by developers alone. Good software meets the needs of its target user audience. For this to happen the developer must know who their audience is and what their needs are. This is not always easy to establish, especially in open source communities where users are spread geographically and use different communication channels. We recommend using GitHub Issues to gather requirements and roadmap software development.

Shared code

All OPF software projects should have an open license and a publically available source code repository. We have several GitHub organisations that host open source, digital preservation projects. You can find out more on our GitHub page.

Shared testing

Regular testing throughout the development life-cycle is key to delivering high quality software. For effective community testing against requirements there has to be test data that represent the requirements. A good set of test data that accurately and comprehensively represent a set of requirements helps software engineers know when they’re done, and allows users to verify that they are. By using open, shareable corpora and public continuous integration servers everyone interested in a project can see what works, and what doesn’t. This helps the community to prioritise and road map future development basing their decisions on accurate information.

Both individual developers and teams should establish a continuous integration build for their software projects before the first line of code is checked in. We recommend using the Travis Continuous Integration service. You can find out more in an introduction to Travis that also provides pointers to other resources.

Quality & visibility

These tools and practises are intended to encourage openness and visibility at all stages of a softwares life time. We also host a Project Healthcheck that summarises and displays informative indicators. Our Jenkins and Sonar services also provide daily information about builds, tests and code quality.