I gave this talk at the OuiShare Rethink & Remix conference in Barcelona:

https://www.youtube.com/watch?v=K9PjbHIkmTQ&feature=emb_title

Today, hearings begin at the Massachusetts state house over how to regulate the budding ride-sharing / on-demand transportation industry (Uber, Lyft, et al). Adam Vaccaro over at Boston.com has a good summary of the various competing bills -- a pro-Uber bill that welcomes new Transportation Network Companies (TNCs) with relatively light-touch regulation, and a pro-taxi industry bill that makes it harder for TNCs to operate. As I've written about before, I think the emergence of ride sharing, on-demand, TNCs is a good thing.  It makes getting around the city easier and safer, and it provides a flexible opportunity for work.  And, as cities ponder how to regulate them, they need to think differently -- looking at the data-driven trust and safety techniques the TNCs bring to bear as a "regulatory innovation" rather than a threat to traditional law & order. I call it "regulation 2.0" - thinking about public sector regulation the same way platforms (uber, etsy, airbnb, ebay, etc) think about "trust and safety", by loosening up-front requirements for participation in exchange for data-driven accountability: moving from this:

to this:

So, looking at Massachusetts, what's the one thing missing from any of the proposals?  Data. The proposals cover important issues like insurance and passenger safety, and largely differ on how easy it is for platforms and drivers to get started.  But none of them make any mention of the data being generated by these platforms, why it matters, and what it can be used for. I recently spoke with someone in the NYC Mayor's office about their ongoing efforts to understand the impact of TNCs on the city, and to regulate appropriately.  As a refresher, NYC recently dropped their bid to regulate the supply of Uber drivers and instead opted to study the impacts of TNCs on city traffic. It became clear to me that the city is basing its regulatory decisions on very little data.  The Department of Transportation doesn't have reliable, standardized, longitudinal data, the Taxi & Limousine Commission (the taxi industry's regulator) doesn't keep usable data, the city doesn't have partnerships with other transportation data networks (for example, Google/Waze, Verizon, AT&T, etc). My argument, then, is that a primary point of negotiation between cities and TNCs (and any other web/mobile powered network that intersects with regulated aspects of the city -- food, housing, etc) should be about access to data.  For web/mobile platforms, data is a huge asset, yet for cities it's not even on the table. Of course, this has to be a trade.  No platform would be willing to share performance data without a proper incentive.  And my point is that the incentive should be fewer traditional regulations, and more freedom to operate, in exchange for data sharing. Further, data negotiated by cities in these situations should be available publicly, to enable independent analysis by third parties.  Not only do cities not have the internal capacity to analyze such data, but they also want any conclusions they draw to be verifiable and peer-reviewable.  Just like science.  So that, if and when they do decide to enforce regulations, they have a leg to stand on One saving grace is that this conversation is happening over and over again in cities across the world, so we'll see many permutations of solutions and outcomes, and hopefully some cities will start to get it right and get the best of both worlds: more competition, more experimentation.  Less regulation, more data.  Better transportation and safer, more convenient cities.

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!)