Home » Information Policy & Ethics » Government Experience Design: Open Source
Government Experience Design: Open Source

Government Experience Design: Open Source

This is the final post in a series of blog posts expanding on the four ideas I consider central to government experience design: transparency, listening, adaptability, and open source. In all four posts, I aim to provide concrete ideas for how governments can deliberately think about the experience that citizens have when interacting with them.

Open Source

Open source is a subset of transparency; I call it out separately here because it warrants a bit further explanation. The open source software movement is the idea that, by publishing the source code of a particular piece of software, that software will become stronger because many eyeballs are reading that source code and thinking of improvements and finding security flaws. This philosophy is easily extensible into the government domain; what would it be like if we could crack open the source code of government programs (once again, within reason) and help to find flaws in logic and computation? What if citizens could save governments money because they fixed bugs?

The idea extends beyond software as well, to being able to see how legislation evolves over time – imagine being able to see the original draft of a piece of legislation, then how that legislation was changed, with each legislator’s change listed clearly for all to see. Watching how a key law changes over time to reflect the current state of affairs can be a valuable tool in the citizens’ toolbox. Think of it as “Track Changes” in a word processor; auditability becomes a key component of determining how government is working in the interests of the people.

That’s not to say that open source ideals will always make sense or should always be used. Does it always make sense to allow for the “many eyeballs” philosophy to strengthen government operations? The most straightforward example I can provide here is the judiciary; it doesn’t make sense to pry open the books on parenting proceedings, for instance. There are some facets of what the judiciary decides that do not warrant visibility for the level of impact they provide. There are other examples of when applying this ideal may not make sense. The point here, though, is that those examples are necessarily limited and well-justified.

Government should:

  • Consider that most actions it takes are, by default, auditable. The Freedom of Information Act and its compatriots make it abundantly clear that people can get information about things out of government, for the government is in service of the people. The issue is that there are often roadblocks; formal requests must be made, reviewed, approved, disseminated, and commented on before the information is released. If what the government produces belongs to the people, are roadblocks always necessary? This point was made in the original post on government transparency, but the “more eyeballs” approach functions best when this component is present. It is thus worth restating.
  • Allow open-sourcing internal software when doing so does not adversely affect individuals. Person-based systems – those where individuals are central to the operation of the system and the system would not be able to operate without having an individual selected – are exempt here because these types of systems tend to be about managing “life events” (marriages, court cases, licensing, etc.). Programs, though, that deal with statistical reporting or data that is already publicly available should be examined for open sourcing to allow citizens to understand how the data government holds is being manipulated and used to support decision-making processes.
  • Dive in to open source with both eyes open. Do not simply throw programs out under an open source license simply because they are there. Data dissemination personnel, legal services staff, records officers, and IT staff all need to understand the impact of releasing code and materials to the public. Such an action changes the conversation government has with its constituency, and the ramifications are not to be taken lightly.
  • Consider what could be done internally to foster an “open source”-like culture. The “more eyeballs” philosophy applies to all problems, not just those that are software-related. Culturally, government agencies need to fight the tendency to “silo” information. It is in the interests of government to break down as many silos as possible, as it is only through collaboration across units that agencies can find efficiency gains in an era where funding has already been cut to the bone. This includes reducing the likelihood that something gets done multiple times by different people for different reasons.

Government experience design is less about nitpicking over the details of whether or not a certain government agency should or should not release information and whether it needs to focus on the needs of the people it serves; instead, it focuses on mileposts. There are varying degrees of implementation of government experience design principles, and it is a fairly easy argument that there are deeper and more varied facets than what this series outlines. Part of why this series was written was to “open source” this idea and begin a conversation: what does it mean to engage with government? What does it mean for government agencies to serve the people? Which people? With what services? Do those agencies have any rights to withhold even when they operate within the public realm?

Is it enough to throw information management and user experience design philosophies at government and call it done? No. Government tends to be slower to evolve than other companies; to a degree, they can afford this. This is a funding problem, a person problem, an information problem, a philosophical problem, an environmental problem, and a cultural problem. What tools, then, can government begin to use to better itself? Government experience design proposes that the first step to that is a basic set of tenets, upon which agencies can build. It is not at all a panacea, nor is it intended as one. It does, however, start a conversation; one that, in this author’s opinion, sorely needs starting.

(Editor’s note: This article is the first in a series published on Peter’s blog. We will be featuring subsequent articles in the near future.)

About Peter Ellis

Peter is a 2009 alumnus of the Information School's Master of Science in Information Management program, where he was the inaugural technology officer for the Association of Information Management Students. Since his graduation, he has worked for federal and state agencies with a particular focus on application development, information architecture, knowledge management, and user experience. He currently works for the Washington State Administrative Office of the Courts.

Leave a Reply

Your email address will not be published. Required fields are marked *

*