Matthew Burton

Author: matt (page 2 of 4)

Should We Let Apple Decide What We Read?

The below essay appeared in The Guardian on January 26, 2010, in advance of Apple’s public announcement of the iPad.

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.
Continue reading

A Peace Corps For Programmers: A proposal for reforming government technology innovation

In the coming weeks, O’Reilly Media will publish Open Government, a collection of new essays on how technology can make DC more transparent and efficient. Today, O’Reilly released a preview (PDF) of the book that features the first eight chapters. My chapter on improving government technology is included; its entire text is below.

—–

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.

Continue reading

The Death of BRIDGE: The US Government’s IT Failure of the Year

UPDATE: Given the events of the past day, I feel it’s worth referring back to my post from last February in which I discuss how intelligence failures are normally dealt with, and propose a more common sense solution. BRIDGE, the program I discuss below, would have provided a model for doing some of the things I recommended.

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. Continue reading

On the Weaponization of the Collaborative Web

Around this time yesterday, I, along with countless others, tried to bring down the Web sites of Iran’s information and justice ministries, and state-sponsored media outlets. The idea was to silence the pro-Ahmadenijad, anti-dissent messages coming from these outlets, and in so doing, strengthen the opposition protests in Tehran.

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:

Continue reading

Open for Questions Needs MORE Pot Smokers!

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.

An Information Age Strategy for Government Information Technology

The below is a chapter I wrote for Threats In the Age of Obama (Amazon), recently published by Nimble Books. The book is divided into two portions: one set of chapters on future threats, and another set on ideas for dealing with them. My chapter–in the latter section–focused on information technology solutions.

___

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. Continue reading

Apps For Democracy: An Idea For This Time and Place

The Washington, DC government just procured 47 Web-based tools in 30 days.

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.

Now blogging at Personal Democracy Forum

Yesterday, I started blogging for Personal Democracy Forum. I’ll have a couple of posts there per week. My first one is on the White House email backup system—which sounds totally boring at first, but is actually kind of interesting (and important, of course).

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

DC’s Apps for Democracy: Helping Coders Help the Man (with one small complaint)

Because this is timely, I reserve the right to say some presumptuous/incorrect things that I never would have said had I had time to think it over, as I usually do when I post things here.

The Washington, DC Chief Technology Officer just launched a project called Apps for Democracy, a contest to create apps with DC’s data catalog.

I love this project. DC doesn’t get much revenue to work with, so this project makes a lot of economic sense–the tools they will get out of this contest would, through the standard contracting route, cost about 40 times the $20,000 in prize money they’re giving away.

But the economics, I’m guessing, is what sold the mayor on the project. I bet the initial motivation was much different: the CTO’s office understands that the public will create better tools, and more quickly, than government contractors can. They know that the benefits of opening their data far outweigh the speculated, yet unproven, pitfalls.

Also, I can tell the CTO likes to experiment. That’s really gutsy, because an inevitable byproduct of experimentation is failure. This is why most bureaucrats hate experimentation and would prefer to coast: sure, you won’t make progress by doing things the same way, but at least you can’t screw up!

This CTO (Vivek Kundra is his name) gets it. This is exactly the kind of stuff a CTO should be doing. There are rumblings of such a position being created under a presumptive President Obama. If it happens, I hope they use Apps for Democracy as a model for this title: more technology, less chief officer. Technology is about experimentation, not red tape. A new bureaucratic position should have an eye for counteracting the increased bureaucracy it will inevitably engender. Projects that delegate power to the public are a great way to do that.

I’m excited about Apps for Democracy, but I have some reservations, which I voice below. As a segue, here are a few possibilities for app submissions:

  • Use the Speed Detector GIS data to build an iPhone app that alerts drivers to their presence (though that won’t go over well with the mayor’s budget office)
  • Use the Bicycle Lane and Bike Routes GIS data to build a Google or Yahoo! Maps mashup that creates cycling-friendly directions
  • Use the Trails, Trails NPS, and Crime Incidents data to create safe jogging routes
  • Mash any public safety data–Crime Incidents, Juvenile Arrests, etc–with a SIMILE timeline to spot trends
  • Use that same public safety data to spot correlations between incidents and the proximity of other facilities; for example, maybe juvenile arrests near banks spike in June, while arrests near current construction projects spike in December. (Whether the revelations would be valuable, we cannot say. But I’m sure sociologists and criminologists would find it interesting.)
  • Use any number of the tourism- and transportation-oriented data files to make the ultimate online day planner for washington.org.

I guess some of those ideas are decent. The problem is, I’m just a citizen. So most of my ideas are for public-facing tools. Only one or two would improve District operations. Public-facing tools are great, and the project is accepting them, but is that really the spirit of this project? I see it differently. The goal here is to help government, and I imagine Kundra is hoping people will create tools that do that. As the CTO, his job is to “develop and implement the District’s IT infrastructure” and provide “technology solutions to improve services.” What he really wants are tools that help the DC Government do its job better. This project can yield a slew of neat-o iPhone apps, but remember: projects like Apps for Democracy ultimately happen because of the possible budget savings, and if the project doesn’t deliver on that front by cutting internal IT costs, there may not be an Apps for Democracy ’09. So he has to deliver at least one great new tool for the inside.

What to build, what to build…there are surely countless opportunities for improving DC’s systems and data management. The problem is, people like me don’t have the good ideas, because we don’t experience the day-to-day frustrations of the problems we’d be fixing. We don’t understand the environment. We don’t know what’s lacking.

The most beneficial tools will probably never be thought of by the general public. People with no understanding of municipal water systems can’t (or don’t) ponder ways to revolutionize the DC Water Authority. Even more important, even if I did have the idea, I would have little incentive to build it on my own. Unless I understand the good that will come from creating that tool, I’m not going to spend time on it. Someone at the Water Authority needs to say, “We need a tool that will do X, Y, and Z, and it would help us because _____.” The _____ is the most important part. I’d love to help DC, but only if I know I’m helping. That’s why there needs to be a way for DC employees to share ideas with developers. Has this project been promoted to District employees? The project site is not targeted at them: it grabs the attention of tech firms and indy developers, but there’s no mention of the end user. Do they have a forum for voicing ideas? Whip up a way for those developers to team with District employees so we can put together something that really changes your business. What do you say, Mr. Kundra?

UPDATE 10/25 11:57 PM: After posting this, I sent an email to Apps for Democracy project manager Peter Corbett to tell him about it. He wrote back in less than an hour saying he’d already read it:

I just read that, Matt and it’s a really good post. I just sent it to Vivek. We have http://apps08.ning.com up for collaboration purposes and I suggested to Vivek that he broadcast to dc.gov that we need ideas from them about what they need built!

I often complain that although the federal government is finally abandoning clunky enterprise software for more modern Web tools, their procurement model has not changed: they still rely on the slow, expensive, clunky contracting route instead of trying the more agile, release early-release often approach that makes Web tools great in the first place. But the speed and content of Peter’s response, and his allowing me to post it here, are all signs that this is a much different DC software project. I like it.

Related: Why I Help “The Man,” and Why You Should Too

The Value of Open Source Information: Two Military Intelligence Coups by the Web

Recently, I was a panelist at the Director of National Intelligence’s Open Source Conference. The title of my panel was “Young Analysts Talk About the Value of Open Source.” The intelligence field’s definition of “open source” is different from what you might think: all it means is “information derived from public sources”: newspaper articles, television broadcasts, Web sites, etc.

To outsiders, it might seem odd to have a conference about this: doesn’t everyone understand the value of information? But when your desk has piles of secrets stolen from the enemy, it’s understandably difficult to spend time reading about things the whole world already knows. And because network security is extremely important, many intelligence analysts do not have easy access to the Web. So the Intelligence Community is slow to realize the power of publicly available information in anticipating threats.

Many of the product booths in the exhibit hall showcased products that harvest Web content en masse so that it can be delivered to analysts on a non-Web network. (This is an important point to emphasize to readers outside the intelligence world. Analysts have access to infinite stores of foreign newspapers and news broadcasts, but this content is stored privately, copied from a public medium to a private data store, with an interface that looks like a card catalog rather than the Web sites where the content was originally found.)

What to do with all of that information? Is open source intelligence somehow special or different from classified sources? The title of the panel implied that it is different; it also implied that I would have a unique take. I do.

Continue reading

Older posts Newer posts

Copyright © 2017 Matthew Burton

Theme by Anders NorenUp ↑