What the Open Government Directive Means for Open Source

By / Feb 1, 2010

On the heels of the Open Government Memo of January 21st, 2009, the Obama Administration has issued the Open Government Directive. The Directive tells agencies what they must do to meet the expectations set by the Memo. The directive names many deadlines for agency compliance, most of them around reducing FOIA backlogs and increasing the amount of agency data released to the public. This isn’t surprising, since the Memo names transparency, collaboration, and participation as the guiding principles. Transparency is the easiest to articulate and implement — just get the data out there in a useful form. Josh Tauberer’s Open Data is Civic Capital: Best Practices for “Open Government Data” is an excellent handbook for doing this. If you want to track agencies’ progress, the Sunlight Labs folks have produced the outstanding Open Watcher.

What’s most interesting to me, and my friends at Open Source for America, though, are the more ambiguous orders. Although the Directive does not use the phrase ‘open source software’ at all, many of the principles and methodologies described are obvious references to open source. Many of these orders stand out as opportunities for open source developers, in the public and private sector, to demonstrate how our development model can help the Administration also make good on the last two principles: collaboration and participation. As Macon Phillips, the White House New Media Director said, “Open Source is… the best form of civic participation.”

Let’s take a look at the deadlines, helpfully produced by Daniel Schuman at the Sunlight Foundation.

45 days — January 22, 2010

“Each agency shall identify and publish online in an open format at least three high-value data sets and register those data sets via Data.gov” (p.2)

This is a wonderful opportunity for open source developers to demonstrate the power of citizen participation through software. The Administration has taken a great risk by pushing this data to the public. There are all kinds of reasons to not do it: privacy concerns, security issues, and the risk-averse culture in most of these organizations. Despite the instructions to be careful with citizens’ privacy, and the reminder to be sensitive to security issues, there’s still a chance that something could go wrong — plenty of reason to not follow through with this exercise. We need to help the Administration prove that this was a worthwhile cause. Just as we showed the power of citizen programmers in Apps for Democracy and Apps for America, we need to take these data sets and make them useful to the American public.

“The Deputy Director for Management at OMB, the Federal Chief Information Officer, and the Federal Chief Technology Officer will establish a working group that focuses on transparency, accountability, participation, and collaboration within the Federal Government. This group, with senior level representation from program and management offices throughout the Government, will serve several critical functions, including:

Now here’s a working group I would like to speak with very much. If you read the language of the third subsection, it’s amazing how many words you have to use to not say the words “open source”: experiment with new technologies, using expertise inside and outside the government, high-impact collaborations with many communities of use… they’re all but begging to create open source software projects to support the release of this government data.

In this “forum for best practices” on open data initiatives, you can imagine how useful a recommendation of open source software might be. You can even imagine the working group recommending government open source projects to help handle data that may be in strange government-specific formats.

60 days — February 6, 2010

“Each agency shall create an Open Government Webpage located at http://www.[agency].gov/open to serve as the gateway for agency activities related to the Open Government Directive” (p.2)

“The Federal Chief Information Officer and the Federal Chief Technology Officer shall create an Open Government Dashboard on www.whitehouse.gov/open. The Open Government Dashboard will make available each agency’s Open Government Plan, together with aggregate statistics and visualizations designed to provide an assessment of the state of open government in the Executive Branch and progress over time toward meeting the deadlines for action outlined in this Directive.” (p.5)

Of course, if an agency is writing new software to support these new “/open” areas, I’d like to see that software made available under a open license. If there are any clever data analysis or visualization tools, those should be licensed as open source software, as well. That way, citizens would have the opportunity to help the agency with their own disclosures, and agencies could more easily share tools with each other.

90 days — March 8, 2010

“The Deputy Director for Management at OMB will issue, through separate guidance or as part of any planned comprehensive management guidance, a framework for how agencies can use challenges, prizes, and other incentive-backed strategies to find innovative or cost-effective solutions to improving open government.” (p.5)

This is a strangely oblique reference to Vivek Kundra’s Apps for Democracy project when he was CTO in Washington, DC, and the national-scale follow-on, Apps for America. Both of these contests asked that submissions be provided under OSI-approved licenses. This is important to keep these projects going. If contestant’s software is under a proprietary license, there is no momentum behind the contest, since nobody can contribute to it after the fact. You might as well hold no contest at all, and instead just bid the work out to a contractor.

120 days — April 7, 2010

“Each agency shall develop and publish on its Open Government Webpage an Open Government Plan that will describe how it will improve transparency and integrate public participation and collaboration into its activities. Additional details on the required content of this plan are attached. Each agency’s plan shall be updated every two years.” (p.4)

I would hope very much that these plans for additional public participation and collaboration include invitations to open source developers who would like to help an agency build tools that make them function more transparently and efficiently.

“The Administrator of the Office of Information and Regulatory Affairs (OIRA), in consultation with the Federal Chief Information Officer and the Federal Chief Technology Officer, will review existing OMB policies, such as Paperwork Reduction Act guidance and privacy guidance, to identify impediments to open government and to the use of new technologies and, where necessary, issue clarifying guidance and/or propose revisions to such policies, to promote greater openness in government.” (p.6)

I hope that this review would include an examination of FACA implementation guidelines, which is understood by many to prevent open source developers from directly participating with some Federal agencies, for fear of having offered the explicitly prohibited “volunteer help.” We believe this isn’t the case, and it would be great if OIRA published some clarifying language. If they were to provide an interpretation of OMB Circular 130-A that ensured it was safe for agencies to create open source software without running afoul of procurement regulations, that would be wonderful.

So here’s a tremendous opportunity for the open source community. We have been given an early Christmas gift: a pretty clear path for more open source software and (perhaps more importantly) more government-sponsored open source projects inside each agency. If you want to help take advantage of this opportunity, you can sign up at Open Source for America and join a working group. You’ll be glad you did.

A hearty thanks the Heather West of CDT and Melanie Chernoff of Red Hat for their invaluable comments.

I’m the Chief Technology Strategist for Red Hat’s US Public Sector group, where I work with systems integrators and government agencies to encourage the use of open source software in government. I was recently named co-chair of Open Source for America and one of Federal Computer Week’s Fed 100 for 2010. I’m an active member of the Military Open Source working group, the RHCE Loopback, and a GTO-21 commissioner. I also help run Red Hat’s gov-sec mailing list. I perk up when people talk about cross-domain security, edge innovation, and interagency collaboration through the open source model. Prior to joining Red Hat, I worked as a developer, systems administrator, and IT director for a series of internet businesses. I’ve also been a business and IT consultant to not-for-profit organizations in New York City. During that time, I spearheaded the reform of safety regulations for New York State’s electrical utilities following the tragic death of Jodie Lane. When I’m not spreading the Good News about open source, I’m wishing I had a dog. You can find what I’m reading on Goodreads, what I’m saying on Twitter, and what I’m listening to on last.fm.

  • Tim Evans

    If Open Source developers are interested in anything here, you *must* address Accessibility issues for the visually impaired and other challenged individuals.

  • Chris Puttick

    @Tim Evans: Open source approaches have the ability to better address accessibility issues than any approach taken before; because open source and open standards are interrelated and because, at worst, you can reuse the parts of the software that read/write the software output to present it in an idealised form for the individual, whatever their needs. For example, a word processor that is designed from the ground up to work for visually impaired people; not to work for them *as well*, but that addresses as a focus their needs, not the needs of those who are not visually impaired. A no-compromise solution.

  • Pingback: Links 5/2/2010: Linux Foundation Contest for 2010 | Boycott Novell

GovFresh / About / Contact