5 Lessons from European cities using open source software to improve public services
Digital innovation is key to improving public services, and relies heavily on supporting softwares. Cities and governments have a responsibility to exploit digital innovation as it represents a key opportunity for meeting citizens’ expectations of next generation public services and helps cities in solving societal challenges. Open collaboration around software development and data sharing can improve public services, making our cities more efficient, transparent and resilient for residents and visitors. By replicating existing open-source software solutions for public service, cities can stay in control of their data, while accessing wider expertise and networks in the co-development process. The bottom line is better public services at a lower cost.
By Juliette Ténart and Dana van der Zee (Bax & Company)
8 European cities have worked together to collectively improve public services (specifically in the fields of air quality, flood risk and mobility flows) with open-source software solutions and open data. The quality and costs of public services and the time needed to develop the targeted solutions have been assessed through illustrative case studies.
The main lessons are presented below to guide action in other cities.
1. Replication makes open-source software cheaper, faster, and better.
The benefits of open-source software for public organisations are harnessed when replication of software solutions comes into play. Where replication has been successful, meaning a city fully or partially replicates a software from another city, the replicator city has reduced development time drastically from months to a few hours by copying and adapting the codes to the local needs and contexts.
Replication of software solutions is apparent and valuable in different forms. Conversations around replication have inspired others to approach a challenge, gain experience for selecting sensors, replicate components of a software, or replicate a software fully. With the different levels of replication mentioned above, the quality of the software and therefore of the service provided is increased. More brains and hands have gone through the codes, fixed potential bugs, provided feedback and improved user experience.
Replication of open-source software has allowed for a reduction in the costs of services through direct savings in software development, and indirect savings through efficiency of cities’ operations (including material and fuel savings).
2. Challenge-driven helps as a conversation starter, but data determines feasibility.
The challenge-driven approach, i.e. improving public service delivery, was to provide purpose and to make good use of taxpayers’ money. Starting with the challenges helped to frame software development, anchoring the solutions within the organisations (engaging challenge owners) and sustaining funding for maintenance and updating.
Although challenges were useful as a conversation starter, data availability soon became a reality check and guided software development. The quality and quantity of the data available within cities determines whether a software solution can be developed and/or replicated successfully.
Software development that focused on improving cities’ own operations (to improve public services) was more effective, as the cities had control over data and implementation.
3. Solutions should be replicable-by-design: Open, modular and scalable
A main criterion for smooth software replication is building the software ‘replicable-by-design’. This means the software is built so that other cities are able to reuse and customise it. Building a solution replicable-by-design requires a change of mindset to deliver a codebase suitable for more generic use. It has shown great potential, especially for meta solutions that can be deployed and upscaled to different use cases, such as the QR Code Toolkit for managing assets and collecting feedback by citizens. Here, cities actively sought use cases based on the existing software, driven by a desire to replicate code. Matching the software solutions to the use cases is essential and helps in linking urban challenges and data availability.
4. Need for brokerage and facilitation of cross-departmental and inter-organisational collaboration.
´Open source is not about code, it is about community’, as stated by the Foundation for Public Code. Software development and replication requires an ecosystem of developers, multiple data providers, and users. Several stakeholders are involved in public service delivery, and challenge owners (policy advisors, operators) should collaborate with developers. Although this requires time, it generates valuable learning. Urban challenges, for example climate change, often involve many adjacent policy domains (e.g. greening, mobility), organisations, and departments. Internal and external facilitators have effectively stimulated collaboration and progress.
City-to-city replication requires the replicating city or department to be aware of the opportunities and solutions available. The developing city should have the time to develop a solution replicable-by-design, and be available for consultation and guidance on necessary parts of the solution being replicated. By doing so, recognition and feedback for the solution developers is created, resulting in better quality and reduced replication time of the solution. Successful cases were observed where entrepreneurial individuals invested time to support the process of solution development within the city and replication across cities, or where external brokers (consultants, universities) matched people, challenges, and solutions.
5. Benefits of co-development must be explored further
Developing an open-source software solution in partnership has the potential to reduce the development time. The process of co-development can take place in various forms, ranging from several developers physically working together towards the same product or service (strict co-development), to active collaboration, inspiration and sharing of ideas and best practices. Strict co-development took place once, as bringing developers together proved difficult due to issues of availability, timing and priorities. One success story of co-development is illustrated by the IoT registry solution currently used in the cities of Amsterdam, Hamburg, Aarhus and Ghent. Building upon the code-base developed by the city of Amsterdam, the collaboration of in-house developers of the different cities accelerated the development and adoption of the solution in the other cities. Success factors indicated by developers were working together face-to-face, all having an open-source mindset, and because they built upon framework sketches or building blocks developed beforehand. Although this specific case shows potential to accelerate the development and replication of solutions, the willingness to organise co-development sessions remains to be seen, particularly without the context of a specific joint project.