October 30, 2008
Yesterday I sat on the panel that I referred to here. I thought I’d follow up with a brief post about one topic of our panel conversation.
To start the panel we were asked “what’s bugging us?” This started an interesting conversation about some specific open source roadblocks in defense. In particular, Bdale Garbee made the point that open source projects rely heavily on personal reputation. Even when major corporations participate in open source community, it’s the reputation of the individual that determines whether and how contributions make it into the project repository. People get commit rights, not companies. This can be problematic in the defense space.
I added that many key contributors to open source projects have self-selected to participate. The ability to self select is important to the ability of a project to find people with high levels of commitment and expertise. Look at the list of contributors on the Apache web server project for example. While there are certainly participants that represent major corporations, I would estimate from looking at the list that at least a third self selected. And that third is important as it is often the source of key (and difficult to find) skills. In fact, even many of the company sponsored contributors self selected and were later hired because of their participation.
Unfortunately, for a variety of reasons, within the DoD it can be much more difficult to self-select to participate. In defense work every hour is accounted for and must match a specific project plan line item. Community participation often requires a contributor to assist with things that don’t have an exact corresponding work breakdown structure element from the program that is paying them. In defense work, if you don’t have a charge code, you don’t work. There’s simply less wiggle room for participation that doesn’t directly relate to the program that is funding you at that moment.
We also touched on a bunch of other issues that impact the ability to participate in or contribute to open source projects. Things like export controls, copyright, culture, etc.
These specific issues that impact defense contribution and participation have broad implications if defense is to be able to effectively leverage the work going on in open source communities. One of the things that makes open source community tick is the right to fork. Knowing that you can fork the source if the project direction deviates from your own direction is important to alleviating risk. The antidote to forking is community participation and the development of trust. The more you participate, and the more you develop trust, the more you or your organization can influence the direction of a project or at least make sure that your specific needs can be met. With all of the rules that currently make meaningful participation difficult, it is very difficult for defense contractors to participate in the upstream software value chain. The result is perpetual forking.
It will work like this. A defense contractor does a trade space analysis and decides that they can save a lot of money for the government by using a particular open source project, so they include it in their bid. They win and they build the system using the open source component, however, they realize that they have to modify it in a few critical ways to satisfy some specific requirements. They can’t participate in the community so their changes never get offered back, and never make it into the trunk. A few years later, under a follow up maintenance and sustainment contract, they do an upgrade of the system and, because their changes never made it into the core project, they have to repeat the work again on the newest version of the open source project.
In the not too distant future there will probably be whole classes of software infrastructure that are effectively only available as open source. It simply won’t be economic for a proprietary software firm to compete in areas that have been completely commoditized. Therefore, it’s imperative that the Department figures out how to resolve the issues that are preventing their own people or their contractors from participating meaningfully in the communities that they will be forced to rely on.
That’s probably enough on that. There was one other thing I wanted to touch on in this post. This was the fourth year of this conference and, maybe I’m just an impatient person, but I’m getting really bored of the same old remedial conversations with a bunch of suits (full disclosure, I was in a suit too). Or as John Scott put it to me during a break, “Where the geeks at??” Too much of the conversation is still about whether or not Linux qualifies as CoTS in the FARS and that sort of thing. Where are the breakout groups on open geo tools? Where’s the presentation from the guys using XMPP as a cheap messaging stack in some major program? Where are the non-DoD geeks who are attending because they are participating in an open source community that was started in defense but is now being widely used to solve all kinds of other problems? Where are people trying to build an open service bus that will deal with intermittent service end points that you find on a battlefield? Where are the SOSCOE developers talking about how they used JXTA’s service advertising mechanisms? Etc…
It’s time to move from the basics into the advance course kinds of stuff; the stuff you talk about when you are actually doing it. It’s time for DoD policy makers and decision makers in key programs to really start to push; push for expertise, program outcomes, and key policy initiatives that will alleviate the kinds of road blocks we discussed (again) in our panel. In short, it’s time to stop talking about open source in defense and start using it at such a meaningful scale that next year the room won’t be full of suits, but will be full of geeks and practitioners.