OpenSource Connections
Category: Community
My partner Eric Pugh recently spoke at the Association For Enterprise Integrations 3rd Department of Defense Open Conference. He and Matt Jenks from SAIC covered the topic “Best Practices in the Use of Open Source In Government.” While it is, in my opinion, good that the government is moving towards embracing open source (Jim Laurent of Sun notes: “Its clear from attending this conference again (this is my third time) that there is no avoiding the use of open source tools in the Federal Government. Whether it is something as simple as glassfish and openssh or more advanced technologies like the UltraSPARC T1 and T2 processors, open source is everywhere in the DoD.”), I was surprised at the relative lower level of discussion in most of the presentations, defining what open source is and is not, etc. The chasm between the government and open source community was most apparent to me when Jim Stogdill of Gestalt asked the audience how many people had attended OSCON or a BarCamp, and only a couple of hands aside from Gestalt representatives went up.
The tone of most of the questions in the audience during the keynotes was focused on what the open source community could (with the tone hinting towards should) do for the government. The only way for the government to get engagement from the open source community is for the government to engage the open source community first. Otherwise, it is missing the motivation of the open source community completely.
Here are five ways that the U.S. -government could benefit from greater adoption of open source technologies:
- Reuse Utilizing open source platforms represents being able to leverage hundreds, thousands, and oftentimes millions of man hours of development work to build from. Rather than needing to build everything from scratch, oftentimes, by using open source platforms, software development projects become more focused on bolting together packages and then customizing them to achieve the end result. We make the analogy to building a house. In building a house, the cheapest labor is found working on framing and foundation work. While crucial to the success of the house, the art does not lie in the basic infrastructure. The distinction and differentiation to a house is found in the carpentry and finish work, where the artisans have the most impact in the outcome of the house. The same holds true for software development. Most projects can piece together the infrastructure from existing open source projects, leaving the artisans to do the custom development to build on the deployed infrastructure. There is no need to pay high-cost developers and consultants to build the basics, particularly when they already exist and are tried and true.
- **Auditability **With proprietary systems, the buyer has to assume that the product does what the vendor says its going to do because there is no way, aside from extensive post-purchasing use case testing, to ensure that it will do 100% of the things that are promised. While contract law does provide some protection, it does not regain lost time. With the use of open source code, though, the recipient can completely audit the functionality of what is being delivered instead of opening up a .exe file and hoping for the best. Perhaps this would be a good use of the SETA`s time?
- InnovationThe United States has maintained a competitive economic and military edge because of innovation. However, as Jeff Jarvis reports from Davos, the rest of the world is catching on and catching up. One of the commenters in the innovation discussion in Davos noted that the open source community has been robust, but not particularly innovative, while the U.S. Department of Defense has been, historically, the cauldron of innovation. Open sourcing allows the creation of a fire brigade, where people take ideas, add a little, and pass them on. By taking the sparks of the best ideas that come from the government and open sourcing them, the path to commercialization and incremental improvement becomes much easier.
- More eyes on the problem should mean fewer bugsAn inverse correlation exists between the number of bugs and the number of eyes looking at code. Even the U.S. government, as big as it is, cannot command the resources of the world, and, therefore, cannot ensure that all of its homegrown code is bug free. The more people who play with code, look at it, and test it, the more likely it is that the bugs will appear…and be fixed.
- SecurityIt is very hard to hide a backdoor in code that is open. While exposing code which was once proprietary does open it up to greater vulnerabilities in the short term, in the long term, because the code is visible to everyone, so are the intrusion attempts. David Wheeler writes an excellent article on the inherent security improvements of open source. The only true way to guarantee full security is to see the code itself to verify that no backdoors or vulnerabilities exist.
In no way do I promote the notion that the government should open source everything, nor should it open source the things which it could stand to gain in a wily nily manner. Just as in commercial enterprises, it should keep proprietary the things which give it a competitive advantage, although it could certainly open source those to a closed community. However, it should look much more closely into open sourcing the “infrastructure” pieces which do not add a competitive advantage. If the government currently pays for a piece of functionality which it would not care about if a foreign government used the same vendor, then it should look at open sourcing. It might even be able to grab best practices from elsewhere, including other governments.