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)
Michael Daconta at GCN has posted a brief call to arms for the software industry. Here’s the gist:
Although I am a believer in free markets and the benefits of competition, industry has a responsibility to work together on the foundational layers to build security, quality and reliability from the ground up to advance the professionalism of the field. In essence, the information technology industry must emulate other engineering disciplines, or technological disasters and cybersecurity holes will worsen.
Daconta is uneasy with the number of platforms and methods available to software developers, and sees ever-more options and disruptions in the near future; IPv6 and 64-bit computing seem to trouble him particularly. We’re already balkanized and disorganized, how can we possibly expect to produce reliable and useful software with all this messy innovation happening?
The answer, of course, is control. Lots of it. Specifically, three proposals:
- Licenses for software developers
- A new, reliable, layered software platform developed by the NSF and DARPA
- Treat software like engineering, not art.
Gracious. I barely know where to start. Let’s try to imagine the software development world in five years, with these proposals in place.
Continue reading... (1124 words, estimated 4:30 mins reading time)
Like most of Jonathan Ive’s work, the iPad is beautiful. Like most of Apple’s work, it also makes me uneasy. I was planning to write about this feeling of unease, so imagine my delight when I discovered that Timothy B. Lee and others have already done the work for me. In “Why Geeks Hate the iPad,” “Tinkerer’s Sunset,” and “Nothing Creative,” we’re treated to a thorough overview of what’s sacrificed when Apple compels you to trade flexibility and freedom for a shiny new platform. I believe you can apply this same analysis to the iPhone, the iTouch, and everything else in the Apple’s consumer electronics stable.
Put another way, the iPad and its siblings are not personal computing platforms. They’re Apple computing platforms. The hardware itself is sealed, discouraging anyone from seeing how it works or improving on it. The platform software is largely proprietary. The vaunted App Store, which brought to the computing public the same ease of installation and application management that open source users have been enjoying for years, is rigidly controlled to advance Apple’s interests. Just ask Google.
Now, this doesn’t make Apple evil. They’re obviously entitled to produce as many beautiful, locked-up devices as they like. It’s important, though, to understand just what you’re trading for Apple’s warm, comfortable architecture of control.
Continue reading... (753 words, estimated 3:01 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.
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)
Using open source software, the US Navy was able to standardize the shipboard systems on its new destroyers, reducing the complexity of the ship’s systems and their reliance on proprietary real-time software. Wall Street now uses this same technology to execute orders predictably, without relying on vendor-specific hardware and software.
Every ship in the Navy is a floating data center. Computers run the ship, handle navigation, and track inventory. There are mail servers, databases, and everything else you would expect in a corporate data center. Unlike a corporation, though, the Navy also has weapons systems and radars. These systems are unique, since they must perform in a very predictable way: when you pull a trigger, you can’t wait for the computer to send an email. It has to happen right away. This determinism in a computer system is called “real-time” performance.
The Navy has already saved millions by moving to industry-standard computers and commercially available software. This real-time requirement flew in the face of this: the software is very expensive, and often very proprietary. Frequently, real-time systems require specialized hardware and specialized software, which was also expensive. These new systems also meant special training for the operators. So this meant two sets of infrastructure: one to regular applications, one to run the real-time applications. This was expensive and inefficient, especially since a Navy ship is so constrained by the lack of space. It would be much easier to have the regular computers handling the real-time work.
Continue reading... (549 words, estimated 2:12 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.
