If there were ever two concepts that are representative of where we are today in technology, they would have to be Government 2.0 and Community. Unfortunately, they are also two of the most overused and over-hyped phrases in our technology vocabulary.
Government 2.0 is a general term referring to a new level of transparency and agility within the Federal space. It has many components, including public-facing efforts like re-launching whitehouse.gov with open source technology such as Drupal (a content management system). However, Government 2.0 also has an inward-facing component relating to how software and systems are designed, built, and managed.
Community, in the context of software development, is the use of collaborative development tools and processes to enable shared use, drive the re-use of code, and expedite discussions and cooperation among all project stakeholders, regardless of their geographical location.
No longer just empty buzzwords, these concepts, utilized by open source communities and projects such as Linux, Apache and Subversion, are driving tremendous value when applied to internal government development efforts. Specifically, community-driven collaborative development builds better software in shorter timeframes, allowing agencies to do more with less.
Forge.mil - A Template for Government Collaboration
Forge.mil is a project initiated by the Defense Information Systems Agency (DISA), the cross-services IT arm for the US Department of Defense (DoD). It's designed to:
The system provides integrated collaboration tools such as source code control, defect and requirements tracking, wiki pages, document management and discussion forums.
One of the most outstanding things about Forge.mil is that it resides inside of the .mil network, but could very well usher in a new era for software development, acquisition and vendor collaboration for all federal agencies. In a nutshell, this project is about building the equivalent of an open source community inside of the .mil domain, so that participants (DoD contractors, vendors, etc.) can utilize a collaborative approach and toolset for their future projects.
Forge.mil was built using the same open, collaborative approaches it is enabling for the DoD. As a result, the initial capability for the system was launched in just 180 days, a quantum leap in efficiency improvement within the defense space. This caught the attention of other government agencies in both the military and civilian arenas, and these groups are now asking how they can participate or build their own "forges" to replicate this success.
Government 2.0 Through Successive Approximations
The early successes of Forge.mil, data.gov, and apps.gov, have inspired questions such as: "When will we know that we've reached Government 2.0, and how long is that going to take?"
That begs the question of exactly what constitutes Government 2.0 and sets an unrealistic expectation of a finite process that has a clear beginning and end.
Clearly, any effort designed to fundamentally change such things as technology acquisition, transparency, or collaboration within the government will not be a "forklift revolution," but an ongoing process that is constantly reviewed.
The Forge.mil team realized early on that a key to its success would be the notion of "successive approximations." The Forge.mil community managers continue to treat their effort as a continuous process, not a finite deliverable. It is critical that the larger government community adopt this same approach, as attempting to build out all parts of what Government 2.0 could, or should, be right away would be expensive and doomed to a lackluster reception by those in the community who need it most. The DoD has been tasked by Congress with developing a new technology acquisition plan, and early drafts seem to correctly recognize a need for "course corrections" or "approximations" as they move toward building a more participative technology infrastructure for government.
Community Building - Government 2.0 Style
One of the best examples of federal cultural change is how IT and other software support systems are developed and fielded in the Forge.mil effort at the DoD. A large change in the culture being engendered is shared (and in many cases, "open within the DoD") collaboration. There are approximations within this cultural change effort aimed at getting people used to stepping outside of their development silos, looking for and building reusable components, and accepting contributions from qualified members of the department outside of their immediate project team.
Some of the hurdles faced in building out government communities are already known:
First, unlike a lot of other systems in government, software communities are not static - what a system is today is not what it will be in the future. Software requirements are difficult to fix months in advance - they should be more fluid, responding to the needs and requirements of the users/warfighters in the field. That's what government software development communities need to accomplish with their capabilities: an agility of development, test, certification, and deployment that lets agencies develop and field systems in a much more efficient fashion.
Second, technical specialists want to know when, or if, a government site could be stood up to allow collaboration between the Federal space and the greater open source world. The main caution is to understand that the culture would have to shift to get the various Federal IT stakeholders, especially project managers, to embrace such an effort, especially around things like acquisition policy and information assurance.
Given these challenges, the question remains, "How do you build a collaborative development community?" There are two components to this answer: culture change and collaborative development tools built for distributed teams. It is important to note that you can't have one without the other. Instructions to work collaboratively without the right resources will not gain traction. Similarly, a strategy based strictly on deploying a new set of tools without the associated culture change management/shepherding will not work. This is where community managers come in to tie the tools to the culture, make necessary adjustments in processes, and to be the ‘glue' between the people and the technology.
The good news is that there are pockets of somewhat frustrated, but extremely passionate open source / open collaboration champions in the federal world. Those are the people that keep the momentum going, and software development community managers have to give them as much care and feeding as possible, since they are paddling upstream against a very strong cultural current.
Other government agencies, such as the Transportation Security Administration (TSA), have already begun collaborative software development efforts similar to Forge.mil. Given the intense interest that the DoD has received, it seems likely that other military and civilian agencies will begin participating in similar efforts. Hopefully, there will be some coalescing around Forge.mil on the defense side, and a proposed Forge.gov for the civilian agencies.
The true value of better internal government collaboration is clear if you ask Forge.mil's executive sponsor (General Cartwright, Vice Chairman, US Joint Chiefs of Staff) what he thinks is the most important aspect of the system. He'll tell you that it isn't delivering new tools just for the sake of wrapping up bad processes in new skins. Instead, he wants to see Forge.mil push the edge of the comfort zone with regard to how software and systems development is currently done in the DoD. His support and mandate is helping that team work hard to make this a reality, and it provides a great model of how to build Government 2.0 internally for other agencies.
© 2008 SYS-CON Media Inc.