Government Software Pedigree (a.k.a. Why We Need Forge.gov)

[Note: edited 9/8/10 to clear up misconceptions about my involvement in Forge.gov]

I'd like to talk today about why a system similar to Forge.mil is a good idea for Federal government civilian agencies. I'll preface this with full disclosure: I work for CollabNet, the main infrastructure provider for Forge.mil. The CollabNet TeamForge product is the 'glue' underlying Forge.mil, but it allows for additional services to be 'plugged in' in the future. My role in Forge.mil is that of a community management consultant (and part-time day-to-day community manager). Despite the fact that the GSA (General Services Administration) is looking to the DoD (specifically DISA) to help them replicate the success of Forge.mil, the main point here is not to sell TeamForge, but, instead, to make customers and communities successful from a cultural and process standpoint.

Therefore, I'm posting this here for neutrality rather than at the 'OnCollabnet' blog. What follows is my opinion (and mine only - I'm not officially involved with Forge.gov, though I'd be happy to consult if asked) of why a 'Forge.gov' would be a valuable resource for the US government and its citizens, based on my experiences building Forge.mil, as well as similar 'internal community source' systems for previous employers such as Sun Microsystems and Motorola. The genesis of this post was a very logical and probing question asked by Ryan Brady on Twitter:

'What can a Forge.mil clone offer that you can't already get through popular and proven svcs?'

Ryan also asked a follow up question regarding why we should consider spending the money for this rather than use existing external services (by which, I presume he means one of: github, sourceforge.net, or code.google.com).

Though I tried to answer Ryan within the confines of Twitter's 140 characters, I thought it was important to lay out the 4 areas I think are important to consider when determining what solution to use for a civilian cross-government agency code collaboration initiative.

Pedigree of Contributors



Initially, a site like Forge.gov will probably be for internal government agency use only. That's not to say that private citizen involvement won't become a critical factor, but the pedigree of people participating in software development for government systems is going to be HUGE. Even if code reviews and a more 'Open Source' development model were followed, being able to positively identify and vet individuals contributing to common code utilized by multiple government agencies is critical to protecting our country's infrastructure. That being said, as a firm believer in Open Source, and having a knowledge of how it has helped innovation, I don't want this to become an excuse not to have citizen participation, but given the relatively weak identity mechanisms in use at github, sourceforge.net, and code.google.com, I can't imagine using those systems to develop or host mission-critical government code.

Whether we in the Open Source world agree or not, 'sharing' and 'Open Collaboration' are not things that come easily to the government mindset, and having a 'Forge.gov' type solution solves some of the perception problems as well when trying to get agencies to cooperate and collaborate. Unlike external sites, participants feel there is some 'safety' in participating in a system sanctioned by and using a .gov domain.

The public sites do serve a valuable purpose, though, for open source components that may be used within government systems. I believe that government needs to continue to work with components in the Open Source world where necessary and contribute to communities on the external side as well.

Finding Government-specific Code for Reuse



On public development sites, it is sometimes difficult to build up communities of interest around specific topics, or to find something specific you would like to reuse or work on. Even if you do find it, there are usually multiple competing projects that are difficult to characterize as to their usability. Having a centralized 'Forge.gov' entity would allow for community building & reduce duplication of effort by a simple project qualification process (something which has let us successfully connect multiple duplicate project efforts in Forge.mil). Since the public services mentioned earlier are really trying for the opposite effect (multiple competing efforts), it would be nearly impossible to implement something there that allows for ease of use when looking for code with GPR (government purpose rights) or similar restrictions.

Government Controlling Its Own Destiny



As much as some people may consider this next point 'Big Brotherish,' I think it is critical for software infrastructure used for mission-critical government systems to be within the control of someone other than a corporate entity. No offense to github, Google or Sourceforge.net, but what would happen to not only code and data, but to the accumulated knowledge collected in these public sites if they decide to move to another business opportunity, or go out of business altogether? I know that Google has done a good job of making customer data in its systems portable, but in the extremely unlikely occurrence of Google going out of business, migrating all of that data would be cost prohibitive to the US taxpayer. Having a centralized government infrastructure whose costs could be spread out over the agencies involved is a small price to pay for controlling the destiny of code and knowledge critical to our country's infrastructure.

A Platform for All Stakeholders



Lastly, the public services for code collaboration mentioned earlier all have a few things in common, not the least of which is a focus mostly on enabling collaboration among developers. As a former developer myself, I'm not necessarily against that. However, as someone whose job is now to sit 'in the middle' of developers, testers, project managers, and senior leaders/decision makers while getting them all to collaborate and cooperate, I realize the value of having a platform 'in house' that can be tweaked and modified to allow for integration of other capabilities for these additional stakeholders. Among these necessary capabilities are:


  • Enablement of CI (continuous integration) tools

  • Requirements management/traceability

  • Provisioning of cloud services for development/testing/production
  • Integrated knowledge management



Services like github, Sourceforge.net, and code.google.com have advanced the state of the art in software development and have helped push innovation forward in the technology space. However, seeing what can happen if you take the best of those environments and utilize them internally where it makes sense, I'm comfortable with saying I believe we need a civilian equivalent of Forge.mil - if for no other reason than it takes away one more excuse from government agencies that don't feel 'comfortable' sharing critical code or other technologies 'in the open.'

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. However, I'd urge those folks to think seriously about the balance between security, reliability and transparency when talking about federal government systems that control everything from the IRS, to Veterans Affairs, to Health and Human Services. A centralized Forge.gov that utilizes a strong identification/authorization model gives us the best part of community development while allowing us to protect a critical piece of our national infrastructure.

Comments

Popular posts from this blog

Great Panel Discussion!

Community Management is a Career, Not a Job

The Power of the Open Source Periphery