(this is page 8 of 121)





Latest

The real Kindle Fire story

Tim Wu wrote a fantastic book on the history of communications and media where he pointed out that patterns tend to repeat themselves with every new medium, starting with an open ecosystem full of enterprising entrepreneurs leading eventually to a closing down opportunity set due to the market power of the new winners. In the book he covers the telephone, the radio and television and forecasts that the same will happen to the Internet. With today's Kindle Fire annoucenment, things certainly seem to be headed in that direction.

First of, as many will write, the new Kindle strategy is terrific. It's about the content and the price. Even their "top of the line" Fire at $200 has the chance to become the first personal mass market tablet device. At current course and speed, I could see the iPad becoming the family desktop of the tablet space— a shared machine that is bought once per household while the Fire takes the "one in every bag" position (of course I doubt Apple will stand still this time next year when Amazon has sold 1/2 to 2/3 as many Fires as iPads).

Back to Wu's book: the most significant part of yesterday's announcement to me was Silk, the browser that runs half its MIPS on Amazon's web services. Nominally the idea is that the web's architecture is not ideally suited to a low bandwidth, screen & CPU constrained device and that by pre-processing all of the requests and content on a powerful server, the experience can be sped up significantly. It's not a new idea: Blackberries worked like this along with Danger's Sidekick, Opera Mobile, and Skyfire's browser (an investment). However, I'm just not sure that the improved user experience is the end of the story.

After all, the Fire is a Wifi only device so unless they are thinking forward to some world where they go 3G (instead of LTE), it can't be bandwidth alone. Plus, the existing mobile ARM cores are plenty zippy when it comes to running web content (witness iOS). Even the Kindle Fire can be set (likely through some deep options menu no one will find to "client only" mode). And to boot, the cry of "mobile first" has publishers and app developers racing to optimize for the new relevant target of the tablet and the smartphone.

Additionally, why take the execution risk of server-side rendering? Not only does this add a variable cost that Amazon has to support for every user surfing their web on the Fire, but it also creates a dependency on a web service that has to be managed, debugged, and made compliant with all of the browser idiosyncrasies that currently live on the client.

I believe the real reason for squirting all of the web through Amazon's AWS straw comes down to control, the most important bit being ownership of the clickstream data. Plenty of people have raised the privacy issue thus far and have quoted Amazon as saying that the data will remain anonymous and aggregated is different from not captured or "incapable of being used to build profiles." At my last company I had someone from Amazon's early days (before cheap storage, Hadoop, and the big data obsession) who told me that Amazon had kept every click on every log since inception despite the fact that it used to cost a lot of money to do so. There is no doubt this is a company that understands the value of data when it comes to discerning shopping intent, the lifeblood of a low margin high volume e-commerce retailer.

If I were Best Buy or B&N, I'd be worried. All signs today point to 7-10% of e-commerce happening on mobile devices (smartphone, tablet), with some people believing the tablet may come to take 50% of that in the next 2-3 years. With the Fire Amazon has effectively extended their storefront to this new platform in a closed and proprietary way, a completely rational strategy. But with Silk, they've gone one step further, choosing a page out of Microsoft's old "embrace & extend" playbook applied to something much more relevant than the DOM or some other geeky browser standard, the currency of commerce on the web (data). Bold, and bit scary.

In a day when all the rest of the Web 1.0 companies seem like dump trucks crashing into each other in the night, who'd have thought that the humble little bookseller which just 12 years ago was jokingly known as Amazon.org (no profits) would come out on top of the next major phase of the Internet?

Comments Permalink

Why most people seem intent on taking computing back to the mainframe era with all of the intelligence at the center of the network in mega datacenters and the endpoint devices acting like fancy display terminals is beyond me. However, rather than prognosticating about the future at the architecture astronaut altitude, I'm going to just point out three interesting details that occurred to me over the course of the summer as I caught up with some geek stuff. And they all start with:

Writing a webapp is different now than it was five years ago because:

(1) ...clientside Javascript has matured to the point where it is a viable interactive application runtime. Some of this is due to the focus on speed of execution that the Google Chrome team put on the rest of the industry, but just as important has been the emergence of rich client-side frameworks that aim to bring all of the MVC goodness of Cocoa or RoR to the browser. Whether it is a kitchen sink framework like Sproutcore or the significantly more slender backbone.js (and its kissing cousin spine.js), the amount of structure that can now be put into a client-side application takes us well beyond the spaghetti code tightly bound to the DOM that was the gold standard for webapps of yesteryear. Furthermore, all of these frameworks are starting to standardize on RESTful resource-oriented protocols for updating stuff on the server which brings us to the second point...

(2) ...increasingly in the webapp layer cake, more and more of the complex logic is being handled on the client with the server being relegated to persistence and a few other relatively standard functions. Back in 2004 when Ruby on Rails burst on to the scene, a lot more magic used to get done on the server but now it feels like RoR, Django, and most of the other clones have a whole host of crud in them that has been rendered obsolete by the richer client (1) as per above. For instance, each of the frameworks has some clever way to map URLs to controller-like server methods, but why do we need this in a world where everything is REST-based? Even complex interactions can be mapped as resource transformations which of course gives us a huge advantage when we think about the prospect of dumping the middleware that is the server-side framework and talking straight to whatever post-SQL persistence store people happen to favor. JSON to Mongo or Couchbase? No problem. Of course the world isn't quite this simple yet, but one of the huge advantages of our getting there quickly would be that...

(3)... it might get us to a place where developers could depend of fairly standardized (and dumb) servers that persist resources and handle basic tasks (authentication, versioning) while letting all of the heavy lifting and value add happen in the client, be it a rich HTML5 one or a native mobile application. That we'd get to a simple set of APIs seems preposterous until of course you see how many PaaS companies have emerged in the mobile space alone over the last 6 months (Stackmob, Kinvey, Parse just to name a few). Why? Because most long-tail mobile applications have relatively meager server-side needs and in an ideal world mobile developers could just stick to worrying about the client and leave the boring server stuff to someone else. But why should it be any different for the folks developing rich web applications? Why couldn't they combine some relatively robust byte-pushing service like S3 to pump out a bunch of JS+CSS that delivers a full application without the need for a pesky middle tier of server goop?

In a sense this was the promise of Google AppEngine before Google priced it out of existence. Though in this new world, AppEngine would have looked like it was trying to be too much to too many different kinds of folks.

My bet is that this kind of dumb-but-flexible service is going to come from a company like Amazon (which has mastered delivering dumb-but-flexible services as well as charging fairly for them) though it is clear from the early docs that iCloud is meant to be that for the Apple ghetto and in the house of mirrors that is the current Google mobile strategy, something similar but distorted is soon to follow from them. It will be interesting to see how many other big players decide that they need something like this, but mostly to all of the "post PaaS" startups looking to do Heroku-for-X these days as this competitive field will likely set the number of likely exits.

As for me, I'm all for the smart edge and dumb center— it somehow feels like a better substrate for creative people to make far out stuff.

Comments Permalink

I am back

Since 2004, the last two months have been the longest break I've had from blogging. In the olden days of personal publishing this would have been a horrible admission that I took two months off from thinking. But in today's world of fortune cookie blogs, the hiatus felt more like a break from being at a cheap dentist office looking at posters with titles like "Motivation," "Teamwork," and "Ambition."

Fortune cookie blogging?

You know the type: usually a picture of a sunrise, steaming coffee mug, egg, or other suitably vacuous visual metaphor followed by a bullet list of aphorisms thinly disguised with power adjectives (epic, awesome, killer) and a personal confession on the part of the author of some realization that seems obvious to us but is Earth-shattering to him, short only in lifetime impact of the day he discovered that retweeting is easier than thinking and goes a lot further for the page views.

And to boot, because these posts are viral by nature within the veal pens they circulate in, the missives are usually sprinkled with a set of links to a whole host of other equally inane posts, some of which can be about "deep" personal matters like diet, exercise, and a desire to practice a Zen-like minimalism that requires shopping only at the Apple Store, the Moleskine online depot, and the local Prius dealer.

Combine with the fact that I've now been a VC for almost a year and a half which brings with it the guilty feeling that I ought to be writing "VC posts" and it is not surprising that it may take more than a double dose of Milk of Magnesia to cure this particular constipation.

VC posts?

As far as I can tell, these come in three varieties, two of which overwhelm the channel to the detriment of the third. To those that came to this racket from "operating" (working class) origins, they entail writing about experiences you've had with a deity-like certainty that the choices you made along there way were predestined and completely generalizable for eternity in the world of technology where the only constant is constant change. You certainly wouldn't want to write that you were making the shit up as you went along and got lucky to have a few breaks go your way— or that if you were especially lucky, you had some really bright people around you to pull your head out of the manure when you firmly planted it there.

The other variety of VC posts center on the fallacy that an interested party can give you the "inside view" of how to work "the capital raising process." In my view, these skirt the fortune cookie genre the same way vampire novels border on the bodice ripper— they get tantalizingly close to the goods without giving you the good stuff. For instance, they tend to neglect to mention that competitive dynamics in the deal process drive a lot of the speed (and nonlinearity) of the raise. Or they also neglect to mention the ugly underbelly of the VC industry— namely, that almost none of those well-coiffed, smart, charming, entrepreneur friendly, "buddies" of yours from the last three summer cruises have ever returned a dime of profit to their taskmasters (the limited partners)— and trust me, at the end of the day, we're all working for someone here.

As an aside, it'd be great for some VC to write a "down-and-dirty VC blog" where they treat these topics honestly and directly— it would be much more humanizing than the sunshine up your butt drivel out there today and would definitely separate said author from the current sea of sameness in investorland.

The third kind of VC blog is as endangered as the bald eagle but just as pleasant to find: it's sharp, well-researched, and somehow blends personal experience with portfolio learnings in a way that makes entrepreneurs bookmark it for constant reference. I am obviously biased but my partner and former board member David has what I consider to be the best of this variety of blog at For Entrepreneurs.

So if I'm back and I'm not into fortune cookies or VC blogging, what am I left to write about? I used to enjoy writing about technology so I think I'll start there, though that gets harder the further away you get from it. I'll also likely take on some of my favorite Boston entrepeneurs that others don't naturally tweet about (sorry SJ, but you're all washed up anyway), both past and present. And, in case it wasn't clear from this GI-clearing post, maybe even a little bit of irreverence— if only to clear the collective gastrointestinal tract.

Anything else I'm missing?

Comments Permalink

Despite having launched is limited release a couple of weeks ago, people still can't stop talking about Google+. Is it a Facebook killer? The jaws of life that will finally pry the social graph free? Will brands flock to it from Twitter? Will your mother use it?

It's hard to make an early call when so little of my network is on but my overall impression is that this is a real solid move forward for social software. Back in 1999 my friend Jon Udell wrote the book that forever changed my mind about how productive social software could be, "Practical Internet Groupware," a half polemic, half recipe book on how to make groups more productive. The book is out of print and quite dated now— NNTP figures prominently— but it is still worth reading; along with "The Unix Philosophy," it defined how I would look at building for the Internet for the subsequent 10 years.

Despite Jon's best efforts, one thing which the world seemed to have completely veered away from during the intervening decade was the idea that normals would understand fine-grained access control in the same way that people in corporations at least seemed to. For a long time, ACLs meant "invite a bunch of email addresses to each and every object you want to share or collaborate on" (think of all of the first generation photo sites), and it wasn't until 2004 when Flickr pioneered the "public by default" that the Internet became social. Del.icio.us, YouTube— all of the of the Web 2.0 darlings followed this path until Facebook came along and gave us "quasi-public," or share with all of my social graph. Sure, everyone would bolt on an access control dashboard (Facebook's in fact looks quite a bit like the cockpit of an Airbus A320), but no one really expected you to use it.

So it is interesting to see Google's approach in putting the "circle" front and center and working hard to make creating access control fun with silly animations that appeal to the collector nerves in our basebrain. If it works, this— and not whether Plus kills Facebook or becomes the next high school popularity contest— will likely bring social software forward quite a bit when it comes to being useful.

Comments Permalink

Bye Bye space program

The shuttle that took off yesterday morning is the last of 135 flights various shuttles have taken since the start of the program. There are all sorts of arguments that NASA and others have made for why it just doesn't make sense to keep the small fleet of shuttles in operation, and I am sure that there is some good logic but it's a huge bummer to all of the geeky kids who grew up awestruck by the whole shuttle program— from the dramatic launches with the detaching parts falling back to Earth to the reentries where this thing that had been to space would land like an oversized airliner.

The romance of the geek adventure aside, I worry that the fading of the space program is yet another sign that we're done having the government drive the kind of basic research that no company can take on. By comparison, the X-Prize feels much more like the "lean startup" version of the space race— incremental steps using known commercial technologies to put small payloads into space. Which is fine except that it is unlikely to yield the substrate that the combination of NASA and DARPA did for what led eventually to the microprocessor and the Internet.

I'm not sure what it will take to reverse this trend (fear of China as an alternative superpower doesn't strike me as realistic), but we sure will need something to kick that kind of basic research and absolutely awesome engineering back into gear.

Comments Permalink