We just posted this morning on the Civic Commons blog that our founding Executive Director Andrew McLaughlin is now moving on to take a totally awesome job atTumblr, and that I’ll be moving into the ED role at CC as of today.

It has been great working with Andrew since Civic Commons launched in May (and by “launched”, we mean, “launched with funding”, as we’ve been developing the idea for much longer than that). It’s been a real honor to work with him, and I’ve learned a lot about how to approach the vision, strategy and management of an organization with ambitions of high impact. Andrew has a ridiculous background, with extended stints at ICANN, Google, and the White House, and frankly, I’m proud that we were able to squeeze Civic Commons in there between the WH and now Tumblr :)

But in all seriousness, I couldn’t be more excited for Andrew’s next move — Tumblr is one of my favorite web platforms. Not only did it singlehandedly ignite my personal ability to blog, it has also helped to demonstrate that social web platforms can be mobilized for incredible civic purposes. I’m a firm believer that the future of the Civic Web is as much about making our social apps more civic as it is about making more civic apps. And it’s clear that Tumblr has the ability to lead the way here.

As for what’s next here at Civic Commons: we’ve accomplished a lot in our first seven months — from working with many government entities to open-source internal applications, to growing the Open311 project — an open web standard that facilitates citizen<->government communications, to working to open up the civic technology marketplace. Perhaps more importantly, we’ve learned a lot about what’s hard and where we think our real opportunity is, and are refocusing our efforts to best reflect that. More on that in the coming days and weeks.

So, to Andrew: thank you, and here’s to an amazing new frontier. To our team, partners and collaborators at Civic Commons, let’s get busy taking it to the next level.

The first CityCamp, in January 2010 was a memorable event for a bunch of reasons. It simultaneously marked the birth of several civic technology initiatives — the CityCamp unconference series itself, which has grown like gangbusters since then, Code for America, which has since just finished its first year and is growing like mad, and of course Civic Commons, which started as a partnership between Code for America and OpenPlans at that very CityCamp.

Despite all the delicious awesomeness that went down that cold, rainy, snowy weekend, there’s one thing that has stuck w/ me more than anything else.

As folks who’ve been to unconferences know, the traditional opening activity is to pass the mic around the room and have each person introduce themselves and say exactly three words that describe them. At this CityCamp, I remember that my words were “making” “cities” “easiertouse” (so I was cheating a bit, obv – I’m kind of hit or miss w/ the three words).

The line that has stuck with me still from this CityCamp was Phil Ashlock‘s opening 3 words. Phil said “Open” “Interoperable” “Cities”. Kind of a mouthful, and perhaps a bit abstract if you don’t sit around every day thinking about what “open” and “interoperable” mean in the context of cities, like we do.

Phil’s line stuck with me so much because the more I think about this (and now here we are, two years later), the metaphor of the “city as internet” just keeps getting stronger and stronger for me. We’ve focused on various aspects of this over the years — collaborative culture, open source development, etc. But the more I think about what really interests me, and what’s a really powerful idea, it’s this one.

Open means extensible — free to change and grow and adapt, without asking permission. Interoperable means that small pieces know how to work with one another. Taken together, you get one of the core ideas that has made the Internet such a place of innovation. When you can build on the web (or on your city) at will, and you can connect to all the other things that have been built, you can pretty much do anything.

In the Civic Technology land, we spend a lot of time building civic apps. Startups, cities, and independent developers are making all kinds of great stuff. BUT — and I think this is the big idea — what if we were to focus less on building more civic apps and more on making all apps more civic?

For a concrete example: we’ve done a lot of work in the 311 space — coordinating an open web standard that supports citizens reporting issues from wherever they are, and routing them directly to any city’s management system. And lots of people are building apps that directly support this activity. This is super great, and is without a doubt a huge step towards making cities more accessible. But imagine that instead of (or in a addition to it) using a dedicated 311 app, you could report an issue to a city from whatever app you’re using? Take a photo with Instagram of a pothole, and send it to your city right from there. That’s what we mean by interoperability.

When cities are open and interoperable, you should be able talk to your city from any device and nearly any app, just the way you can send a tweet from any device and lots of apps. That’s powerful, and that’s where I’m interested in seeing things go.

One of my favorite phenomena over the past few years — and one of the stories I like to tell most about why the internet is awesome — is something I call “Prescient Markets”. Marketplaces (or just producers in some cases) that take a large amount of the risk out of producing & selling products by only building what they know, in advance, that people will buy.

The original, and still my favorite example is Threadless. In case you don’t know it, Threadless is a t-shirt making/buying website where users upload the t-shirt designs. Then, other users vote on the designs. The highest-scored designs are then actually produced as shirts and put up for sale. “Winning” designers are given $2500 cash if their design is selected (in advance of any sales, mind you) plus $500 in Threadless gift certificates and $500 every time their design is reprinted.

With this system, Threadless drastically reduces their editorial role in deciding what to produce, based on the assumption that a shirt with many votes and a high average score is likely to sell. (of course, it’s no guarantee, as the people voting may not actually buy, or may not speak for real potential buyers, but it’s a really good head start). Then, perhaps my favorite feature of Threadless is what happens when shirts go out of stock — if you see an out of stock shirt that you like, you can sign up to order it in your size, and if enough people do that to justify a run, new shirts are printed and put up for sale.

Another site that takes this approach is Quirky, which is basically “Threadless for stuff.” Through a structured, crowdsourced product development process, product ideas are honed, and ultimately a final product idea is developed. Quirky employs a presale process that proceeds to manufacturing once a certain threshold is met.

Quirky’s process is infinitely more complicated and collaborative than Threadless’, and to be honest, I’m impressed that they’ve been able to successfully architect, describe, implement and manage their scheme. Revenue is shared with each product’s “creator”, plus a (potentially quite large) group of “influencers” who have contributed to the development of the product in certain ways. One really nice touch is that when you order a product from Quirky, the picture of the inventor and the names of all the influencers are on the outside of the box.

Another, super high-profile example of a related model is Kickstarter, which crowd-funds creative projects, using a pledge-against-a-threshold model. The most incredible story coming out of Kickstarter is the TikTok+LunaTik kits that turn an iPod nano into a watch — with a modest fundraising goal of $15,000, the creator Scott Wilson raised $942,578 in pre-sales. Last I checked he was on a plane to Beijing to scope out manufacturers.

Kickstarter is slightly different than Threadless and Quirky because there really is zero risk for the producers — they’re not committing to build anything unless they get the money up front — and I almost didn’t include it for that reason. What I think is particularly interesting Quirky and Threadless is that they are using crowdsourcing and community to de-risk a product development bet.

Naturally, I’m wondering how this kind of a process can be applied to other sectors. In particular, it’s gotten me thinking about how it can be applied to the government technology buying/building market, which we focus on with our work at Civic Commons. Government is under-performing in technology, procurement is a problem, and cities are running out of money. So something’s got to give.

Somewhere within all this mess, I suspect that there’s an opportunity for governments, vendors, startups, and civic hackers to make something good out of this idea.

Whenever you start a project (and I’m thinking about building websites and web applications), you are balancing two somewhat opposed goals: 1) get something working right away and 2) satisfy all your hopes and dreams. The first, I think, is a good instinct. The second is the real challenge — it’s your wildest hopes and dreams for a project which can ultimately stop you from just getting something working, now, that accomplishes the smallest essential essence.

Paul Graham and Eric Ries describe this as the Minimum Viable Product — I agree with that idea completely — but sometimes in practice it feels like even “MVP” ends up being bigger & more complicated than it should be. I’ve worked on projects where the idea of “getting to MVP” looms large over the team — I feel like when that starts to happen you’re actually building more into your MVP than you should be. The beautiful moment in building a product is the first time when it actually serves some basic need, and does that in a way that’s fun to use. And that moment can’t come early enough.

So, if you find yourself debating problems you don’t yet have, or arguing the nuances of the perfect, most elegant data model, maybe the thing to do is stop completely and ask yourself if the most basic essence of what you’re making has been built, and if it has, if it’s fun to use. If it’s not built yet, you should stop and build just the absolute simplest thing that works. Not for public consumption, necessarily, but for yourselves and your team. If it is built, then you should ask: is it fun to use? If it’s not fun to use when it’s at its most simple, it’s only going to get harder to make it fun to use once it’s more complex.

Simple, and fun to use.

I’m not saying I’ve successfully approached every project this way, but I try to, and will keep trying to.

This past week, I spent some time cutting a hole in the wall in between our kitchen and our family room. It’s a project we’ve been talking about for a long time, and we considered lots of different ways of doing it before we actually got down to it. We were concerned about the cost, and also about the possibility that this was a weight-bearing wall and what to do about that.

In the end, we went with a relatively simple approach: just remove the drywall, plaster and lath, but leave the structural elements as they are, resulting in a hole that connects the two rooms nicely (the effect we were going for) without having to hire a contractor or do anything crazy. What you see above is the half-finished state of the project.

It’s amazing what you can do with some basic tools — in this case, a saw-zall (aka reciprocating saw) a circular saw, and a hammer. I’m by no means a professional contractor, but I’ve got some tools and have done enough DIY projects to feel comfortable with the basics. Most of the time, I make a bunch of mistakes the first time through doing something, and do it a little bit better the next time through. (in this case this is illustrated clearly — I cut the jagged hole on the left on day one, and the nice, square hole on the right on day two). But the point is, it feels great to be able to manipulate your environment using tools. To make. To build.

Where I’m going with this is that it’s the exact same thing in the digital world. Every time I fire up a Terminal and execute some linux commands, I get the same feeling I get when I break out the circular saw. I’m not a professionally trained programmer either, but I’ve picked up a bit of it over the years, almost entirely through reading books, reading online, and building stuff. Being able to actually get your hands dirty and manipulate the digital world is a really great feeling, and it feels as fundamental to me as using IRL power tools to do a household project.

For instance, here’s the python script that powers the “latest activity” section of the civiccommons.org homepage:

You can argue that the era of the DIY handyman is winding down — cars are too complex to really maintain on your own, etc. But I’ll put forward that the era of the digital handyman is in full force and growing. Thanks to the existence of open source tools and the “view-source” nature of the web, it’s easy to peek under the hood, figure out what’s going on, and tinker to your heart’s delight. Of course, you can get yourself into all kinds of trouble doing this — the same way you can when you start cutting holes in walls — but that’s OK as you know when it’s time to call the electrician!