The Vibe: Shapeways + Soundcloud = Awesome

I usually take weekends off from blogging, but this one is just too good to pass up: Shapeways and Soundcloud have teamed up to bring out “the Vibe” an iPhone case which comes with a completely custom waveform as its back. 

I love this because it shows off the power of the platforms that Shapeways and Soundcloud have created.  It also represents a completely unexpected use case for a sound file.  And it is a completely organic, API-enabled collaboration between two of our portfolio companies. 

All of that launched at SXSW!  Makes me wish I was there after all and even has me tempted to get an iPhone.

PS Some nice coverage over at Businessweek. 

A Rational Internet Venture Valuations Bubble

There is no doubt in my mind that venture valuations have become incredibly stretched.  I have been thinking about why that is and what will come of it.

First off, here are the factors contributing to the stretching of valuations.  It starts with the genuine potential for building hugely valuable businesses, which is based on four key factors:

1. The immense possibility for scale on the Internet — global businesses with millions of customers can be created in relatively short time periods.

2. The huge operating leverage of many Internet business models, such as marketplaces, which have near zero marginal cost.

3. The potential to disrupt large markets, such as eduction and finance, with Internet based business models.

4. The winner-take-all nature of network-effects businesses in which the dominant business can be an order of magnitude more valuable than other competitors.

The fourth of these factors leads to an interesting interaction with the economics of the venture capital market to spur on valuations: If given a choice of investing in the perceived leader in a market versus one of the followers, a venture investor should be willing to pay a significant premium.  In fact, if the leader can be expected to be 10x as valuable, then even paying up by 5x will still produce a return that is 2x better than investing in the number 2 or 3 company.

So it is entirely rational given the Internet environment to see a dramatic stretching of the valuations for market leaders with network effects. It does, however, not bode well for aggregate returns for the venture capital asset class:

1. In a race to pick the winners ever earlier, valuations get stretched even for companies that have not yet proven that they really have strong network effects and that they will be the leader in their respective market.

2. These stretched early stage valuations will lead to depressed returns in a large number of companies and will also make many of these companies harder to fund.  There will be more of these companies and more capital invested in them (in aggregate) than in the winners.

This also isn’t great for entrepreneurs who happen not to be one of the market leaders.  They will have financed their businesses at too high a valuation along the way and will either face highly dilutive down rounds or in quite a few cases will find themselves with businesses that are hard to finance altogether (if they have taken their burn rates up too much).

All of this is reminiscent of other markets with strong winner-take-all effects, such as professional sports leagues or movies. The economics for a few winning teams or blockbusters are great but industry aggregates are terrible.  It is a prisoners’ dilemma type of situation where everyone is behaving individually rational but we wind up with a collectively undesirable outcome.  Investing at a significantly higher price for a perceived winner is rational for both the VC firm and the entrepreneur on any specific deal.

The situation is further compounded by the internal structure of VC firms and the overall financial market:

1. There are well-known agency problems between the GPs and LPs of venture firms.  Because of management fees, the GPs’ payout profile is relatively insensitive to entry valuations (for all outcomes that produce sufficient fund returns to raise a subsequent fund) and above that actually encourages swinging for the fences (remember that paying 5x for a winner in the example above still produces a 2x better return).

2. Most large LPs are themselves institutions (pension funds, endowments, etc) which suffer from internal agency problems which contribute to a concentration of capital among fewer venture capital funds.

3. The rates of return available on many other investments are at historic lows and/or suffer from much higher volatility, resulting in an acceleration of capital flows back in to venture capital.

Given these contributing factors and that this is a rational bubble, we can expect it to continue for quite some time until there is either an external shock (the European debt crisis might yet be that shock) or the collective returns become so bad that there is an endogenous correction.

Heyzap Releases Self-Documenting API

Heyzap’s API announcement is technically yesterday’s news, but there is so much to like here that I figured I would write about it today.

First, they announced this on their newly launched developer blog.  Etsy has had a developer blog for some time and I think those are a terrific idea. Engineering tends to be a big part of startups and yet often doesn’t have an external voice.  A developer blog is a great way to address that and to share accomplishments and techniques with the world.  That is both motivating for the team and can help grow the network of people connected to a company.

Second, the API is self-documenting.  Starting at the root of the API, you can simply point a browser at the API or run curl from the command line.  As you access the root you learn about the available categories of requests.  When you access a category you learn about endpoints and how to access them.  And so on.  At every level if you don’t make a final request you receive documentation on how to proceed. 

Third, Heyzap didn’t wait to roll out an API until they had covered every single use case. Instead, this is an early read-only version.  But it begins to expose interesting data and will let developers start to interact with Heyzap for instance at a Hackathon.  From what people will try to do with it and the kind of things that they request can guide future releases of the API.  I would encourage everyone who is uncertain about what their API might ultimately look like to dip their toe in the water in the same way.

Heyzap itself built a very cool game-play map on top of their API.  I look forward to seeing what others will build.

PS I also recommend checking out Heyzap’s awesome 404 page

Dispatch from London

Very short post as I am about to get on a plane to fly back from London to New York (and Virgin Atlantic does not yet have wifi on its flights).  Reading the papers in London and talking to people it is clear that the European debt crisis is very much on everyone’s mind while we at home seem to be enthralled with either the latest startup valuations, or Rush Limbaugh and maybe the Republican Primary. Here the discussions are about Greece and Spain and the fact that the European Central Bank (ECB) has expanded its balance sheet by several trillion dollars.  There is a distinct sense that something will give but nobody knows exactly what it will be. All in all it feels like the time before a big storm (could of course just have been the cold and damp weather!).

Tech Tuesday: HTML

Over the next three Tech Tuesdays we will cover the three essential technologies that together make up the bulk of most web sites: HTML, CSS and Javascript.  This is Step 7 of the web cycle where the web browser uses these three (which were all retrieved from one or more web servers) to construct a web page.  The easiest way to think of how these three make up a page is as follows: HTML is the content of the page, CSS is the look-and-feel of the page and Javascript is the behavior of the page (i.e. how the page acts on its own and in response to events such as mouse clicks).

HTML stands for HyperText Markup Language and it was part of Tim Berners-Lee’s original design for the World Wide Web.  As a markup language, HTML consists of a series of tags which “mark up” the content, i.e., the tags indicate what the different parts of a page are.  For instance, here is a list in html:

<ul>
    <li>First list item</li>
    <li>Second list item</li>
    <li>Third list item</li>
</ul>

The tags are the parts enclosed in the so-called “angle brackets” - the “<” and the “>”.  The “<ul>” tag starts the list (the “opening tag”) and the “</ul>” tag ends it (the “closing tag”).  Every list item starts with “<li>” and ends with “</li>”.  You can see here that generally speaking HTML consists of opening and matching closing tags.

There are tags to describe various content elements such as headings, paragraphs and lists.  There are also tags that relate directly to the HTTP protocol.  Most important of these is the hyperlink.  Here is an example:

<a href="http://www.dailylit.com">Visit Dailylit!</a>

Here you see the opening tag contain a so-called attribute with the name href.  The value of the href attribute is the URL of that the link points to.  The text which will be displayed for the link is “Visit Dailylit!”  Here you can see the whole thing in action: Visit Dailylit!

So far I have shown what are called HTML fragments — pieces of HTML that together form the contents of a page.  The overall structure of an HTML page looks roughly as follows:

<html>
    <head>
        <title>Hello World!</title>
    </head>
    <body>
        <h1>Hello World!</h1>
        <p>This is a simple HTML page.</p>
    </body>
</html>

This is a very simple page that illustrates the basic structure, including the head and body sections.  The title in the head section is what shows up as the title of the window or tab when the page is displayed in a web browser.  The body section has the actual contents of the page itself.

There are quite a few different tags to learn about, such as tags to describe forms with labeled input fields, tags for showing images, and more.  You can learn more about the available tags at W3Schools where you can try them out right in your browser.  Next Tech Tuesday we will look at how CSS can be used to change the look and feel of the content described by the HTML.

Oxford Style Debate About Facebook

Earlier today I participated in an Oxford-style debate in London of the motion “Facebook Is Not Your Friend.” I argued for the motion together with Baroness Susan Greenfield.  Taking the opposing view were Ben Hammersley and Lewis Iwu.  This was a lot of fun as the Baroness and I have very different takes on this subject.  She came at it from a neuroscience and cultural perspective with a concern over what a shift away from time spent in person to time spent online will do to how people think of themselves and others (e.g., will we become less empathetic?).

My own arguments were quite different and came in three parts: privacy, identity and control.  Below is what I had prepared in advance.  What I actually said was of course slightly different:

Let’s start with privacy. Scott McNealy famously — or depending on your view infamously — said “your privacy is dead - get over it.” And there is a sense in which he was right.  Everything we do leaves an electronic trail — increasingly that includes activities in the real world due to our constant companion, the smartphone.  And anyone who has access to our electronic trail can not only inspect it but potentially publish it to the entire world with the push of a single button.  In that sense our privacy *is* dead.  But in another sense it still exists.  There are strong human conventions around privacy expectations.  For instance, we expect a private email sent to a single recipient to be considered private.  That is we would be surprised and upset if that email was posted to the Internet.  It’s possible and it happens but there is a convention around that being a breach of privacy.  The same goes for text messages and instant messages.  Now Facebook is not your friend because it gives you a misleading sense of privacy. Something posted to your 500+ best friends and possibly their friends is hardly any more private than something you shout from the roof top. Yet Facebook with its privacy controls gives you an illusion of privacy.  Twitter — and full disclosure we are investors in Twitter — has a more binary and I believe more honest model of privacy.  You can publish to the world or you can direct message a single individual.  One is clearly public, the other clearly private.

Until fairly recently the norm for identity at web sites was a username.  And there was a rich universe of usernames out there.  Some people, myself included, chose to use their real name as their username.  On most services you can find me as albertwenger.  But many more chose some kind of fun name, sometimes referred to as a handle. Similarly, people could choose to be represented by a picture of a cat or a dog instead of a picture of themselves.  In other words, we allowed ourselves at least on occasion to be someone else online.  Pseudonymous expression was an important part of online speech just as it had been of speech and publishing in the offline world.  Facebook is not your friend because Facebook is aggressively pushing its “real” identity model as the default identity model of the Internet.  There are a rapidly growing number of services and sites that either support only Facebook login or default to it.  Facebook is also promoting its comments solutions to publishers.  The lure of Facebook virality is hard to resist, but it makes the Internet a more boring and uniform place and ultimately will have a chilling effect on expression.  In particular in combination with the uncertainty about what’s public and private people will think twice about what they do on services that are connected to their Facebook identity.

Finally let’s consider control.  The Internet was designed on a set of principles that helped create a network with no single point of control.  It is called the “Internet” because it is really a network of networks, or “small pieces loosely joined.”  That design has served all of us who use the Internet incredibly well. It has unleashed a huge wave of innovation because companies did not have to ask for permission when putting up web sites and services.  Parts of the Internet can evolve separately from each other and the connecting standards make that possible. Facebook is not your friend because it is trying to be “the one network to rule them all” by exerting control over the Internet ecosystem.  Instead of being an open connector between services, the way Internet standards are, Facebook is an interested party that controls how viral different services are and plays favorites.  For instance, it has a special deal that gives Spotify far more exposure than other services.  Put differently, unlike the Internet itself, Facebook is not a level playing field. In the short run we may not care that much.  But in the long run this control will be detrimental to innovation on the Internet.  No one player should have a dominant role or become a single point of failure for the Internet. 

I meant to post all of this before the debate but then got busy with meetings here in London.  There was a livestream of the debate and tomorrow the video archive should be available on Youtube.  Ben and Lewis were able to convince more of the undecideds but our side carried the day in absolute numbers.  One of my favorite comments from the audience was: “I find Facebook incredibly useful, but I know it is not my friend.”

Bringing Time Back to the Web (Or: The Struggle for Depth)

Evan Williams apparently recently said that there is an issue with all of us being stuck in a kind of “continuous present” on the web (ironically, I can’t find that quote right now).  I am certainly stuck in that all powerful present many days.  There is so much new output hitting the web every day that one can barely scratch the surface of it, let alone delve into the past. Google has only aggravated this problem by tilting their search algorithm more heavily towards recency.  Techmeme — one of my daily go-to sites — only aggregates the day’s output.

The power of the present is another example of a type of “filter bubble.”  And just like I have called for an “opposing views reader”, what we need to do is surface time explicitly.  I am not a fan of Facebook by any means, but timeline may turn out to be an important contribution to the future of the web.  Similarly there is something quite magical about Timehop as a way of bringing our own past back to us.  Just the other day my Timehop email reminded me that a year earlier we had picked up a dog from a shelter.

Now imagine a version of Techmeme that links today’s topics to their historical precedents using a kind of timeline view.  Or think of a search engine that adds a time dimension to the results navigation — so that instead of having to explicitly ask for older content you can just “scroll” into the past.  Thinking about this has given me a whole new appreciation for the importance of what Brewster Kahle and the team at the Internet Archive are working on.

PS The thoughts here were inspired by an interesting conversation I had yesterday with Nick Hasty from Rhizome which has another interesting archive in Artbase (thanks, Nick).

Who Is Next After Newspapers?

Yesterday I tweeted out this fascinating chart about what has happened to newspaper advertising revenues:

The chart comes from this blog post by a professor named Mark Perry.  In the comments to the post there is a brief discussion that points to the shift away in classifieds to Craigslist and other outlets as a primary reason.

I went to be shortly after tweeting that and couldn’t help but think about which industries are up next for that level of disruption.  I believe a chart showing textbook revenues might wind up looking not all that dissimilar.  I also believe that TV advertising revenues are probably going to decline meaningfully as that advertising gets switched to online video.

There are two mechanisms at work that are likely to produce similar charts for many more industries to come that are illustrated by these previous two examples.  First, a shift from offline to online and second a replacement of paid by free.  Together these form an incredible one-two punch and managers in many existing businesses would do well to print out the above chart and put it in front of them on their desks as a potent reminder of what is coming.

We Need Peer Produced Mobile App Security

First there was the Path address book tempest.  Now there is a concern about apps being able to access photos without permission.  It would be a shame if this resulted in more centralized control over apps and longer review processes.  What we need instead is some kind of peer produced approach to app security.  What I have in mind is something along the lines of what Chris Dixon did with SiteAdvisor for web sites. Some people will (voluntarily?) run software on their mobile handsets that monitors app activity, including which servers these apps communicate with.  The results from these “monitors” are aggregated to provide security rankings for applications.

This is not meant to be a substitute for a permissions model but to complement it.  I like that apps need to check with me about accessing say my location and I certainly would want the same for my address book.  But that still doesn’t tell me anything about where this data goes.  Admittedly monitoring what an app does won’t capture what happens once the data reaches servers.  For that we will need to rely on other trust models.  This is an opportunity for startups like Parse that are providing a backend for mobile apps.

Meanwhile, Mozilla is making a big push around HTML5 apps.  With a thankfully growing array of Javascript APIs to device capabilities, these apps will eventually rival native apps. Arguably because all the Javascript is “visible” it might be easier to have security for these apps based on code inspection.  But I think that’s a bit of a red herring as people are obfuscating their Javascript. So there too a peer produced monitoring approach would be tremendously helpful.

If there is an initiative like this already out there, I would love to know about it.  I think it will be critical to a healthy app ecosystem that doesn’t get choked by a few centralized market places.

Tech Tuesday: Web Browser (Part 1)

We have now reached step 6 of the web cycle and are back at the web browser.  The web browser is receiving an initial HTTP response from the web server. The first part of this response tells the web browser is whether or not the web server is delivering some useful information.  That happens via the response status, which will be 200 OK if the HTTP request is being properly fulfilled.  The second part are additional so-called response headers which provide information about the content that is contained in the response.  And the third part is the actual content.

For today, we will examine the case where the content consists of a web page in HyperText Markup Language or HTML. We will have an entire Tech Tuesday on just HTML in the future but for today we will focus on just one aspect of HTML which is critically important to understanding the web cycle: the (frequent) need for additional requests to be made to the same and/or other web servers. Leaving aside the “how” for a moment, HTML describes what is on a web page.  On my blog here the page consists mostly of text, but in the sidebar titled Shapeways, you are seeing several images of 3D printed objects.

When your web browser made its first request to this page, the HTML that came back did not also contain those images!  Instead, it contained information that told your web browser to go to a different URL from the URL of the page and request those images there.  In fact, every image that you see on a page (generally) requires a separate HTTP request to fetch the data for that image.  Each of those requests invokes the entire web cycle that we are just going through.  Now I just counted and an initial request to the frontpage of Continuations, spawned an additional 53 (!) requests to get all the pieces needed for that page.

How did I determine that?  I use Google Chrome as one of my web browsers and it has a set of developer tools built in that let you inspect what happens when a page is loaded.  To see these go to the “View” menu and select “Developer Tools” from the “Developer” sub menu (these are the Mac OS X instructions but I am assuming Chrome for Windows has a similar menu). This will give you an additional window.  Select the “Network” button, go back to your primary browser window and reload the page.  You should now see something similar to this:

This is a list of all the requests the browser is making to get the pieces necessary for this page.  For each request you can see what was requested from where and how long that request took to complete. Apple’s Safari web browser has a similar developer menu built in as do the latest versions of Firefox.

What is the take away from today?  Even before it gets around to figuring out how to display all the content that it has received, a web browser does an awful lot of work just sending out requests to receive all the various pieces of a web page.  These requests are sent more or less in parallel (as the image above shows) because if they were sent one after the other, the page would take a very long time to load. In turn each of these requests hits a web server somewhere that needs to respond.  All of that runs over the network.  We take the fact that a web page loads quickly almost for granted these days and yet fundamentally the fact that it loads at all given everything that goes on is quite remarkable.