I’m sitting in beautiful Charleston, SC, where I just finished attending the Forge.mil release 1 review/release 2 planning meeting. There were some great discussions that occurred, since we had almost the entire deployment/development team here in the room (we ‘eat our own dog food’ by using the system to collaborate across geographies and DoD components normally, but some ‘meatspace’ time is always good too).
First off, I’d like to correct some erroneous information that has gotten out in recent press articles/blogs about Forge.mil. The correct URL for the site will be (eventually) http://www.forge.mil, NOT https://www.forgemil.com. The latter is our test site, which has since been locked down from public access to prevent confusion that came out in when Slashdot picked up Matt Asay’s article on this. The former currently requires a DoD CAC card, or ECA certificate to access the site (available to DoD/miltary personnel, and government contractors). Before we go into our ‘official’ launch at the end of March/beginning of April, we’ll open up www.forge.mil so it is easier for interested parties to see what the capabilities of the system are.
Second, let’s clear up a misconception going around that the first capability we are delivering (Software.Forge.mil) is ‘not Open Source’, because it will sit behind a PKI-layer and not be available to the general Open Source population. Yes, strictly speaking, it isn’t ‘Open Source’ in the traditional sense, but the reality is the DoD is attempting to utilize development models and methodologies from the Open Source world to help develop and deliver software more rapidly and in a collaborative fashion. The current plan is to limit this for internal DoD and contractor community use, but that could be re-evaluated at some point if it makes sense from the community standpoint.
Third, the software infrastructure used to deliver the capability is not SourceForge.net, but is actually the CollabNet SourceForge Enterprise product.
With those things out of the way, let’s talk about the meeting. Basically, we got the team together partly to go over the accomplishments of release 1 (ok, and to celebrate this first release with the entire group, since we don’t regularly see each other in person), and to work on plans for release 2 (the ‘official’ launch). The three elements we are targeting for release 2 are:
- Build Community
- Mature System Capability
- Build Partnerships
The Forge.mil system is a ‘platform’ effort, which will eventually deliver the following capabilities to the DoD community:
Release 1 delivered the Limited Operational Availability (Beta) phase of Software.Forge.mil. Release 2 will be the official launch of Software.Forge.mil for internal DoD and contractor partner access.
We started yesterday with an overview of where we are to date, including some great stories I was able to share on community. Specifically, I created a ‘Utility Library’ project to host requests we were seeing for full blown projects on the site that didn’t warrant that much overhead – usually, these are smaller ‘code snippets’, scripts, or self-contained libraries. After I created the project, I was able to recruit two users (the first two to contribute code) to become the project admins. I introduced them to each other (one from the Army, one from the Pentagon), and away they went. I removed myself from the admin list for that particular project, and they are now running it themselves, and onboarding new users and code for the project. It seems like such a little thing to those of us from an Open Source background, but this simple act is a HUGE deal for a government space that has traditionally not seen a lot of this kind of sharing.
We are also seeing a lot of excitement so far in this limited launch, with projects/programs literally pinging us every day to inquire about the system. We’ve put in a very lightweight governance/adjudication process for new projects on the site – the only thing it is there for is to make sure the project meets the terms and conditions (fully public/open within the DoD community), and that there aren’t duplicate efforts going on. So far, we’ve been able to shepherd several groups together that either didn’t know about each other, or hadn’t been able to collaborate before.
Again, I know this sounds very mundane for those of us used to the way Open Source projects and methodologies work, but this is literally starting to ‘change the world’ for these folks in and around the DoD. I know there will be future challenges along the way, but this effort is very visible (even at the Joint Chiefs of Staff level), and the excitement and momentum is palpable!
Finally, I should take some time to mention the implementation team. It is made up for DISA personal, CollabNet consultants, and members of the Navy SPAWAR command. This meeting (the second of two face-to-face planning/review sessions) went very, very smoothly, with the members of the government community really starting to see the power of Agile development and collaboration. We started the build out of this project using Agile, and delivered this initial early-access capability in 90 days, which is practically unheard of in the DoD (or any government entity for that matter). This is a testament to a group of folks who are willing to blend the unique expertise and perspectives of traditional government development and procurement with Agile processes. I won’t lie and say there haven’t been challenges along the way, but, so far, each has been met with determination, and a team spirit that I’ve rarely seen in my career (in fact, I’ve only seen it at two previous career stops).
I’ll continue to keep folks updated via this blog, as I think this is going to be a very exciting project, even if we just build the capability for internal DoD use only. The methodology and capability we are bringing to the table have a chance to fundamentally shift how software development is done in the department, and this can be a model for other government groups as well. Now I’m going to get on a plane back to California and get going on release 2…