Earmarks are a notorious vehicle for pork, in part because they lay nestled inside opaque legislative prose. In the FY2010 budget, WashingtonWatch’s crowdsourcing effort identified 40,000 separate earmarks — about 75 for every elected official.
There was a lot of talk about earmark prohibitions earlier this week, and each party swears it will be responsible with earmarks this year. But how do we hold elected officials accountable to these pledges?
Well, we can start by ensuring that earmarks see the light of day. A coalition of transparency advocates, including Sunlight Foundation, Americans for Tax Reform, OMB Watch, and OpenRegs.com all call for earmark data to be published in a standard format, so they’re easy to find, easy to understand, and easy to analyze. You can show your support here: http://earmarkdata.org/petition/
And if you’re a developer, take a look at the schema. What kind of applications could we build on top of data like this? What if I could get an RSS feed of earmarks for my elected officials as they’re reported? What if we could automatically rank the worst earmark offenders? What if we could correlate earmarks with campaign contributions automatically? The mind reels.
So I finally decided that Google had more than enough information about what I liked and disliked, that the laggy Google Reader interface was much more trouble than it’s worth, and Google Reader meant a separate and completely unnecessary inbox, which was playing havoc with my workflow.
So instead of going for a specialized RSS feed reader, I decided to integrate my RSS subscriptions into an inbox that I already know how to manage: my email.
I’ve done this before, and it worked really well. New items show up as emails, which I already know how to manage online and offline. They’re easy to forward, easy to search for, and so on. I’ll give up the Buzz and “sharing” option, but that’s what Twitter’s for, anyway.
To get this working, I installed the rss2email program on my server, and set up a cron job to run it every 15 minutes or so. New articles are emailed to me at a special address, which my mail server automatically files to a “news” folder. In order to get rss2email to use the same subscriptions I had in Google Reader, I had to add OPML import support to rss2email. It was pretty simple. I found a patch for this already, and just had to port it to the most recent version of rss2email. Here’s the updated patch, which applies cleanly to version 2.66. With that patch in place, I exported the Google Reader OPML file, and with a quick r2e import google-reader-subscriptions.xml, all my subscriptions were now being polled by rss2email.
Continue reading... (270 words, estimated 1:05 mins reading time)
Although it may be simple to conflate the Apps for Democracy and Apps for America contests with the exciting new Apps for Army contest, they really couldn’t be more different. Together they represent an exciting experiment in what it takes to pull communities together around a problem. Though they all offer cash prizes to the winners, they each took a slightly different approach, with different results.
Cash incentives are somewhat controversial in open source circles. Most old-school advocates for open source development strongly prefer developers who are personally invested — famously, those that “scratch their own itch.” Developers who are paid a salary to work on software are also invested, but perhaps less zealously than those who are solving a problem they are afflicted with themselves. Developers who are working for glory and cash prizes, the model used by the “Apps for…” competitions, is yet another class of developer, and despite the excellent submissions to the previous contests, there are valid concerns that the quality and sustainability of the code is not as good as it could be with a different set of incentives. Time will tell, of course.
Continue reading... (1252 words, estimated 5:00 mins reading time)
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.”
Continue reading... (1354 words, estimated 5:25 mins reading time)
In mid-October, the U.S. Department of Defense CIO released a memo on the use of open source software in the DOD. The Clarifying Guidance Regarding Open Source Software (OSS) was hailed as tremendous leap forward for open source software in the US Government. And indeed it is. At its heart, the memo is fairly simple. The basic points are:
- This is not formal policy, just a clarification of policy that already exists.
- OSS is COTS (Commercial, Off-the-Shelf Software) and the same rules that apply to regular software apply to OSS. In other words: you cannot disqualify an open source software product just because it is open source.
- Further, the memo reminds us that COTS software has special status in DOD procurements, because you’re supposed consider commercial alternatives before writing your own.
The memo has been under development for 18 months, and can trace its lineage to the DOD-commissioned report by MITRE. You can think of the 2007 Navy memo as a kind of prototype for this document, which applies to all of DOD.
The memo’s Attachment 2, though, grows more bold, offering several specific benefits that open source software can offer the DOD:
Continue reading... (462 words, estimated 1:51 mins reading time)
Here’s a really nice writeup on the CONNECT Code-a-thon at iHealthBeat. They quote me a lot, which is what makes it really nice.
Most of you already know about the US Courts’ shameful profiteering through the PACER system. They charge $0.08/page for public court documents and in so doing stifle the public’s access to their own content. Not long ago, our friends at CITP released an open source project called RECAP. When you install this gem in your browser, documents your retrieve from PACER are deposited in a public archive, where they can be retrieved by everyone, at no cost, forever.
So no surprise that US Courts is now discouraging the use of the plugin. They stand to lose a lot of cash if these documents are free.
What surprised me first is this little gem:
A fee exemption applies only for limited purposes. Any transfer of data obtained as the result of a fee exemption is prohibited unless expressly authorized by the court. Therefore, fee exempt PACER customers must refrain from the use of RECAP. The prohibition on transfer of information received without fee is not intended to bar a quote or reference to information received as a result of a fee exemption in a scholarly or other similar work.
Continue reading... (388 words, estimated 1:33 mins reading time)
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.
Continue reading... (290 words, 1 image, estimated 1:10 mins reading time)
Two soldiers in a hastily built watchtower.
In Iraq, Sergeant 1st Class Martin Stadtler had nothing. He was stationed near Mosul, at a base that covers 24 square kilometers. Surrounding the base was a wall, and at intervals along that wall stood watchtowers. Those towers were improvised; they were large concrete water pipes, stood on their ends.
Inside each tower is a pair of soldiers. They’re watching for insurgents. To communicate with the home base, they had standard-issue tactical radios. Unfortunately, these radios couldn’t reach home base — the base was too big. Soldiers had to play a game of Telephone to reach the base: one tower radios the next until they are finally in range of the home base. Obviously, this would not do.
Continue reading... (1137 words, 3 images, estimated 4:33 mins reading time)
Using open source software, the National Security Agency was able to gather a community of professional and amateur security experts together to make unprecedented security protections available to public.
The National Security Agency has a mission. It is not just the nation’s code keeper and code breaker, but it must ensure the security of the nation’s digital infrastructure. Ironically, it had a security problem: the ecosystem for software that was keeping top secret information secret was deeply broken. There was little competition, no innovation and this essential software was expensive, slow to market, and antiquated.
Multi-Level Security, or MLS, is a complex problem: how to allow data with many different security classifications exist on the same machine? MLS software is difficult to get right, and easy to get wrong. It is subject to a stringent certification process. Although useful in certain areas of the private sector, there’s really only one customer for this kind of software: government. Once you’ve deployed MLS software, it’s very difficult to move to another solution as every MLS system was different. These are near-perfect conditions for very expensive, proprietary software that doesn’t innovate.
Continue reading... (716 words, estimated 2:52 mins reading time)
I'm the Chief Technology Strategist for the Red Hat US Public Sector group, an open source and free culture advocate, a picky drinker, an amateur aesthete, and a dog enthusiast.
