Home Sorry, Open Source Isn’t The Panacea For HealthCare.gov

Sorry, Open Source Isn’t The Panacea For HealthCare.gov

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 outall 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.

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.