It is a little weird that I just received my June edition of [The DoD Software Tech News](http://www.softwaretechnews.com) … the day before the 4th of July. The front cover is plastered with a montage of Open-relative phrases to include:

• [Open Technology Development](http://www.acq.osd.mil/jctd/articles/OTDRoadmapFinal.pdf)
• [Open Source](http://www.opensource.org/)
• [Open Communication](http://www.computerworld.com/managementtopics/management/story/0,10801,88666,00.html)
• [Open Standards](http://www.openstandards.net/viewOSnet3C.jsp)
• [Agility](http://agilemanifesto.org/)
• Business Revolution

It is the last one that is of relative interest to me, currently. And it is the one area that very few people (outside of the Navy’s acquisition process) can comprehend - especially, not the federal contractors. The reality is that we are not that far from [$600 toilet seats](http://en.wikipedia.org/wiki/Toilet_seat). Contractors work against contracts. Contracts specify statements of work (SOW) to be performed. The statements of work are based on responses to requests for proposals (RFP). Request for proposals are predisposed by request for information (RFI) documents. Contractors lie about capabilities and relationships in their responses to RFIs in order to get pre-positioned in the RFP process.

As goofy as this is, the acquisition cycle is made even less efficient by the inherent disability for solution reuse. Never-mind sub-agency contracts that disregard interoperability. Even within the contractors, the “color of money” is an issue. Work being done under one contract may not be used to advance any other contract. So, you can imagine that the potential for inter-contractor sharing is a farce.

Agility is definitely and issue. Vendor lock-in is preventing innovation on a grand-scale. Worse is the same vendor-based lock-in is also tying solutions to proprietary interfaces - so systems are non-interoperable before the engineering even begins. The lack of agility is also inherent in the process and methodologies that design and develop solutions. Too often contractors are a “house/shop” that is only capable of a particular solution path. And, for software systems (which every system is affected by) there are many more problems. [CMMI](http://www.sei.cmu.edu/cmmi/), though noble in nature, does nothing for contractor’s agility. Granted many systems much support longevity to a greater capacity which enforces the need for structure. However, the risk is that contractors stifle innovation by being bogged down in a super-conservative process. Just take a look at today’s battlespace and the segregation of each service’s technology.

There are pockets of effort - including [GIGlite](http://www.giglite.org) and the Open Technology Development concept. The Navy’s recent “coming out” regarding [Open Architecture](https://acc.dau.mil/oa) is impressive. Vendors are starting to [publicize](http://www.lynuxworks.com/solutions/milaero/navy-open-architecture.php). But, we are still stuck on vendors not working in the Open. LynuxWorks effort, again is noble in nature - but really a little to self-serving for me to relate to a real Open Architecture.

I’m currently working on an internally-funded firewalled open source project - meaning that the code is only available with the company’s intellectual property firewall. Projects and programs are free to use the my work, regardless of the “color of money”. I’ve quickly realized the problem. This concepts completely goes against the notion that we charge the customer for every bit of work, and recharge them no matter the levels of reuse. I won’t go into the “lines of code” problem that is being burned down by SOA - but, I am very aware that my executive layers are more worried about what they can charge for and get itemized in a SoW than they are about being efficient and agile. That said my current user-base is strongly being bent towards a R&D role. This isn’t bad. And, it is still Open.

The only, real, solution is to resolve the acquisition problem, ensuring that RFIs, RFPs, and SoWs specify the use of Open Technology Development, Open Source, Open Communications, Open Standards while promoting supplier agility. This is where the real revolution will take place.