Discuss on Twitter is a WordPress plugin that uses Twitter as the commenting system for your blog.

I've been developing it over the past few weeks along with Fred Wilson and Kirk Love as part of the launch of AVC 3.0 which went up yesterday. It's currently live on this blog, as well as AVC and also USV.com.

The idea is pretty simple: whenever you publish a new post, the post is auto-tweeted to your account. Then, you get a "Discuss on Twitter" button on your post, which will prompt a reply to the auto-tweet, as well as a "View Discussions" button which will link to the Twitter thread.

Twitter is a natural place to discuss long-form content on the web, and moving blog commenting to Twitter can both engage people in a natural way and help expand distribution and reach.

I should pause here and note that the core WP/Twitter functionality is provided by the amazing WP to Twitter plugin created by Joe Dolson. Joe's plugin does all the heavy lifting of authenticating with twitter and teeing up the tweets. It's really configurable and nice. Thank you Joe.

This is alpha software (Version 0.3 to be precise), so we are still testing and tuning. Totally open to feedback, so please send any ideas on github or in the comments.... er, on Twitter

Enjoy!

Every month at USV we have an internal hack day, where we work on various fun tech projects.  We hack on USV.com, we build internal tools, we play with fun new hardware, try out new APIs, etc.  It's a nice change of pace, and an opportunity to get a little closer to the tech we spend most of the time talking about. One area we've spent some time on recently is building tools for the USV Network.  We have about 60 active portfolio companies, and it's Brittany's job to help them learn from each other as much as possible.  She's the human router within the portfolio, matching up skills, questions, needs, and experiences.  As part of that, she runs over 50 peer-driven summits ever year across functions (engineering, mobile, people, trust & safety, etc), where members from each company come together to talk shop. Each summit produces a long list of notes, follow-ups, questions, contact info, etc.  One persistent problem has been making that document accessible, hackable and shareable, both during the summits and afterwards.  Version 1 was a google doc later ported into a Yammer document for archiving.  We recently moved the portfolio network from Yammer to Slack, where we are now approaching 1000 members.  As part of that, we decided to see if we couldn't hack something together using the Slack API to easily share docs across this large and diverse group. Last Hack Day, we built a "login with Slack" workflow into USV.com, and created a simple CMS for group-editable documents using Firepad (an excellent open source collaborative document engine built on Firebase).  After doing that, we realized that it would be just as easy to open this up to anyone, regardless of their Slack team, and the result is Quackpad:

It's very simple: go to Quackpad.io and sign in using your Slack account.  You can create a simple group document that's immediately shareable with anyone else who is a member of that Slack team (and not to anyone else). It's particularly good for Slack teams made up of people from across organizations, who wouldn't otherwise have an easy way of sharing docs privately (vs., say, a company, where everyone is on gApps). This is alpha software!  So use at your own risk and let Brittany and me know if you run into any trouble. Big props to: Michael Lehenbauer from Firebase, the primary author of Firepad, the whole USV team and network for helping build this and test it, and Slack for having a really nice API to work with. Enjoy!  (and vote it up on Product Hunt!)

I couldn't sleep last night, and was up around 4am lurking on Twitter.  I came across an old friend, Elizabeth Green, who is an accomplished and awesome education writer -- you've probably read some of her recent NYT mag cover stories, and it turns out she has a new book out, Building a Better Teacher.  I know Elizabeth because back in 2008 at OpenPlans, we worked with her to launch GothamSchools, which eventually spun-out and became Chalkbeat. I said to myself: oh yeah, that was such a great project; I had totally forgotten about that. So awesome that it is still up and running and thriving.  And I dutifully headed over to update my Linkedin profile and add it to the section about my time at OpenPlans. During my nearly 6 years at OpenPlans, we built a lot of great things and accomplished a lot, and I'm really proud of my time there.  But it's also true that we made a ton of mistakes and invested time, money and energy in many projects that ranged from mild disappointment to total clusterfuck. Looking at my LinkedIn profile, I started to feel bad that I was only listing the projects that worked - the ones that I'm proud of.  And that's kind of lame.  The ones that didn't work were equally important -- perhaps more so, for all the hard lessons I learned through doing them and failing.  So rather than be ashamed of them (the natural and powerful response), I should try and celebrate them. So I decided to add a new section to my LinkedIn profile -- right under my work history: Self.Anti-Portfolio.  Projects that didn't work.  I started with things we did at OpenPlans, but have since added to it beyond that. Here's the list so far:

• OpenCore (2005-8) - a platform for organizing/activism. Hugely complex, too much engineering, not enough product/customer focus, trying to be a web service and an open source project at the same time and basically failing at both. (now http://coactivate.org)

• Homefry (2008) - platform for short-term apartment sharing.  Seemed like such a great idea. A few friends and I built a half-functional prototype, but didn't see it through. Maybe a billion dollar mistake. (more here).

• Community Almanac (2009) - platform for sharing stories about local places. Really beautiful, but no one used it (http://communityalmanac.org)

• OpenBlock (2010) - open source fork of everyblock.com, intended for use by traditional news organizations.  Stack was too complicated, and in retrospect it would have been smarter to simply build new, similar tools, rather than directly keep alive that codebase (https://github.com/openplans/openblock)

• Civic Commons Marketplace (2011) - a directory/marketplace of open source apps in use by government. Way overbuilt and never got traction.  Burned the whole budget on data model architecture and engineering.

• Distributed (2014) - crowd funding for tech policy projects. Worked OK, but we discontinued it after brief private pilot.

Looking through this list -- and there are certainly ones I've forgotten, and I will keep adding; trust me -- what I noticed was: in pretty much every one of these cases, the root cause was Big Design Up Front - too much engineering/building, and not enough customer development.  Too much build, not enough hustle.  Another observation is that these were mostly all slow, drawn-out, painful failures, not "fast" failures. I thought I learned these lessons way back in 2006!  That was when I first read Getting Real, which became my bible (pre-The Lean Startup) for running product teams and building an organization.  The ideas in Getting Real were the ones that helped make Streetsblog and Streetfilms such a big success. And they are what helped me understand what was going wrong with the OpenCore project, and ultimately led me to disassemble it and start what became OpenPlans Labs. But it turns out the hard lessons can lurk, no matter how much you think you've taken them to heart.  Perhaps tracking the Anti-Portfolio in public will help.

Today, we announced that USV is investing in Hailo.  I am psyched about this for a number of reasons, but primarily because it’s infrastructure that connects people to their city in new ways. What’s most fascinating is that we almost certainly don’t yet know what those ways are. I want to point out one quote from Fred’s interview in the Wall Street Journal.  He says:

“We think this is a kind of Trojan Horse to get people using a large network on their mobile phones to actually transact and get real stuff,” said Fred Wilson, managing partner at Union Square Ventures. “From there, I think lots of interesting things can happen. Alone in the taxi cab market, there’s a pretty big business to be built, and the fact that there’s potential beyond that gives us a lot of confidence.”

We talk a lot about backing into your network - in other words, starting with a thin edge of the wedge and ultimately finding a secondary purpose that may in fact be more profound than the first. For instance, we often say “twitter backed into identity” — when Twitter started out, it didn’t start by announcing itself as the de facto identity provider on the web. Instead, it became that after achieving ubiquity in public messaging. Relatedly: a few weeks ago at the election campaign tech / data postmortem event held at google, Oscar Salazar (co-founder of Uber, now founder of Citivox) had my favorite line of the day.  He said ”I hate the term ‘civic apps’.  All apps are civic.  For example, Waze has submitted more pothole reports than all of the other ‘civic apps’ combined.”  I love that. A few years ago I wrote about the idea of the Enterprise End-Run, which is related — the idea that we can cause big shifts in enterprise behavior by drawing the change out the back end, rather than pushing it through the front. I just love the idea that the direct approach is not always (or perhaps is hardly ever) the right one.  It’s so interesting to think of other areas where this is happening or could happen.

I have had a hard time finding the perfect to-do list system.

I am a light implementer of GTD -- I haven't read the whole book, but I get the basic idea -- capture; focus; do.  Stop working from the top of your inbox.  Amen. A few years ago, I started using Things for Mac, which is quite nice.  But I got frustrated at how long it took for Things to roll out over-the-air sync between desktop and mobile (it took them 2 years), and so I switched to Wunderlist.  But Wunderlist didn't quite feel as nice as Things, and I always wanted to switch back.  Finally, in 2012, Cultured Code released Things 2 which solved the sync problem.  Woohoo! Sync worked great, and they even added a really thoughtful new feature called the Daily Review.  Daily Review helps you manage your list of "today" tasks by automatically bumping them off of the "Today" list at the end of each day, and then asking you whether you wanted them to go back to the "Today" list, or go into the "Next" list (where tasks are parked for later review).  Basically, forcing you to proactively re-build your Today list at the beginning of each day.  It turns out that this very subtle feature was the difference between me engaging with my todo list on a daily basis, and getting overwhelmed by a todo list that just kept getting longer and longer every day, which ultimately just made me lose faith in the todo list system.

Anyway, on Things 2 Everything was hunky dory and I was *super* productive Then, I switched to Android.  Which has been great.  However, Things is mac / iOS only.  No support for Android (by comparison, Wunderlist is completely cross-platform / html5). So, once again, I was on the market for the perfect lightweight todo list system.  Here's the set of requirements that I was looking for:

• Nice desktop experience on Mac (either through a native app or a single-site browser via Fluid)

• Seamless syncing between desktop and mobile (for me, mac + android)

• Really quick drag & drop reordering / prioritizing (desktop & mobile)

• Create a task by email (in my case, by fwding an email thread for follow up)

• An easy way to do "Daily Review" as created by Things

Turns out it is hard to find this combination of features, packaged in a UI that feels nice (simple & quick for the most frequent tasks). I tried everything.  Any.do, Do.com, Asana, Producteev, Wunderlist. I'm sure there were more.  Nothing did everything on the list above just right. What I really wanted -- but just couldn't have -- was Things 2, but with an Android client. So, I figured maybe there was a way to hack one of the existing Android options to get what I wanted. My first stop was Do.com -- Do is pretty good, and even has an API that lets you hack on it.  The mobile client is decent (has drag & drop to reorder, which Wunderlist doesn't, sadly).  The web / desktop UI is more complex than the others, to a fault (IMHO).  But I applied for an API key and never heard back, so so much for that. In the end, I hacked Wunderlist to be more like Things -- specifically to make work for the Daily Review / Today / Next workflow.     Here's how it works:

• Use "Lists" to create buckets for Today/Next/Later/etc, including one for Daily Review.

• Create a shell script that will take all of my "Today" tasks and move them to the "Daily Review" folder.  I am thankful that, despite there not being a public API for Wunderlist, there is at least some documentation, and the underlying database schema is really straightforward (this script makes edits directly to the Wunderlist Sqlite database).

• Every morning when you're starting your day, run $ today to initiate the script. Then, work through your daily review list, moving today's tasks to the Today list and everything else elsewhere.

This is  clearly janky, and won't work for everyone (especially if you use "projects" within Things), but for me it's doing the trick so far. Here is the code on Github, with detailed instructions. Hooray for hacking!

The Civic Works team at OpenPlans just launched another sweet micro-site: cibi.me -- for NYC's forthcoming bike share program. The site is notable for a few reasons: First, it's beautiful and fun to use.  The OpenPlans team has been putting out a ton of these small, beautifully designed and really fun sites recently (see change.st, beautiful.st), including the NYC Bike Share location suggestions map that got thousands of suggestions when it launched last year.  A lot of the functionality you see here has been built into the open source Shareabouts app. Second, it's built on top of the OpenTripPlanner -- OTP is an open source, multi-modal trip routing engine that OpenPlans has been working on for a number of years now; originally built for the new TriMet system map, it's also been used in several other countries.  Cibi.me represents one of the more creative ways to use OTP -- as an API which the site talks to via JS. OTP lets you do awesome stuff like use the "bike triangle" to prioritize between safety, speed and flatness. (note that this feature was originally developed by David Emory for the Atlanta A-TRAIN mobility map) Here is Frank Hebbert's write up on cibi.me on the OpenPlans blog. I am really impressed by and proud of the work that OpenPlans has been doing lately.  They are on fire pumping out small, but beautiful, compelling and powerful apps.

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!

As of 11am this morning, buses in Brooklyn are telling the internet where they are.  And I'm proud to say that our work is behind it. For the past several months, we've been working with the MTA on this one-line pilot, to demonstrate that it's possible to achieve a workable bus tracking solution using existing hardware (in this case, farebox computers that will be rolled out citywide soon + GPS device + cell modem) and open source software (in this case, the excellent OneBusAway).  The hope is that this approach can work city-wide, and for a fraction of the cost of other approaches. There is lots of good coverage out there in the blogosphere, particularly over at Second Avenue Sagas, which did an in-depth look prior to the launch, as well as a follow up post-launch.  You can also read our official reaction to the launch on the OpenPlans blog. On a side note, in anticipation of some amount of attention related to the MTA launch, we also put up a new OpenPlans Transportation website today, showcasing our services and projects in the transportation space.  It's nice to finally see the business that we've been building for the past year take a bit more shape. I really love this photo -- it is a huge honor to have something we worked on (in this case, the screen shot of the map behind the mobile phone) featured on an honest-to-god MTA transit ad.  That is super geeky, I know, but as a lifelong New Yorker and transit rider, it's pretty cool. Now, as Jeff Maki, our project manager for the MTA project, said on his way out of the office today: time to go to bed and dream about buses moving on a map... // photo: Ben Kabak on Flickr

  I opened my talk at last week's Times Open event with this little video plugging Phone Idol.  It got a few laughs, which was the point, but unfortunately no new songs sung just yet.  Derek Gottfrid from NYT made the great suggestion that I print up some stickers and put them up in bar bathrooms.  I think that is a great idea and I'm probably going to do it. Go sing!

Thank you so much to everyone who helped us think through our re-name of TOPP Labs yesterday.  Your feedback and insights were absolutely invaluable to our process. 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.