Imagine if tomorrow, 10 of the top open-source developers showed up outside the gates of the White House with pitch forks and battering rams, somehow (peacefully) got inside, and was able to convince the powers that be to release the code that runs say, The Situation Room. Do you think once public, the project would have much chance of sustainable success in the wild?
Code born in captivity
Even with the code out in the open and a small team of committed developers, the White House will still have its own, probably Waterfall-ish workflow, its own, private issue tracker, and most importantly, it’s own goals, priorities, and chain of command that the rest of the world wouldn’t be privy to. I doubt the software would be very well documented to begin with, so have fun reverse-engineering half the functionality, not to mention, you’d likely be hard pressed to find a wider use case for such purpose-built code which I can only imagine is written in Cold Fusion or some other unfortunate (proprietary) language last seen when Palm Pilots were in vogue. It’s still a closed-source project, governed by a closed-source mentality and closed-source tools. The code just happens to be available online.
Making code public is the last thing we should be worrying about. Lining up at the gate and demanding to see code (with or without the torches), asking that an agency open source project X, or release an API for the data behind service Y implicitly treats open source as an ends, not as a means. And it’s no wonder that we’re struggling to gain traction in certain circles or are frustrated that people simply don’t “get it.” If we have to ask, it’s too late. The damage has already been done.
Open source ≠ public
We can make all the arguments we want for why open source produces better, more secure software, how it’s already paid for by the tax payers, how it reduces duplication of efforts, or prevents vendor lock in. But none of that matters if the workflow on the other side of the (fire)wall is predicated on a culture of distrust. We need to make the plea further up the value chain. It’s time to backwards integrate.
We should focus our efforts on the 99% of the process that happens before the code makes it out the door, the bulk of the iceberg that’s hiding below the water’s surface. Open source was never intended to be a verb, and we shouldn’t treat it that way. Open source has little to do with code being public. Hitting a publish button does nothing to change the underlying worldview that technology has long since deprecated.
Empowering internal stakeholders
We should be opening the eyes of public servants. Let them realize that their workflow may as well involve a typewriter and a fax machine (if it doesn’t already). To inspire people on the inside - the people coding the software, collecting the data, and writing the policies - that there are much, much easier ways to do things, and then to show them how. To break the bad habits sub-par software has unfortunately ingrained.
Whether public or within an organization, at its core, open source is about open collaboration. It’s about realizing that creating stuff is a team sport. That it’s not a zero-sum game. That erecting technical and administrative constraints to hinder the free flow of information simply serves to introduce friction and decrease the overall efficiency of the system. That for every dollar spent locking things down or defining rigid procedures, you also spend a dollar shooting yourself in the foot. It’s almost as if government employees haven’t heard the story of Encyclopedia Britannica v. the entire Internet.
The technology’s the easy part
We should work to remedy the underlying culture, not its symptoms. We need to focus on making the entire process open from the start, even if the code never leaves the firewall. We need to counterbalance the FUD that is leaving government agencies stranded in the pre-Internet age. Yes, getting access to government source code can have value in and of itself, but if the process isn’t open, if it’s just a one-way code dump, what’s the point? The technology’s the easy part. Buy a developer a six pack and a weekend later you’ll have something comparable, if not better.
It’s about creating communities around shared problems. About recognizing that we’re on the same team. It’s about creating a culture within government - a realization that it’s easier to work together - so that next time, we don’t even have to ask, let alone break down the front gate.
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 →