Two of the most frequent questions I get, as GitHub’s Government Evangelist (other than “is that your real title?”, of course), is “what exactly does a Government Evangelist do?”, almost always followed by “wait, but why would GitHub do that?”. Here’s the what and why, along with why it’s important to the open source community that roles like that exist, at GitHub and elsewhere:
What is a Government Evangelist
In a sentence, the Government Evangelist role at GitHub is about helping government agencies to ship (open source) software better — to fold the map in half, and bring the West coast a bit closer to the East coast. We encourage agencies to take the first, often scary step, into the world of open source, open data, and open government, and to ensure that once they do, that the agency has the resources and support they need to succeed.
Use the term “open source” in government, especially around those that wear a suit on a daily basis, and you might conjure up images of hippies with tie-dyed laptops passing around source code like they might pass around an illicit substance. In many agencies, open source isn’t taken seriously, nor is it seen as a potential “enterprise-grade solution”. While closed-source software has dedicated sales teams to have a presence at government technology conferences and explain how their product might improve the agency’s workflow, open source traditionally doesn’t have any such seat at the table. It’s simply not part of the conversation — why would it be?
Why does it matter if GitHub has one
From the outside looking in, the government speaks a very different language and transacts business very differently than the rest of the world. What you and I might call “a website”, an agency, when writing a procurement document, might call that same collection of code a “scalable, cross-platform, digital public engagement platform”. Unfortunately, Google Translate hasn’t yet figured out how to translate between “government” and “geek”.
Government agencies had been using to GitHub prior to the role’s creation, but whereas a private-sector firm might simply type in their credit card number to upgrade their account to a $25 subscription, those same transactions in government require a certain level of white-glove support. Custom terms of service need to be negotiated (government employees can’t simply click “sign up”), new billing mechanisms need to be developed (subscription services can violate the Anti-Deficiencies Act), and government-specific resources need to be curated (misinterpretations of government security and privacy frameworks can render open source a forbidden venture).
The government evangelist role provides agencies with someone familiar with open source who wears a suit, speaks their language, knows the unique challenges they face, and when they approach us to take that first step towards joining the open source community, we can make it easier (and more successful) for everyone involved.
If we’re going to try and break government out of its anachronistic ways, we’re going to need to expose government agencies to new, leaner ways of working. If you’ve got a project, open source or otherwise, and the government can benefit, speaking their language is just the start.
This is an excerpt, originally posted on opensource.com, and is republished here under a CC-BY-SA license.
Prior to GitHub, Ben was a member of the inaugural class of Presidential Innovation Fellows where he served as entrepreneur in residence reimagining the role of technology in brokering the relationship between citizens and government. Ben has also served as a Fellow in the Office of the US Chief Information Officer within the Executive Office of the President where he was instrumental in drafting the President’s Digital Strategy and Open Data Policy, on the SoftWare Automation and Technology (SWAT) Team, the White House’s first and only agile development team, and as a New Media Fellow, in the Federal Communications Commission’s Office of the Managing Director. His paper, Towards a More Agile Government was published in the Public Contract Law Journal, arguing that Federal IT Procurement should be more amenable to modern, agile development methods. More about the author →