Unit 7
How David Eaves teaches Unit 7 (part 2)
Working in the Open
What is this page?
This is a detailed breakdown of how David Eaves, a Lecturer at the University College London's Institute for Innovation and Public Purpose (UCL IIPP), teaches the contents of Unit 7 of the open access syllabus developed by Teaching Public Service in the Digital Age. See here how part one of Unit 7 is taught.
This page is part of a series of twenty-five classes that David developed originally for the Harvard Kennedy School's master and executive education programs, where he taught for eight years, and are now taught at UCL's master and applied learning programs.
We believe presenting diverse ways to teach the syllabus will help others adopt and teach the material in various contexts. See here how Konstanz University's Prof Ines Mergel teaches the same unit.
Who is this page for?
This page was developed for university faculty who teach public administrators or master's levels students in public policy and public administration. This material may also be suitable for teaching to upper year undergraduates.
Class Overview
The previous class focused on how governments can leverage digital technologies to share public information more easily. This can serve several goals including improved accountability or create public value by having members of public build on top of the governments data.
In this class we explore two other ways of working in the open that are becoming increasingly prominent in government. One involves "open sourcing" government practices and software so others can use them. The other are a set practices that allow public servants to work share what they are working more widely to either build trust or solicit input from a wider audience. This class explores the implications, challenges and risks behind open source and working in the open.
This Class' Learning Objectives
By the end of this class students should be able to:
High level understanding of working in the open in a government context
Explain the motivations that governments can have to work in the open
Name some of the most common risks that come from working in the open
Identify situations in which working in the open creates value, and where it doesn't
How this class relates to the Digital Era Competencies
💡 This class has a specific focus on Competency 6 - Openness. See all eight competencies here.
Assigned Reading and Practical Resources
For this class readings, students should have in mind the following questions:
Does “working in the open” or adopting open collaborative approaches undermine accountability?
Many projects like Wikipedia or GCPEDIA/Diplopedia appear to have “flat” organizational structures - what is good and bad about this? How does this mesh with governments more hierarchical structure?
What are the benefits and drawbacks of working in the open?
Core Reading (Required):
Accountability in a Computerized Society pages 25–42 (1996), Article by H. Nissenbaum for Science and Engineering Ethics 2
The Tyranny of Structurelessness (1971), Article by Jo Freeman
The Cathedral and the Bazaar *(2001), Chapter Two of “The Cathedral and the Bazaar”, Book by Eric Raymond (or try the free version The Cathedral and *The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary the Bazaar (2002).
What exporting a country and its digital infrastructure looks like (2016), Article by Rubiks Digital
Advanced Reading (Optional):
The Crowded Boardroom - When the long tail collides with hierarchy: A real life example (2013), Article by Thom Kearney et al.
Reputation Formation and the Evolution of Cooperation in Anonymous Online Markets (2014), Article by Diekmann, A., Jann, B., Przepiorka, W., & Wehrli, S. for the American Sociological Review
Diplopedia Imagined: Building State’s Diplomacy Wiki Diplopedia (2010), Article by Chris Bonk and Tiffany Smith
Detailed Class Breakdown
Class Plan: 75 minutes
The segments below describe the dynamics of each part of the class. The videos were edited to only display the most relevant parts of each segment:
Segment 1 - What is Open Source? – 05'
Purpose of this Segment
In this segment David shares some common traits around what makes work or a product "open source." The goal is to have students understand how an open source project differs from a proprietary or closed project.
➡️ Unfortunately, the recording for this class started after the first segment, so we can't display a video.
Discussion
In this short segment, David first asks students to define the traits that make work or a project open source before sharing his own: "A project people can modify, share and/or contribute to because it is design or source code accessible."
One key goal is to have non-technical students understand how this concept applies to software. However, it is also a goal to have students reflect on how the idea of open source need not only apply to software.
While more optional, David also uses this segment to provide a high level outline of different open source licenses. This builds off the license conversation in the open data class but exposes students to an increased variety of license and the implications of their use. For example that some licenses allow for proprietary solutions to be built using an open source product, while others are "viral" requiring any derivative works to use the same open license.
Segment 2 - The Mechanisms of Open Source Software – 40'
Purpose of this Segment
Enabling other parties to reuse or even shape a product or project can generate an enormous amount of uncertainty and concern. This segment seeks to engage both the risks and benefits of open source "work." It will also engages students to think of what governance of shared assets might look like and seeks to provide successful examples in a government context.
Video of David teaching this segment
This segment tackles the benefits, examples, governance and risks of open source. To make it easier to follow the discussion, we broke this part into smaller clips.
Video 2.1 - The Benefits of Open Source
Before jumping to the discussion about benefits, students are introduced to some common tool and terms used in open source projects.
David starts with a popular tool GitHub and draws an analogy with Google Docs, a tool students tend to be more familiar with. GitHub is like a Google Doc in which tracked changes must be approved by the file owner in order for the document to be published.
David also explains the definition of forking, in which a user makes a copy of open source project in order to start a separate, distinct project. He believes it is useful to have this common vocabulary to be able to talk about open source.
⚠️ Part of the goal of this initial section is to simply demystify some core terms. In a perfect world these explanations would occur prior to class, saving class time for higher value discussions. One place instructors can point students towards to find definitions for a number of technical terms is the Sideways dictionary (sadly this site is not using HTTPS - something to discuss with students!).
Following the short lecture David asks:
What are the benefits of making a code open?
Answers will vary, but some of the points to be highlighted are:
It can increase the scope and robustness of the project if more people contribute work
It can help accelerate the commodification of a tool or service (think back to Wardley Mapping in Unit 2 here) by
increasing the number of users of the service, creating a market with more people supporting the tool
causing stakeholders to align around a single open solution
reduce vendor lock-in if multiple vendors can support a code base
It could improve security as more people test the code for potential threats and bugs
Transforms the project into a public good that others can leverage
Video of David teaching this segment
Video 2.2 - Examples of Open Source
David uses this part of the lecture to make the concepts outline above more concrete. Some of the examples he describes are:
The browser Firefox - David tells the story of how this browser was born as a citizen-lead response to what members of the web community saw as a monopoly threat from Microsoft. Although the number of people who work full time for this initiative is small, there are hundreds of thousands contributors to the open source code.
COVID-19 self assessment tool created by the province of Alberta, Canada - Alberta officials shared the code with the government of Ontario, which now offers an adapted but structurally similar tool. The government of Ontario also posted the open source code on GitHub.
Gov.UK Notify - In 2016, the UK's Government Digital Service (GDS) launched the first version of an API that allows government departments to send messages, emails and letters to citizens. A few years later, the governments of Australia, Canada and Brazil got interested in the tool and started building their own based on an open source code. Today, Canada already has a similar service, the Notify Canada.
MOSIP, an open source identity platform - With the goal of enabling developing countries to develop their own digital identities system, Omidyar Network funded MOSIP, a modular platform that has been used by at least three countries so far.
Estonia's X-Road - Estonia's famous data exchange software is also open source and has been adapted and implemented by countries in every continent.
One key goal here is to have students realize that they have been consumers of open source products and that there are a growing number of governments building and sharing tools using open source licenses. This is an under utilized and poorly understood policy tool already at the disposal of many public officials.
Video of David teaching this segment
Video 2.3 - Governance
This part highlights the problem of governance around open source software. To illustrate, David shows a simple framework he and his student Lauren Lombardo (Harvard Kennedy School MPP 2021) created to understand the level of community engagement in open source governance. The three categories are:
No community, when the code can be forked, but changes to the source code can only be made by the original author (ex: COVID19 dashboards)
Informal community, when the code can be forked and some contributions are incorporated into the source code by the original author (ex: GOV.UK Notify)
Formal Community, when there is a clear group of members that have a shared ability to change the source code and oversee the decision making process (ex: X-Road and MOSIP)
He adds the examples of NIIS, the Nordic Institute for Interoperability Solutions (2'15'') and Kuali (3'43''), an institution that provides open source software to higher education.
Video of David teaching this segment
Video 2.4 - Risks and Challenges
There seems to be several benefits around open source software, but what are the risks and challenges public leaders should be aware of? After a discussion with the class about that, David summarizes the main points:
In theory, having many people contributing to a code has many benefits, but in practice most softwares only have a few contributors. The consequence is that it's easier to introduce malicious code without being noticed;
There is a risk of introducing more errors in the code;
There is a risk of sharing something confidential in between the lines;
It is harder to keep contributors accountable an pinpoint errors to a single person. That's why governance matters so much.
Finally, the key ideas for this segment are:
Governments are consumers are consumers of open source tools
There are huge opportunities to reduce costs and lock in
The main challenges are around the governance
Segment 3 - Working in the Open – 20'
Purpose of this Segment
The digital era and the advances of tools that enable information sharing is also changing the way that governments work. If in the past each department worked as islands, today there are tools that enable more collaboration. So what does it mean to work in the open and what benefits does it generate? This segment discusses these questions.
Video of David teaching this segment
Discussion
This segment starts by deconstructing the idea that working in the open and co-production with the public is new. David shares a couple of examples in which governments were crowdsourcing work, such as the 911 phone line.
911 only works because - sometimes self interested, sometimes good Samaritans - provide government with critical information about the location of fires or illegal activities. Without the public's input the governments ability to allocate these scarce resources would be much harder.
The second idea introduced is that crowdsourcing is a tool, and it can be used both for good and bad causes. For example, the Iranian government once asked for citizens to identify the faces of democracy protesters, a use that makes many students uncomfortable.
The third discussion goes around the benefits of working in the open. To illustrate them, David likes to share the case of UK's Government Digital Service, which shares templates for how public servants should blog. For them, working in the open was a strategic tool which allowed them to:
gain citizens and public servants trust on the work that was being done
identify and recruit talent by showcasing their working practices
engage users for testing and learning
share and spread new practices across government
scale approaches and processes across organization
Another example that David likes to share is the Canadian GCPedia, an internal Wikipedia in which public servants shared projects, memos and other relevant content.
Finally, the last message that should be highlighted in this segment is around the Tyranny of Structurelessness. This concept, which is presented in a famous article by Jo Freeman Joreen, is the idea that there is not such a thing as a completely structurelessness group. What does this mean for the context of working in the open? When people work in the open, is seems that organizations have gotten flat and that everyone can contribute equally. But not having a clear power structure doesn't mean that it doesn't exist. In fact, it's harder to know how people's contributions are being valued in the organization and oftentimes the visibility won't be equitably distributed.
Segment 4 - A Few Thoughts and Myths – 20'
Purpose of this Segment
When people think about working in the open, there are several immediate associations. For example, many think that it's a way to work more collaboratively, meritocratically and democratically. In this segment, David demystifies these and other ideas around working in the open.
Video of David teaching this segment
Discussion
David structures the discussion in two parts: one about myths and one around lessons for online engagement. Regarding myths, the messages he likes to highlight are:
Myth 1: People often misunderstand how 'open source' communities solve problems. Open source is often associated with collaborative work, but in fact it enhances cooperation more than collaboration. The difference is that collaboration implies working together, while cooperation is more about working in harmony. What open source does it that it allows people to work individually and still contribute to a common goal or shared interests, even among competitors.
Myth 2: Online communities are democratic. This is not the case for most organizations, which can range from not having any governance to being autocratic. Still, there are invisible incentives that make the community behave overall responsibly.
Myth 3: Online communities are meritocratic. Eliminating structure doesn't eliminate power inequities, it just makes them invisible. For example, it is common that the order in which members join a community generates power imbalances. There are also many biases, especially in terms of gender and race.
Finally, he shares a few lessons on how to engage online:
Leadership and the norms they create matter
The power structure should be visible to the community so people know how to navigate
When you are not responsive to the contribution, people are less likely to contribute again
Be an architect to foster systems of cooperation, not necessarily collaboration
It is better to have specific concrete tasks than open mic
How can you get support teaching this unit?
We're dedicated to helping make sure people feel comfortable teaching with these materials.
Send a message to mailbox@teachingpublicservice.digital if you want to book in a call or have any questions.
You can also connect with David on LinkedIn.
What are your rights to use this material?
We have developed these materials as open access teaching materials. We welcome and encourage your re-use of them, and we do not ask for payment. The materials are licensed under a Creative Commons Attribution 4.0 International License.
If you are using any of our syllabus materials, please credit us on your course website using the following text:
We are proud to use the Teaching Public Service in the Digital Age syllabus in our curriculum and teaching. Developed by an international community of more than 20 professors and practitioners, the syllabus is available open-source and free at www.teachingpublicservice.digital
Why was this page created?
This teaching material forms part of the Teaching Public Service in the Digital Age project. Read more about it here.
Acknowledgements
David Eaves would like to note that this material was made possible by numerous practitioners and other faculty who have generously shared stories, pedagogy and their practices. David is also grateful to the students of DPI 662 at the Harvard Kennedy School for enriching the course and providing consent to have the material and questions shared. Finally, an enormous thank you must be given to Beatriz Vasconcellos, who helped assemble and organize the content on this page.