Great post with excellent, cogent points. I’d also point out that the current acquisition, development and C&A processes are ALREADY deeply flawed, as they come out of a mentality of rigorous ‘up-front’ requirements management and testing, which leads to long, slow software projects which are out of date technically long before they are ever fielded. This may work well for buying missiles and tanks, but it is far too slow for software development.

One can argue a lot of things about what we are doing with Forge.mil, but one of the fundamental things we are trying to push is a change in the software development culture to one that is closer to what is represented by Agile software development (to wit: early and continuous involvement of the customers and other stakeholders).

The days of attempting to ‘read the minds’ of the users for government software need to stop. The most powerful part of Open Source is not necessarily the fact that you can see the code (though that helps). The success of projects like Linux, Apache, etc. is largely due to their use of continuous collaboration/discussion/debate about what features and requirements need to be addressed.

Government contractors will soon have to start living in this world, with the recent passage of HR 2647 (specifically section 804), which reads in part:

“The Secretary of Defense shall develop and implement a new acquisition process for information technology systems…to be designed to include:

1. early and continual involvement of the user;
2. multiple, rapidly executed increments or releases of capability;
3. early, successive prototyping to support an evolutionary approach; and
4. a modular, open-systems approach.”

We’ve already proven this out on a small scale with Forge.mil itself, which was built from the ground up in 180 days, a feat that still makes government folks sit up and take notice.

I’m under no illusion that successful implementation of this (and the ideas you put forth above) is going to require anything but a huge sea-change in both government and contractor behavior. However, I don’t believe we can continue to carry a mentality of ‘business as usual’ in the software space. We are up against adversaries who *DO* understand the value of true collaborative software development.