Skip to content

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.

[Thanks to Melanie Chernoff, John Scott and Jim Stogdill for helping to cut this post by more than half.]

  • kitplummer

    Awesome, just awesome!

  • ctovision

    Thanks Gunnar for the great context.

  • Jms3rd

    great comments, hopefully someone will listen and stop the group-think madness

  • Josh Doe

    Excellent commentary!

  • James Barkley

    Terrific write-up and I agree that gating access to will be problematic. However, you don’t address code which may have a sensitivity somewhere between “classified” and “completely open”. For instance, what about NOAA/NASA environmental satellites? Power grid agencies (e.g., DOE)? FAA software? For cases like these it might still be useful to have an internal and restricted environment corollary to the public

  • Gunnar Hellekson

    James, you’re right that there’s some software that’s sensitive but unclassified. We may need a home for that kind of thing eventually.

    I think, though, that once we take most (not all) of that software away from the data it works on, it becomes completely mundane and has no security implications.

    Also, we shouldn’t let the perfect be the enemy of the good. The goal is to default to open, for all the reasons I mentioned, and create exceptions afterwards. What concerns me is that will default to “closed”, setting a very bad precedent.


    I think you’re making several assumptions or assertions that aren’t true:
    1) All software development must be open, and there is no value to having an access controlled development environment
    2) Other government agencies don’t have the same requirements that drove the need for an access controlled development environment for DoD. BTW, the need for access controls in driven much more by force protection needs (it’s not the well meaning developers that we’re attempting to exclude) and intellectual property laws than a “sense of safety”. You point out that open environments like github and sourceforge are already freely available to the government, why invest limited resources to recreate them?
    3) will only ever provide DoD with an access controlled development environment and never provide an open capability. Let’s not assume that only what we offer today will be what we offer tomorrow.
    4) If leverages it too will only offer a “gated” development environment. I don’t believe that the specific access control and data protection requirement for have been set, but even if they’re different from’s, that doesn’t mean there’s no value in leveraging the existing capability.


    To set the record straight, there was never a “previous version of”. In 07-08 the JC2 program had a tool called the Federated Development and Certification Environment (FDCE). This tool was custom developed in ruby and focused on managing JC2 requirements and governing JC2 development. While there wasn’t much love for the FDCE tool, there was a great deal excitement about the concept of a FDCE especially when applied beyond the JC2 program. DISA CTO took a task to define a conops for a enterprise-wide FDCE that was initial called the “GIG FDCE”. When initial funding became available at the end of 08, the effort was renamed Beta capability build on the TeamForge product was released in Jan 09, GA on NIPRNet in April 09, GA on SIPRNet in July 09 with incremental releases and enhancements since then.

  • Jms3rd

    I have to say having “” responding to this article is BS, is this collabnet responding? Guy, Rob?, who?
    its a bit disconcerting.
    Since these are the comments of, are these official comments of DISA?
    at least put your name at the bottom of the post

  • Jms3rd

    there was a previous collabnet hosted service prior to the

  • Jms3rd

    “Let’s not assume that only what we offer today will be what we offer tomorrow.”
    - promises promises, yes some day
    lets talk about what you have deployed now versus what some day, some where might be deployed

  • Gunnar Hellekson

    Thanks for writing,!

    > 1) All software development must be open, and there is no value to having an access controlled development environment

    Oh, no. I don’t believe this at all. I think I was pretty clear that keeping some projects closed is perfectly reasonable.

    > 2) Other government agencies don’t have the same requirements that drove the need for an access
    > controlled development environment for DoD. BTW, the need for access controls in driven
    > much more by force protection needs (it’s not the well meaning developers that we’re attempting to exclude)
    > and intellectual property laws than a “sense of safety”. You point out that open environments like github and
    > sourceforge are already freely available to the government, why invest limited resources to recreate them?

    We completely agree! That’s great feedback on about force protection and intellectual property being the primary concern. I was probably papering over some important specifics when I talked about a “sense of safety”. In my mind, I was talking about both security and a cultural sense of safety. Looking back, I can see how that could be read as an oversimplification. If you read a little further, though, I think you’ll find me completely sympathetic.

    > 3) will only ever provide DoD with an access controlled development environment
    > and never provide an open capability. Let’s not assume that only what we offer today will be
    > what we offer tomorrow.

    That’s great! You’ll understand, of course, that I’m only working with the information I have available to me. If becomes more permissive in the future, I think that would be great — and would obviously change my opinion.

    > 4) If leverages it too will only offer a “gated” development environment.
    > I don’t believe that the specific access control and data protection requirement for
    > have been set, but even if they’re different from’s, that doesn’t mean there’s no value
    > in leveraging the existing capability.

    If I take your meaning, you’re saying that because is already built, should assume its limitations because it’s already in production? I think we’ll have to disagree there, for all the reasons I mentioned in my post.

    Thanks for writing!

  • Gunnar Hellekson

    Sorry,, I’m not sure I understand since I’m not as familiar with the history as you are. How were the FDCE goals different than the goals, and why is it unfair to say that there was a previous attempt at “”?

  • Brian Behlendorf

    Disclaimer: I’m an ex-CollabNet employee and current board member.

    Whoever posted as “” should probably clarify who they are, otherwise it’s unclear how much weight to give various claims. The writer does not appear to be a CollabNet employee to me; the ones I know on the project wouldn’t dare to speak psuedonymously as a government project. Let’s also be clear: CollabNet is a tools provider, and while part of that is describing best practices in open communities, the policies around access and control are set by the customer.

    CollabNet has long advocated that if we can encourage better internal collaboration and re-use inside any enterprise on their existing projects (corporate or governmental) then those participants can better grok how to be more and more public with their work – hopefully, leading a project from purely internal to purely public, or incorporating more public code into their private projects. Projects forced into the open without the support of their dev community become abandonware; without stewards and public dev processes, the code deteriorates, bugs accumulate, and the chances of building a productive public dev community are de minimus. Miracles happen, and maybe tossing hundreds of projects over the wall means a few would find enough public interest to fight the learning curve and carry it forward. That’s what happened with VistA – but I don’t think anyone would say that’s how it ought to work.

    So I can reconcile “some projects on need to be private” – private to the developers at a single agency with a single set of deadlines and deliverables, as they would using some other internal or bespoke tool – with the principles that “as many projects as possible should aim to be public.” I would also suggest that in most cases, what has been done in-house is not terribly novel; rather than release an agency’s in-house tool, it’s better to get them to progressively move to open source COTS platforms and components and squeeze their agency-specific needs to as small a profile as possible.

    This is about shifting culture through shifting of tools. It took more than a decade of regular use of the Web before agencies started to feel comfortable pushing their own “social media” strategies. If every new government IT project involved a toolset that had a bias towards transparency and collaboration, then the balance over time will tip from “private by default; public by exception” to “public by default; private by exception.” We can hope.

    Meanwhile: let’s not make this about tools. Git can clone an SVN repo and you can commit finished branches back upstream just fine; if git support at is desired there’s no reason it can’t be added if the customer wants it, that kind of thing is pretty modular. However, consistency of toolset often makes it easier for participants on one project to look in on other projects, or to set up cross-project processes.


  • Gunnar Hellekson

    Great comments, Brian, thanks!

    I want to make sure we think critically about the infrastructure, which is composed of both tools and policies, and ensure that infrastructure is accomplishing an agency’s goals. Since has been successful, there’s a dangerous temptation to take that same set of tools and policies and apply them elsewhere unchanged. For all the reasons I mentioned earlier, I think that would be a mistake.

    Both you and “” (the commenter) rightly disentangle the issue of open, public, collaborative development from internal collaborative development. They’re two different problems, and it makes sense to distinguish them. Unfortunately, they’re conflated at On the front page of the site, though, I read:

    “The system enables the collaborative development and use of open source and DoD community source software.”

    Positioning this way triggers all the concerns I discussed in the article. If was explicit about being an internal collaboration tool, and didn’t position itself as a conduit for open source projects, many of my concerns would go away.

  • Kfogel

    Gunnar, just a “me too” comment: really excellent post, great analysis. Thanks for writing it up!

    -Karl Fogel

  • Guy Martin

    Some disclaimers: The following is my own opinion, not CollabNet’s or’s. The quote Gunnar used from me was from my personal blog (which I used deliberately to post my thoughts on this topic). Also, for those wondering, Brian Behlendorf is correct –’s reply below was not me – I’m trying to find the person on the team who did post so they can clarify here.


    Thanks for an interesting post. I agree with your assessment that we should encourage more usage of and government participation in the Open Source community.

    I appreciate the fact that you took the time to explain why the ‘CAC Wall’ is important to what goes on in However, I’d like to correct a bit of a misconception. You state:

    “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.”

    You are right that this is very serious business – so serious in fact that the community management team that I help lead is very very diligent about vetting new project requests. One of the main criteria we use is making sure that projects aren’t forked ‘just because I want to build custom .mil capability’. Of the 350+ projects on the site, I can only think of two where we’ve approved a ‘DoD fork’ of Open Source, and both of those were for operational security reasons. So, not only do we encourage people to contribute their time and effort to the proper Open Source projects (thanks for noticing BTW), we actively try to maintain an environment that prevents those forks, for the very good reasons you mention.

    You mention that a lot of civilian government CIO’s have taken notice of and have been pushing for a .gov equivalent. Honestly, I don’t necessarily see this as a bad thing. The reason I feel this way is because, despite all the best efforts of those of us in the Open Source community, we are never going to get 100% of the applications written for the civilian government sector into Open Source. That doesn’t mean we shouldn’t continue to try, however, I think provides a solution equivalent to for the problem of inter-agency collaboration. I also agree with you that the unfortunate label of ‘ as Open Source collaboration’ needs to be dealt with, and not repeated for an internal-only (or limited citizen participation)

    As a taxpayer, I’d rather see us solve the ‘silos of excellence’ problem inside of civilian government agencies, while at the same time pushing for more true Open Source usage and participation. If giving civilian program managers a ‘warm fuzzy’ to start sharing their code internally (assuming they wouldn’t be putting out into the Open Source world) within a .gov site is what’s needed, then I think there is value to that. As Brian points out in his comments, maybe having this helps start the evolutionary path toward a more open and participatory approach.

    Lastly, I *really* like your idea of a ‘’ catalog – sort of the program/developer equivalent of, and an excellent way to get participation for all comers (citizens or not). I will say I believe an integrated set of tools provides value for *all* stakeholders within the ‘internal’ All of the different groups (not just development) need to be able to work together effectively in support of system development and deployment, as Brian points out in his comment.

    In the end, I’d rather we be pragmatic about what we *can* change in Federal government software development behavior, and provide a way to at least break down the silos of what remains after we do the best we can to move folks to an Open Source participation model.

    Thanks for helping to push this debate/discussion forward!

  • Robert Vietmeyer

    Sorry for any confusion, I’m the one that posted as

  • Robert Vietmeyer

    I didn’t understand what you were trying to imply, there seemed to be a negative connotation. The JC2 FDCE is primarily focused on managing about 3000 system requirements that had been established for that program as well as reporting to the PM on the acquisition status of sub-system components. It was very Jc2 specific. GIG FDCE was the concept that was renamed to once funding became available. It’s incorrect to state the GIG FDCE was pulled, if that’s what you were referring to. GIG FDCE was renamed because we thought that “” would resonate better with the developer community that we were hoping to support and because after 17 years in the DoD, I’m really sick of acronyms.

  • Robert Vietmeyer

    You’re right, DISA had used collabnet prior to The NCES program acquired hosted services from collabnet in 03-04 time frame to support the development of that program. Those services were eventually terminated because of concerns over hosting DoD software in a commercial facility and because of the decision to focus the program on the acquisition of commercially delivered managed services vs government driving development.

  • Robert Vietmeyer

    I agree. The bigger point I was trying to make was let’s not assume that a would implement the same access control mechanism. I know the OSS community doesn’t believe we’ve gone far enough with, it’s still achieving a significant ROI. I think that the rest of the federal government would also benefit from a similar capability.

    Gated communities and open communities are not mutually exclusive. I think both are necessary.

  • Robert Vietmeyer

    I certainly don’t mean that GSA should invest in reusing any part of if that doesn’t meet their needs. However, if they decide that they need a gated community that meets FISMA requirements (and maybe even HSPD-12), I think DISA has a lot to offer them.

    So far, our investment has primarily gone into ensuring the security and dependability of the platform. If that additional security is either unnecessary or even limiting to what’s needed in for the federal government, I’m sure their not going to reuse our solution just because it exists.

  • Robert Vietmeyer

    I really like your idea for a catalog of open GOTS projects, I wonder how hard it would be for the federal government to create and maintain a Freshmeat or Ohloh like capability?

    For project hosting of open GOTS software, are you thinking something simple like adding github and/or SourceForge to or something more complex like creating a similar solution offered and maintained by the government?

  • Jms3rd

    cool, can you publish the ROI calculations?

  • Gunnar Hellekson

    Oh, interesting — thanks for the background, Rob! I had no idea that could trace its lineage back to FDCE.

  • Gunnar Hellekson

    Oh, interesting — thanks for the background, Rob! I had no idea that could trace its lineage back to FDCE.

  • Gunnar Hellekson

    I think this is where we diverge — making FISMA easier makes sense, but there’s no special engineering for FISMA compliance, since it’s a paperwork exercise. Not that paperwork isn’t work, but it’s not necessary to alter a piece of software for FISMA compliance. You just have to file the right paperwork.

    And as for HSPD-12, I don’t want HSPD-12 anywhere near — as I already discussed.

  • Gunnar Hellekson

    I know that GSA is negotiating terms with some web service providers that allow them to be used for government purposes. Those re-negotiated sites then get posted on Why not negotiate with Ohloh, Freshmeat and friends? As you say, no sense re-inventing the wheel.

    I think for any unclassified projects, unencumbered by IP questions and with unlimited government rights, we should be posting them on github, sourceforge, and so on. It will broaden the visibility of the projects and avoid some of the problems that I described in the article.

    Would that make sense? You’ve been through this far more thoroughly than I have.

  • Robert Vietmeyer

    I believe it comes down to the sensitivity and protection needs of the software the will be developed in If it’s designed to host open projects that have been approved for public release, then I agree that the increase auhthn/authz security would be problematic and limit it usefulness.

    However, if will be used to host sensitive development efforts and software that is not approved for public release, then the increase security and assurance will be necessary, at least for those product.

    While we had to take through DoD’s DIACAP process rather than FISMA, a can state that it’s only a paperwork drill as long as the system, its operational environment, and its operations meet the requirements. From my experience, that’s a rare situation in commercially provided SaaS. So, the challenge is not in acquiring software and implementing the initial service, the challenge is in maintaining secure, dependable operations for your customers while continuing to improve your service capabilities.

    If only needs an open community, there’s a large, competitive market of potential suppliers where internet economies of scale can drastically reduce costs. However, if the federal government also needs a protected, “walled” environment then the choices are much more limited and expensive.

  • Gunnar Hellekson

    Mark the date. I think we agree!

    Do you know of any regulation, law, or policy that would help PMOs decide what would belong on and what should be put out in the open? I know I have my own opinions about it, but once you’ve cleared the classification hurdle, I’m not sure if there’s anything that helps folks make that kind of decision.

  • Gunnar Hellekson

    Thanks for responding, Guy — it looks like we’re much closer to consensus on this issue than I’d imagined. Wonderful!

  • Jms3rd

    don’t forget the NASA, DOE, NIH repo’s already running as well. would be easy to pull them in

  • Kane

    I also really like the catalog idea. One of the problems I see is that if the catalog doesn’t also host the code it is virtually impossible to verify that it passes the mandatory security checks required prior to going live. E.G. If, lets say, WordPress 1.5.xx is given a Certificate of Net-worthiness (CoN) and the actual downloadable code is hosted at, under the current guidance anyone using WordPress 1.5.xx would have to go through a new security scan (and potentially a new CoN depending on the hosting facility) on every independent installation. Obviously if the code is not hosted within a gated environment, it is impossible to guarantee that it is the same code that passed the security scan. This alone is a time-consuming waste of time and funding (something like WordPress could easily take 3-6 months and cost $60,000 to $80,000 to get a CoN).

    Since hosting duplicate projects risks gated forks, how can we keep open source projects open behind the gate while ending the waste of redundant security scanning and testing? A few ideas to hopefully continue the discussion . . .

    Idea 1 – Host the approved code (and only the approved code, no forks) in the catalog. This would allow everyone to use a public project (WordPress for example) and the hosting facility would know it came from a trusted source and already passed the security muster. I see two downsides to this: (1) eventually forks will become inevitable, and (2) it is a duplication of the projects repository which can draw attention away from the project’s existing community. The upside is that implementation costs across the DoD would drop since redundant pre-launch security scans and fixes would drop drastically.

    Idea 2 – Cooperate with the project to host an approved version on the official project site. A project can be packaged and password protected by the governmental organization issuing the CoN, then sent to the project team. Only people in the gated environment can request the password to open the package from the governmental organization who issued the CoN. The downside here is that it’s not fool-proof and requires cooperation and hosting from groups that have no vested interest or need to cooperate or host anything for the government. The government hosting something on non-governmental servers may require compensation or may be prohibited. The upside is that in addition to lowering costs, it provides no incentive to split the original community.

    This pretty much deals with only one narrow aspect of the problem–untrusted CoN’s. What are other narrow issue problems people are running into in-practice? What other ideas do we have?

  • Jms3rd

    to follow up before, is a platform based on collabnet right? so collabnets product has been taken thru DIACAP? right?

  • Jared Jennings

    You don’t want a password, you want a cryptographic signature. This way anyone can verify the signature, and there’s no need to modify or rerelease the original file. The signature file is small and could be hosted anywhere. All of the trust is placed in the DoD PKI, not the means of distribution.

blog comments powered by Disqus