Impatience Spurs Innovation and the iPad is the New Fold


Drupal or Solr may not be my forte, but when Rob Winikates, Deputy Director, Office of Digital Strategy, Online Engagement at the White House asked how many people used Open Atrium, Gov Delivery, a URL shortener or Drupal, I knew that I belonged in at least two of these categories.

Last week’s OpenGov DC conference was filled with an array of interesting speakers, with a keynote from FCC’s Steven Van Roekel. The one-day conference was tailored for open government stakeholders, developers and people interested in open source tools such as Drupal. This is not to say that other open government players, including organizers both on and offline, were not represented, but I found it interesting that out of all the speakers, only three were involved in citizen engagement and, even then, that they were from the public sector. I suppose this means that NASA’s advocate for open government, Nick Skytland’s dream of a future of collaborative code, where citizens develop government websites, will have to wait — if this representation is anything to go by.

But let’s talk about the fun parts…

Van Roekel mentioned during his keynote that a “site at rest tends to stay at rest”. The premise here is that you should have an evolving website. Understanding that the website you designed is for the people and by the people (though this may not be so with government websites) helps you engage them better, especially when you use a bottom-up approach. And for organizers, it is a useful way of getting feedback from citizens through crowdsourcing while allowing for room to act on the feedback. Van Roekel noted that times have changed, and the culture of government needs to do so as well. Thomas Cochran, the Director of New Media Technologies at the White House, summed it up when he said that “the speed of government is the opposite of the speed of the Internet.”

Overall, the echoing theme was that when it comes to open source, it is important to remember that it is about the people. The software maybe free, but its management is not. There has to be constant involvement of people in the progress of the project.

In the session titled, Collaborative Code: How to Build and Share Inter-changeable Features, NASA’s Nick Skytland made an interesting observation about how the open gov initiative is about culture change. Indeed, there is need for government to move from the machine age that was structured around an industrial model to the information age. One of the suggested ways on how to do this included using participatory exploration (where you think about what your organization can do). Open source software is not just an opportunity, it’s a responsibility, and being experimental with it while soliciting for ideas from outside can transform it from a product to a process. It also increases transparency because the source code is available for those interested.

But what is collaborative code?

Most of the speakers defined it as one of the ways government can realize its true potential, while others thought it is a way of finding a shared need and partnering with the community to find a solution. However, the rhetorical question remains: How do you apply open source to policy?

In the meantime, for Skytland, having to deal with the challenging terms and services that collaborative code presents is a small price to pay to see astronauts tweet in space!

For Jason Hoekstra, the technology solutions advisor in the U.S. Department of Education, the experience of thinking about how to prepare and release open data did not come without headaches. Not only did he find it a mental challenge, but the process was further complicated by releases on different schedules and different keys, making its scalability limited. Solution? Label data consistently!

A tip to bear in mind is that with secure open source information, the maturity of the project weighs heavily on how secure it will be. Also, If you allow users to log into your site from outside entities, then you need to have clear guidelines on what the security controls are. But if you are wondering how you can tell when open source code is secure, the panel on securing open source applications advised that secure code is not pushed through an automated system. It is code that has been through a process that involves the assessment of the code. If it meets the requirements it was designed for, then you know it is secure.

A panel called Design Matters: Why Thoughtful Information Architecture and Branding Matter, concluded the conference with a remarkable walk-through on designing and — by Design Director at Blue State Digital, Matt Ipcar.

(For more of the pictures from OpenGov DC, check out this Flickr slideshow courtesy of Betsy Ensley of Phase2Technologies )