
This Friday we have a special "Scandinavian edition" of the Europe roundup, brought to you by PDF friend Bente Kalsnes.
If you want you can send us stories or interesting links to look into. And don't forget to check our twitter account!
Almost three months ago, the City and County of San Francisco launched a site called DataSF where they publish data sets from a variety of city departments for public consumption and application development. The initiative, led by Jay Nath in the Department of Technology, was inspired by President Obama's transparency directive on his first day in office. They then looked at what had been done with Apps for Democracy in Washington, D.C.
The Senate's ad hoc Subcommittee on Contracting Oversight held a hearing this morning. The subject: "Improving Transparency and Accessibility of Federal Contracting Databases." Senator Robert Bennett spoke for many of us today when he sat up on the dais in room 342 of the Dirksen Senate Office Building and rubbed his temples over, and over, and over, and over again.
What prompted the subcommittee to convene today (if you can call attendence by two senators, Bennett [R-UT] and Chair Claire McCaskill [D-MO], a "convening") is a particularly difficult problem: what the American public, watchdog groups, and even Congress' own investigators know about the thousands of firms and individuals who make their money as federal contractors is trapped within electronic databases. Eight databases. Or a dozen database, depending on who's doing the counting. Databases with names like FPDS and ORCA and PPIRS, the last of which goes by the adorable nickname of "Peepers."
All told, there are a million lines of code involved. But there's really no all told here, because the databases don't talk to one another. For example, FPDS, the Federal Procurement Data System doesn't communicate with EPLS, which stands for Excluded Parties List. Which means that the FPDS-powered USASpending.gov website -- heralded as the American public's window into the inner-workings of government -- doesn't even know that contractors contained within it have been banished from government service for defrauding the United States government or otherwise behaving badly. What's more, on some of these legacy systems, a search for Contractor X, Inc. won't return results for Contractor X Inc. The shorthand for that particular wrinkle came to be, during the hearing, "the comma problem."
In fact, GAO's William Woods explained to the senators, the poor state of those databases meant that when his agency was asked by Congress to detail how many contractors were billing the United States government for work in Afghanistan and Iraq, the government watchdog group was forced by technology to admit its ignorance. "We could not answer those questions," said Woods. How many KBRs are at work in American war zones, being paid with taxpayer dollars? How many Blackwaters? Dunno.
Everyone was in agreement that that status quo is unacceptable. And so the question became, what do we do now? Enter problem number two...
I'm pretty confident that danah boyd's was the most talked about talk during the Personal Democracy Forum 2009 Conference in New York City. I can say this because she was mentioned more than 750 times in the twitter stream during the 2 days of the conference. Michael Wesch got a lot of buzz - almost 600 mentions - and Jeff Jarvis and Mark Pesce (who gave a really powerful talk last year too) did well, each getting almost 500 mentions. But boyd topped them all.
Over in the Open Government Google Group (which you might want to consider joining) Alexis Madrigal admits that the Wired story on open government he's been working on wasn't working: "The actual mode of journalism with its traditional endgoal of a 'finished product' article that tells people how it is wasn't up to the task." So, he figured, hey, what's good for the government is good for the writer, and went open source with the project. Be sure to check out Wired's new How-To Open Government Data wiki, built on MediaWiki. The goal is pick a wide assortment of brains on specific areas where data sets the government produces should be put to better use for lay citizens and government employees alike, like turning USDA spreadsheets on crops and cattle into far more user-friendly XML feeds.
Madrigal's wiki joins a suddenly more crowded field of folks working to help incoming CIO Vivek Kundra figure out to marshall the information the government has at its fingertips. The W3C (World Wide Web Consortium) eGovernment Interest Group is holding a meeting in DC March 12th and 12th aimed at "develop[ing] a road map for developing Web standards to realize open and interoperable solutions."
We all have wishes for what Federal CIO Vivek Kundra will do during his term. The item at the top of my list concerns data.gov, which Kundra mentioned yesterday to the press:
Kundra, in conference call today with reporters shortly after President Barack Obama named him as federal CIO said one of his first projects is to create a data.gov Web site to "democratize" the federal government's vast information treasures by making them accessible in open formats and in feeds that can be used by application developers.
"How can we leverage the power of technology to make sure the country is moving in the right direction?" asked Kundra, stressing that his ambition is to "revolutionize technology in the public sector." (emphasis added)
A lot of people are really excited about Kundra's appointment. Most of these people want to see government data mashed up for public consumption. Such applications of this data are great, but I care more about mashing it up for internal consumption: government IT is decrepit, and the public tools that we (rightfully) complain about are light years ahead of the stuff available from government desktops. So I was excited to read that last sentence: Kundra wants data.gov to help the government. He is probably envisioning for data.gov something similar to Apps For Democracy, a project that, while successful, resulted primarily in public-facing applications instead of better tools for DC employees.
If his goal for data.gov is to help government IT, he'll need to engage more than application developers.