What is a Government Evangelist?
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 site”, 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.
If you enjoyed this post, you might also enjoy:
- 19 reasons why technologists don't want to work at your government agency
- Five best practices in open source: external engagement
- Why open source
- Twelve tips for growing communities around your open source project
- Everything a government attorney needs to know about open source software licensing
- Why isn't all government software open source?
- A White House open source policy written by a geek
- The difference between 18F and USDS
- Why you probably shouldn't add a CLA to your open source project
- Eight reasons why government contractors should embrace open source software
- Everything an open source maintainer might need to know about open source licensing
Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →
This page is open source. Please help improve it.
Edit