APLAWS: a case study in sustainability

by Aingaran Pillai, London Borough of Camden on 5 June 2007 , last updated

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.


In the latter half of 2006, the Joint Information Systems Committee (JISC) commissioned a study via its Teaching and Learning committee to examine the issues surrounding sustainability of open source software. The resulting report drew together seven case studies of successful but very different open source projects and examined each project’s sustainability model. Each of these case studies has been told from the point of view of the lead developer or one of the key personnel and gives a fascinating insight into the factors that have determined the success of each project. These case studies are now presented by OSS Watch as stand alone documents in a series.

This case study, examining the APLAWS project, has been written by Aingaran Pillai, London Borough of Camden.

Brief description

Accessible and Personalised Local Authority Website (APLAWS) was initially funded through the Office of the Deputy Prime Minister’s (ODPM) Pathfinder programme. It resulted in two main products: a set of open standards, including accessibility and category lists based on the Government Category List (a controlled vocabulary used to describe local authority services) and Dublin Core; and an open source content management system (CMS). Designed by UK local authorities to help deliver their services online, the product suite is currently supported and developed by an active user group of local authorities, commercial suppliers, universities and international organisations.

There are currently over 30 UK local authorities (LAs) using APLAWS for either their website or intranet. It is also used by numerous international organisations such as the United Nations Development Programme, Malaysian and German Universities, Brisbane local authority (Australia), the Chinese meteorological bureau and the Indian government. Support is provided by half a dozen suppliers ranging from small and medium-sized enterprises to multinational companies. It was recommended by the European eGovernment Good Practice Framework.


Under the terms of the grant for projects funded under the ODPM scheme, the software products that were developed had to be capable of being shared, free of charge, amongst other local authorities. When the project began, the APLAWS team didn’t set out to find an open source solution and other projects, certainly, did not go down this route. APLAWS is therefore an interesting example of a kind of ‘accidental’ inter-institutional model of open source software development, where a group of institutions agreed to collaborate on and invest in a focused, but open, development project.

Project history

In 1999, the UK’s Modernising Government agenda was established to change the way Public Services are delivered. One of its key deliverables was to make government services available online, referred to as the Electronic Services Delivery or ESD programme. As a requirement of ESD, all local authorities were obliged to provide a variety of digital and online services, many of which had to be linked to existing back office systems and databases. For example, they had to provide an online facility for paying council tax, or to register births and deaths.

As part of this process, what was, at that time, the Office of the Deputy Prime Minister, invited expressions of interest from councils, or groups of councils, to act as ‘pathfinders’: exemplar projects that would have access to a special £25million fund to develop products that would help councils realise ESD. The key condition of funding was that all products developed through Pathfinder projects should be capable of being shared, free of charge, among all UK local authorities. APLAWS was one of 25 projects chosen; its remit was to build a Web content management system that could be freely adopted by any LA in the UK, and to develop Web standards relating to navigation, metadata and accessibility. The idea behind APLAWS was that the LAs would be able to easily install the CMS and the associated categories and default content and thereby provide a basic level of information to the public very quickly.

The Pathfinder commitment to be able to share the product among other local authorities for no additional cost other than the deployment cost, provoked different responses from different Pathfinder projects; some, for example, achieved agreements with a single supplier that their products would be free of charge for local authorities. The situation for APLAWS, however, was slightly different: we were looking for a robust, highly developed solution with a low level of risk attached to it. At the time, there were very few companies that had a comprehensive Web framework for developing websites. ArsDigita, the original developers of the APLAWS code, were perceived as a large company — they had just opened a UK office — with a well developed product. The fact that it was also open source meant that it could be shared easily, thus ensuring that the product suite remained free to be shared and developed.

Project structure: process and governance

The APLAWS Pathfinder project was a partnership of five LAs: the Greater London Authority (GLA), two charities (Royal National Institute for the Blind (RNIB) and Age Concern) and three commercial companies (Sun Microsystems, Oracle and Red Hat). Led by the London Borough of Camden, the project was divided into five different work strands: Accessibility, Architecture, Content Management and Metadata, Dissemination, and Programme Management. Each of the LAs was responsible for a particular strand:

  • the London Borough of Newham acted as the lead organisation on the Information Architecture strand to develop standards relating to the organisation of the sites driven by the CMS, their navigational structure and their search systems
  • the London Borough of Lewisham led on developing metadata standards, in particular the content types for the underlying database, and worked closely with the architecture strand and the Office of the e-Envoy
  • the London Borough of Bromley, together with RNIB and Age Concern, had responsibility for developing core accessibility standards upon which the architecture of the APLAWS system was built. They worked closely with the architecture group, community groups and engaged with National and International standards (e.g. RNIB, WAI) to get APLAWS accessibility standards adopted as a key recommendation to accessibility considerations for local authority websites
  • the London Borough of Harrow acted as the lead on dissemination and worked with an international event management company to develop and implement a national strategy, including the development of the aplaws.org website
  • the London Borough of Camden provided project management services and were responsible for delivering the core CMS. Part of this role was to support partner authorities but the major part was to work with Red Hat to make sure that the core system functionality was developed and implemented according to the common requirements of the other work strands. The project CMS code was originally supplied by US open source developers ArsDigita1 , who were subsequently bought by Red Hat. They, in turn, incorporated the code into their own CMS product. Technically, therefore, APLAWS was built with the Red Hat CCM2 code and support for Oracle database system.

The other technology partners were Sun Microsystems (hardware) and Oracle (for the underlying database). As the initial APLAWS systems all used Sun hardware, Sun was responsible for enabling the delivery of integrated solutions, from IT architecture to day-to-day operations, and members of the Sun team also supported some of the training. Representatives from Oracle attended the Programme Board meetings and assisted with facilitating inter-authority meetings.

Representatives from the GLA also sat on the APLAWS Programme Board, with a particular interest in the rollout and implementation of APLAWS to other London authorities.

During this first phase of the APLAWS project, most of the development work was done by Camden and Red Hat. There were other developers and suppliers involved, but they worked away from the core code. At this stage, quality assurance was handled informally by a team of people involved in the project (based around major release cycles) and there were no formal meetings between the users and the suppliers—members of the Camden team would go out and meet people on an ad hoc basis. The focus at this time was to deliver a stable product by the end of the project’s funding period.

Whilst working on the project the Pathfinder team found that the categorisation process was bigger than the rest of the development and, in effect, they were trying to build a controlled vocabulary of services provided by all English LAs. In response to this the categorisation process was spun out as a separate work strand with multiple, related threads and a dedicated project team to support it. This became an important requirement for the CMS development—it had to be capable of supporting multiple taxonomies. From a user’s point of view this meant that they wouldn’t have to manually tag content with all the categories from all the lists, they would only have to select one tag and the others would be derived automatically.

Practically, this meant that the definition of the category lists was driving the requirements of the APLAWS CMS and not only was this the first time this had been done in a CMS, it was a practical demonstration of the categories standards working well together within an application and it actually helped people to understand the standards. It was also one of the reasons behind APLAWS’s success.

Growth and development: governance and sustainability

Following the success of the Pathfinder, the APLAWS Project was taken forward in 2003 as the foundation of the Local Authority Websites (LAWs) project—the content management strand of the National Projects programme. The LAWs project was led by West Sussex Council, and there were seven work streams developing various products. The content management, information architecture and standards streams were led by the London Borough of Camden.

The first focus of this phase of the project was to further enhance the content management system. This included adding support to use a fully open source stack and separating the various components of the content management system to ensure they can be developed and extended independently. Under the National Projects phase of development the system was renamed APLAWS+ to show that it was a major new release.

The categorisation work was extended to integrate developments from other projects such as the Life Events Access Portal (LEAP3). The objective was to develop a local authority category list that could be mapped to the Government Category List. This would be a controlled vocabulary for classifying local authority content and important for compliance with the Freedom of Information Act. Existing national standards such as the Government Metadata Standard were also incorporated.

The APLAWS content management system and related products were always intended to be capable of being sustained by the local authority community. During the second phase of the project, a user group was established from amongst managers from the authorities directly involved in the LAWS project4 to take the product set forward and ensure its sustainability.

The user group

The initial user group meetings were organised and hosted by the London Borough of Camden, and in the early stages they were mainly dissemination events. The group consisted of different managers from the different local authorities who had varying levels of technical ability; there were a couple of authorities that actively participated in the online fora, e-mail groups etc. so they managed to keep up with the changes and new functionality. Others, however, were less experienced or didn’t have a technical background and didn’t really understand the open source development model. The user group meetings gave the less experienced councils the opportunity to pick the brains of the webmasters, IT managers and developers from the other councils, and also gave them the opportunity to provide feedback on how they were finding changes and new functionality. As Camden was still making major changes to the code base we also used the meetings to outline the changes we’d made and the new functionality available.

As the principles of open source, the intricacies of its operations and the benefits of using the community development model came to be understood better, the user group matured. The technical teams from authorities other than Camden were getting very good at working with APLAWS+ and developing enhanced functionality themselves. The group was keen to formalise and take its work forward, and the third user group meeting was the first to be held outside Camden. Since then, meetings have been held all over the country, and the format is evolving. For example, one of the ideas being trialled is that of sponsored lunches. In return for being given a thirty-minute slot to present their product or make a sales pitch to the user group, suppliers are asked to pay for lunch.

The user group has been a useful means of exchanging ideas, and sharing experiences on how to take various products forward. The group has since grown and any authority or partnership who has installed APLAWS+ and is actively considering using the content management system for their website, intranet or portal is now invited to attend the meetings.

The development group

Within the user group there was a loosely defined group known as the ‘development community’— those suppliers and local authorities who were not only using APLAWS but who were also actively developing new functionality and submitting bug fixes. This group was led by Camden and Red Hat.

During the Pathfinder phase there had been only one main supplier, Red Hat, with other developers simply carrying out small parcels of development work away from the core code, and only Red Hat developers actually able to commit to the code base. However, as the project grew, more and more suppliers contacted the Camden team asking to become involved. It was in our interest to make sure that there was a healthy pool of suppliers providing support, and while money was available from our funding streams we were able to give these new companies small pieces of work to carry out. Essentially, this equated to paying them to learn the product and develop with it but it also helped us to work out who was most suited to working with us in the long-term. Some suppliers were not able to deliver and did not participate further in the project. Others, however, took APLAWS and made it part of their main offering to customers—one even ran their own website from APLAWS.

As more and more suppliers joined the project and they began to understand APLAWS better their confidence grew and they started digging into the core code in order to develop functionality. Around 2003 this started to become an issue, since it was not possible for them to contribute the code back in to the core product in order for it to be taken forward by the community. In addition, as some suppliers won major contracts and were carrying out significant developments it became increasingly important to encourage competing suppliers to work together. In order to prevent a forking of the code, which we felt would undermine our young development community (especially as it was just coming to terms with the actual process of open source development), suppliers were brought together for discussions and Red Hat were encouraged to open up the code base to allow submissions from others.

This work was formalised in 2004 when Red Hat set up a shared common code base on SourceForge, to which other suppliers could submit code. They also set up an online tracker as part of an informal quality assurance process so that individuals from organisations other than Red Hat could prove that they had a good grasp of the product by successfully submitting bug fixes and patches. Once an individual had proved themselves, they were given write access to the code base. To back this up, Camden acted as a kind of ‘benevolent dictator’, e.g. writing and publishing a development framework and ensuring that core community members, including suppliers and local authorities, were signed up to it. This ensured that there is just one official APLAWS+ release, available under the APLAWS+ banner from the project site, and these actions were formally ratified in 2005 with the formation of the Technical Steering Committee.

The Technical Steering Committee

Usually, within open source projects, a team of principal developers oversee the core product releases. Within the APLAWS community this could be any number of approved suppliers. Thus, to ensure stable and reliable releases, a Technical Steering Committee (TSC) was formed at the Coventry user group meeting in May 2005. The TSC initially consisted of representatives from Camden and two of the most heavily involved suppliers. This group was responsible for the quality assurance process and the delivery of releases.

The TSC adopted a formal development framework which detailed the roles and responsibilities of the suppliers and which placed Camden as the lead organisation. It provided details of the development model, the QA process and the code submission process, with clearly defined criteria for submitting bug fixes and enhancements. Using the criteria outlined in the development framework, the TSC would then assess the code submissions and consider whether or not they should be rolled into the core product during the next release process. These decisions were primarily based on the principles of product stability and value for money for local authorities. Developers of submissions not included in the release for either quality or budgetary constraints were notified of the decision, together with an explanation5. The TSC was also responsible for incorporating the accepted changes into each new release of the product. This included preparing the release notes of what was being changed and regression testing.

Based on this process, a more formal User Steering Committee was later set up. Primarily responsible for ensuring a reliable release process, they were tasked with managing the testing of the release candidates. They liaised with the wider APLAWS+ community to ensure that each iteration of the product was robust and did not break any existing functionality.

Changes to the licence

As the final tranche of ODPM funding came to an end, Camden proposed that subsequent versions of the system should be released under the GNU Lesser General Public License. Changing from the GNU General Public License meant that future modules developed on top of APLAWS+ do not necessarily need to be open source. It was hoped that this would encourage suppliers to integrate their other products with APLAWS+, thereby improving the functionality and appeal of the core APLAWS+ product, and encourage more suppliers and third party integrators to join the community. The suppliers who had been involved in the project were contacted to discuss the idea and they were all in favour. This decision was later formally ratified by the TSC.

Reflections and future

When the project began, the team didn’t set out to find an open source solution. Cost was obviously always going to be one of the key factors, but one of the main considerations was that the product should be easily shared among local authorities. As it happened there was already a highly developed solution which offered the kind of comprehensive Web CMS functionality that was required, and it just happened to be an open source product. Having taken the open source tools, there were then various options open to us as to how we should proceed with the project. With hindsight, some of them were good, others were not so good and there are several things we might consider doing differently if we were doing a similar project again. For example, from our perspective we would probably be more likely to:

  • Pick open source products with established communities and build on top of them. There are numerous framework products that can be used to build on and choosing products with established communities will ensure that members of the existing communities will do the bulk of the development work on the underlying products, which spreads the burden of work.
  • Decide carefully on the technology. APLAWS is written in Java, a lot of the installation scripts are written in Perl and it is specific to a Linux environment. This suite of technologies introduced a couple of problems. Firstly, the use of Java required LA developers to set up and use quite complex code development environments and compilers. Secondly, most local authorities use Microsoft Windows and are reluctant or struggle to install and manage technology that was designed for Linux.
  • Be aware of emerging developments in standards. Since the project started the Java community has developed Java API standards and frameworks, which standardised some of the functionality of APLAWS (e.g. at the persistence layer). These standards have been adopted by the various CMS suppliers.

Where clear standards have emerged it is our development goal to try and incorporate them into our products and to this end the TSC is looking to de-couple and replace the various APLAWS custom code components which have since been standardised by the Java community. The TSC discussed this idea and presented their decision to the wider community for comments, which were taken on board before the final planning to carry out this standardization process. Our overall goal is that we should not continue to use custom-made solutions to content management issues which have now become standardised within the Java community. We aim to look at the functionality that is required for a specific UK local authority and to build these specific requirements on top of the standard CMS frameworks.

There has been growing international interest in the APLAWS+ product, user group and the development model, especially within Europe. This has led to the APLAWS+ community becoming more international in nature. The reason for this is the unique way in which APLAWS+ handles categories of content for the UK local authority domain. This functionality and the associated category list can also be used to define regional or local government domains in other countries. We imagine that this activity will increase in the future.

The OSS Watch briefing note Avoiding abandon-ware: getting to grips with the open development method provides a summary of the open development practices which successfully enable open source projects to become sustainable.

Current status

Since 2006, when this document was written, APLAWS+ has reached version The APLAWS website states that the “APLAWS community is now moving towards becoming user-led” and the bulk of activity seems to have moved to the APLAWS wiki.

Aingaran Pillai is now the CEO at Zaizi Ltd.

Further reading


Related information from OSS Watch:


The sustainability study from which this case study is taken was commissioned by the JISC Learning and Teaching committee and funded from HEFCE’s IT Infrastructure funds. The Learning and Teaching committee is responsible for supporting the learning and teaching community by helping institutions to promote innovation in the use of ICT to benefit learning and teaching, research and the management of institutions.

The sustainability study was edited by Gaynor Backhouse of IntelligentContent and her editorial guidance has contributed in large part to the excellent result.

  1. This was actually an important criterion since the product was seen as being backed by an impressive company and was therefore perceived as having a low level of risk attached to it (as opposed to an open source product developed only by volunteers with no formal support arrangement).

  2. Red Hat Content and Collaboration Management’s CMS is a standards-based open source content management system built on top of the J2EE platform.

  3. Prior to the LAWs project, the Camden development team had been re-developing the Camden website and had carried out a process of categorising council services and the manner in which people used them. To make the website more relevant to members of the public, the team organized the Local Authority services around a series of ‘life events’ e.g. register the birth of a child, find a school place for the child, register a marriage etc. This was the first known attempt to completely categorise and list all the services provided by the LA to be delivered via the Web channel.

  4. This list included London Borough of Camden, West Sussex County Council, Coventry City, London Borough of Harrow and States of Guernsey.

  5. Contributions submitted by the community which are not included within the core product are still available from the ‘contributions’ bundle on the main website.