After a long night and day of deliberations, we’ve settled on our new name. Drumroll please… (and this is obviously unnecessary since it’s in the title of the post)

Civic Works

T-shirt goes to fkh for the winning suggestion.  Thanks Frank!  Hat tip to Peter for getting close, with “Civic Code Werkz” and “Civic Alpha Werkz.”  And I already gave a t-shirt to Noel for finding a way to make “The AWESOME” work as an acronym.  I’m sure someone will find another use for that one someday.

I’m very excited about the new name, as it definitely embodies what we’re doing and why we’re doing it.  We clearly wanted to include the term “civic,” and I really like that “works” has the triple meaning of “the place where things get made,” “the things that get made” and stuff that “just works.”  It evokes the public realm and public service, and gets you excited to go out and make something.  It’s a factory for new ideas, and the foundation for a new civic infrastructure.  Civic Works.  Ahh.

Of course, it’s not without precedent: this Civic Works is an AmeriCorps program in Baltimore, and, as Phil pointed out, it’s reminiscent of GovWorks.com and the movie Startup.com.  But that’s OK.  We’re not planning to promote Civic Works as a standalone brand as we (kind of) did with TOPP Labs.  Instead, it will exist primarily as an internal division here at TOPP, and we’ll focus our branding efforts on the products and initiatives that Civic Works produces.  For that reason, we intentionally left “open” out of the title, as Civic Works will almost always appear in the context of The Open Planning Project, whereas our projects (such as OpenTripPlanner) and initiatives (such as OpenMuni) will stand on their own.

So thank you again for the fun day yesterday name-storming.  Next time I need to name something, I’ll come to you first.

For the past year or so, the group at TOPP that I manage has been known as TOPP Labs.  TOPP Labs was originally chosen not because it was the best or most compelling name, but because as we were dialing back work on the OpenCore project, we needed a name that was better than “The Team Formerly Known as OpenCore,” or “Non-geo TOPP” (since OpenGeo is TOPP’s other main software group).  Without a whole lot of thought, we settled quickly on TOPP Labs, as it was better than nothing and it generally evoked the spirit of experimentation and innovation we were hoping to embody after working for a long time on a single, large project.

Since then, TOPP Labs has come a long way.  We’ve re-imagined ourselves as an incubator for new enterprises and initiatives that make cities work better, and have taken off down several paths: information systems for public transit (under the OpenGeo Transit brand); tools to facilitate citizen engagement, such as FixCity and Community Almanac; and initiatives to help public agencies get on board with “open,” such as Open311, OpenMuni, and the NY Transit Data project.  We’ve been busy connecting with the open government, open cities, and progressive planning communities, and have been documenting our progress on our blog, The Civic Hacker.

But now, the time has come for us to choose our grown-up name.  This was spurred in large part by our new Executive Director, but I fully agree that the time is come, and that we should have a name that does a better job describing what it is that we do, and perhaps more importantly, what we can offer.  As I’ve written before, I’ve always been conflicted about the “TOPP” acronym, as it’s not self-evident what it means, and of course the same goes for TOPP Labs.

Of course, I’m not just writing this for my own good, I’m writing because I need help.  Please help me choose a new name for TOPP Labs.  Let’s make it a good one.  Thank you in advance for your thoughts here.  To help this along, here are a few things that should inform the choice of a new name:

First, what we’d like the name to evoke:

• Technology, innovation, and creativity
• A strong commitment to civic issues and the goal of making cities work better
• A serious, competent organization that can deliver quality products & services

Second, here’s what we’d like to avoid:

• Terms or phrases that could easily become cliche or dated (for example, Labs, or e, or i)
• Anything that sounds overly silly and not business-y enough (e.g., the Super Awesome Group)
• Anything that sounds overly business-y and not creative enough
• Open Abuse — there’s only so much “open” people can handle

Lastly, it should be informed by the things that we actually do, such as:

• Find opportunities for software and technology to help make cities more
  livable, communities more engaged, and government more effective.
• Develop open source software products that accomplish the above, selling our services to government agencies, foundations, and other partners.
• Cultivate communities of open source developers and other civic technologists.
• Help liberate data for the public good.

So far, the strongest contenders for names have been something like the Civic ____ Group, where the blank is “tech,” “dev,”  “data,” or something similar.  I’m not opposed to those approaches, but I still haven’t fallen in love-at-first-sight with a name, which I’m hoping is still in the cards.

Other names I’ve noticed lately that I like are the Office of New Urban Mechanics, which is Boston’s new office for civic technology innovation, led by their innovation director, Nigel Jacobs.  Also, I dig John Tolva‘s title at IBM of Director of Citizenship and Technology.  We could go the city-analog route and name ourselves the Department of Public Networks or the Department of Civic Hacking (I could be Commissioner), but that’s almost certainly too cheeky.

So, that’s where I’m at.  The clock is ticking, as I need to make a decision by the end of the day tomorrow, Friday 2/19.

What do you think, intertubes?

Here’s how these events typically go:

• Day 0 (evening before conf begins): maybe some late drinks with attendees as they arrive, or just heading straight to bed after travel.
• Day 1: Conference begins in the AM — introductions and big kickoff. Woohoo! Everyone is so psyched!  Evening socializing (very important).
• Day 2: Morning attendance shows that some people have split (sometimes for good reason, sometimes to get a breather or explore a city on their company’s dime) — participation is good but waning.  More evening socializing.
• Day 3: Lame-o stragglers pick up the pieces.  Poo!

The ideal conference would keep everyone there and fully engaged for the whole time, right?

So, what to do about it?  Some suggestions I’ve heard: only accept RSVPs if people commit to all days (not realistic); schedule some awesome speaker for the morning of day 2 or 3, to draw people along (not a bad idea); limit conferences to just one day (sometimes tough to justify travel).

But this morning, I may have come across the perfect format.  Talking to John Barstow from Orton Family Foundation (about our joint project, the Community Almanac), he described how they organized their recent staff retreat:

• Day 1: Conference starts in the afternoon, to allow for morning travel.  Introductions and orientation. Excitement!  Evening socializing.
• Day 2: The real meat of the conference — all day activities and good stuff.  More evening socializing.
• Day 3: Casual breakfast and wrap-up.  Time to decompress, process what went down, schedule any ad-hoc follow-up, then plenty of time to relax and travel home.

I gotta say, I really love this format — there’s still enough time to get real work done, and there’s no lame aftermath moment.  I think I’ll be scheduling my next event this way.

I had a great crowdsourcing experience yesterday.

Here at TOPP Labs, we’re doing a 6-month check-in on our annual employee reviews.  What that means for me is a 30-minute interview with each of the folks on my team (about 20 in total), where we look back on the past six months to see how we’re doing re: professional goals outlined in the annual reviews.  So, today and Monday, I’ll be having 20 30-minute meetings, each followed by 15-minutes of write-up time by me.  That’s kind of a lot to schedule.

Here’s how it went down:

1) First, I cleared my schedule for today and Monday.

2) “Hmm, I guess I need to ping each person to see when they can meet up.  Ugh.  Time to procrastinate.”

3) “Since I’m out of the office today, it will be super annoying to email every single person from my phone.  I’ll just write one email to the team list and have each person email me back times that work for them.  Nice.  Offloading the work.”

4) “Wait!  Even better, I’ll just ask everyone to add their own appointments to the team Google Calendar.  Now we’re talking.”

So in the end, I just had everyone schedule their own meetings on a first come, first served basis.  Kind of empowering to just let other people schedule two whole days for me.  Plus, the communication overhead went from a lot to zero.  Yay for crowdsourcing.

• Massive funding from a visionary with a dream (in OSAF’s case, Mitch Kapor, in TOPP’s, Mark Gorton), where that dream may not always be perfectly articulated;
• Rapid staffing around an open source project attempting to satisfy that dream (OSAF’s Chandler to TOPP’s OpenCore /  OpenPlans CoActivate);
• Due to both of the above, a propensity to expand scope and broaden the potential market(s).

Since Dreaming in Code (the book chronicling the story of Chandler and OSAF) was published in 2007, Kapor has stepped away from the project and pulled his funding.  Through 2008, OSAF operated under his funding, but with a scaled down staff (10 down from ~25).  Long story short, the project failed to get enough traction and was just too expensive. There has been lots of commentary about why this happened, so I’m not really attempting to describe anything new here.

For my own understanding, though, I want to jot down the takeways that seem most relevant to my work at TOPP.  Here’s what it seems that OSAF couldn’t do, and what I’m hoping to do at TOPP Labs:

Choose one market to start with, and satisfy it fully. In Crossing the Chasm, Geoffrey Moore describes a (high tech) market as the following:

• a set of actual or potential customers
• for a given set of products or services
• who have a common set of needs or wants, and
• who reference each other when making a buying decision

According to Moore, it’s the last one that tends to hang people up — it’s not a market unless the members reference each other.  In other words, you need to focus.  In his “beachhead” (aka D-Day) strategy, he advises putting your full effort into your initial market segment, generalization be damned, and satisfying other users with what’s left over.

If there aren’t any real constraints, create some. If embrace change was the mantra of the XP movement, and embrace constraints is the mantra for web 2.0 startups, then perhaps introduce constraints to create change should be the mantra for over-funded tech non-profits.  Some constraints that are particularly relevant in this case are:  target market (see above), team size, project scope and timelines, and if all else fails, funding.  Granted, it is difficult (but not impossible, IMO) to introduce other constraints when funding is plentiful and reliable.

Don’t get too academic, OR, let the market drive your decisionmaking. This is perhaps just an extension of “constraints”, above, but I think it’s worth mentioning separately.  Looking at the way Things (team of 2 devs) and OmniFocus (experienced sofware entrepreneurs) ate Chandler’s lunch, it’s clear that there was a failure in the product development process.  While the Chandler team was debating database infrastructures and making endless product spec notes in their wiki, Things brought a simple, usable product to 1.0 in just over a year.  They didn’t have the luxury of lengthy debates; they needed to get something out there, get people using it, and get feedback.  Since their 1.0 release in January 2009, they’ve steadily released relevant updates based on real feedback.

Can you be market-based and constrained in an open source environment?  I think so; it just required leadership and understanding of these factors.   It could be argued that Chandler wasn’t able to implement these kinds of changes because of its open source nature and collaborative process, but I believe that it’s possible (and this has been clearly demonstrated) to maintain market focus and constraints in an open source project.

So, now that we’ve got that straightened out, it should be smooth sailing, right?