More on walled gardens and protocols

Richard MacManus linked to my previous post on GData. One particular sentence right at the end caught my attention:

I'm not sure if this points to less of a walled garden, or paradoxically more of one because Google is defining the protocol now.

This is misleading: Yes, GData is a new protocol in some sense, but its really just sending plain XML over plain HTTP. No wacky binary transmissions that need to be reverse engineered, nothing truly proprietary. It's certainly not an old-Microsoft-style "embrace and extend" trick-- It's based on open standards and the provided libraries are open source (Apache licensed).

I think that "protocol" has become a slightly loaded term. It's really just a convention used to communicate between two endpoints. So by this definition, any API (even the Openomy API I work on) can be considered a protocol. I think the past has left negative associations with the word protocol-- hearing a company say they are creating a new protocol just naturally raises red flags of vendor lock-in and closed tools.

I'm still optimistic about GData-- I'm sure there's nothing like that to worry about here.

GData: The end of Google's walled garden

Google's recent release of the GData protocol has caused some confusion.

It's a matter of interpreting it correctly: GData is not a stand-alone application, it's just a protocol. It is a general framework for posting/editing/deleting XML data to already existing feed.

For example, check out the Google Calendar API. Here it is, in a nutshell: Google has an XML schema that lets you describe events on your calendar. Adding/editing/removing events on your Google calendar is just a matter of using the GData protocol to put/update/delete the XML representation of an event to a feed provided by Google Calendar. GData just handles all the infrastructure stuff, such as authentication, versioning, etc.

Other objects in Google-land have their own XML schema (Google calls these kinds). For example, the Message kind can be used to represent an email, a blog entry, a comment on a blog post, and a posting on a newsgroup. The Contact kind can represent a person, a location, or venue. Using the GData protocol, Google can create APIs that let you interact with each of these kinds.

Now, what does this all mean? In the past, Google has taken a lot of flak for being a walled garden: the data that users put on a Google app, is only accessible thourgh that application (Google Base is the most famous example of this). GData changes the situation completely: it provides a framework for Google to easily and consistently create APIs for all of their applications.

Put simply, GData means that the walled garden of Google's applications is coming to an end. I'm really excited to see what will come out of this.

Hash Auto-vivification

One of the more convenient (but sometimes bug-creating) features in Perl is autovivification: a variable is created just by referring to it (or, comes to life on its own). This is useful for creating composite data structures out of hashes or arrays-- for example, writing '$a{"a"}{"b"} = 3;' creates a hash of hashes called %a for you automatically.

Ruby doesn't have this "feature" by default, but like many other things in Ruby, you can work around it. Here's one neat way to autovivify hash-of-hashes, using recursion and Hash default procs (posted by Bill Kelly on ruby-talk):

HashFactory = lambda { Hash.new {|h,k| h[k] = HashFactory.call} }

irb(main):181:0> x = HashFactory.call
=> {}
irb(main):182:0> x['abc']['def']['ghi'] = 123
=> 123
irb(main):183:0> x
=> {"abc"=>{"def"=>{"ghi"=>123}}}

Awesome...

Unfair competitive advantages don't exist on the web

UPDATE: Here's another good post on this same topic over at
EarlyStageVC

When Ian and I presented about Openomy at the Techdirt Greenhouse this past March, we spoke right after Andy Kessler, an author and successful investor. He was a pretty tough act to follow-- he was a really good speaker and had some pretty interesting things to say. When discussing his invesment philosophy during his talk, he mentioned that when he is evaluating a potential investment in a business, he looks for what he calls an "unfair competitive advantage."

Yes, having an unfair advantage would be excellent, and from an investment point of view, I agree it would be ideal. However, I think its a totally unrealistic expectation, especially when it comes to investments in web applications. The vast majority websites out there are just a product of good ideas, programmer-hours, and good execution. None of these things are a source of a sustainable advantage: any innovative website will spawn many many copy-cats, some of which will be run by people just as talented and motivated as the creators of the original site. This is completely unavoidable. If you honestly believe that no other company can copy or improve on your creation, you are kidding yourself.

Coincidentally enough, the folks at Techdirt did a pretty good job at explaining why insisting on an unfair advantage is silly in a post this past weekend about patents:

[...] in a competitive market there is no such thing as a sustainable competitive advantage. It's a myth -- and a somewhat dangerous one for those who believe in it. Instead, the way to succeed isn't through sustainable competitive advantage, but through continuous innovation -- that is, through a series of fleeting competitive advantages. You don't need patents for that -- just a smart, motivated team and a market to serve.

So what does this mean for people building web applications? Should you be worried that you don't have an "unfair" competitive advantage? I really agree with Mike here: as long as you have a smart, passionate team that is capable of moving quickly enough, I think you will have a fighting chance at success.

"Whats the next big thing in Information Technology?"

One of the cool things about travelling a lot is all of the people you meet. A few weeks ago, I was at the airport waiting for my flight home and I decided to try out this new restaurant that opened up in the terminal. There was a sizable line outside of this place. The restaurant didnt want to seat a small group to a larger table, so they started combining multiple groups into one table.

A co-worker and I sat with an older gentleman on his way to visit his daughter in Florida. We started chatting, and after a while he asked us: "So, what's the next big thing in information technology?"

You would think that an IT consultant would have a semi-intelligent answer to this question, but I totally blanked: there's so much cool stuff happening that I didn't know where to begin. After a few seconds of thought, here's what I came up with: "Not too much is really brand new. Most of the cool things happening now are a result of people using existing technologies in new ways." He seemed very underwhelmed by this answer, and for good reason I think: Instead of hearing about whiz-bang cool stuff, he got an answer that seemed to imply that there was nothing worth getting excited about (which is really very far from the truth).

What would you have answered? How have you tried to explain what's going on in the world of web applications to a non-technical person?

The Great Ruby Rewrite

Its been a while since I've really liked something Joel Spolsky has written.. here's a gem from his latest entry, the Development Abstraction Layer:

These companies are harder to find because in most circumstances they keep quietly to themselves, polishing code in a garret somewhere, which nobody ever finds, and so they fade quietly into oblivion right after the Great Ruby Rewrite, their earth-changing refactoring-code code somehow unappreciated by The People.

The funniest part about this is that I constantly pester Ian with the same suggestion: We should rewrite Openomy using Ruby on Rails. Of course I'm not serious, but it the mere suggestion annoys him like no other.

I really think Rails is great, and any new web application I write will most likely be written in it. However, is the small productivity boost really worth the 4-6 months of no development on the current live site? I don't think so..

Take Kiko for example. They launched a pretty cool web-based calendar application last September. At that time, there weren't too many of these around (the techcrunch post on their launch only mentions one real competitor). A few months after their launch they decided that the site should be totally rewritten in Rails. They thought it would only take a month -- it really took them 6!

Here's what happened in the mean time: 30boxes launched, Zimbra launched, and many others did too. They went from being one of the only ajax online calendars out there to being just one player in a crowded market. Would they have been better served by just gradually refactoring the current codebase as they add new features? Probably.