Over the past decade, I’ve watched open source become standard operating procedure within large and small enterprises. Once confined to software, open source is at the heart of a hardware revolution led by Facebook, not to mention bleeding over into other industries. There’s even an open source ski boot now.
But broad adoption doesn’t necessarily mean open-source code is the solution to all of the world’s problems, much less the failing HealthCare.gov website. Despite petitions and PR to the contrary, it’s not actually clear that open source will solve what ails Healthcare.gov.
Déjà Open Source?
HealthCare.gov’s failure isn’t a simple matter of open and closed. After all, HealthCare.gov already is open source. Well, some of it, anyway. As the developer page on HealthCare.gov indicates:
We’re making our source code freely available on GitHub. All of our educational content about the Health Insurance Marketplace is available in machine-readable formats so that innovators, entrepreneurs, and partners can turn it into new products and services.
See also: There’s No Simple Fix To HealthCare.gov
The problem is that this isn’t the code that needed most to be open. The culprit behind the system failures was the meatier, more difficult back-end software, which was written by 50-plus contractors behind closed doors and released in the old-school, legacy software fashion, as The Verge reports.
Needless to say, it was the back-end code that crapped out when put under a heavy load.
This is inanity at its best (or worst). As Cloudera’s Mike Olson has pointed out, all essential infrastructure technology has been moving to open source for some time, a trend that is likely to continue.
A Problem Of Process, Not Code
It turns out that infrastructure code benefits from having many different people involved so long as their efforts are coordinated in the open. As critics like Paul Ford highlight, HealthCare.gov failed not so much because of its code, but rather because of how it was assembled and rolled out: in secret.
Companies such as Google, Amazon.com, Twitter and Facebook all … deploy lots of small teams that are expected to ship new features and fixes all the time—sometimes daily. Like anything that involves human beings, shipping code can devolve into squabbling, missed deadlines, and flawed releases. The programming community’s key realization is that the solution to these problems is to create more transparency, not less: code reviews, tons of “unit tests” to automatically find flaws, scheduled stand-up meetings, and the constant pushing of new code into the open, where it’s used by real people.
Again, the problem isn’t code. Not really. The problem is process. This needn’t be an overtly open source process, but we’ve yet to find an equally efficient way of code collaboration between disparate developers.
Anarchy In The UK?
Just ask the UK’s director of digital, Mike Bracken. As he tells NPR, a range of UK government websites were beset by many of the same problems that plague HealthCare.gov. As Bracken alludes, the UK government’s IT team was “getting too bogged down in long-term multiyear procurements” and “were trying to predict the future in a digital world that’s changing rapidly.”
Looking at the Healthcare.gov debacle, Bracken faults its cost and its methdology (“large-scale IT enterprise technology, no real user testing, no real focus on end users, all done behind a black box, and not in an agile way but in a big waterfall way, which is a software methodology”).
The solution when Bracken and team rolled out Gov.UK? Lots of open-source software, but more importantly, a much more open and agile development process.
And not just any open-source software. Just because code is open doesn’t mean a) that it’s any good or b) that it contributes to agile development. Whether by license (Apache-style licensing tends to be more flexible than GPL-style licensing) or by code (technologies like Hadoop enable a flexible data infrastructure to allow rapid iterations on the rest of the system), care must be taken to ensure open source equates to open process.
As Bracken told ReadWrite, this approach made “the Gov.UK launch…impeccable.”
More Than Just Open Vs. Closed
Head over to Slashdot and you’ll find no shortage of views that open source is both salvation and stupidity when it comes to HealthCare.gov. This is appropriate, given that it’s neither. Or both.
In general, open-source code will be better for projects like this because it involves open source process. But even where both open-source code and open-source process are involved, choosing the right code and right process isn’t as easy as just blindly saying “open source.” Open source is not a monolithic thing, but rather a composite of many different ways of thinking about open development.
Update (9:27 am PST on November 5, 2013): An earlier version of this post inadvertently indicated that the UK’s initial roll-out of Gov.UK was fraught with errors. The problems were actually experienced with earlier versions of other UK government website’s, leading to an improved process for Gov.UK. I apologize for the error. (Matt)
Image courtesy of Shutterstock.
