April 6, 2007 by jimstogdill
Open Technology III – pushback
I had a reality check moment this week in my thinking about “GLOSS” (a term I invented in this previous post to describe a DoD gated open source project) during a conversation at an Air Force Research Lab. In so many words I was let on to the likelihood that I’m pretty much clueless (the occasional reminder never hurts). Despite the fact that my credibility as an engineer was openly questioned, I appreciated the discussion, as heated as it was, because it helped me to constrain and inform the idea of gated open source in the DoD (GLOSS) with the very real cultural, contractual, and legal barriers to implementing it. Better to know the reality and face it than to blindly forge ahead and get no where.
The conversation occurred with researchers who have developed a very sophisticated component of a federated training environment. In the midst of a conversation about the difficulty of coordinating the ongoing development of such a complex product with a broad community of stakeholders, I naively asked whether they had considered an open-source-styled collaboration approach to its ongoing development. I suggested that this would let the core team continue to focus on the fundamental capabilities while members of a wider community might provide value in the integration frameworks, human interface, and in other areas where the lab’s core team might not have deep expertise. Furthermore, I suggested that by essentially commoditizing the capability within this specialized community, the government would be able to get better return on its investment by encouraging wider adoption. I suggested that this approach would simultaneously provide the very disciplined configuration management of the source code that they desired.
Some quick background might be useful to give some perspective. The product under discussion has taken approximately four years to develop with a team of roughly six people and was built largely to meet the internal needs of the lab’s testing and research. However, it has proven to have great utility and wider applicability. The developers for the most part have been research scientists and and have focused on complex physical world emulation while paying less attention to the non-core elements of the capability (they would probably argue this point).
The software is very sophisticated and effective at modeling the complex physical processes it is designed to model, but, as we discovered in a recent project to integrate it with other systems, it suffers from some typical “lab architecture.” Architecturally it reminds me a bit of a project I worked on in the 90’s that was derived from research at Carnegie Mellon University’s speech recognition and AI labs. Insanely sophisticated internals wrapped in what can only be described as a naive application and integration architecture.
So, back to what I learned the other day.
One of the key push backs in this case to an open source approach (even a gated community) is the perception that opening the code will result in a loss of control. In one sense the lab is concerned that by opening the code they will no longer have control over the capability’s fundamental direction. However, perhaps a greater concern is their perception that by opening it they will simply pave the way for an unscrupulous contractor to take the code and figure out a way to sell it back to the government. Given that this is well within the realm of possibility I can appreciate the vehemence with which this objection was offered.
There also seemed to be an inordinate amount of concern about the cost of managing an open source community style of working. I think really this issue was linked to the loss of control and was a surrogate argument for keeping all of the development work (and associated funding) at the lab.
There would of course be costs associated with managing such a community; from infrastructure to community management, so it would only make sense if the gains offset the cost. This may be a case of cost – value mismatch in the sense that lab might perceive from a budget point of view that it is absorbing all of the cost while benefits are largely distributed outside the lab. This may or may or not be true, but even if it is it is probably a case of a local minimum short circuiting a global maximum.
An important aspect of this capability is the need to protect the IP from foreign disclosure. Little of the application code is classified (if any; though the parametric data associated with it certainly is) but it would definitely be subject to export restrictions. So another significant issue raised by the lab is the overhead associated with verifying the credentials of potential community members. The need to ensure that only authorized and authenticated individuals can gain access to the source repository is well founded. However, they were equally concerned with verifying the software development skills of potential community members and contributors; they did not understand the hierarchy of involvement within an open source community and the idea that commit privileges are earned over time.
Finally, they took exception to my position that commoditization of this capability would result in wider adoption within the targeted community. The issue here was that a number of contractors are also developing products that at least overlap in the space that this capability is in. The lab claims that they are regularly threatened with lawsuits from angry contractors who claim that the government is unfairly competing with them if they field this software outside of a pure R+D environment. I agree that this is an issue that cannot be ignored, and the government spending tax dollars to field open sourced code in a “public works” mode will always raise the ire of contractors. But, that same government built a network of super highways when the country was already well served by a network of rails. I guess my reaction to this concern is if it is a “public good” build it and deal with the lawsuit.
To summarize the issues raised:
– It is expensive and difficult to manage the community; and if community members (other programs) submit code they are going to demand that it belong to them regardless of the “GGL/GLOSS” licensing.
– The system is very sensitive from a classification and distribution point of view; this will make it even more difficult to create a community.
– There are significant Government / Contractor competitive issues with this approach.
– We will lose control over product direction and the source.
More grist for the mill.