Why the Healthcare.gov fiasco SHOULD teach us to Open Source Government Application Development.

We Spent How Much?!

According to The Daily Beast the United States Government has spent $118 million to build Healthcare.gov and another $56 million in fixing it…and based on the fact that the site isn’t expected to be fully patched for some time yet I wouldn’t be surprised if the total cost in “fixing” exceeds that of building the system in the first place.

Image courtesy of OpenClipart.org and Iwan Gabovitch
Image courtesy of OpenClipart.org and Iwan Gabovitch

I’m not going to take a position on the Affordable Care Act (ACA) – I try to avoid speaking publicly on controversial issues…but I would like to suggest a lesson we can learn from the ACA that I don’t think will be (very) controversial across party lines – that the Government should utilize open source in the development of applications as a standard rule.

Now, I’m not particularly interested in arguing that every government project should be open source – I’ll be happy if 95-99% of them are. I understand that some people rightly or wrongly believe that using open source in sensitive areas could cause security risks. I’ll let Kevin Clough and perhaps Richard Stallman[1] argue that point.[2] But for the vast majority of projects (Healthcare.gov for example) I can see no reason why the development should not be open source and believe there would be significant advantages to such a course of action.

Lets take a look at the specific ways in which open source development could have reduced or eliminated the issues involved in the Healthcare.gov launch:


The government (not just one department, but its entirety – e.g. the white house and congress) and the public could much more readily have seen that issues were arising, deadlines were slipping, etc.  and made necessary adjustments.

It is a constant problem within organizations that individuals at higher levels make decisions without the proper knowledge base upon which to make such decisions. This can result in unrealistic timelines and even if the timelines are realistic, if unexpected issues arise and there is slippage, there is a temptation to “gloss over” the setbacks and “hope” that the timeline can still be met.

This oftentimes results in extreme pressure on those actually working on the application as they are pressured to produce more, quicker – which, especially in the case of programming – is unwise. The more you pressure programmers the more likely they are to make mistakes, to take shortcuts and the more hours you demand of them the less productive they will become and, again, the number of bugs will grow exponentially.

Bug Fixes

Open Source software is oftentimes very stable and secure because of the number of eyes looking over the code. Further, individuals who are amateurs can make small contributions that allow the programmers to development on system architecture and bigger issues instead of stomping out bugs and making aesthetic improvements.

It would make sense for the Government to take a similar approach to Microsoft, Google, and Yahoo! on this front – each offers cash rewards for the discovery of issues. This is a relatively inexpensive way to get folks to pour in their energies – and individuals receive (for them) a significant compensation (hundreds to thousands of dollars – depending on the issue discovered).

Load Testing

The failure to properly load test the Healthcare.gov site is shocking. An open source project still needs robust methods of load testing performed by the core team – but it also benefits from other individuals and organizations implementing the application and discovering bottlenecks.

An open source, distributed team, also could have easily simulated the significant load that the site experienced upon launch – exposing the load issues early enough for remediation.

Code Reuse

When a project is open source the code can be reused by others for all sorts of purposes. The code to this project would certainly have applications in other government projects as well as the private sector. Reuse of code can significantly streamline development timeframes and even if someone in an entirely uses a portion of code for an entirely different project in a different industry – they will oftentimes contribute their version of the function (with enhancements/bug fixes) back to the original project (resulting in better, more flexible, secure, and robust code).


I really am just spitballing here – but I have a hard time believing that the development of an open source system to perform the Healthcare.gov functions would have cost anywhere near the costs expended thus far upon this closed source system. I’d guess that $10 million could have completed the project in a more robust and timely manner via open source.

Lesson Learned?

Please, let us take a lesson from this fiasco. We want more affordable healthcare – we can start by not wasting millions developing an application as a closed system which lacks robustness and stability.

I know some areas of the Government are already working with open source (and that is great) – but this needs to be a greater emphasis. Perhaps (I don’t know) there should even be some legislation that makes the (required) standard for new applications be open source and any applications which are desired as closed source systems should require review by a panel to determine if there is actual, substantial reasons for developing in a closed source system.

[Apparently I’m not the only one to think OSS could have made a huge difference. See this article by Christina Farr over at VentureBeat. Not directly related, but still interesting is Dylan Tweney’s article “Healthcare.gov costs show that feds have literally no idea how to build a big web site” also on VentureBeat. Another article comes from NBC News staff writer Gil Aegerter and can be found here.]

[11/4: Good article from Matt Asay entitled, “Sorry, Open Source Isn’t the Panacea for Healthcare.gov” on ReadWrite.]

  1. [1]Though Stallman would argue for free software rather than open source, but I leave that semantics argument, however important it may be, aside for the time being to focus on an area in which a relatively minor change in procedure (moving to open source development) could make a significant change in cost and efficiency.
  2. [2]There are some excellent arguments on how and why open source technology can be more secure than closed source technology. Specifically, the additional security in closed source systems usually isn’t b/c the systems are actually more secure but a function of “security by obscurity” – in other words, security holes exist, no one knows about them (including those who wrote the software). But I digress…