We’ve Been Selling Open Source Wrong

TL;DR: We should work to remedy the underlying culture, not its symptoms.

2 minute read

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.

Originally published May 14, 2013 | View revision history

If you enjoyed this post, you might also enjoy:

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