This workshop took place at October 8th 16:00-17:30 at the Code for All summit Heroes Of Tech in Bucharest, Romania
The Smart Cities? Public Code! project aims to explore and develop the concept of public code. Public code is an early stage concept for a type of code developed with the public interest in mind. This means we need to look differently at the software developed for public tasks as compared to software for private tasks. At a minimum, we should guarantee that it is inclusive, usable, adaptive, open and sustainable.
In three international workshops, the context, challenges and opportunities for public code are discussed with various actors in the field. How should we understand public code, what should we expect from it, and how can we create it? What kind of technological and institutional arrangements are needed to shift towards the production of public code?
This workshop is organized by a consortium made out of the Foundation for Public Code, the City of Amsterdam and Amsterdam University of Applied Sciences. The aim is to gather information for the benefit of this research and to start a network of collaborators on the topic.
This workshop
In this workshop we:
- Identify the current problems with software in public institutions.
- Explore solutions: What can we do about this? Who can do it?
- Discuss challenges: What is stopping us from implementing these solutions?
The goal of this workshop is to further develop the concept of public code. How should we understand public code, and how can we create it? What kind of technological and institutional arrangements are needed to shift towards the production of public code?
Participants can include anyone interested in the application of information technology (IT) in public institutions, and the safeguarding of public values in software procurement and development. Experience in city government is welcome but not required.
This workshop is part of a series of events that will lead to a implementation guide for public software, a research agenda, and a consortium for future research.
Introduction
The first workshop took place in Bucharest, during the Heroes of Tech conference, organized by Code for All, an international network of organizations supporting each other to empower citizens to meaningfully engage in the public sphere and have a positive impact on their communities. As such Code for All is firmly embedded in an international scene around civic tech.
In our workshop, the concept of public code was discussed in three rounds, each focusing on a particular question: what are the current problems around software in public institutions? What can we do about that? And what is stopping us from doing that?
The workshop took off with a brief exploration of the current issues with software developed by or in public institutions. The point of departure is a structural shift towards a network or platform society, in which software is becoming an agent in the organizations of all sectors of society. Increasingly software can be understood as a basic infrastructure that underlies all facets of society, including the management of public resources and interactions between governments and citizens. In these processes, software should not be understood as a merely neutral layer.
Instead, it is becoming an agent that acts based on rule sets, organizational goals and ideological preferences and cultural assumptions set in its code. This means that software is becoming an enabling and disabling actor, that can steer interactions in the public domain. In addition, its architecture sets (or fails to set) the conditions for the organization of public values such as transparency and accountability. In other words, software code increasingly equals legal code. Both forms of code set conditions for society to function according to democratically set public values, the former executed by machines and the latter by humans.
If indeed software should be understood as an active agent in democratic processes and the organization of markets and social interaction, what would this mean for the ways that public institutions deal with software design and procurement? That question was addressed in three rounds.
The current problems with software in public institutions
Discussions in this round (as well as broader discussion taking place during the conference at large) can be divided into two themes: the values perspective and the production perspective.
Values perspective
The design of software that fulfills a particular public or civic service vs. the design of principles for public software as a basic infrastructure in society.
Although definitions and interpretations vary, representatives of the civic tech sector present at the conference understand their field as using technology to enhance relations between people and government, or the design of software to empower citizens or civil society organizations in their internal relations, or their relations vis-à-vis governments. Through user centered design processes and iterative delivery, practitioners in this field come to a better understanding of problems existing in civil society and design solutions for these problems. They do this by either appropriating off-the-shelf technologies such as social network or mapping software and open data repositories, or by creating new software or collecting new data sets. This approach can partly be understood as a tactical movement that is strongly influenced by a hacker’s ethic. It’s about collaboratively bending the use of existing technologies toward collectively set goals. Part of it is also more strategic, as some actors also seek to integrate this approach into the workings of existing (government) institutions, or seek to redefine relations between civil society and government.
However, to a far lesser extent does the community address the principles of software design as a fundamental infrastructural layer active in our network or platform societies. On what principles should the software enabling civic interactions be based? In this view, software is not just a tool (e.g. a mapping tool that displays citizen monitored air quality, or a tool that helps citizens report issues of concern to their political representatives). Rather, in this perspective, questions are raised about the principles of software operative in the public domain. How can software be designed so that it is legible and understandable for citizens, for instance with regard to its algorithms that sort data and prioritize certain actors or actions over others? This shift from seeing software as a mere tool to software as a basic infrastructure and active agent in society is so far insufficiently developed.
In our workshop a number of underlying values relevant for public software were articulated. According to participants, public software should be well documented and made legible so that both users as well as (potential) subjects of the code can understand its workings. So far, many discussions have focused on ‘open data’ as a way of making governments more transparent. However, in public software not just the data (which serve either as the input or output for computational and algorithmic processes) but those processes themselves should be transparent. This becomes more and more important as software is increasingly developed with AI or smart contracts that set priorities or enable or disable transactions. Citizens need to be able to inspect the workings of these processes.
Production perspective: software as a product vs software as an ecology
According to participants in our workshop, currently, many governments understand software as a product that they can buy as a one-off to solve a particular need. The whole procedure of procurement is based on these principles. Usually the government defines a particular issue or problem and, based on that, defines a number of requirements and specifications that are tendered to third party developers. Once developed, vendors often hand over the software package to the local government, either continuing the upkeep of the software through a service agreement, or alternatively handing over the management to government officers. Usability and user testing are often low priorities in the requirements and development cycle.
This ‘engineering approach’ in which specifications are set early in the process lacks a more iterative development cycle in which specifications can be set and reframed through various iterations of a design in collaboration between the client, users and designers. In addition, software development should be understood as a living process or as an ecology. Software needs to be able to continuously adapt to shifting contexts. In turn, developers need to be part of learning development communities in which they can exchange knowledge, insights and learnings. Current procurement practices and their attribution of time to the design of specific requirements often prevent both external contractors as well as government officials from taking part in these communities.
Another problem is ‘re-inventing the wheel syndrome’. It is hard to develop software as open source that can be shared across cities.
Next, software procurement and development is mostly still approached like one might order some custom furniture for a municipal building. As a result, the initial round of engagements with digital infrastructure contacted under the rubric of smart cities were often onerous relationships with enterprise software corporations. These contracts often locked cities into long-term, expensive software systems which controlled access to the cities’ own data and decision-making processes. Often the very function of governance was outsourced to 3rd party providers and city governments learned hard lessons about losing control of operations and knowledge that they thought was firmly under their own oversight. Increasingly, cities are learning that commissioning the software that runs their internal functions is more like making decisions about zoning or taxation - some of the most political and important decisions a city can make. However, this insight is currently not structurally embraced in procurement practices.
What we can do about these problems: values perspective
We need to advocate a new vision and understanding of software as a basic infrastructure in our societies and as an active agent in the shaping of the public domain. From a values perspective, it means that the articulation of public values in relation to software should become a standard aspect of policy at a generic level. Such a values perspective should also become part of the development of concrete software projects. A society-centered design perspective needs to be put in place next to or on top of a human-centered one.
What we can do about these problems: production perspective
From a more concrete production perspective, various strategic approaches were mentioned:
- The development of open source government software
- Setting up exchange markets for the reuse of open source
- Development of an international learning community around public software
- Scale-up through cooperation: cities can cooperate and attain scale advantages by collectively developing solutions
- Governments taking back agency in the development of software: not outsourcing everything, but developing knowledge in their own institutions
- Change procurement to make iterative design processes in co-creation between developers, users and society at large easier
- Guarding the streams of data that are being created by, as well as those required for, the software
- Create a ‘datasheet’ taking into account which information is considered when the software automates its ruling
What is stopping us from doing this: values perspective
So far there has been a lack of understanding of software as an active agent and basic infrastructure at a political level. And whereas commercial software developers and platform companies have large sales forces and lobby teams, there is only limited lobby power for open source or public code perspectives. Additionally, there is no public infrastructure for the support and development of open source communities (which exists for things like public broadcasting).
Entrenched interests in the vendor ecosystem (and in some countries also corruption) are not helping to create a broader consciousness about the implications of software for the public domain.
What is stopping us from doing this: production perspective
An open source approach or public software framework are not seen as urgent. Even though the current procurement model often fails, these failures do not have political consequences. People more or less expect software development to be complex and to not live up to the expectations they have. Additionally, the consequences of failures in public software more often than not touch the disempowered, whereas software companies will get their bills paid anyways.
An additional problem is that open source often does not have a ‘help desk.’ Who can you call when something does not work? Or who can you sue if things do not live up to expectations? There is a lack of a broader open source network/community that can be recognized as a reliable and durable partner, setting frameworks and support networks that can guarantee long term quality and support.
In some countries there is a belief that software development should be left to the market, that entrepreneurialism should be stimulated and that governments should not be involved in this sector. The consequence is that government does not employ officers with the skills to judge proposals by market parties or understand what exactly is being sold and what the consequences of acquisition and implementation would be.
Procurement is overly complex and prescriptive.
Reflections
The domain and application
Public software as we have been using it is currently referring to various themes:
- The ontological understanding of software as an infrastructural layer in society that can be understood as a platform and/or an actor. Software is a platform in that its code incorporates particular goals and ideological or cultural views that set opportunities and boundaries for societal actors (in a way that a law or constitution does). It is an actor in that it also executes policy through algorithmic governance.
- A set of standards or a licensing scheme that guarantees public values in software production (e.g. legibility and transparency of decision making).
- A next level open source model that allows governments to share building blocks or modules of software that adhere to public software standards.
- A values-in-design or a participatory design framework for the production of software in learning communities that iteratively co-creates software for the management of various services in the public domain; understanding software as an ecology, and applying not a human-centered design, but a society-centered design.
- A normative ethos: all actors involved in the production or management of public resources should embrace an approach to software and platforms that put public values first, and efficiency or commercial value production second. This goes beyond the mere standards with regard to e.g. privacy or legibility.
We may have to better articulate this stack of approaches, or perhaps choose a focus. Or we may have to better articulate the logic between these layers. That could begin with an ontological understanding of software as infrastructure. That would lead to a normative ethos in which this infrastructural layer should be developed from a public values perspective. Which would lead to a particular design framework, prompting questions, such as “how do we do this?”, and answers, such as “through a values-in-design perspective, learning communities and a set of standards.” The outcome could then be an open source-market place for these technologies. Do we want to tell this whole story? Or do we want to focus on particular aspects? Which of these layers is the focus of the ‘public software’ concept?
So far our interest have been wavering between these layers. In the workshop we started off with the goal to discuss tech questions such as “what should be the specifications of public code?” But we discussed social issues such as illiteracy in governments, the lack of an ‘ecology’ model for software development, and the need for a society-centered design perspective.
Another unclarity in our use of public software is its precise domain of application. Is it about inserting a layer of public values in all software (including commercial), like a privacy law or GDPR standard? Or are we mainly concerned with software that operates in or manages a public domain or resource such as electricity provision, the organization of transport, government-citizen interactions, or even more limited: is it a framework for government technology?
The ‘smart citizen’
We started off by positioning public software against the black box proprietary smart city approach of the city as a service, wanting to contribute to the transition from proprietary smart city software to the design and employment of ‘public code’ that can be deployed by cities in their operational and policy processes in order to better safeguard public values. In addition, we have now found that we also have to define ourselves in relation to the ‘smart citizen’ perspective of civic tech. Civic tech takes a more tactical perspective whereas we take a more fundamental and ontological approach. Civic tech also runs the risk of becoming solutionist, somehow embracing a Silicon Valley or Web 2.0 ethos of appropriating existing tech to solve civil societies’ issues, without a deeper rethinking of the underlying principles in these tools. It is not that we are against civic tech, or smart cities, but both need an underlying public software approach.
What we can do next
There are various things we could do.
- Strengthen ‘ontological’ vision of software as platform and active agent shaping society. There is a bit of literature on this in software studies and platform studies. This could be the underlying philosophical argument for our case, and could be developed in a position paper as well as in a scientific paper or journal article.
- Develop a ‘design manifesto’ or guidelines or process for software development from a public code perspective: a what and how on public software.
- Develop policy guidelines for public code (e.g. is public code something like a GDPR that affects all software and platforms, or is it mainly applicable to particular areas?)
- Develop software standards for public code and a licensing scheme.
- Develop ideas for a public code production ecosystem: what should this look like, who is responsible for it, what kind of market places and collaborations do we foresee, is there a business model etc?
Which of these has our priorities? What is already out there? How can we make these operationable in our next workshop series?