Tech@State: Oh, the places we STILL need to go...

The fact that the State Department hosted a conference last week on open source shows how far the U.S. Federal Government has come in terms of tech policy. Yet the content at Tech@State: Open Source often illustrated that the road ahead is still long and arduous. I nearly cheered when Greg Elin, chief data architect at FCC, said “open source is a nonissue inside of the FCC anymore.” But when he asked, “Are people really having a problem that where they work in government is saying 'we can't use open source?'" responses ranged from raised hands, to angry mumbling, and a couple of frustrated shouts of “Yes!”

This brought me back to last month’s Federal Open Technology Report Card, presented by Open Source for America co-chair Gunnar Hellekson at the conference. The Report Card showed a wide disparity between high-scoring agencies like the Department of Defense (82%) and low-scoring agencies like the Department of the Interior (37%). The Report Card and conferences like Tech@State Open Source show that we’ve made great strides in the increasing adoption of policies that allow for the use of and contribution to open source projects, but that implementation by government agencies varies widely. Fortunately, such conferences help connect those who have already successfully integrated open source into their agencies with those who still have concerns or face uncertainty or doubt within their departments, which I view as a very positive step on the journey to a technology-savvy government.

I won’t do a full content round-up on Tech@State, because you can read Alex Howard’s excellent coverage and see video here. The conference brought together government employees, software vendors, open source developers, think thank policy wonks, academics, and a very enthusiastic high school student interning at OLPC. It was a great mix, and I applaud the State Department for pulling together such a good program. Still, this was a conference about open source policy for government leaders by government leaders, which brought to light the lack of knowledge and capacity that many of our government agencies still have about open source.

For example, there was a session titled “How We Got Here: Industry and Open Source Software” that should have been called “Open Source 101.” I had hoped we were beyond that, but given some of the questions – How do you make money off of free software? Free as in speech, or free as in beer? If we use open source, do we have to then open source all of our code? - showed that we are not. These novice questions demonstrated that there’s still a lack of real understanding about FLOSS within the federal government, even by those interested enough in the topic to attend a seminar on it.

During a panel on “Zen and the Art of Open Source,” Deb Bryant of the OSU Open Source Lab listed four common misconceptions about proprietary software that she often hears from government folks:

1. You will always have support when you need it.

2. If you report a bug, it will always be fixed at the moment you need it fixed

3. That company will always be in business, and they will never change their business model and will always support the product you have purchased.

4. The person who wrote the code under your contract will always be working for that company and will be available with great documentation.

As Bryant pointed out, “issues with open source and proprietary software are really the same thing. You can think of open source as a different way of approaching the sourcing.” She then proceeded to give several examples of successful government projects that were able to achieve financial and accountability outcomes using open source software.

This brought me to the last point – the need for case studies. Throughout this and other similar conferences that I’ve attended over the past few years, it has become evident that government leaders are clamoring for case studies they can use to share information. One reason is to see and evaluate successful implementations that can be replicated and perhaps save money, time and better serve citizens. The other, quite frankly, is that if you’re a department CTO, it’s easier to justify your selection of Drupal to your boss when you can point to whitehouse.gov as an example.

Judging by the enthusiasm of the participants at Tech@State, there is a lot of interest in using open source, but some of the barriers to entry in the government evidently still exist. We need to make it EASY for government folks to choose open source. Bryant is putting together a group to work on conducting vendor-neutral case studies of government use of open source as part of her work at OSU Lab and Open Source for America. If you’d like to help, sign up on the State/Local working group at Open Source for America. It may still be a long journey, but we’ll get there faster if we help each other out a little on the road.