Forge.mil: The Government Version of SourceForge

This is a cross-post from my blog on the Military Social Networking system milBook.

The US Federal Government has created a family of services to support technology development in the Department of Defense (DoD) called forge.mil. According to the site, forge.mil is a collaborative environment to accelerate the development and deployment of dependable software and services within DoD.

Much of this post will be based on an overview presentation available on the site titled "Forge 101: An Introduction to Forge.mil".

The Forge.mil Vision is to enable the rapid development, test, certification, deployment and acceptance of new products and services on the Global Information Grid (GIG) by providing policies, processes, tools and a federated development and test infrastructure. Forge.mil is intended to provide a collaborative environment for developers, testers, Warfighters and other stakeholders for the rapid development, testing, certification and deployment of software.

Top level support for this idea is starting to take shape. In the National Defense Authorization Act for FY2010, Congress has called for the DoD to ‘develop and implement a new acquisition process for information technology systems’ – one designed and based on early and continual user involvement, rapidly executed incremental capability, early prototyping and open systems. The Forge.mil environment is perfectly suited to meet these goals.

To build a toolset, Forge.mil initially focused on the development community.  Software developers were the ones least likely to be involved in the ongoing program management and software acquisition process. The capability that exists in Forge.mil today is centered on software development, software version control, code management, and release management. The core product Forge.mil is built on is CollabNet TeamForge.

There are two types of tools in Forge.mil today:

1. Development Tools (Source Code Management, Trackers for Requirements, Bugs or Issues, Change Requests, File Release Management, Task Management and Real-time Reporting
2. Communication Tools (Project wiki pages, Discussion Forums and Document Management)

One of the greatest features this set of tools provides is the ability to relate software builds with the requirements met or bugs fixed in each of these builds.  The ability to associate artifacts within the same tool set allows users to associate:

•  A Document with a task (create training manual by a certain date)
•  A Tracker with a discussion post (a user requirement that needs clarification)
•  A File commit with a bug tracker or requirement tracker (commit new code that fixes a bug or fulfills a requirement)

Artifacts – documents, requirements and bug trackers, software builds and releases – are visible and accessible to the test community, the IA community and other program and project stakeholders.  This visibility and availability of program information is key to successfully working with distributed teams.

Forge.mil is available to U.S. military, DoD government civilians and DoD contractors for Government authorized use. Access to Forge.mil requires a valid DoD Common Access Card (CAC) or a PKI certificate issued by a DoD approved External Certificate Authority (ECA) with a DoD government sponsor.

The first offering launched in April 2009 was SoftwareForge.  The goal for SoftwareForge was to model the best of the open source communities in terms of doing collaborative development and bring that into the DoD by offering the same set of capabilities and enable the same set of approaches that have been driving successful open source projects. SoftwareForge enables the collaborative development and distribution of open source software and DoD community source software.

After SoftwareForge rolled out, there were project teams stating they had a need for the same toolset for projects and teams that were unable to operate in the open.  They wanted the same tools in a private project space.  ProjectForge provides the same application life cycle management tools to DoD projects and programs as SoftwareForge, but for projects that are not doing DoD community source development and/or need to restrict access to specific project members.

The following criteria are used by the community/project review committee when determining whether a project is appropriate for the SoftwareForge site: Project has an Open Source or DoD Community Source license Project is not a ‘fork’ OR a 'mirror' of an existing external Open Source project If a fork is required (e.g. - security reasons), will be evaluated case by case Project must accept ‘DoD internal public/open’ view permission Project must be willing to consider contributions (code, docs, patches, etc.) from participants outside of their team Project should not be a duplicate of an existing project on the site The goal of the project adjudication process is not to deny or make it difficult for new projects to be created. Ideally, if the new project criteria are adhered to, project approval can be done in less than 48 hours (depending on the number of requests in the new project queue). This process is designed to ensure the usefulness of SoftwareForge for both developers and consumers of software.

The plan currently is to use this for the FedWave development effort, if other conditions are met (Sponsorship, approval, etc.).

I believe this is an exciting advance in Government software development and should be very beneficial. As always, the opinions expressed here are strictly my own, and I welcome your comments.