The basic story is that I spent a week deciding on the Open Source solutions we were going to build out from and selected ServiceMix as the core integration platform. A very quick Google-search led to LogicBlaze (now IONA) as a source of “quickstart” training. We brought out Hiram Chirino and Bruce Snyder, core developers of ActiveMQ and ServiceMix to help flush out our architecture and push us in the “correct” direction. [The story of ServiceMix is worthy of a post all to itself - I’m very willing to discuss - just drop me an email.]

By being to able hit the ground running, and focusing our team’s collective efforts on the services which hold the application logic, we could iterate-in “real” functionality rapidly. During our software integration process we identified shortcomings in both ActiveMQ and ServiceMix. Because we already had a relationship with LogicBlaze (both project’s parent) we rolled both bug reports and fixes up through them. In this scenario, there really is no difference between a proprietary application and an Open Source project. Except one very significant point…our fixes were available to all, and we were able to get a new “release” immediately.

I began to spread the engineering story through the company’s software center, and functional lines. Interestingly enough, our customer was doing the same thing through program and product lines. Catching this, I decided it was time to formalize our company’s approach to internalizing Open Source software…and make our current project Openly available to anyone within the corporate firewall to reuse.

I made a convincing-enough pitch to executives that there is an opportunity for Open Technology Development inside the company…before we need to commit to doing software in the public Open Source world. I had enough money to establish a project Benevolent Dictator position, and capture (more formally) what it means to run an “internal” Open Source project, and the steps to create the infrastructure (we’d already set up a GForge repository on the intranet). It was only a matter of weeks after the project wiki began to take shape, and the code was downloaded/checked-out, before the team started getting lots of questions from DoD-funded projects. Most of the interest revolved around the technicalities of the project, but there were various concerns over the licensing implications. It was much easier to answer the latter: ServiceMix is distributed the Apache 2.0 license, which gives us the ability to make modifications to the source code and not have to provide them back to ServiceMix. The only binding agreement is that the original ServiceMix code must maintain the original attribution to the Apache 2.0 license. But, most importantly, all of the companies IP is built in the software services, and not the integration framework - this is key. [Coming up with a license scheme that “firewalled” sourcecode was fairly painful…and is still a work in progress today.]

The company’s GForge repository now hosts more than 120 projects and 350 developers. From zero to these statistics in just around a year. Instant collaboration and knowledge sharing by empowering engineers. Not bad, for a once completely tribal development environment.

The moral of this story is that it is much easier to sell the “internalization” of Open Technology Development - than the inherent giving away of company intellectual property by the way of public Open Source Software. But, through the success of this particular project - the door has been opened for true proactive development of software on the public Open Source arena. The company is now discussing the potential for a true Open Source effort to build a DoD-centric service platform to meet the mobility (ad-hoc networking) and security (NSA-grade) requirements that lie within. Again, the point is that taking a “walk” (internal) before you “run” (public) position on the consuming and producing of Open Source Software might get you a lot further, faster. And the result is a smart, more agile enterprise.

One other key data point to take away is that many of the upper-echelon Open Source projects are parented by a corporate entity just like IONA for ServiceMix, or IBM for Eclipse. I know that many managers and executives want the comfort of knowing that there is a facility for support, and some level of warranty/guarantee on the software they are consuming. These facilities do exist. And, it doesn’t just stop at support. These same companies are willing to provide engineering and architectural services to ensure your project’s success.

Rather than beating the DoD acquisition problem/process in to a pulp - maybe we need to continue to spread the Open Technology Development success stories that are happening within and between our companies. And, more importantly, continue to share the Open Source gospel as a mechanism for internal operational optimization. The spread of Open Technology Development starts at the engineering levels. The effects and value of Open Technology Development are realized in schedules a deliveries. It is then that the acquisition cycle can take notice, and truly evaluate the potential return-on-investment. We software engineers call this “dog-fooding”. Maybe, we just need to start eating dog food?

BTW, sorry for the linkless post. I wrote this on a plane…and don’t have the energy to go back and edit.