The future of the government forges

The GSA is currently planning, which is widely assumed to be based on, the much-discussed collaboration platform from the Defense Information Systems Agency, or DISA. is a pretty incredible idea: a single destination for testing, certification, and software development in the Defense Department.

It sounds obvious, but the idea remains revolutionary. For the first time, there would be a single repository for source code that could be shared between the hundreds of agencies, commands, and programs in DOD. Developers would be able to share their work in a familiar, web-based environment. A previous version of was pulled for unknown reasons, but the current iteration is based on the TeamForge product from CollabNet. If you’ve used SourceForge, you get the idea. The DOD is the largest consumer, and one of the largest developers of software in the world. Much of this software is redundant, locked up by vendors and integrators, can’t work with other software, and nobody remembers how to maintain it. There’s no doubt was long overdue.

It’s dangerous, though,  to assume that is a useful template for I think could lead down the same road as and other failed attempts to encourage source code reuse in government. To understand why can be useful and simultaneously poisonous to, you have to first understand how the DOD does software.


Before, say, the mid-1990s, much of the DOD’s software was owned by the government. GOTS, or “Government Off-the-Shelf” as it’s now called, was built and maintained by the DOD and its contractors. This was appropriate for some military-specific systems, but the strategy outlived its usefulness when the government could no longer keep up with commercial enterprises. For many pieces of common software, like operating systems, spreadsheets and web browsers, the open market produced more innovative and higher-quality products. So down came the order: use commercial software. COTS (“Commercial Off-the-Shelf”) was ascendant.

Boeing, Lockheed Martin, General Dynamics, and the other integrators no longer write as much software from scratch. Instead, their business model has changed. They now glue commercial software together, and wrote code to fill in the gaps. Their business model, however, remains the same. Instead of seeking rent on the proprietary software they’ve written on behalf of the government, they seek rent on the integration work they’ve done.

This is a lucrative business: the latest UAV is composed of hundreds of software systems, some commercially available, some written by the integrator. If I’m the integrator, I’m the only one who knows how all the pieces go together and I can charge a handsome sum to anyone who’d like to field their technology on my platform. Think of Apple’s locked-up App Store, but flying through the air with a missile strapped to its belly.

There’s nothing nefarious about this, of course. Integrators are doing what the market commands, and controlling access to platforms is an perfectly legitimate business model. It discourages reuse, though, which means that it’s difficult for the DOD to effectively use the software it purchased or developed. You can read more about this strange market and its consequences in the excellent “Losing the Softwar(e)” by my friend and fellow Open Source for America member, John Scott.

Openness as a Desperate Act

So Rob Vietmeyer of DISA decided to borrow from the principles of the open source community and Internet governance. A more open and transparent development process at DISA could remove barriers to reuse, encourage collaboration, and discourage proprietary or closed systems. COTS software is still king, but where the government needs to control its own integration, set its own standards, and exercise stewardship over its own infrastructure, it can still develop its own GOTS solutions — this time, in an open, collaborative manner. Where GOTS was once insular, slow-moving, and highly proprietary, it can now be produced at lower cost and with lower barriers to entry for new innovations. Because this “Open GOTS” is built using familiar open source methods, the projects have a fighting chance of working together.

The Walled Garden and the Moral Hazard

So far, the DOD software problem sounds similar to the government software problem. Don’t misunderstand, though. It’s not your typical open source development environment. If you talk with the project team, like Guy Martin of CollabNet, he’s quick to correct you if you compare to SourceForge. is something very different. With all the challenges of this profoundly broken market, had to make some serious sacrifices.

The first thing you’ll notice about is that you can’t get to it. Access to is severely restricted. To get access, you must have an official DOD Common Access Card (CAC) or have a DOD employee sponsor you for an “ECA Certificate”. Dave Wheeler of the Institute for Defense Analysis describes it as “gated development.” On the mil-oss mailing list, this is referred to as the “CAC Wall”.

The CAC Wall has some unintended consequences, and raises some very difficult questions. First, it prevents many well-meaning developers who don’t work for the Defense Industrial Base from helping the projects inside. There are literally tens of thousands of developers behind that wall, and keeps that group partitioned from both the public and government employees without CAC or ECA credentials. The bargain is that by keeping these undesirables out, they carve out a sense of safety so skittish program managers are more likely to host their code. The cost of that sense of safety is a much smaller audience than they could muster hosting on more public platforms.

The CAC Wall also creates a dangerous an incentive to split communities. What happens if someone in the DOD wants to hack on a piece of open source code? They’ll host the hack at, and the public could never see those hacks again. If I’ve licensed my project under an open source license, it’s because I want others to contribute. If that code disappears behind the CAC Wall, I’m cut off from tens of thousands of DOD developers. This “ fork” scenario is serious business. It’s a scenario where everyone loses.

Finally, the CAC Wall may create a moral hazard for the developers who live behind it. In the open source community, folks are very careful about what code they commit, and since they’re never really sure who’s a friend and who’s a foe. In a community where everyone’s “trusted,” developers can become complacent, making them more vulnerable to poorly written or hostile code.

Despite these real concerns, the CAC Wall still makes sense for DISA has some very legitimate security concerns about the code that’s being developed. They’ve weighed that risk against the advantages of public scrutiny, cooperation with external projects, and they’ve made the informed decision to keep the code behind the “CAC wall”,  and to their credit they encourage developers to contribute patches upstream wherever possible instead of hosting on as Role Model

So we have a kind of Judgement of Solomon in the platform. Because of its very unique market dynamics, the DOD needs to take advantage of open source projects, the open source development model, encourage collaboration, and reduce its reliance on proprietary platforms. But for that to happen, DISA had to put all the work behind the CAC wall. has attracted the attention of other agencies. How could it not? The DOD has the worst-case scenario: the gravest problem, the most complex market conditions, and the most dire consequences. So other CIOs take notice and the press on this experiment has been relentless.

This brings brings us to the news that the GSA’s Dave McClure is planning, a civilian counterpart to This is exciting. This is also terrifying, because they seem to be following the model by restricting access to only US citizens. Guy Martin says:

I realize that putting up a barrier to entry in the form of positive identification of US citizenship and a vetting process will irk some who believe that everything should be free and open…

Consider me irked. I want to be perfectly clear about this: the compromises made in are dangerous for If were to follow the “CAC Wall” approach, it will permanently damage the “Open GOTS” movement. cannot be may be instructive and inspiring, but it’s a corner-case and fraught with compromises that have diminished its utility. In the case of, it would be hosting unclassified code for civilian agencies. There’s no need to create a “trusted” environment. There’s no need to verify the citizenship or security clearance of its participants. The standard open source mechanisms are more than sufficient: only project leaders can commit code to the repository, a semiformal review procedure for patches, and so forth. In any case, I’m struggling to imagine why the repository would be better secured by allowed access to 300 million people. Let’s agree that making US citizenship a prerequisite is counterproductive, unworkable, unnecessary and most important: it’s un-American.

The entire country of Jordan has adopted the VA’s VistA software for their national healthcare system. Countless overseas researchers collaborate with their US counterparts through open source projects. When we share our source code with the world, it improves the quality of the software and is, in fact, a uniquely practical kind of diplomacy.

Since we don’t need to control access to the projects as we do in, I have to wonder why we would need a prescribed set of tools for hosting each project. TeamForge is a fine piece of software, but there are literally dozens of viable alternatives. Developers are very picky about their tools, and extremely picky about the version control systems that are at the heart of these code repositories. If we presumptuously select tools on their behalf, we create an unnecessary barrier to entry.

The ideal is two forge.govs.

With this in mind, we should break the project in two.

First, is useful as a catalog of open source projects that are used and created by the civilian government, many of which happily reside on agency websites or public repositories already. could be the way that projects and developers easily find each other. The Freshmeat or Ohloh of government, if you like. Let’s call this the Catalog. The Catalog would be as inclusive as possible, tracking the progress of every Open GOTS project we can find.

There are still projects that need an infrastructure, of course, and could provide that. The Repository would be provided by the GSA as a service to agencies, and provide a complete development environment. Here, I’m thinking of github or SourceForge.

I think by splitting these roles, and avoiding the dreaded CAC Wall, we can include the largest possible group of contributors and take best advantage of the excellent open source work that’s already underway.

Am I missing something here? Is there a national security concern that I’m overlooking? Is there an advantage to a homogeneous set of developer tools that I don’t understand? Let me know.

About Gunnar Hellekson

I’m the Chief Technology Strategist for Red Hat’s US Public Sector group, where I work with systems integrators and government agencies to encourage the use of open source software in government. I was recently named co-chair of Open Source for America and one of Federal Computer Week’s Fed 100 for 2010. I’m an active member of the Military Open Source working group, the RHCE Loopback, and a GTO-21 commissioner. I also help run Red Hat’s gov-sec mailing list. I perk up when people talk about cross-domain security, edge innovation, and interagency collaboration through the open source model. Prior to joining Red Hat, I worked as a developer, systems administrator, and IT director for a series of internet businesses. I’ve also been a business and IT consultant to not-for-profit organizations in New York City. During that time, I spearheaded the reform of safety regulations for New York State’s electrical utilities following the tragic death of Jodie Lane. When I’m not spreading the Good News about open source, I’m wishing I had a dog. You can find what I’m reading on Goodreads, what I’m saying on Twitter, and what I’m listening to on

2 Responses

  1. I take your points that should not be thought of for gov.

    I’m advocating; at least that it should be evaluated when making a decision about where to keep project source code. I understand the shortcomings of Or, I thought I did. I realize now, I think, that there are two top level use cases. One is operationally focused, for the #miloss coder; a place to put open source that can be quickly, freely shared, modified, and re-purposed without having to go through centralized, disconnected approval gates. Let users – boots on the ground operators – tell you what works and what doesn’t; what is safe and what isn’t. Is that the gist? I get that is maybe not optimally suited for that. I’d like to discuss this further.

    The other use case, however, is much different: driving contractor (and government) written code into the Creative Commons (if I can use that term here) and away from vendor-owned servers. We are dealing with this at Bridgeborn right now, in fact. A customer has been relying on source code that was on a sub-contractor’s version control server. Further complicating matters, there have been product and version issues with the *version control software*, server licenses, approved clients, and the like. The proverbial camel’s back was broken when the sub-contractor was let go. The prime has no backup plan. It’s a mess. Moreover, the code itself is behind a wall that is a much gnarlier obstacle than the CAC wall. The only people who can get to it are the ones on the project and physically in the building. No one can independently evaluate the code or make fixes, extensions, or enhancements. None of the code is sensitive or proprietary. It’s an “enterprise” project, meaning broad distribution and access. Some parts should be re-usable in other projects. Other parts should be re-using code instead of re-inventing code. Unfortunately, the source code isn’t just “closed.” It’s invisible. It might as well not exist. If the code was in the forge none of these issue would exist. Naturally, there would be other issues. I think it’s worth the trade-off.

    I also still have a lot to learn.

    Good post.


This site uses Akismet to reduce spam. Learn how your comment data is processed.