Meet Ben Balter. He's a Government Evangelist at GitHub, where he leads the efforts to encourage adoption of open source philosophies, making all levels of government better, one repository at a time.
Ben was a member of the inaugural class of Presidential Innovation Fellows and also served as a Fellow in the Office of the US Chief Information Officer, helping to draft the President’s Digital Strategy and Open Data Policy. As both an attorney and a developer, he's probably spent more time pondering and writing about Federal IT Procurement rules than most people would agree is healthy.
Ben will be talking about Software Development as a Civic Service at next week's All Things Open conference, and he answered a few questions for us about what the US government is doing right (and wrong) in terms of open technologies and policies.
Would you please describe your current role as a "Government Evangelist" for GitHub?
In a sentence, the Government Evangelist role at GitHub is about helping government agencies to ship 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-died laptops passing around source code like they might pass around an elicit 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 a seat at the table. It's simply not part of the conversation—why would it be?
Why did GitHub decide it was important to create this role?
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 at GitHub who wears a suit, speaks their language, knows the unique challenges they face, and when they approach us to take that first step, we can make it easier for both parties.
What originally attracted you to open source?
I've never taken a computer science class in my life. My story likely isn't too disimilar from others who got their start within the open source community. Being the token geek in the group, I was asked to make a website for a student organization I was part of. I stood up a WordPress install, started reading what others with similar challenges had done, and modified a line of code here or there to see what broke. Being able to pull back the curtain like that, I remember being simultaneously both amazed and mortified to see that there was no "secret sauce" to the way things worked.
The internet was being built around me, and open source gave me not only a front-seat ticket to watch it unfold, but also provided the opportunity to take a role in shaping it. I began contributing to WordPress shortly thereafter, got hooked, and have written open source code for four federal agencies and the White House since.
You've worked with some of the top technology policy folks in the U.S. Government as a Presidential Innovation Fellow and New Media Fellow. Where do you feel the US government is "doing it right" in terms of tech policy? Where did you feel it most lags?
From the standpoint of workflow, we may as well be using a typewriter. Heck, the process would be essentially the same. An analyst fires up a word processor, types out the policy, and then emails it around to increasingly larger circles of stakeholders, often creating a punch list of proposed changes (using their desktop spreadsheet application, of course) to opaquely track feedback after each round. Did you miss my comments? Did you disagree with them? Who'd you discuss them with and what were the arguments against it?
After several months of this, the document is set in stone and finally pushed outside the firewall, sans this rich pedigree, often as a PDF, and given the pace of technological change, is almost undoubtedly already out of date. I was fortunate enough to be part of the small team the drafted the White House Digital Strategy and Open Data Policy. For the digital strategy, we took the baby step of publishing the digital strategy—a document which begged and pleaded agencies to use machine readable formats—in HTML, rather than PDF, a somewhat unheard of move at the time. For the open data policy, we took that a step further and drafted in, and published the policy as a living, collaborative document on GitHub, where anyone—government employees and civic hackers alike—were invited to submit proposed improvements.
On a substantive level, the bulk of the policies we've seen have, by-and-large, taken basic assumption on how the open source community approaches software development (open standards, shared tools, lean workflows), and codifies them into law. It's an uphill battle, for sure, but there are two areas where we should start to see movement:
- Culture and education: We can't run the government of the 21st century with 20th century skills and workflows, and the way to get there is to cross-polinate life in government with life outside the beltway. Attending non-government technology conferences, speaking freely about ones work (both online and off) without stringent approval requirements, and streaming best-of-breed technologists from the private sector across government for an hour each week to simply show how they approach basic things like deployment, customer service, or managing risk will go a long way to bridge that divide.
- Anachronistic laws: Most developers in government are well versed in the alphabet soup that is the PRA, FISMA, FAR, and ATOs. That shouldn't be the case. We need to let software developers be software developers, not *de facto* lawyers. Policy folks need to rethink how we approach hiring (so we can attract and retain great developers, rather than contracting that role out), how we evaluate risk (so we can lower the minimum batch size before it becomes practical for a project to go out the door), and how we structure contracts (so that developers, not contract officers or tradition proscribe what's needed).
There's been a lot of great momentum generated from the policy side, giving the geeks the environment they need to do what they do best, but it's just the start.
One of your most recent articles rebuts the old argument that open source software is inherently insecure. Why do you think this perception still exists? What does the open source community need to do to lay that FUD to rest once and for all?
There are a handful of reasons for this. For one, it's visibility. All software initially has the same number of bugs, just as I suspect, all text has roughly the same number of typos, given a large enough sample. Whereas a vulnerability in your purpose-built customer relationship system may (A) go undetected if unexploited, and (B) if discovered isn't newsworthy, in open source, those bugs are more likely be discovered before they're exploited, and when they are discovered, given their user base, are broadcast far-and-wide.
There's a great business model to be made for supporting open source and many staples in the industry have done just that. WordPress has Automattic, Linux has Red Hat, and Git has GitHub. Having "a suit" behind an open source project that can be a visible presence at conferences along side their closed-source counterparts, who can answer questions and provide training, and most importantly, who can provide legitimacy to the products they support. All of a sudden it's no longer David versus Goliath, but Coke versus Pepsi.
What will put it to bed once and for all? Time. As in other sectors, we're seeing a consumerization of technology in government. CIOs originally clinged tightly to their Blackberrys and looked down their nose at the iPhone, as not capable of "real" work. Now, it's almost the opposite. Your agency's purpose-built system, regardless of age, is about to get Blackberry'd in a big way.
You're both a lawyer and an open source developer. What's one thing you wish government general counsels understood that they typically don't?
Open source licensing is the over-the-counter (OTC) drug of open source. They're used by lay people on a daily basis, without much guidance from those with formal training in their field. But unlike OTC drugs, where most doctors (and patients alike) know what Advil is and when to use it, MIT, GPL, and Apache licenses, are, by-and-large, a foreign concept within government (and law schools).
As they say on the Internet IANYL ("I am not your lawyer"), but code created by government employees is not subject domestic copyright under 17 USC § 105. Great, public domain, right? But what happens if the Queen of England wants to use that same code? What if I'm a private corporation that wants to downstream that code, but needs to warranty to my customers that it's unencumbered by copyright restrictions? Complicating things further, while the default under US procurement law (the dreaded FAR) is that the government gets unlimited rights to code developed under government contract (and thus can open source it), but by habit (and market forces), almost without exception, that right is negotiated away. Tell your agency's general council that you'd like their sign off to open source something, and you're often entering unfamiliar territory for them. Government attorneys are some of the smartest legal minds when it comes to administrative law, human resources, and procurement, but may not be exposed to intellectual property law, especially open source licensing, as often as open source developers are. Open source licensing has commoditized the way we license intelectual property in the open source world, but that hasn't necessarily made its way to government. Almost without exception, government code should be licensed under a creative commons zero (CC0) public domain license, or if restricted by copyleft clauses, e.g., Drupal or WordPress derivative code, the least restrictive terms possible.
What should we anticipate about your upcoming All Things Open conference session?
Fireworks, a lazer light show, and lots of animated GIFs. Oh, and something about software development as a form of civic service.
I've spent the past five years helping agencies to get code outside the firewall, but that's a very high-touch process, and the results aren't always great. Open source is a very scary prospect for governments at all levels, and there's a lot the open source community can do to help. There's more in common between government and open source than we often let on. Both are about forming communities around shared challenges that we can't solve on our own. Both have branches, bugs, and trolls for sure, and are something many volunteer their time to shape, be in knocking on doors for a campaign or submitting a pull request to correct a typo.
As government franticly tries to absorb as many lessons it can from the open source community, what if the open source community became a bit more proactive. We've got passionate open source developers in just about every town across the country. What if they each spent a single Saturday showing their local webmaster how to create their first commit? What if they explained to their city councilperson the value of open data? What if they organized a small hackathon to show their mayor the true power of the open source community? It's easy to focus on what's wrong with government IT, and how we got here, but I'm hoping to talk about the tidal wave of collaboration that's slowly forming on the horizon, and how developers, designers, and user experience experts who'd never consider themselves a civic hacker is going to become one in the next few years.
Anything else that you'd like to add?
Every metric we have at GitHub suggests that we're about to hit a tipping point for open source in government.
In startups we talk about "the hockey stick", a growth curve with a long tail followed by a steep uptick. If you take a look at the number of active government users on GitHub, you see just that. This summer we crunched some numbers and published a long-overdue blog post explaining the long-tail history of government agencies on GitHub (stretching back to 2009), with more than 10,000 active government users using GitHub each day, with thousands joining each month.
The same holds true if you look at government repositories on GitHub, which I suspect, by now, is nearing the 10k mark as well. When I first started advocating for open source in government, the response was just short of hostile. As recently as two years ago, when I started at GitHub, that same conversation often took a more inquisitive tone, with questions like "what is open source?" or "why should I care?" Today, at least from my perspective, the conversations around open source in government has fundamentally shifted to a place of "how?" How can my organization begin using open source? We've published this project, what are the best pracices? How can we level up our open source game? I've been talking mostly about the US Federal Government, if only because it's something that most technologists can presumably relate to, but this same shift is happening in cities, counties, and states across the country and in countries around the world, with more than 500 government organizations on GitHub today.
Government notoriously moves at a snails pace, but the rate at which open source has and is winning over the hearts and minds of government employees at all levels of government, is nothing short of exactly what we need to change the perception of government IT once and for all.
See the full series of All Things Open 2014 speaker interviews.
3 Comments