 Hello everyone, my name is Ben Balter. My role at GitHub is to help government agencies take their first or second step into the world of open source to make sure that when they do that that they're successful, that they're happy that they have a good experience and that the community has a good experience as well. I've been doing so, I've come up with the idea that government is the world's largest and longest running open source project. Think about it for a second, right? We have a bunch of people that form a community around a shared challenge to solve a problem that they wouldn't be able to solve on their own. We have different branches. We definitely have lots of bugs, definitely have lots of trolls and we treat it like an open source project. So if you start from the premise that government is an open source project, how does that inform how we as a community should approach government and how does that inform kind of the workflows that government should follow to make the best government we can possible? Clicky click, there we go. The one thing if you space out, I know we just got some food or not, so we just got some caffeine if you fall asleep. The one thing that I want you to take away today is that open source has absolutely nothing to do with software. Open source is a philosophy. It's a workflow. It's an opinionated way that says that when you do things in the open, you create better things, but get open source, all the different workflows we're talking about are all content-atnostic. It doesn't matter if you're collaborating on open source software, it doesn't matter if you're collaborating on open data, if you're collaborating on open government policy, all that matters is you're doing things in the open. So if you're not a developer, as I talked today, think through things in terms of your own language, in terms of data, in terms of policy, in terms of pros, in terms of storytelling, whatever makes most sense to you. So before I want to take a look at government workflows today. So we say government is an open source project. How does government collaborate when they have to create different things, create policy, create data, maybe even create the things that power different websites? If you're like me, this is a very familiar site. I used to be a government employee, and this is a default workflow by which governments collaborate today. You have an email that's get sent around, a cross-distribution list, that says, hey, here's the file, the policy that we're working on. It's maybe the name of the file at some point. There's then a string of numbers that somehow, somewhat represents a date, and then Ben's at its final, Ben edited it again, then came edited it too. Right? This is version control in government. This is how we think about collaboration. I like to call that somewhat bespoke collaboration. Every time government employees need to get together to create something, again, whether it's policy, data, source code, whatever it might be, we're reinventing the wheel each time and trying to figure out how to collaborate as if this problem hasn't already been solved. What I like to think is that if you want to look at the best way to collaborate, you look at open source developers. If I want to know the best way to take care of myself, I look at my doctor. Does my doctor take a multivitamin? Does he exercise or she exercise on a regular basis? Take a look at how open source developers collaborate, and you start to realize that there's certain workflows that are becoming the norm within the open source community. Open source developers know that if so much is a single semicolon is off, the entire program is going to be crashing to a halt. So as a result, we've created really, really great tools over the past couple of decades to track every change, whether proposed or realized, and discuss it in a very granular way. So it's not just doing things over distribution lists. It's not just doing things over email through attachments. Because if I send this to you, I have no way to know. Did you get my attachment? Did you miss my attachment? Did you just ignore my changes? Did you think my ideas were stupid? There's not a lot of transparency through process here. You're not really capturing an exposing process. So when you think about it, the workflow that government uses today hasn't really changed since the Cold War. Sure, we swapped out typewriters for word processors, or maybe word processors, things like Google Docs. But by and large, the workflow is still the same. I sit down on my computer at my desk. I write something. I send it out to you to get some edits. And then somehow you collaborate and get that back to me. The problem with that is we still have these quintessential smoke-filled back rooms. At least in Washington, they see you can't smoke indoors anymore, so they're not smoke-filled anymore. But it's still the idea that you had to be part of that conversation in order to participate in. It's like a bad joke that you had to be there in order to get it. If I'm not part of that distribution list, if I'm not on that email chain, whether I'm in the agency or a citizen out on the outside, I can't participate in the conversation. And the starting premise of open source is that the more eyes, the more ideas you have in a conversation, the better the result is going to be. So let's look at how we got here, at least from the United States perspective, that might inform kind of where we're going to in the long run. So when the country has found it, people had needs for different information. Maybe I'm a colonist in 1776, and I want a copy of the Constitution. I walk over to George Washington, and I ask him for a copy of the Constitution, and we don't really have mechanisms in order to get government information out of the government and into the hands of citizens. That's that kind of bespoke collaboration, that bespoke kind of content sharing process we talked about. So you make the process up each time. Then in 1966, we created something called the Freedom of Information Act, which as I understand, it's very similar to the Official Information Act here in New Zealand. The Freedom of Information Act said, let's standardize the way that when people ask us for information, we don't have to think like, should we give them this information? Is this information releasable? We have a standardized way to know what information can and can't be shared. That's the middle column there. We're talking about the government's response and my use of that information. The problem with that is when you get government information, that's not the end of the conversation, that's not the end of the transaction. Human beings have a tendency to have questions about stuff, to challenge stuff, to want to improve stuff. So in reality then, you have this kind of question and answer phase that happens even after I get that information. I get the information from the government and as we do as a community, as an open source project, we have a discussion about that information. The government then realized in about 2009 or so with the White House Open Government Directive that they kept getting Freedom of Information Acts for the same information. People kept asking about tax records. People kept asking about pollution data. People kept asking about regulatory information. And they said, wait a minute. Rather than waiting for the citizen to come ask us for information, let's be proactive about things. We know what they're gonna ask for. Let's just put things out there and let's simplify then the left-hand side of that kind of equation there. So if you look at it at kind of a macro level, we went from closed government where the information wasn't available. We didn't really have a way to get it out. To open upon requests that if you asked for it, you can get access to that information. To an actual open government where the information is proactively put out for citizens to use. That kind of parallels the way that open source has evolved as well. So let's say you're a lawyer, right? And you write this very important legal document, right? And you send it to me. You're like, Ben, I got this important legal document. And you're like, ooh, this is really awkward, Ben. That's not actually an important legal document. What you sent me is actually an impotent legal document, right? After the fourth character of the first word, you need to insert an R. How would you communicate that typo back to me? If we're in some sort of an office setting, maybe you'd email it, that kind of the email to Ben. Again, Ben's revised final, Ben's edits. Maybe we have some sort of Dropbox or SharePoint mechanism. In government, there's not really a standardized way to do this, and that's how open source started out. People emailing around, like, hey, you should change this file here. You should change this to that. So from basically the dawn of open source to today, we basically had a workflow that looks like this, very similar to that kind of open government workflow. A creator of a software project, be it Apache, be it Linux, be it Firefox, be it WordPress, would publish out code. I, as a user of that information, would consume that code. I'd find a mistake in it. I would modify it. I would create what's called a patch, insert an R after the fourth character. I'd contribute it back to you, and then you'd republish the software out. You have a central point that is a purveyor of information, the keeper of that information, and the rest of the community just kind of out there that can communicate with that broadcast tower. The problem with that is that's not how open source actually worked in practice. I would be using Firefox. I would find a bug. I would email the author of that piece of software, and I'd say, hey, should this be right? I think this is a typo. Maybe you should add this word here. And lots of things are being transacted via email. And then when I had to contribute that patch back, again, that's happening via email. The problem with that is that's no different than that email that's going around your distribution list in your office. You're not exposing that process to other people in the community. You're not creating a conversation. You're having one-on-one conversations and maybe getting some of that information and surfacing it back. But chances are, if everyone in this room notices that I had a misspelling on that slide, if 380 people email me, that's not a really good use of our time, where 379 people are doing work that's already been done before, which is kind of antithetical to the way that open source works. And it was also a very complicated process. This is actually in size one font, the readme file for how to contribute to the Linux kernel. I am a software developer and I don't even understand that. I'm not gonna take the time to go through that process. So what happened was, we went from centralized open source to decentralized open source. We went from a community, where rather having one person that had all the source code, all the keys to the castle, but to trusting people. So that when I downloaded a source code project, I had the entire project, all the history, all the files alongside of it. What that did is that empowered the community to begin to regulate itself. An author would publish out code, the collaborator would modify that code. Then instead of sending it directly back to the author of the software, I'd give it to the community, the community would discuss it, they would evaluate it, they'd make improvements to it. We'd get it to a good place and then all the author has to do at that point is not review into a thorough analysis of the code, but just give it a thumbs up, a thumbs down, hit merge and it automatically gets published out through this virtuous cycle. That's what we call decentralized open source. The other advantage of this decentralization is that we standardize things. If you go to petitions.whitehouse.gov, the We the People Petitions platform where you might try to deport Justin Bieber back to Canada, it's open source. This is how you'd contribute to it. There's literally a one line instruction because we now have a common vernacular for how we can contribute to projects, how we can collaborate around open source software. So we went from closed source to open upon request. I can email you and ask you for the software, maybe put it on a zip file on an FTP server or something like that. To centralize open source, where you're the purveyor of the information, the key master, the keeper of the source code, to decentralize open source, where we have a community, we're all on the same footing, we're all on this together, we're all trying to solve the same problem. If you want to look at that in terms of government to bring things full circle, we went from closed government to open upon request, to open government. And I think the next kind of phase in this evolution, if you follow the idea that government is an open source project is to collaborative government, to which government is not just publishing information out and citizens can kind of review that information, but to which government is putting out drafts of information and we can improve that data, improve that pros, improve that policy together that we're using it as an open source project. And there's kind of three ways that we're seeing this happen. I like to think of it a continuum going from geeky to wonky. On the left side of the, and left side? Yes, on the left side of the equation, you have open source, right? Open source is around, is about geeks, right? It's still black background, green text. The tools are very confusing. On your working in source code, you're working in things that computer scientists and software developers work on. It's websites, it's algorithms, it's things like that. Some place in the middle, we have open data. Open data is consumed by software developers. They're the ones that kind of build the tools to publish it out and to slurp it back in, but it's used by subject matter experts. It's analyzed by wonks. It's part of how they do their job. It's how they do their regulations. And then the far end of the spectrum, we have open government. Things that are completely devoid of source code, but taking those tools, taking those workflows, taking those philosophies and saying, hey, what if we treated the next piece of legislation like we treat a WordPress plugin? Like we treat a Ruby on Rails project. But we put it in this collaborative version trail that the citizens and the government to get together to build something. Again, we're not quite there yet. We're still black background and green text, but I think that's the direction that we're heading. I think all government agencies go down this path through three distinct phases. And depending on where your organization is, whether you're a government agency, whether you're a citizen, and you kind of see where your town is, the first step is government agencies consume open source software. They'll build a Drupal website or a WordPress site or use Ruby on Rails to build some sort of project. They'll then publish out source code. They'll say, hey, we made this great widget, this great module to pull in tweets to publish press releases. Let's put this out to see if the community would like to do anything with that. And it's not until later, later down the path, they start to then realize the value of community, realize the value of open source, and become a member of the community to actively participate, to actively collaborate. So just to close things out, I wanna look at a couple quick examples of kind of this inaction, where this is happening in the United States, hopefully inspire you to bring some back to New Zealand, or at least maybe inspires us to step up our game as well. So the first example is the White House digital strategy. This came out in May of 2012, I believe. And it was normally when the White House publishes out policy, it's put out as a PDF that's kind of static in time in a proprietary format that's very hard to use. We thought for the digital strategy, let's put it out in an open format. So we grabbed Twitter Bootstrap, an open source kind of CSS framework, design framework. And even though no citizen could change any of the content, we consumed open source software, we put it out in such a way that said, hey, we see the value in open source, it's a lot easier for us to use Twitter Bootstrap than to reinvent the wheel, and so it got published out. The second kind of phase of that evolution, about a year after that to the day, was the White House open data policy. The White House open data policy was published on GitHub in a collaborative living, breathing document. So not only is the government now consuming open source, but we're also then publishing out open source. So you can kind of see the underlying code of how things work. It was a policy, it was set in stone, so you couldn't actually change the things that had legal weight to it, but at least there was a conversation that was starting to happen. If you notice at the top there's a big edit this page button. They're starting to get the community involved, trying to engage developers to make things better. And the third kind of evolution of this happened between the summer and now or so. The Playbook and the White House CIO Playbook and the HTTPS standard, both proposed templates, that the HTTPS standard is not yet in law. The White House put this out and says, you guys know HTTPS better than we do. There's an entire community of experts out there more than we can ever bring into the White House in any given day to discuss this. Here's what we're thinking should be the government standard for encryption. Please help us, collaborate on this, make this better. You're the users of government software. So that's a draft policy memo that is up on GitHub that anyone can fork, can modify. You can, again, you have to edit this page button and you can kind of see changes over time. It's no longer things happening in that smoke-filled room. It's things happening out in the open. So for five years from now, 10 years from now, when we go back to look at how things came about, you can see who made what argument in favor of what position and why. So you're going from public engagement to then pulling those things inside the firewall. You say, hey, this is really great. Let's take this workflow and bring it inside between different agencies. The type of problems that agency space, press releases, blog posts, they're not unique to a given agency. Or maybe we can just do it within the agency ourselves. So the last example I'll leave you with is the National Geospatial Agency's GeoCube. They made a crowdsourcing platform for geospatial information. And so what they did is they put out, this is how you can, in a disastrous scenario, where to get an ATM, where to get electricity. And 18F, a startup kind of within the General Services Administration, a government agency in the United States, took that project, forked it, and made some changes that they needed for their own use, submitted them back to NGA without any sort of like interagency peering agreement or anything like that. That's just the true spirit of open source. Hey, this needs a future that doesn't have, can we add this feature? And then FEMA, our emergency management agency, came along, took that project that was created by one agency, modified by another agency, or without touching a single line of code, sort it up into production and is using that today for a crowdsourcing disaster relief. I think that's a great example of where open source can be going if we work together and treat government as an open source project. So we go from interagency to intraagency to public engagement, hopefully one day between different governments as well. Maybe there's some sort of an open source CMS that different governments work on together because when it comes to open source, we're all on the same team. So I said that if there's only one thing that you remember, that it should, wait, what was that one? I already forgot it. It was, if there's only one thing you remember, it's that it's not just about open source, that it's not just about software. If there's two things you remember and that the challenge I leave you with today is as you approach open source, as you take open source back to your organization, just focus on shipping 0.1, not 1.0, as we say in open source. Think the smallest thing you can do to take a step in this direction. Maybe it's making a list of your favorite coffee shops near your office, maybe chocolate chip cookie recipes, whatever it might be, just to go through the motions of exposing one other person that hasn't been exposed to open source and show them this passion, show them this value. And I think they'll start to realize that we can reimagine open government. We can imagine the way that government works as more like an open source project and more of a collaborative way and realize that we're in this together and that we can only make it better if we work through it together. Thank you very much.