Outsourcing
From OpenEGov
Contents |
Procurement
The initial tender should specify that the software will be under a free software licence. This can be achieved in two ways: either the supplier retains copyright but is contractually bound to place the software under an agreed licence, or the copyright is transferred to the government department. Care needs to be taken over the choice of licence: in particular, one-off licences or licences that are not widely used are likely to cause future incompatibility problems.
Companies responding to tenders may either be companies which specialise in free software or companies which normally produce proprietary software.
Companies in the first category are more likely to be small. This has the benefit that they are likely to be part of the local economy and to have low rates, but the downside that they are less likely to have full-time sales and legal departments to deal with the bidding process. To make bidding easier some of these smaller companies are grouped in the Open Source Consortium, but many others can be found.
Companies in the second category are likely to be larger and to have more experience in management of large projects, but to have less experience both of free software and of the free software culture, and may possibly charge a higher rate if they have to relinquish copyright.
Project management
Outsourcing proprietary software development may involve spending a long time with lawyers clarifying exact responsibilities and penalties, and then handing the entire task over to the contractors until the software is ready for its first user tests. This approach is unlikely to work well with free software development, even if the consultancy involved is a large one. It also loses most of the benefits associated with free software.
The fact that the code is intended to be open has a number of advantages during initial development:
- It is possible to check the quality of the code at any point
- It can easily be seen whether the documentation of the code is adequate
- Additional modules can be generated by third parties if needed
Managing the quality checks can be done in-house or by outsourcing to other companies; if done in-house, programming expertise is needed, and if outsourced multiple companies need to be managed. Either way this stage may involve more in-house work than the IT department is used to. The pay-off is a much higher chance of a reliable end product and the chance to get further testing, maintenance and development done through a community of users. Code developed through normal proprietary development processes is commonly too poorly documented and structured to be released as free software; the act of sticking a free licence on proprietary software is often referred to as 'throwing the code over the wall', and is unlikely to inspire any community around the code.
Community building
The code initially produced should be under a maintenance contract with the original developers. The aim is for this to be short term: it is unrealistic to expect a company to maintain code which is being worked on by others, and undesireable for the users to be locked in to a permanent contract with one supplier. If the code is of any general interest it should be possible to create a community around it. However, this does not happen without effort.
The first stage is to provide a platform for others to access the code. This should include at least the ability to download the code and documentation, a version control system for code changes, and a mailing list. The easiest way to do this is to use one of the web sites which provides these facilities as a public service. The best known is Sourceforge but it may be worth considering other similar sites which are more geared to a particular target audience such as Savannah, which is completely non-commercial, or even push for the creation of a UK-based equivalent to the Dutch site which hosts open-source government software. One temptation to avoid is limiting access to mailing lists and software to the original developers and other government departments: this immediately recreates lock-in by ensuring that no competing programming companies ever see the software.
Just placing the software on such a site is unlikely to create a community, unless the particular software is in strong immediate demand. It needs to be sold to others. In particular, there is a 'boot-strap' problem at the start: people will not join a non-existent community. At the minimum there needs to be a person responsible for responding immediately and informatively to all queries on the email list, which will inevitably at first be mainly about installation. Good documentation for installation is a must to reduce this.
Once a successful community is created, you have a piece of software which will be continually updated and for which there is a pool of developers for any future work.
References
Some of this page was influenced by the excellent paper by Alasdair Mangham describing the procurement process for APLAWS. Alasdair and Camden are not responsible for any of the opinions here!
