The news about the HealthCare.gov site wasn’t always bad. When the front-end code for the website was released as a prelaunch, it was lauded as a new chapter in government technology. That part of the website was designed to be open source from the beginning, and its front-end code was up on GitHub months before the official October launch of the website. The process was heralded as a major achievement. It was a symbol of a government comfortable with and willing to embrace technology, a government where the President presented the tech demo for HealthCare.gov himself a few years ago to underscore the fact that the government was now that tech-savvy.
So what went wrong?
While the front-end code that went up on GitHub was open source and available through the repository (except for a short period after the October launch when it briefly disappeared), the back-end code was not public. And it was the back-end code that ended up being the breaking point for (and the root cause of) the website’s faults.
Steven Brill’s article for Time outlines the events beginning with the disastrous October HealthCare.gov launch and delves into a detailed exposé on the team that saved the website eight weeks after launch. The hidden high drama of HealthCare.gov comes together in his piece -- there's a government shutdown, proverbial war rooms, server outages, a looming deadline, and a crack team of dedicated tech industry professionals in the middle of it all. Since the code has been fixed, HealthCare.gov has been functioning mostly without error, and people have been signing up for different health-care plans. The White House has even made more of the source code freely available through GitHub.
The most important lesson of HealthCare.gov may be that the experts should be left to do their jobs and that the government should adhere more closely to tech industry standards for launching websites. The problems with HealthCare.gov would never have happened — at least not at the scale that they happened — if the back-end code had been shipped in increments to ever-widening concentric circles of users, if shipping and debugging had been handled simultaneously, and if the source code had been open sourced from the very beginning. All of this would have exposed potential errors to smaller groups before they went live nationally.
Open sourcing all of the code earlier would have eased many of the launch day headaches for sure. However, the lesson for the government — and for all governments possibly — may go further than that. When the front-end code was released, it was lauded as not only a sign of a more tech-savvy government but also as a fulfillment of basic tenets that are at the core of the United States government and, to some extent, democracy in general. Developers know — and more people are starting to accept — that code is speech, and, like speech, it should be free. Even if sharing code didn’t have practical advantages, keeping the code for a website created for the public good proprietary does not make sense.
Because the code was created for the public good (and in the public’s interest) the government is taking the right steps towards making open source a part of its website development policies. This step should be standardized not only because it makes the government more transparent and effective, but also because open source is another means to engage citizens in the work of government. Whether each of us considers ourselves to be political or not, having source code like this available invites developers to use their skills for the public good, doing something they might have done anyway. Open source should be something all democratic governments consider — as a form of democracy in action if nothing else. If democracy is about a government of the people, then open source lets the people take part in the government again.
