From Crypto-Native to Crypto-Enabled
I’m not one to make big annual predictions, but one thing that seems likely to me is that 2024 will mark the emergence of mainstream apps powered by ...

Bitcoin as Battery
One of my favorite things about crypto is that, every so often, your conception of what it is changes.Bitcoin at first was "weird internet money...

The Internet's Next Business Model: A Conversation with Cloudflare's Matthew Prince
I just released a new episode of The Slow Hunch with Matthew Prince, CEO and co-founder of Cloudflare. Since we invested in their Series C back in 2013, I've watched Matthew and his team build one of the most critical pieces of internet infrastructure—protecting and accelerating vast portions of global web traffic. Our conversation traces Matthew's journey from his early "slow hunch" that the internet was fundamentally broken and needed fixing. We start with his law school days in 2000, when ...

Subscribe to The Slow Hunch by Nick Grossman
Investing @ USV. Student of cities and the internet.

I've spent the better part of the last six years thinking about where web standards come from. Before joining USV, I was at the (now retired) urban tech incubator OpenPlans, where, among other things, we worked to further "open" technology solutions, including open data formats and web protocols. The two biggest standards we worked on were GTFS, the now ubiquitous format for transit data, including routes, schedules and real-time data for buses and trains; and Open311, an open protocol for reporting problems to cities (broken streetlights, potholes, etc) and asking questions (how do I dispose of paint cans?). Each has its own origin story, which I'll get into a little bit below. Last week, I wrote about "venture capital vs. community capital

I've spent the better part of the last six years thinking about where web standards come from. Before joining USV, I was at the (now retired) urban tech incubator OpenPlans, where, among other things, we worked to further "open" technology solutions, including open data formats and web protocols. The two biggest standards we worked on were GTFS, the now ubiquitous format for transit data, including routes, schedules and real-time data for buses and trains; and Open311, an open protocol for reporting problems to cities (broken streetlights, potholes, etc) and asking questions (how do I dispose of paint cans?). Each has its own origin story, which I'll get into a little bit below. Last week, I wrote about "venture capital vs. community capital
From Crypto-Native to Crypto-Enabled
I’m not one to make big annual predictions, but one thing that seems likely to me is that 2024 will mark the emergence of mainstream apps powered by ...

Bitcoin as Battery
One of my favorite things about crypto is that, every so often, your conception of what it is changes.Bitcoin at first was "weird internet money...

The Internet's Next Business Model: A Conversation with Cloudflare's Matthew Prince
I just released a new episode of The Slow Hunch with Matthew Prince, CEO and co-founder of Cloudflare. Since we invested in their Series C back in 2013, I've watched Matthew and his team build one of the most critical pieces of internet infrastructure—protecting and accelerating vast portions of global web traffic. Our conversation traces Matthew's journey from his early "slow hunch" that the internet was fundamentally broken and needed fixing. We start with his law school days in 2000, when ...

Word on the street is that USB-C was less of a consensus-driven standards body project and more of an apple hand off. Time will tell, but now that USB-C is the port to beat all ports in the Macbook 12, it could become the single standard for laptop and mobile/tablet ports. You can do this if you're huge (see also: Microsoft and .doc, Adobe and .pdf) The Happy Magnet Approach I mentioned the GTFS standard, which is now the primary way transit agencies publish route, schedule and real-time data. GTFS came to be because of work between Google and Portland's Tri-Met back in 2005, as their collaboration to get Portland's transit data into Google maps - so they created a lightweight standard as part of that. Then, Google used "hey, don't you want your data in Google maps?" as the happy magnet, to draw other agencies (often VERY reluctantly) into publishing their data in GTFS as well. Here's a diagram I made back in 2010 to tell this story:

This approach includes elements of the Brute Force approach -- you need to have outsized leverage / distribution to pull this off. It's also worth noting that GTFS won the day (handily) vs. a number of similar formats that were being developed by the formal consortia of transit operators. I remember talking to folks at the time who had been working on these other standards, who were pissed that Google just swept in and helped bring GTFS to market. But that's exactly the point I want to make here: a path to market is often more is more important than a perfect design. The Awesome Partner Approach Not really knowing the whole story behind Creative Commons, it seems to me that one of the huge moments for that project was their partnership with Flickr to bring CC licensed photos to market -- giving photographers the ability to tag with CC licenses, and giving users the ability to search by CC. CC was a small org, but they were able to partner with a large player to get reach and distribution. The Make-them-an-offer-they-can't-refuse Approach Blockchain hacker Matan Field recently described the two big innovations of bitcoin as 1) the ledger and 2) the incentive mechanism. The incentive mechanism is the key -- bitcoin and similar cryptoequity projects have a built-in incentive to participate. Give (compute cycles) and get (coins/tokens). While the Bitcoin whitepaper could have been "just another whitepaper" (future blog post needed on that -- aka the open standards graveyard), it had a powerful built-in incentive model that drew people in. The Bottom-up Approach At our team meeting on Monday, we got to discussing how oAuth came to be. (for those not familiar, oAuth is the standard protocol for allowing one app to perform actions for you in a different app -- e.g., allow this app to post to twitter for me, etc). According to the history on Wikipedia, oAuth started with the desire to delegate API access between Twitter and Magnolia, using OpenID, and from there a group of open web hackers took the project on. First as an informal collaboration, then as a more organized discussion group, and finally as a formal proposal and working group at IETF. From being around the folks working on this at the time, it felt like a very organic, bottom-up situation. Less of a theoretical top-down need and more of a simple practical solution to a point-to-point problem that grew into something bigger. The Pretty Pretty Please Approach (aka the Herding Cats Approach) This one is hard. Come up with a standard, and work really hard to get everyone to agree that it's a good idea and adopt it. It's not impossible to do this, but it's not easy. This is more or less the approach we took back in 2009-12 with Open311. In 2009, John Geraci from DIYcity (a civic hacking community at the time) wrote a letter to Mayor Bloomberg suggesting NYC take an open approach to its 311 system (I worked on the letter with John, as did several of my colleagues at the time). From there, Philip Ashlock from OpenPlans took the lead on turning it into a real thing -- working doggedly for 2 years with cities across the US, technology vendors large and small, and adjacent orgs like Code For America, to develop the specification and get it deployed. As of 2012, there were something like 50 cities and 10 vendors live on the standard. I would say that Open311 never had the "slingshot" or "magnet" it really needed to become huge and impactful -- it was more of a slow grind. But Phil in particular gets tons and tons of credit for making it happen. And...? In thinking about this, I also looked into the history of foundational web standards like HTTP and SMTP. Here is Tim Berners-Lee's original concept for an online hypertext system, and here is his more formal proposal to his bosses at CERN to fund initial work on the project. He asked for $50k in manpower and $30k in software licenses. Glad his bosses gave him the green light! Here is John Postel's original proposal for SMTP (the primary protocol behind email) to the IETF networking group. I honestly don't know the politics of how either of these went from whitepaper to real, and I'd love to hear that story from anyone who knows. Another good story is HTML5, which was begun by a splinter faction away from W3C (dodging the slow process there and the focus on XHTML), and then eventually merged back into the formal W3C process. One lesson One big takeaway I've had from working on all of this is that these things take time, and that if you're playing the open standards game, you need the ability to be patient (in addition to having a clever go-to-market hack). It's difficult to push a standard on a startup timeline. You'll notice that many the historical players here had full-time employers (CERN, Google, universities, etc) that gave them the stability they needed and the flexibility to devote time to this sort of project. And to reiterate the main point here -- when looking at emerging standards and protocols, we've got to focus on the question "how do we get there", and think hard about which go-to-market strategy to take. // P.S., for a funny and slightly NSFW twist on this, see this post about the book "Where Did I Come From?" which I thought of when writing this post -- my parents definitely read me that book when I was a kid and it made an impression.

Word on the street is that USB-C was less of a consensus-driven standards body project and more of an apple hand off. Time will tell, but now that USB-C is the port to beat all ports in the Macbook 12, it could become the single standard for laptop and mobile/tablet ports. You can do this if you're huge (see also: Microsoft and .doc, Adobe and .pdf) The Happy Magnet Approach I mentioned the GTFS standard, which is now the primary way transit agencies publish route, schedule and real-time data. GTFS came to be because of work between Google and Portland's Tri-Met back in 2005, as their collaboration to get Portland's transit data into Google maps - so they created a lightweight standard as part of that. Then, Google used "hey, don't you want your data in Google maps?" as the happy magnet, to draw other agencies (often VERY reluctantly) into publishing their data in GTFS as well. Here's a diagram I made back in 2010 to tell this story:

This approach includes elements of the Brute Force approach -- you need to have outsized leverage / distribution to pull this off. It's also worth noting that GTFS won the day (handily) vs. a number of similar formats that were being developed by the formal consortia of transit operators. I remember talking to folks at the time who had been working on these other standards, who were pissed that Google just swept in and helped bring GTFS to market. But that's exactly the point I want to make here: a path to market is often more is more important than a perfect design. The Awesome Partner Approach Not really knowing the whole story behind Creative Commons, it seems to me that one of the huge moments for that project was their partnership with Flickr to bring CC licensed photos to market -- giving photographers the ability to tag with CC licenses, and giving users the ability to search by CC. CC was a small org, but they were able to partner with a large player to get reach and distribution. The Make-them-an-offer-they-can't-refuse Approach Blockchain hacker Matan Field recently described the two big innovations of bitcoin as 1) the ledger and 2) the incentive mechanism. The incentive mechanism is the key -- bitcoin and similar cryptoequity projects have a built-in incentive to participate. Give (compute cycles) and get (coins/tokens). While the Bitcoin whitepaper could have been "just another whitepaper" (future blog post needed on that -- aka the open standards graveyard), it had a powerful built-in incentive model that drew people in. The Bottom-up Approach At our team meeting on Monday, we got to discussing how oAuth came to be. (for those not familiar, oAuth is the standard protocol for allowing one app to perform actions for you in a different app -- e.g., allow this app to post to twitter for me, etc). According to the history on Wikipedia, oAuth started with the desire to delegate API access between Twitter and Magnolia, using OpenID, and from there a group of open web hackers took the project on. First as an informal collaboration, then as a more organized discussion group, and finally as a formal proposal and working group at IETF. From being around the folks working on this at the time, it felt like a very organic, bottom-up situation. Less of a theoretical top-down need and more of a simple practical solution to a point-to-point problem that grew into something bigger. The Pretty Pretty Please Approach (aka the Herding Cats Approach) This one is hard. Come up with a standard, and work really hard to get everyone to agree that it's a good idea and adopt it. It's not impossible to do this, but it's not easy. This is more or less the approach we took back in 2009-12 with Open311. In 2009, John Geraci from DIYcity (a civic hacking community at the time) wrote a letter to Mayor Bloomberg suggesting NYC take an open approach to its 311 system (I worked on the letter with John, as did several of my colleagues at the time). From there, Philip Ashlock from OpenPlans took the lead on turning it into a real thing -- working doggedly for 2 years with cities across the US, technology vendors large and small, and adjacent orgs like Code For America, to develop the specification and get it deployed. As of 2012, there were something like 50 cities and 10 vendors live on the standard. I would say that Open311 never had the "slingshot" or "magnet" it really needed to become huge and impactful -- it was more of a slow grind. But Phil in particular gets tons and tons of credit for making it happen. And...? In thinking about this, I also looked into the history of foundational web standards like HTTP and SMTP. Here is Tim Berners-Lee's original concept for an online hypertext system, and here is his more formal proposal to his bosses at CERN to fund initial work on the project. He asked for $50k in manpower and $30k in software licenses. Glad his bosses gave him the green light! Here is John Postel's original proposal for SMTP (the primary protocol behind email) to the IETF networking group. I honestly don't know the politics of how either of these went from whitepaper to real, and I'd love to hear that story from anyone who knows. Another good story is HTML5, which was begun by a splinter faction away from W3C (dodging the slow process there and the focus on XHTML), and then eventually merged back into the formal W3C process. One lesson One big takeaway I've had from working on all of this is that these things take time, and that if you're playing the open standards game, you need the ability to be patient (in addition to having a clever go-to-market hack). It's difficult to push a standard on a startup timeline. You'll notice that many the historical players here had full-time employers (CERN, Google, universities, etc) that gave them the stability they needed and the flexibility to devote time to this sort of project. And to reiterate the main point here -- when looking at emerging standards and protocols, we've got to focus on the question "how do we get there", and think hard about which go-to-market strategy to take. // P.S., for a funny and slightly NSFW twist on this, see this post about the book "Where Did I Come From?" which I thought of when writing this post -- my parents definitely read me that book when I was a kid and it made an impression.
>1.2K subscribers
>1.2K subscribers
No activity yet