DOD Open Technology Development Guide Released!

The DOD’s second Open Technology Development Roadmap has been released: “Open Technology Development: Lessons Learned and Best Practices“. It’s a handbook for using and making open source in the DOD and the US Government, sponsored by the Secretary of Defense. It provides practical advice on policy, procurement, and good community governance, all under a Creative Commons license. I’ll be providing some more commentary later, but this is a huge step forward in the adoption of open source in the US Government.

Updated: Here’s the source document in ODF format: OTD2: Lessons Learned.

 

Fighting Forks

This is the ignite presentation I gave for the Mil-OSS WG2 conference today. It’s a tremendous group of sandal-shod revolutionaries who want to bring open source and the US Department of Defense together. You can sign up for the mailing list here. If you use your imagination and insert a lot of stumbling, fumbling, and false starts to this, you’ll have a pretty good idea of how it went. You can find the full presentation here. [Update: Josh posted a video of my presentation, so you don't have to imagine it.]

Open Source in Government: Who was first?

Brian Purchia of Burson-Marsteller has a post over on GovFresh about the value of open source to unions. His argument pivots on cost-savings. I think you could make a more expansive argument that includes risk mitigation and innovation, but describing the advantage to unions is an interesting angle I hadn’t seen before.

I noticed that Brian repeated the misunderstanding that San Francisco had the nation’s first open source policy. I don’t want to diminish his larger argument, but it’s important that we give credit where credit’s due. So for the record:

  • May 28, 2014: DOD issues the “Stenbit memo,” which assures readers that open source is commercial software under the law, and can be used in the DOD.
  • July 1, 2015: OMB issues OMB-04-16, making clear that open source can be used in the Federal Government
  • September 30 2009: Portland, OR is the first city to issue an open source policy.
  • October 16, 2009: The US Department of Defense CIO issues a memo reiterating that open source software is commercial software for procurement purposes, and encouraging DOD branches to include open source when they’re picking software.
  • January 7, 2010: California‘s open source policy is published.

Open Source headlines from the Open Government plans

The Obama Administration’s Open Government Directive ordered Federal agencies to produce open government plans by April 7th, and while some advocates are disappointed, we have before us a bewildering number of initiatives to improve transparency, collaboration, and participation across the Government. It will not surprise you to learn that I spent some time looking for places where open source is being used in these plans.

I’m not sure I can recommend reading all of the plans cover to cover, but if you’re an advocate or have a vested interest in the future of a Federal agency, these plans are fascinating peek into each agency’s interior life. It’s not just the content of the plans, which run from exciting to comical to mundane. You can also learn a great deal about how agencies view themselves from the way these plans are presented and marketed. It will come as no surprise that the Department of Justice’s rather unlovely document spends a lot of time thinking about reducing its FOIA backlog. The Department of Energy clearly understands itself to be a first a research organization, based on its flagship data sets. The Department of Defense plan is crisp, to the point, and focuses on getting the behemoth to better collaborate and interact with other agencies, rather than the public.

My OSCON 2009 Talk on Open Source in Government

The good people at O’Reilly have posted my Open Source in Government talk at OSCON 2009 on blip.tv. It’s also on YouTube. I’ll admit to cringing a bit when I started watching, but I’m pretty happy with how it all went. Here are the slides.

In the panel afterward, someone asked my why open source developers should be helping companies make money on open source software, or helping the military-industrial complex or the prison system. I completely sympathize. There’s no reason whatever that someone should help the military or the prison system if they don’t want to. Those were just the examples that I used. There are many opportunities to work with the government elsewhere, especially at the local level. A good way to start is by finding something that’s annoying or broken in your local schools or library, and use open source software to fix it. Open Source for America should be making it easier for people to find these opportunities. But more on that later.

Open Source and Open Standards

Open standards are motherhood and apple pie – they ensure a level playing field in which many implementations can compete against each other, keep the barrier to participation low for newcomers, will outlive any given company, and ensure that systems can communicate with each other with a minimum of fuss. In other words, open standards create efficient and durable markets.

Open standards also keep costs low for buyers, who have many options and a minimum of friction when they want to switch from one implementation to another. Because the standard is open, there is no danger of being locked into a single vendor since anyone can create a new implementation against the standard. Since open standards will always exist, there’s no danger of the standard disappearing, becoming unsupported, or being later made proprietary. An open standard will encourage these efficient, durable markets for as long as the standard is useful.