On Wednesday, Apple is expected to unveil a product that will be, among other things, a competitor to Amazon’s Kindle. That will be a crucial test for Apple, and for society. If the company lives up to its reputation for revolutionizing media, this new product and its successors will one day replace physical books. The test for Apple is in whether they try to control what we read. The test for society is whether we let them.

We all know that this device will be strikingly beautiful, will feel good in our hands, and will have some special touch that, like the iPod’s white earbuds, endows its users with an aura of cool. It will do so much more than display books (reading will be sexy again!) that this simple feature may be lost among the device’s more advanced trappings.

But after fawning over it, we should ask how much freedom the device gives us, and what it means for the future of reading: will the iSlate (as it’s rumored to be named) let us put our own ebooks onto it, or will it only show documents in Apple’s own proprietary format? Will we have to buy everything through Apple, allowing them an eye into our reading preferences? And when we buy those books, will Apple have the technical ability to remotely revoke our access to them? A restrictive iSlate would allow Apple–or someone else–to abscond with your entire library in the middle of the night, all without ever knocking on your door. If the act of reading isn’t safe, who cares if it’s cool?

This ability to take away our books is a current reality, not a future prospect. Kindle users discovered this last year when Amazon remotely deleted their copies of Animal Farm and 1984. Even though customers were storing the books on their own devices, those devices automatically deleted the books when Amazon removed the titles from the Kindle store, like an army of drones taking orders from their master. From day one, Apple has used similar technology to make sure that a song or movie bought on iTunes can only be played on authorized devices. They do this to protect the rights of artists and production companies.

But that was music. This is books. The stakes are higher. And the Kindle goes further. Unlike the iPod, which allows you to play your own, non-revokable songs and movies on your iPod in addition to the ones you bought through iTunes, the Kindle is designed to only display books that Amazon can control. The same technology that is ostensibly protecting books also jeopardizes our right to read them. If the iSlate is similarly restrictive but as successful as its music predecessor, we’ll have surrendered final say over our bookshelves to companies and governments.

Would Apple and Amazon really intentionally censor our books? This all seems very far-fetched. Sure, Amazon did it already, but it actually had good reason to: the publisher who originally provided those titles to Amazon did so illicitly. The irony of the affected titles made the affair sound more scandalous than it was. Amazon acknowledged that it was “stupid” of them and later changed its system to keep such automatic deletions from happening again. So it was all just a mistake. Book censorship happens in fictional dystopias, or in real-life dictatorships. But here?

Don’t discount it. For one, the Amazon fix only applies to cases similar to the Orwell books; it simply prevents Amazon’s system from acting on its own in such cases. Amazon still has the power to seize books you’ve supposedly purchased.

Second, you’re right to feel that our society wouldn’t tolerate a government seizure of books. But that’s precisely because books are physical objects: to seize them, someone must kick in our doors, and to destroy them, they must be burned. Seizing books would be a lot easier for governments were it not accompanied by such graphic displays of tyranny.

But what happens when technology allows books to be disposed of quietly, cleanly, and without force? As a parallel, consider how outraged we’d be by having our home phones removed, and being forced to place phone calls only from approved “monitoring centers.” We would violently resist such demands. But the same government’s use of warrantless wiretaps just years ago was met with public ambivalence. Burning books? No way. But deleting books, or “filtering” them? That’s much more palatable.

What are the odds that we will reject a no-doubt beautiful iSlate just because it won’t read our own PDFs or Word documents? Our past record isn’t good. We seldom reject convenience in return for freedom: we tell FreshDirect what we like to eat so we don’t have to go shopping, let credit cards report our spending habits so we don’t have to carry cash, and use trackable subway cards instead of fumbling with tokens.

Why do we give up so much for more convenience? Maybe it’s because technology’s affordances are much more tangible than its pitfalls. We enjoy the convenience of email and credit cards many times a day, and even though we assume the IT staff is reading our messages and a consumer data firm is tracking our purchases, we never actually see it happen.

Another reason could be that the digital world has muddied the concept of ownership, introducing ambiguities and restrictions that we don’t have the time or the legal expertise to decipher. When you buy a book, there’s no question that the bound collection of paper, ink and glue is yours, and that nobody can take it back from you. But the Kindle’s Terms of Use is over 2,000 words of legalese that most users will ignore. “I never imagined that Amazon actually had the right, the authority or even the ability to delete something that I had already purchased,” said a customer who had his $.99 copy of 1984 yanked.

The fiasco hasn’t fazed Kindle users, who are proving that the convenience of carrying hundreds of books is what really matters to them. Christmas Day marked a turning point for the Kindle: for the first time ever, Amazon sold more ebooks than actual books. Clearly, we aren’t going to be the ones who stand up for the security of books.

So it’s up to Apple, which could be a better steward of information freedom than we have been. The company stopped selling restricted music files last January; customers now have complete control over every song in their music library, even those bought through iTunes. And again, they’ve never barred us from putting our own files on the iPod, making those songs completely safe from any intrusion. Will Apple do the same when it comes to books? Or will it follow Amazon’s lead? Apple’s decision matters a lot more than Microsoft’s, Sony’s or Lenovo’s, all of whom revealed similar new products earlier this month. When Apple makes a decision about digital media, entire industries–and the public at large–follow their lead. As the iSlate goes, so will thought. Let’s keep this in mind during the hysteria of Wednesday’s unveiling.

—–

The federal government should fire me. Like the thousands of other contractors who develop software for government agencies, I am slow, overpaid, and out of touch with the needs of my customers. And I’m keeping the government from innovating.

In recent years, the government has become almost completely dependent upon contractors for information technology (IT). So deep is this dependency that the government has found itself in a position that may shock those in the tech industry: it has no programmers of its own; code is almost entirely outsourced. Government leaders clearly consider IT an ancillary function that can be offloaded for someone else to worry about.

But they should worry. Because while they were pushing the responsibility for IT into the margins, the role of IT became increasingly central to every agency’s business. Computing might have been ancillary 20 years ago, when the only computers were the mainframes in the basement. Average employees never had to worry about them. But today, a computer is on the desk of every civil servant. Those servants rely on their computers to do their jobs effectively. Every day, they encounter new problems that could be quickly solved with a bit of web savvy, were there only a programmer there to help.

And they desperately do need help. Imagine not having Google to quickly find information; no Facebook or LinkedIn to find new colleagues; no instant messaging to communicate with those colleagues once you found them. Imagine having to ask for permission every time you wanted to publish content online, instead of being able to do it quickly and easily with a wiki or weblog. This is the state of computing in the federal government.

SIDEBAR

On top of keeping the government from innovating, the dependence on contractors hurts the country in much more tangible ways. In February 2003, a few weeks into my job as an intelligence analyst with the Department of Defense (DoD), the Federal Republic of Yugoslavia officially changed its name to Serbia and Montenegro. My job was to maintain an enormous database of facilities in Eastern Europe, including labeling each one with a country name. But the tool we used didn’t have an option for “Serbia and Montenegro,” so on the day of the name change, I emailed the contract officer in charge of the database with a simple request: “This country changed its name. Could you please update the tool to reflect this?”

Doing so would have taken a computer programmer less than five minutes. But instead, he used that time to respond to my email:

“We’ll consider it for the next version.”

In other words, his current contract—written months prior—didn’t account for changes in the geopolitical landscape, so there was no paperwork explicitly authorizing him to make this change. To do it, he would have to wait until the contract was renewed (months or years from now) and the government allotted funds for this five-minute job. It wasn’t his fault; he was no doubt aware of how easy it was to make this change. But doing it without permission from either his boss or the government would spell trouble. Yugoslavia didn’t exist anymore. Except inside our office, where we had to wait for a contract to make it so.

The government can no longer afford to outsource IT. It is core to the government’s business. If the government intends to do IT right, it should wean itself from outsiders like me and start doing the job itself.

What’s so wrong with contractors? Nothing, really; the problem is the processes they have given rise to. The pervading philosophy is that government is slow, inefficient, and incapable of quickly adapting to change, while private companies do things better, faster, and cheaper. In many cases, this is true; the government is by no means a well-oiled machine. But software is one thing that contracts do not speed up. Software developed under contract is much slower and much more expensive than any other form of software development still in practice. Here is how the typical IT contract evolves:

1. A low-level government employee complains to her boss about a problem. This could be anything from a bug in an existing piece of software to a gaping hole in her agency’s IT security. The boss has no programmers on hand to solve the problem, so he dismisses it.

2. More and more people complain about the problem until it gets attention from higher levels. But even thinking about a solution is expensive—months of paperwork must come before a contract is awarded and someone finally starts writing code—so the problem remains unsolved.

3. The problem leads to a calamity—a website is hacked, classified information is stolen, or electronic voting booths break down on Election Day—and leaders are finally motivated to solve the problem.

4. Procurement officers write a list of requirements for the ideal solution. Because they have little direct experience with the problem, they survey the workforce to get a sense of what’s needed.

5. The workforce’s version of the problem is condensed into a document called a Request for Proposals, or RFP. The RFP is then distributed to potential bidders, who will respond with a proposed solution and a bid based entirely on the contents of the RFP. Contractors cannot go directly to the users, the people who know the problem best. The RFP is therefore an indirect, highly edited communiqué from the user to the contractor, a substitute for the invaluable direct interaction between user and coder that guides any successful software product. But it’s too late: contractors are from here on out trying to solve what they believe the problem to be, not the problem that really is.

6. The contract is awarded. Months or years after the problem was first noticed, the first line of code is written. Over the coming months, the winning bidder will develop the solution off-site, hidden from the eventual users who could be providing valuable feedback.

7. The solution is delivered. Because the target users had such a small part in the development process, the solution falls short. It is hard to use and comes with an 80-page manual.

It should now be clear why the government is so far behind the times: it isn’t allowed to solve its own problems, relying instead on people who do not understand them. Two glaring faults doom the contracting process to failure. First, the development process is vastly different from that of today’s most popular software. Modern web applications are persistently watching their users and adjusting their code to make it faster and more user-friendly. Adventurous users can begin using these applications before they’re even finished, giving the developers invaluable insight into their users’ preferences. Without this constant feedback, the developers risk spending years on a product in private, only to reveal it to the public and find that nobody wants to use it. Such products are so common in government that they have earned their own moniker, named for their eternal home: shelfware.

Second, the paperwork required to simply start coding takes time and money. So, to even consider solutions, the problem has to be severe enough to justify months of bureaucracy. Why go through all that trouble just for a problem that would take a week to solve? The logic makes the taxpayer ill: the bureaucracy actually wants high price tags. The result is an organization full of easy problems that get no attention until they are big, expensive, and ready to boil over.

Tipping Point: The Extinction of Pencils

One such problem that may soon boil over is the terrorist watch list. For years, the list—created to monitor suspected terrorists and keep them from flying on commercial airliners—had inconvenienced innocent travelers. The problems were evident, but they weren’t bad enough to justify asking for help.

Then a toddler was kept from boarding a flight. Then a senator. At some point, this problem crossed the threshold, and the government issued an RFP for an improved database to manage the list. The $500 million contract was awarded to Boeing and a smaller company. After months of development, a congressional investigation discovered that the soon-to-be-deployed database could not perform basic searches for names, and was missing huge stores of valuable data. The National Counterterrorism Center had spent half a billion dollars on a tool that, while certainly complex, could not do things that you and I do every day from our home computers.

Why so much money for something that seems so simple? This frame of mind—that technology projects should be big, expensive, and time-consuming—has honest beginnings. Twenty years ago, computing was a niche. The government used computers to encrypt the president’s phone calls, simulate nuclear blasts, and predict the weather. The government paid private companies lots of money to build very complex systems. That’s OK, because tasks such as these required lots of computing power, so the biggest, baddest, most expensive system was usually the best. It didn’t matter that these systems were hard to use, because the only people using them were computer scientists. The builder of the system understood the user—the builder and user may have even worked side by side—and if the user ever needed the system to do something it couldn’t, that user probably had the skills to tweak the system. Computers were left to the computer people. Everyone else still used pencils.

But computing is now everywhere. Computers long ago fit on our desktops. Now they fit in our palms. But the government still acts like computers fill basements, and if you could sit down at a government desktop, this outdated mindset would be immediately apparent: on the screen would be websites reminiscent of the mid-1990s, without any of the web-based productivity and collaboration tools that define today’s Web. Expensive supercomputers still matter. But so do cheap, light web applications. Small, unassuming tools can change the way an organization does business. Such tools are commonplace online, but they do not get a second look from a government that expects and needs its technology to be expensive. Meanwhile, independent developers are at their keyboards, proving themselves willing to help a government that, as we’ll see, is slowly opening its arms to them.

Competition Is Critical to Any Ecosystem

One of the reasons the Web has better tools than the government is competition.

Take airfare as an example. There are countless websites that help you buy plane tickets, each of them constantly improving their tools and layouts to make you happier. And if you aren’t happy with those sites, you’re free to start your own business and compete with them. But when the government contracts new software, it gets only one product out of it. Instead of many choices, users have only two: use this tool, or use nothing.

Web developers know that the first attempt at an innovation almost never works, and that it takes many attempts before someone gets it right. For every Facebook, there are countless Friendsters. Given one chance, you’ll likely end up with one of the latter. If the government wants better software, it has to start creating and acquiring more software.

In the past year, two promising government projects have chipped away at this problem. Washington, D.C.’s Apps for Democracy competition let independent developers build web applications for a shot at prize money. The D.C. government’s $50,000 investment bought it 40 tools in 30 days. The District got to keep every contribution but only paid for the really good ones.

Meanwhile, the U.S. Intelligence Community is becoming an unexpected leader in engaging everyday developers. To provide more analytic tools to their workforce, they have released BRIDGE, an open development platform akin to Facebook’s: now, any software developer can build a tool and provide it to intelligence analysts. If the analysts like it, the government buys it. If it’s junk, your tax dollars are saved.

This approach worked for Facebook: it gained 30,000 new tools in two years, and got other people to do all the work. Most of these new tools fall into the junk category, but many others are invaluable. The community finds the good ones and makes them more visible. It is the same principle that governs our economy: we buy the dish soap that works, and the bad ones go away. We should expect the same practice from our government, whose very job is the promotion of market economies and democracy. Apps for Democracy and BRIDGE are a welcome departure from contract-based software.

But while these projects are giving government employees more options, they haven’t filled in all the gaps. Who will maintain software that was built not by a global firm, but by an independent developer who is juggling multiple projects?

And what about user feedback? Neither of these projects addresses the fact that government software is built by people unfamiliar with government users. Apps for Democracy produced useful tools for D.C. residents, but little for D.C. employees. And applications on the Intelligence Community platform are hobbled by the world’s biggest firewall: intelligence analysts use these tools on a top-secret network that doesn’t allow them to communicate with the outside world. As long as the government keeps developers outside its walls, those developers have no hope of solving the government’s technology problems. The civil service needs an infusion of technical talent. The civil service needs intel techs.

Creating a Developer Corps

Decades ago, the intel tech (also known as “mission support” at some agencies) was a specialist in the Intelligence Community who helped analysts with now-defunct technologies: setting up the light table to look at satellite imagery, making mimeographs, and so on. Unlike today’s tech support staff who sit in the basement or in Bombay, these experts sat among the analysts and were solely dedicated to the analysts’ mission. And because they were government employees, they were at the analysts’ disposal whenever help was needed.

But then personal computers arrived. Software made the intel techs’ tools obsolete. The light tables vanished. The intel techs soon followed. It is the opposite of what should have happened: IT’s role in intelligence analysis—and every other government function—has grown tremendously, while the government’s in-house technical talent has dwindled. Government employees’ need for technical help has never been greater, but there is nobody there to help them.

If they still existed, today’s intel techs would be developers. They would be deploying web applications for new needs the moment they arose. They would mash up data and make it easier for both civil servants and private citizens to consume. They would do the things that contractors do today, only immediately—no paperwork necessary—and with users at their side. The intel tech must be resurrected for the Internet age. The government must hire web developers and embed them in the federal bureaucracy.

The government needs to hire the people who have been fueling the web application boom for the past 10 years. They are young programmers who created revolutionary tools from their dorm rooms, and they are small firms with virtual offices who stumbled upon a new way of doing business. The trouble is, most of these people are not compatible with government culture. They like working from p.m. to a.m. They don’t like ties. They seek venture capital, not pay grade bumps. Are they supposed to move from one coast to another and indefinitely trade in their lifestyles for something completely different, not knowing when they would return to their old lives? That is asking too much.

But what if these in-house developers weren’t standard government hires on entry-level salaries? What if their time in the government wasn’t a career, but a mission akin to a term in the Peace Corps or Teach For America? A program marketed and structured as a temporary “time abroad” would let developers help their country without giving up their careers and identities.

Now is the perfect time for such a program. Silicon Valley’s interest in D.C. has never been as great as it is now. Technology icons are encouraging developers to quit creating banal tools and instead put their energy into things that matter. And it’s working: several prominent Internet entrepreneurs have become full-time civil servants. Many more have contributed software tools to programs such as Apps for Democracy and BRIDGE. Apps for America‡—a federal take on Apps for Democracy sponsored by the nonprofit Sunlight Foundation— received 34 submissions during its first iteration, and 46 more on the second. Geeks want to help government. The government just has to give them the right invitation.

Like the Peace Corps and Teach For America, terms in the Developer Corps would have a time limit. Whether this limit is six months or six years, I do not know. But a limit of some kind is important. First, it will be easier for developers to make the leap if they know they will eventually return to their current careers.

Second, being detached from an agency’s pay scale and career plan will give the participants the freedom to experiment and—more importantly—to fail. Failure is a key part of innovation. Technology firms know this, and their employees are used to working in atmospheres that encourage failure. If they don’t try new things, they’ll be killed by their competition.

Not so in government. Unlike private companies, a government—at least ours—is relatively safe from competition, and thus doesn’t feel the need to be constantly reinventing itself. Things are fine how they are. The populace views failed government projects as little more than a waste of taxpayer dollars. No career-conscious government employee wants to take on such a risk. So, to succeed, the Developer Corps’ participants must have the same freedom to fail that they did in their former jobs. The knowledge that their terms will end on a set date will quell the fear of failure that plagues the average government employee.

The greatest threat to this program is lack of permission. If red tape keeps developers from being productive, they will end up wasting their time fixing printer jams instead of writing code.

Developers work quickly. They can implement ideas within hours of conceiving them, continuously deploying, checking, modifying, and redeploying their code dozens, hundreds, thousands of times along the way. Doing this never requires anyone’s approval. But within each government agency are multiple offices that must vet code before it is deployed: system administrators, information security officers, lawyers, and so forth.

Developers will never get anything done with such thick bureaucratic walls between them and their work. Wasting their talent is the fastest way to destroy the corp’s reputation. They must be given authority to code what they please. Not all agencies will grant this authority. Such agencies must not be allowed to participate in the Developer Corps. (Participants in restrictive environments would never get anything done anyway, so there is no harm in barring uncooperative agencies.)

Finally, this program should take a page from a new organization called Code for America (http://codeforamerica.org). CFA recruits coders to work with government offices for set terms, but at the municipal level instead of federal. About to enter its inaugural iteration, CFA’s participants will work with their respective governments remotely from a shared space in California. This communal coding environment will let participants enjoy networking events, guest speakers, and the creative energy generated by each other’s ideas.

The federal program I’ve proposed in this chapter should incorporate a similar communal environment. While coders will spend their days at their respective government agencies, group housing will let them discuss their work over dinner and drinks, allowing the creative process to continue after hours. And select days could be dedicated to meetings with government leaders and tech luminaries, visits to other agencies, and networking. Such events will help ensure a D.C. term is a boost to a coder’s career instead of diversion from it.

Conclusion

Our government agencies need the ability to develop their own software. Keeping them from doing so prevents them from providing vital services that we all pay for. No story makes the case for this capability better than that of Jim Gray.

Gray was a technology pioneer who, during a sailing trip in early 2007, disappeared off the coast of San Francisco. The Coast Guard searched for him for three days and could not find him. They called off their search.

But a group of determined people kept looking. They had imagery satellites take fresh pictures of a swatch of sea outside the San Francisco Bay. If Gray was out there, he and his boat were now on film. But they were left with hundreds of photos, each big enough to cover a wall. A handful of people could never review the images in time to save Gray. So, a team of software developers converted those large photos into lots of smaller ones, which were then posted to a website where the public could review them. Clicking on a possible sighting sent a report to a flight crew, which then searched the area in question. Noticing that the images were blurry, another team of programmers contributed code that automatically sharpened the images. The entire system was created from scratch in just a few days. And it was done without any help from the government.

This effort was coordinated entirely by private citizens with the help of publicly available technology. Though he was never found, Gray inspired the largest collaborative search party in history. Twelve thousand private citizens reviewed more than half a million images. It is an amazing story of teamwork and ingenuity. Inspiring. Soul-stirring.

But also frustrating: why didn’t our government do this the moment Gray was reported missing?

It is tempting to use this story as a case for more self-governance: if the public can do it and the government can’t, why not go with it? Instead of equipping the government to do what private citizens already can, let’s just do their jobs for them from our home computers.

The Web has made it simple to form ad hoc groups and coordinate their actions, and we will continue to see cases where such groups fill the government’s shoes. But such cases will not be the norm. Our populace cannot govern itself just yet. There are too many critical functions that we cannot yet take over. We do not have battleships. We cannot run elections. Some private citizens guard our borders, but that doesn’t mean they should.

We will need a formal government for the foreseeable future. Our government should be at least as capable as a quickly organized group of virtual volunteers. It will certainly have the budget for it.

Back in October, the Director of National Intelligence killed a program called BRIDGE. (I’ve written about BRIDGE before.) As such a vocal advocate of BRIDGE with a financial interest in its success, my bias is clear, but for whatever that biased opinion is worth, BRIDGE’s death was the biggest government IT failure of 2009.

The cause of BRIDGE’s death is the most frustrating aspect of it, and it’s a reminder of what makes government innovation so logistically difficult: BRIDGE wasn’t deemed a failure or a waste or a PR risk. Technically, it wasn’t even killed; it was just put on ice. Following the presidential transition, new priorities were made at the top levels of the bureaucracy. These priorities had nothing to do with BRIDGE in particular, or any other tech-related goals. BRIDGE just got lost in the shuffle along with countless other programs that deserve attention.

It was a casualty of a paradox of government bureaucracy: in government, change comes very, very slowly. It takes a really long time for something to happen, and nothing ever happens without a lot of deliberation. Everything is slow. Everything, that is, except for its hatchet. The government can end large swaths of projects with breathtaking speed.

I used the word “hatchet” deliberately. Many programs are killed not because they were hand-picked as faulty, but rather as a simple result of changes in government administration. This happens at least once every four years, and even more given all the agency directors, cabinet secretaries, deputy secretaries, under secretaries, assistant secretaries, and principal deputy assistant secretaries whose routine replacement can cause not-so-routine changes to the way their staff do business. I stayed at the same desk throughout my three years at the Department of Defense. In that time, six different people sat in my boss’s chair, and my office’s name and mission changed twice.

New government executives come and go. Each new one sees things a bit differently than their predecessor and orders a change in strategy. Whether those changes are for better or worse, they’re changes, and they’re enough to nip any promising project in the bud. That promising project probably took two years of paperwork to get off the ground, but it’s gone in an instant. Later, someone will realize there’s a need for it…and the process begins again. The slow start/fast hatchet paradox makes it extremely difficult to succeed with technology projects that take a few years to bear fruit. They can barely get going before simple bureaucratic machinations force them to stop. That is the reason for BRIDGE’s demise.

The official word on BRIDGE came in October:

Thank you for participating in the BRIDGE experiment…We are working on an updated concept which we hope to launch in the near future under a new name. We would like to see all of you back as we move to a more permanent infrastructure. As soon as we have a launch dateand URL we will post it at http://about.bridge-ic.net/.

BRIDGE died before its first birthday, long before the “next model” deserved any thought. From my seat as a BRIDGE developer, even the first BRIDGE hadn’t been fully fleshed out before it got the axe; some of the technical specs were still undefined. When will this next model be live? The provided link is dead, if that’s any clue. (Remember: quick to kill, slow to start: there’s no time for the previous project to transition to the new one, which probably won’t be announced for quite some time.) As far as I know, the next model still lacks an executive agency–an entity of the Intelligence Community like the NSA or CIA willing to oversee the project. This will be a hard sell, given that it’s not apparent how an individual agency would benefit more from BRIDGE 2’s success than its partner agencies would.

But there is benefit. Major recognition awaits the people who champion this project and guide it to success. BRIDGE and A-Space (a sort of private, classified instance of BRIDGE) are a lot more than a platform for intelligence analysis and information sharing. They are a model for software development that could change the entire government procurement process. Traditionally, the government has bought software–and many other products–through a buy first, evaluate later model that doles out excess money for poor work. BRIDGE provided a way to change that, creating a market for software tools that any developer could contribute to. I’ve detailed the mechanics of BRIDGE in the past, so I won’t reiterate them here.

BRIDGE’s and A-Space’s incredible potential has also been their major fault: the real benefit and genius of these programs has been hard to explain to non-techies, and while government executives have sung their praises to the press, those praises don’t really get to the heart of what these programs are about. (Nor does Wikipedia’s A-Space entry.). They are not simply “MySpace for spies.” They are so much more. If you are an agency CTO frustrated by the insane way you buy software, consider a new and better way. Adopt the next iteration of BRIDGE. While the technical details will be hard to explain to your bosses, the results–better performance and huge savings–should speak for themselves when it comes time for your performance review.

Thanks to Lewis Shepherd for his guidance on this.

I just moved to a Brooklyn brownstone. Right outside my door is a curb cut at an intersection. People park there. Then they get towed and fined about $400. But this shouldn’t happen, because this particular curb cut is at a T-intersection, and there is no crosswalk painted on the road. This makes it a legal parking spot. The law was changed last year. Look, see?

Maybe you found this post because you’re one of the poor schmucks who had their car towed. I wish you luck in recovering it. In the meantime, don’t worry: while you can’t recover the time you’ll spend at the tow pound, you can get your money back. But the burden of proof is on you, so you have to make your case effectively. I think I can help you do that.

My own car was towed from a similar spot in August. I put together a pretty detailed package of evidence to make my case. I’m posting it here for you to borrow. You’re free to copy and edit the letter to make it fit your own circumstances. The pictures, of course, will have to be original–unless you were towed from the exact same spot I was.

My package had five things: the ticket; a copy of my tow pound receipt; a copy of the DOT Web page I linked to above, with appropriate portions highlighted; a letter stating my case; and four pictures of the intersection in question.

1: The ticket. When I finally got to mine, it had been sitting on my windshield for three days and was completely illegible. However, the summons number was on the tow pound receipt, and that’s the only important piece of information you need here. You must still include the ticket with any response, however.

2: The tow pound receipt.

3: The DOT Web page. It felt so good to come home with my car, jump on the computer and read those words:

Parking is now permitted at those “T” Intersections where the adjacent (major) street is not marked with a crosswalk and not controlled by all-way stop signs or traffic signals, even if there is a curb cut at that location.

The only sweeter words were the ones that preceded them:

These locations have caused confusion in the past, as they were not clearly delineated as spaces for pedestrians or cars.

HA! So DOT acknowledges that it’s confusing, changes the law, and yet NYPD Traffic still enforces the old one. Print out a copy of this page. Highlight the paragraphs in the “Parking and Curb Cuts” section.

4: The letter. Download mine in Word format. Edit it to reflect your own situation and sign it.

5: The pictures. My pictures include some handiwork that, while not essential, will probably strengthen your case: I superimposed the DOT’s drawing on my photos to provide the traffic judge with some perspective. Also, I got closeup photos of the address, in order to prove that the intersection in the photograph is indeed the intersection at issue:

Image 1
Image 2
Image 3
Image 4

These enhancements require some decent photo editing skills. If you don’t have the right software, they can probably help you at a copy center. Enhancements or no, print your pictures in full color.

Now what?

Now that you have everything, what should you do with it? I’m not sure. I requested a hearing by mail, sent in my package, and waited. It’s two months later, and I’m still waiting. In the meantime, my fine has been raised $10 because I “failed to respond.” In other words, the people in the “Have people paid their tickets?” office received it (I have a certified mail receipt to prove it) but never told the people in the “Let’s fine people for not paying their tickets” office. If you go the hearing-by-mail route, prepare for this. Use certified mail.

In the course of sorting this out, I was told by city personnel that I shouldn’t bother with hearing-by-mail, and should just walk in to court in the morning. It’s low traffic and fast. I plan on doing this soon.

Good luck to everyone.

UPDATE: I went to the Brooklyn finance office on Joralemon to sort this out. After about 15 minutes of waiting, I saw an adjudicator. The job of the adjudicator is to offer you a reduced fine. If you refuse, you get to see a judge. I explained my case to the adjudicator and showed him pictures. He then typed a few keys on his computer and said with a smile, “That’s dismissed!” He was fully aware that T-intersections are legal spots.

The ticket was now taken care of, but he could not refund the tow fine. That requires a separate form (which you can find here) and a copy of your tow receipt.

I wrote to the Department of Transportation about this coordination failure. Their response:

We have been informed of instances where police officers or traffic enforcement agents may not be aware of the rules change and have issued summonses for parking at T-intersections where parking is now legal. We are working with the Police Department to ensure that all of its personnel are aware of the rules change, and with the Department of Finance, which adjudicates summonses, to ensure that summonses that may have been issued in error are properly adjudicated.

Ah, bureaucracy.

Let’s say you want to become an authority on something but have no academic training or prior experience. The first thing you do is _______.

I got a good response, so I thought I’d post them here:

1. ghelleks become a journalist.
2. topperge read
3. johnmscott find someone to pay your education
4. kirbstr find a mentor
5. Swerdloff Find a mentor in the space.
6. mcpaige Google it!
7. jonmott Get to know some people who are “authorities” in the field. Follow, learn from, and interact with them.
8. Pishba … find the experts, read them, talk to them.
9. [Private account] Start reading. Then, start writing. Mentor will follow.
10. [Direct message] read a book on the subject. Then get to know the best people in that field.

I think it’s interesting that only one person mentioned anything about school. My question was not hypothetical, so I wonder if more people would have recommended schooling had I mentioned the subject at hand: transhumanism, from a philosophical and anthropological perspective. The most popular recommendation was to find a mentor, and that’s something I am going to start doing soon. So if you have thoughts about where to go, please share them.

Also, if anyone wants to refine their answers (or give them for the first time), please comment below or reply to my original tweet.

You didn’t have to be computer smart to take part: a developer in San Francisco had set up a push-button tool that would, upon your click, immediately start bombarding 10 Web sites with requests. I clicked Start, and in the 10 little boxes below, I could see the pages load and reload. About half of them were already down.

This was exhilarating. The goal was to promote democracy, and I could actually watch as it happened. Empowering.

But there’s more to it than that. I’m conflicted about the virtue of this idea. I’m still trying to sort out my thoughts about what happened, but I know that we will be talking about yesterday morning for years to come. We turned our collective power and outrage into a serious weapon that we could use at our will, without ever having to feel the consequences. Network warfare became available to the general public. That is frightening. Here is how my thinking evolved throughout the day:

After a few minutes of watching these Web sites sputter, I spread the word on Twitter. I was met with a few dissenting replies. Clay Shirky felt that by doing this, we were validating the idea of Denial of Service attacks, and that if we endorsed it now, we couldn’t argue against it when the state uses it against dissidents.

I disagreed. While our use of it may make us look hypocritical the next time we complain about a state’s actions, I don’t think we can avoid tactics simply because of that risk. If we forsake every weapon that the enemy uses, simply because the enemy uses it, what options do we have left?

I don’t think the idea of disabling your enemy’s communications is right or wrong. That judgment hinges on a few factors. First, “sticking it to The Man” is not a standard philosophical justification, but there is something about it that feels so right. There were reports that the Iranian government disabled SMS on election day and attacked Moussavi’s campaign site. Giving a citizenry the ability to turn the tables on its own government is, I think, what governance is all about. The public’s ability to strike back is something that every government should be reminded of from time to time.

The nature of the information being silenced also counts. And when the loudest voice is distributing pure drivel, that voice has to be stopped.

I should also mention that the US military is the preeminent practitioner of communications hacking: when we invade, the telephone switches are the first to go.

Fernando Cervantes made a good point: when you attack a Web site, you don’t just attack that site, but every other site on that host as well. You also clog bandwidth. And as I write this, we in the West are still heavily relying on the Internet to tell us what is going on over there; though it’s unclear to what extent, we can also assume protestors are using the Internet to coordinate. By attacking these sites, we’re hurting not just the state, but the people we’re trying to help as well.

This is true. But if government is disabling services that we do want to be available (SMS, Twitter, etc), then we’re allowing the public to be exposed to whatever news the state deems fit, and this is the worst possible outcome. Google gave up the “Don’t Be Evil” mantra on the day they gave in to China and agreed to filter news.google.cn, on the basis that some news is better than no news at all. This argument reeked of B.S. And now that I had the ability to upend that judgment just a tiny bit, I was going to take advantage of it.

I still agree with all of my thinking above. But after a few minutes of letting the attacker run in the background, I stopped it. I don’t know why, but it just felt…creepy. I was frightened by how easy it was to sow chaos from afar, safe and sound in my apartment, where I would never have to experience–or even know–the results of my actions. All I had to do was click a button. And while my intentions were honest, there is something inherently wrong with the ability to so easily cause harm, without bearing any of the ill effects. I could have been causing the failure of emergency services that I was not relying on. I wouldn’t even suffer the guilt of knowing what I’d done, as it’s unlikely I would ever find out.

(UPDATE, just to elaborate: When people want to attack someone or something, they usually can’t do it immediately. It takes time to prepare. And during that preparation, they are repeatedly forced to reconsider their actions before going trough with it. Each step–buying/building a weapon, choosing a time and place of attack, traveling to the location of the attack and finally seeing their potential victims–forces the sane mind to pass through “moral checkpoints” that force them to think twice. Carrying out the plan is both physically and psychologically difficult. Even heat-of-passion criminals are forced to deal with seeing their victims. I am sure these two factors weed out lots of would-be criminals who didn’t have the heart or the means to go through with it.

The DDoS tool does away with these barriers. Nothing forces us to think through the act before we click Start. And we remain safe from the threat of retaliation. The thing about war is that you can’t do it without exposing yourself to danger, thus discouraging you from starting it in the first place. But that is no longer the case. Scary.)

We can assume that from now on, something like this is going to happen every time a citizenry butts heads with its government. (If there was any doubt, the creator of the DoS tool made the code available on his site; the target sites can be easily modified.) It’d be silly to think that we could contain it by declaring it invalid. Still, we–the technopolitics community–need to consider the morality of this tactic, as our collective ability to spread the “Attack!” message is not inconsequential.

For comments, see the original post on Personal Democracy Forum.

In the aftermath of Thursday’s virtual White House town hall, most of us in the tech-politics arena have been pondering one question: How do we improve upon this system to create a better virtual democracy experience? The conversation usually comes back to the problem exemplified by the marijuana questions, which were far and away the most popular questions asked of the president. Some thoughts:

To the tech-politics gurus bemoaning the marijuana questions:

“The marijuana people” did not “game” the system. They didn’t “sabotage” it. They didn’t get advanced notice. There is no (public) evidence of astroturfing or systems exploitation. They played fair. “Sabotage” is shouting from the back of a room during a Senate testimony. All these people did was show up at the polls. It’s the same thing you and I do every other November: they voted. If that’s sabotage, then senior citizens are incredibly cunning saboteurs. It’s fine to look for better ways of building this system. But stop equating fervent yet fair participation with cheating. I see the marijuana questions as a huge success, in two regards.

First, people participated. Yes, marijuana was #1 and #2 in the energy category, and this was caused by disproportionate enthusiasm for Open For Questions. But instead of bemoaning the marijuana questions and figuring out ways to silence them, we should be thinking about why the other more topical questions fared so poorly by comparison. Those questions have constituencies. But those constituencies didn’t turn out. Why? I don’t know, but I’m pretty sure pot smokers aren’t the reason. I’m ashamed that our first reaction has been to blame enthusiasm when we should be celebrating it and trying to generate more. It’s fair to recommend improvements to the system that will make it more representative of public interests. But it’s not fair to blame the people for being vocal.

Second, I don’t know about you, but I’m tired of people asking how the president is going to “bring back jobs from overseas” or “why we don’t have a better health care system.” He’s gotten those questions for the last two years. He knows the answers like the back of his hand, and so do we. The entire point of Web-based interaction with the president is to see something that we otherwise never would. We have wanted this for so long, and now that the medium has finally created that unique opportunity, we’re calling it a problem. The marijuana questions were the only questions that could have taught us something new about the president’s thinking. Outcome: he laughed them off, and now, so are we.

To Macon Phillips and Bev Godwin:

Open For Questions wasn’t perfect, but I’m glad you’re experimenting. Know this: too much participation was not your problem. You want participation. Your problem was lack of participation from a broad base of the populace. That, and a dearth of intriguing questions that inspire interesting answers. For the next iteration, please do not think of ways to–ahem–weed out questions that might embarrass you. Instead, think of ways to create the unexpected. That is the only reason to try new things.

For comments, see the original post on Personal Democracy Forum.

___

What is the perfect information technology solution to coming national security threats?

There isn’t one solution to multiple threats. Rather than searching for a single solution, our national security community should adapt its IT procurement strategy to develop many solutions, each addressing a specific threat at the lowest possible cost.

The existing strategy is as follows: after being caught off guard by an unforeseen crisis–a terrorist attack, an outbreak of violence, a surprise nuclear test–we reflect on our failure and identify a single cause. Maybe we didn’t have enough information. Maybe we had too much information and couldn’t sort through it all. Or maybe we had the right information but we didn’t collaborate.

After pinpointing the cause we spend years–and tens of millions of dollars–trying to develop a handful of Perfect Software Tools to remedy the deficiency. Much of that time and money is spent on procurement bureaucracy: the first line of code is written after months of identifying requirements, issuing RFPs, waiting for bids, and awarding contracts.

This is an outdated strategy for two reasons. First, unforseen crises are rarely the fault of a single deficiency. Fixing one problem while ignoring others is the equivalent of inviting strategic surprise. (UPDATE: To clarify, solutions based on single failures will only solve identical failures; they won’t solve different scenarios. The job of intelligence is foresight, not reaction.) Second, the economics of innovation demand that creating a few tools will almost never solve our problem. After all, the vast majority of innovations fail. For every Google and Wikipedia there are hundreds of failed search engines and online communities. High-dollar attempts at the Perfect Tool puts all of our eggs into a basket that will almost certainly fail us.

If failure is so likely how do we ever build useful tools? By building more of them. And in order to do that, the price of each attempt must fall drastically. Instead of spending $10 million on one tool, spend it on a thousand. The most valuable lesson for government IT decision makers is that real innovation requires experimenting with many different options.

A much lower cost per product is not as unrealistic as it may seem. Modern software need not be expensive; in fact, it is getting cheaper and cheaper to create increasingly advanced systems. The Web has made this possible because it is a free market for innovation, defined by a few qualities:

• Only good innovations succeed. Users are the only people who decide if something is valuable, so bad products are not rewarded.
• Innovators (many of whom are individuals, not companies) are motivated by passion; after all, they had the idea in the first place. This usually means their work is better.
• Everyone with Internet access can learn how to program and can, within days, write a useful application and make it available to the whole world. No special permission is required.

Compare these qualities to government information technology:

• We buy software before our users can decide if it is valuable and user-friendly, meaning there’s less incentive for developers to make a high-quality product. It also means there’s a high risk that we’ll waste our money.
• The programmers who develop our tools are under contract, and their responsibility is simply to fulfill their contract requirements. They often have little contact with the intended users, which keeps them from understanding users’ needs and preferences.
• It’s near impossible for a new developer to enter the government contract market, leaving us a much smaller pool of software developers to work with.

That’s not to say that our systems haven’t come a long way in the last few years. We now have wikis, blogs, link sharing tools, and all the other basics associated with the “Web 2.0″ brand. But we still rely on an outdated, inefficient system for procuring our software. Our systems have recently begun looking like the Web. Now it’s time to start innovating like the Web, too. With recession-induced budget cuts on the way, it is the perfect time to justify a more cost-effective strategy. Here are three ways we can start.

Let analysts solve their own problems. Problems are best understood by those who experience them first hand. Many of the Web’s best tools were not intended to be products; rather, their creators built them simply to solve their own problems. Basecamp, the Web’s most popular project management tool, was created by a small Web development firm to help its remote staff collaborate. It proved so useful that the firm, 37Signals, quit creating Web sites and made the Basecamp suite its sole product. Based on the Web model, intelligence officers would ideally write their own software. But that’s a tall order: few officers know how to write software and few have the time to commit to construction.

The solution is to hire Web programmers and embed them in analysis cells. By working as analysts, they’ll understand our IT needs better than any outside contractor ever could. Give these developer-analysts the permission to write and deploy their own code, so that they may test various tools with their colleagues. Those colleagues would provide frequent, unfiltered feedback, a vital aspect of software development that is absent from the government procurement process.

Give independent Web developers a shot. Developer-analysts wouldn’t be the only people with good ideas for new software. Small companies and independent developers have created thousands of Web-based productivity tools that would instantly help intelligence officers do their jobs better: To-do lists, journals, calendars, Gantt chart generators, people directories, mapping tools, timeline builders, concept mappers, and more.

But right now, most small companies and individuals can’t compete for government contracts. Their products are too simple to justify the cost of the bidding process–not just for the developers, but probably for the government as well. Why spend several months acquiring something that takes only a few days to build? As a result, government networks don’t benefit from the tools that make the Web so powerful.

We need to make opportunities for outside developers to get involved. For inspiration, look to Vivek Kundra, the Chief Technology Officer of the Washington, DC government. In an October 2008 contest called Apps For Democracy he procured 40 Web applications from dozens of solo developers and small firms. And he did it in 30 days on a $50,000 budget. He avoided the standard procurement route, which would have cost over $2 million and taken more than a year. Instead, he sponsored a contest that awarded small cash prizes to the best entries. Among the best tools were a carpool coordinator, a bike route mapper, and a neighborhood data visualizer.

The DC government probably never would have thought to request these tools, let alone issue RFPs for them. The entrants–DC residents and everyday programmers–had their own good ideas. Given the chance to realize them, they did.

The national security community should do the same thing. Thousands of Americans would respond with worthwhile contributions. Intelligence officers could team up with developers to help them better understand our needs. Officers with programming experience might even submit their own applications–a digital version of the DNI’s Galileo Awards. In the end, we would have hundreds of tools at a very small cost. If the contest yielded just one useful application, the return on investment would be no less than that of the average mega-contract.

Open our eyes to Open Source Software. Even better than cheap software is free software. Many of the Web’s best software is “open source,” meaning anyone can download it at no cost. Most government networks are already running some open source products. Apache was created by volunteers and now powers over half of all Web servers, including Intelink. MediaWiki–the software that runs Wikipedia and Intellipedia–is also an open source project.

Open source software is useful because it is infinitely customizable. Anyone may modify an open source package to fit their precise needs. The government, on the other hand, too often reinvents the wheel: we pay exhorbitant prices for proprietary tools when a few modifications to existing open source products would suffice. The FBI wasted over $200 million on SAIC’s ultimately scrapped Virtual Case File, a content management system that would have done much the same thing as WordPress, the popular Weblogging software. In an attempt to fix the terrorist watch list, Lockheed Martin has spent $500 million on a database that cannot search for names. Anyone who has built a Web site with the open source MySQL database language knows what a shameful waste that is.

The Web is full of successful open source projects that would immediately prove useful to national security officers. Why aren’t they more abundant on government networks?

Many believe that open source software poses a security risk because anyone may view and contribute to the code. This transparency actually makes the code more secure: for malicious code to make its way into an application, it would have to be approved by the project managers and evade the watchful eyes of hundreds of honest contributors. Should a user have any concerns about portions of the code, he may always remove them from his own copy. Proprietary code, on the other hand, can never be modified by the user.

In the long term, open source software is not completely without cost. It takes time and money to maintain. But the initial investment of simply trying it is minimal. While custom solutions can take years to complete, open source packages literally take minutes to deploy. Instead of seeing them as inferior alternatives, they should be the first place we look to fill our software needs.

–

The defense industry used to set the standard for information technology. The military was using the Internet and e-mail decades before the general public first heard of them. Today technology transfer works in reverse. New information tools are created by and for the public; bureaucracies catch on years later.

What can we learn from this? Should we try to get our edge back? No. It’s not a bad thing that outsiders have gotten so good at software development. The only problem is our own refusal to adopt their superior innovation model, choosing instead to stick with our bureaucratic process. The Web’s lesson for us is twofold:

• Good software tools require lots of experimentation in order to find the sweet spot with users. Millions of dollars and months of planning for perfection are no replacement for simple trial and error.
• Such experimentation has to be fast and low-cost. It cannot be weighed down by a bureaucratic contracting process.

Becoming comfortable with experimentation is the best thing we can do to prepare for any threat, and here’s why: In order to be truly prepared, the available solutions must outnumber the problems. Otherwise, we’ll have sunk our resources into a handful of tools that address some threats and ignore the rest. And that is not preparation. It is gambling.

That’s gotta be a record, because government software procurement is a nightmare. For a single piece of software, it probably takes 30 days just to write the RFP–Request for Proposals, a document that explains what the government wants and how much they’ll pay for it.

Once the RFP is announced, government contractors spend the next few months submitting their bids, before the government at long last chooses a winner. It’s already been several months, and not a single line of code has been written. The winning contractor delivers the final product a year or two later. (Oh, yeah: even if the product stinks and nobody ever uses it, the contractor keeps the money–your money.)

So what government contractor is responsible for this unprecedented success in DC? None. The DC Chief Technology Officer (Vivek Kundra) simply opened its data catalog and asked the general public to have at it. One month later, the DC government has dozens of new mashups and mapping tools for city transportation, tourism, law enforcement, and public safety. The CTO estimated that the normal contracting process would have taken up to two years.

This is phenomenal, but it’s not the best part. The best part is, this whole program–called Apps for Democracy–cost a total of $50,000, which was awarded only to the best submissions. Estimated cost of doing it the normal way: $2 million-plus.

This is good news in any year. But this year, it is a blessing. A deep recession is coming, and government technology budgets will fall. Government IT executives can take the lazy way out by simply spending less money on their poor system.

Or, they can use their budget shortfall as an opportunity to create a better system. They can starve their slow-moving, wasteful systems, or they can try newly evolved, more efficient systems. Compared to a government contractor, independent Web developers are cheap–even free, sometimes.

A faster, cheaper, and more honest system will always be needed, but it will never be easier to push through than it is right now, when leaders are most desperate for cost-saving measures. If a crisis is the best time for bold ideas, then Apps for Democracy couldn’t have come at a better time.

I hope Kundra’s example will do two things: give other creative CTOs the cover and courage to get their own disruptive ideas out the door; and make all chief executives wonder why their own CTOs aren’t already doing this. Politicians will always be antsy about public campaigns like Apps for Democracy–after all, if you don’t try anything new, you don’t risk embarrassed.

But at some point, the potential payoffs outweigh that risk. I don’t know where that point lies, but a 4,000% return on investment is obviously above that point of equilibrium: DC is already preparing for their next contest.

You can track my PDF posts here, and here’s the RSS feed.