Embracing Chaos

Coincident with the launch of the iPhone 3G hardware, Apple has started
a couple of new online services: MobileMe and the iPhone App Store.  In
some ways these are natural extensions of existing product lines.  But
I believe their launch actually represents a fairly substantial
strategic shift as Apple attempts to diversify from a hardware-only company to one that runs on a mix of hardware and services. In order to make this strategy work, Apple will need to sacrifice its much coveted high hardware margins.

Diversifying from hardware

Since Jobs pulled the company
out of the doldrums, Apple has been a
manufacturer of high-end hardware.  This is a very nice place to be.
Their margins are very high.  If you compare the hardware bits that go
into a Mac to those in any PC, Apple’s prices are much higher.  PC manufacturers
squabble over low single
digit margins because their product is almost completely commoditized.
HP, Dell and IBM struggle to differentiate themselves in the market.
Meanwhile Apple can charge a hefty premium for good industrial design
and software that is slicker than windows.  iPod followed in this
tradition of high margins by setting the bar for usability in portable
media devices and following up with fantastic marketing.



Being a niche retailer of high-end products is a comfortable and stable
place to be.  However, having a single line of revenue isn’t good for a
large company, so diversifying makes a lot of sense.  Thus Apple’s current push into services.

The iTunes music store was an important pre-cursor to the current push
into services.  Even though iTunes moves a massive volume of music, if
you work through the accounting confusion, they’re not actually making
much money there.  Because the established music industry giants are
completely fucked and have no
idea what to do, they drive the margins of all big online retailers
down to a pittance.  But iTunes did something very important for Apple: it established a billing relationship with customers. Cellular operators have this
kind of ongoing billing relationship with their customers which enables
them to push high margin, low utility products like ring-tones. Similarly, people
are used to spending small quantities of money in iTunes to get music.
So iTunes is the perfect precursor for an App Store.  In this way,
Apple doesn’t even need to rely on the carrier’s billing relationship
to build a services business.  This will be very important for Apple in
coming years as carriers increasingly become just another provider of
wireless bandwidth.  In the coming decades, the value will not come
from piping bits around.  It will come from the services built on those
pipes. 

MobileMe is a very Apple service

MobileMe is a cloud-hosted email, contact and calendaring solution.
There’s nothing revolutionary about this.  Google offers all of these
services for free.  By charging for these services, Apple is implicitly
promising to provide a better solution.  Considering their vertical
integration into popular hardware, it’s not hard to imagine that they
will succeed at this.  Google will probably remain committed to supporting
open standards for working with hardware.  By using proprietary
protocols, Apple can provide a higher-quality product and support it
better on the few platforms they care about.  It’s a classic story
we’ve seen in this industry before.

MobileMe’s launch was a
disaster.  This isn’t surprising as Apple is yet to demonstrated great skill in online services.  Personally I believe they’ll figure it out, because it’s
important to their long-term objectives, and they’re a smart company, and the skills to do this well are getting easier and easier to find.
But from a marketing perspective, MobileMe is nothing new for Apple.  Because
MobileMe is a premium service for which there is a very good free
alternative, MobileMe still targets Apple’s classic market segment.
They’re still targeting people who are willing to pay extra to have
something really polished.  They can stick to their classic bag of
tricks, like the ads that make fun of people who aren’t as cool as the
mac devotees.

App Store is new: a platform play

App Store on the other hand is going to be much harder for them to pull
off.  For App Store to succeed, their primary challenge is not to
attract paying customers, but developers.  Because independent software
developers (ISVs) are the ones who are actually creating value in the
App Store.  App is just a distributor taking a cut on that.  So what
attracts developers to the App Store?  Customers do.

It’s a real chicken and egg problem.  Nobody’s going to build software
unless there are customers to buy it, and it’s hard to get customers
without cool apps.  Well right now Apple has the whole farm, but it’s a
very small farm.  There are millions of iPhones out there, representing
potential customers.  Moreover, the iPhone SDK is very rich and capable
when compared to its competitors.  Qualcomm’s BREW, Windows Mobile,
Palm OS, Blackberry and Symbian have all faltered for one reason or
several.  Google’s Android holds much promise and hope, but at this
point it’s complete vapor-ware.  So for now, Apple has almost all the
mindshare of mobile application developers.

But how long will this dominance last?  Software platforms are natural
monopolies, meaning the
economics tend to be winner-take-all.  The chicken and egg “problem”
can easily turn into a virtuous cycle, pushing a winner to the top.
Application developers are fickle and will code to whatever platform
has the best distribution.  iPhones are very popular, but they are
still only used by a small fraction of all mobile subscribers.  Until the distribution of iPhones reaches a critical mass, their dominance as a mobile application platform is very shaky.

The mobile app challenger is HTML

But the laundry list of alternatives shows that the competition is
fragmented.  What could unseat Apple?  IMHO it’s not another
application platform, open or proprietary.  It’s the web.  Every
high-end phone can display web pages, and increasingly they’re using
high-quality javascript engines that can run real web applications.
Webkit, the super-fast open-source HTML/JS engine behind Safari is
showing up in Symbian devices, Blackberries
and Windows Mobile phones.

Apple’s challenge is to make the proprieray iPhone SDK compelling to
developers.  The alternative is to build a web application that works
well on webkit, and works on every high-end phone.  They can attract
developers in two basic ways — make the native features of their SDK
more compelling, and provide a large market for distribution of the
applications.

Charging for distribution of these applications is a gimick that won’t
last long.  Soon all the interesting applications will be free, but
tied to cloud services that have their own business models independent
of the mobile client.  Premium applications will start to seem a lot
like premium ringtones pretty fast.  Still, it will help bootstrap this
market for Apple so long as there are no serious competitors.

To stay on top, iPhones need distribution quickly

One thing that ties all these points together is that Apple’s continued
success with App Store hinges on having wide distribution of iPhones.
They are currently throttling the distribution of iPhones for some reason, possibly
because of software glitches.  But the aggressive $199 pricing is
clearly aimed at attracting a new larger customer base that will help
maintain their dominance in the mobile application space.

Long term they might be happy getting by offering premium versions of
applications that are freely available on the web.  But something tells
me they’re actually trying to break open the mass market on this one.
This is Jobs’ big play.  It’ll be really interesting to see how it
works out once Android hits the streets.

Wonder what I’ve been up to at work lately?  Here’s a tiny glimpse.

Google just launched another way to access the Google Talk network.  It’s a web-based instant messaging chat client optimized for the iPhone browser.  It’s not my primary project or my secondary or tertiary, but I did write a blog post about it and made sure the whole thing got out the door today.

If you have an iPhone, try it out at www.google.com/talk.  Warning: Non-iPhone browsers will be directed away.

Although most corporate mergers fail (often due to mis-aligned incentives on the part of the deal-makers) there is a solid economic foundation for the proposed Microsoft + Yahoo! merger.  Most of their assets will work no better combined than separate.  But the merged Microhoo ad network would be significantly more valuable than the sum of two ad networks alone. 

Why bigger is better for online advertisers

The reason lies in network effects of the online search + advertising industry.  Imagine you’re an ad buyer which is to say you have a service you want consumers to find online.  Unless you’re a huge company, you have limited energy to expend buying your ads.  So rather than buying and managing separate ads from each Microsoft, Google and Yahoo, you’re likely to just deal with a single ad publisher.  The sensible ad buyer will choose the ad publisher which gives them the most value for limited effort. 

Right now the clear choice for an online advertiser is Google.  Because they have the most search traffic, they are best able to reach customers.  Combined with their adsense network, Google clearly has the largest inventory for an ad buy making them the natural choice for anybody not willing to spend a lot of energy managing their online advertising.  This logic underlies the recent acquisitions of Doubleclick, AvenueA/Razorfish/whomever, and now Yahoo!  Network effects in advertising mean that the largest network will be the most sucessful.  So the mergers will continue as far as the anti-trust regulators allow them to until a handful of bitter enemies remain.

This much might be obvious to some of my readers.  But I felt like sharing this analysis since I’ve read nothing in the common press that explains the basic economic motivation of this deal.

Wrinkles, twists

An irony of the network effect comes from the auction nature of keyword buys.  Advertisers bid for the right to get their message in front of customers.  When more advertisers are competing for the targeted eyeballs of consumers, the prices for advertising go up.  This means that prices will tend to be higher on the larger ad networks.  So bargain seekers can get more advertising for their dollar by seeking out smaller networks.  This appears to contradict the logic that bigger is better for ad networks.  But many advertisers are limited not so much by budget but by the ability to reach highly qualified customers.  If you are selling poodle tattooing services in the pacific northwest, odds are you will not hit max out your advertising budget on any of the ad networks simply because not that many people are searching for your services.

I could probably fill pages with speculation about the culture clash between Microsoft and Yahoo and other reasons why it will or won’t work.  But if you’re interested in that stuff, I’m sure you’ll have no problem finding it in the backwaters of the blogosphere.  I can’t help but drop a couple relevant ideas though.  First, from what I hear, the executive management at Microsoft is so dysfunctional right now, Yahoo will provide fertile new ground for their turf wars.  If the top bosses are adept, they will use the many iterations of re-orgs to sluff off ineffective execs to projects where their overall damage can be minimized.  Second, I think I hope Microsoft has evolved enough humility to understand that they’re better off simply shutting down Yahoo’s services than forcing everything to port over to NT servers.  Right, guys?

Disclaimer

I feel compelled to point out that the opinions expressed here are mine and mine alone.  In no way does this article reflect any official position of my employer.  This is my personal analysis of the economics behind the industry I work in.

Sorry for going dark for a little while there.  As expected, starting a new job while taking a full load of classes at school has been challenging.  Also unsurprisingly, the Google job is very engaging.  I’ll describe a bit of what it’s like on the inside and also how this affects the kinds of things I write about here.

I spent my first week in Mountain View at the Googleplex.  My entering class of "Nooglers" were subjected to inane videos and boring HR discussions.  But a couple hours into it we powered up our laptops and within 15 minutes I’d found the internal wiki and started reading project plans for every internal initiative I found interesting and a bunch that I didn’t.  I devoured the information and didn’t unplug myself until wee hours of the morning.

I’ve been spending a lot of time over the last few years analyzing the industry and thinking about what opportunities exist for creating value by solving people’s problems on the net.  Many of those I’ve captured here.  Now I look at the world differently in terms of what problems are still left to be solved because I can see that Google is in the process of solving many of the problems I’d identified.  It’s a little difficult for me to remember what I thought before knowing Google’s plans.  A myriad of half-written blog posts help remind me.  I had been planning on finishing many of them but now I don’t feel so comfortable doing so.  For example, writing about security holes inside Gmail is fun target practice from the outside, but questionably ethical from the inside even though I’d identified it before joining.  The same applies to unexploited business opportunities.

I’ve been asked a lot about the best and strangest things encountered during my week in Mountain View.  The best thing was hands-down the food.  It’s amazing.  Almost every building has their own restaurant with a theme.  My building had a tapas-inspired restaurant featuring many small plates and often fabulous seafood.  The best hamachi sushi I’ve ever had was served there on a real shiso leaf with some light sauce I can only describe through the ecstasy I felt from it.  They served black cod, which I love love love.  (I’ve got a great recipe I need to post to addgarlic.)  Pumpkin bread pudding.  Fresh figs everywhere.  Chilled beet soup.  Even simple things like a ham and cheese sandwiches on fresh bread with arugula were fabulous.  Other cafes have themes like organic hippy foods, dishes prepared with a maximum of 5 ingredients, or everything grown within 150 miles.  It’s all amazing.  As a result I found myself drawn to campus in a predictably Pavlovian manner.

One thing I’ve said for a while that this trip reinforced was the idea that you can’t pay your corporate cafeteria’s chef too much money.  You can get a chef for $50k/yr or $150k/yr.  That extra $100k/yr will do so much more for employee satisfaction than pretty much any other way to spend the money.  Sure you’ll end up spending some more on ingredients or subsidies.  (Or else the chef will leave.)  But it’s worth it.  A couple years ago Real hired a new Chef, Ariel IIRC for their cafeteria and the food got so much better I started bragging to my friends about it.  A little while later a number of things happened at about the same time — Real’s stock dropped, Ariel moved on and life at Real wasn’t as much fun any more.  I won’t try to extract the causality relationships between those events here.

The oddest thing I saw was definitely the automatic toilets.  They’ve got butt-warmers, front and back washing sprays, dryers and more things that I never figured out.  I wonder if they weigh you and keep a high-score list for largest excretion.

Now I’ve got the fire-house turned on full bore and am trying to add value for my team from a position of relative ignorance and keep up with everything going on around me while finishing up a full load of business classes.  But I wanted to take a few minutes to share what’s been going on with you my dear readers.

I caved.  I took a job with Google as a Product Manager.  I start today.  I’m down in Mountain View all week to have kool-aid forcibly injected intravenously.  Make note of this day and see if you can sense a shift in tone of my posts as time continues.  We’ll see when I start thinking and posting about Google in first person.  This change is important to you my dear readers for a couple of other reasons. 

Most significantly is around intellectual property.  Google’s IP policy for its employees can be effectively summarized as "All your base are belong to us."  It’s a fairly standard employment agreement — anything I do or think of on Google’s time or using Google’s equipment belongs to Google.  The only exception is if I do something entirely on my own that is not related to Google’s current or reasonably foreseeable future business.  I’m not a lawyer, but California and Washington laws both read about the same.  The thing with Google is that essentially nothing in technology is outside of that scope.  Designing juggling balls or running shoes might be.  This was a concern for me in considering the position.  But in the end I couldn’t resist.

I suspect this means I won’t be able to post as much about what the industry needs to be doing.  On the flip-side, hopefully I’ll be in a position to be getting the industry to do these things.  People often ask me what I’ll be working on, and I always answer honestly that I don’t know.  As a Product Manager I’ll be working on products but not writing code — this is similar to a PM role in other companies, but there are very few at Google and their relationship is much more of a peer than in some companies.  As to products, I think everybody has to work on ads as a kind of penance.  But hopefully when I get my feet on the ground I’ll be working on all the things I’ve been posting about here.

Personally this means I’m going to be extremely busy for a while as I finish up a full quarter at school and start up a new job.  I’ll also be a cross-bridge commuter heading into Kirkland most days which I’m really unexcited about.  But the opportunity to work with lots of brilliant people and have a huge impact on the world makes up for it.  I’m pretty excited!

After months of rumors about companies trying to buy Facebook, yesterday a deal was announced.  In a sense the deal is quite small because Facebook sold just a 1.6% equity stake to Microsoft.  But by paying $240 million, the deal values Facebook at about $15 billion!  What’s going on here?  This surely can’t be based on rational economics, can it?  Let’s analyze how these deals should be valued and take a few steps back through recent internet acquisition history for context. In trying to keep this post focused, I wrote a separate article about why mergers and acquisitions rarely work.

Economically, companies should be valued at the present value of their free cash flows.  That is to say, project forward all the possible ways the company might behave, and take a probability-weighted average (expectation value) of the total dividends the company would pay in each of these scenarios.  Discount these cash flows by an appropriate discount rate and you’ll get a fair market value for the company.  This is called fundamental analysis.

Now anybody who’s tried their hand at such financial calculations will know there’s a lot of judgement calls involved.  Small differences in numbers like discount rate or growth rates have huge effects on the results, and these numbers are hard to judge.  So it’s definitely possible to come up with a believable (by some) model of future cash flows that will value any currently successful company at whatever huge valuation you want.  But that doesn’t make it correct.  Is Facebook worth $300 per user?  It’s not possible for me to click on a $10 CPM ad every day for 100 years, but maybe they can add more users to grow into that?  Maybe?  It sure seems high.  I think there’s something else going on.

For context, think back to March of 2005 when Yahoo bought Flickr.  IMHO that made Google feel bad because Picassa wasn’t doing so well.  I think they saw this as a big missed opportunity to help organize the world’s photos.  I think this was big on their minds when they paid too much for YouTube.  And Google is still very far from monetizing this investment.  But they now control the dominant way that videos are communicated on the net.  This has to help them feel good about getting closer to their corporate mission of organizing the world’s information.  Since it’s not clear right now how they’re going to achieve that goal for photos.

Now consider Facebook.  Left and right, Facebook’s internal applications are surpassing total usage of th best dedicated net applications.  Their invitation app gets many times more usage than evite, and I believe their photos app is actually well beyond flickr in terms of usage too.  I don’t know where they stand for videos right now.  But it’s clear that they are a force to be reckoned with.  As I’ve written before, their application platform is potentially game-changing because it’s very attractive for information service developers and democratizes the process of product development in a novel and powerful way. 

For all these reasons, I think Facebook has the potential to dislodge Google as king of the hill.  No, Facebook isn’t going to become the dominant search engine, or even the dominant deliverer of internet advertising.  But I think Facebook could become the dominant way the humans communicate with each other using computers.  This could be the leverage they need to claim the crown of innovative thought leader on the internet.  If I were running Google, I’d be concerned about this possibility.  If I were running Microsoft, I’d be excited to get a piece of this.  Any piece.  Because even a tiny piece (like <2%) means that Google can’t take control of Facebook.  And yesterday, Microsoft got their foot in that door.  So, the game is on.  It’s gonna be fun.

I logged onto Google Calendar this evening, and it asked me if I wanted to allow Google gears to access this website.  Wow!  This is gonna be great.  I’m actually not all that excited about offline access, which is valuable but increasingly less important as time goes on.  I’m very excited about the faster UI we’ll get from not having to send packets round-trip to Mountain View to make any content changes.

I haven’t seen anything work differently yet.  But that’s really the way it should be.  The Google Reader implementation of gears where you need to explicitly tell it when you’re online vs offline isn’t an ideal experience.  And the Gears API doesn’t require apps to be written that way either — it’s just easier.

I tried unplugging from the net and nothing interesting happened.  I couldn’t update my calendar.  I couldn’t load my calendar — I was hoping maybe they’re just caching the javascript in gears which would be a nice step.  But it doesn’t appear to actually be doing much yet.

It’s just a matter of time.  I predicted first half of 2008 and I’m sticking to that.

I see a trend of how we’re approaching Tim O’Reilly’s Web 2.0 ideal in a way that he didn’t really identify.  But I think the trend is important, and growing, although still in its infancy.  The trend is towards richer web APIs
that enable people to build value on top of existing websites.  I’ll
give some history on how we got here, and talk about the current
trend-leaders that I see: Facebook and Google Maps.  I’ll also explain why I think Microsoft is in the best position to build the required enabling technology.

Original Web 1.0

Universal access to massive volumes of data.  Being able to search
through masses of data and find what you want.  Connecting people to
huge databases really well.  Key examples:

• Online telephone books
• Web search
• Huge e-commerce sites

But in all of these applications, the data set is static.  User activity will not change the data for anybody else.

Web 2.0.1: Democratizing use of the data

The users of these data make the data better.  They can collectively
organize the data.  (i.e. tags)  They can help filter good data from
junk.  (i.e. voting)  Or they can help you find the data that are most
interesting to you.  (i.e. collaborative filtering).  In other words,
you can interact with the data.

Any "Web 2.0 company" worth their salt has an API that federates out their raw data.  This enables other sites to use the data in new and novel ways.  But the primary problem with this paradigm is that anything built using these API’s is done from the ground up.  Using the gmail POP interface, it’s possible to build a better UI for gmail.  But to do so you need to first build an entire AJAX mail client — no small feat.  Better would be the ability to add features into the gmail UI itself.  But this is really the standard in web 2.0 API’s today.

Web 2.0.2: Democratizing the feature set

The next big trend will be enabling users to make more compelling ways to interact with
the data.  Users can change not just the data, but how other users see
and use the data.  Sometimes this means API’s with UI hooks.  Or other ways to enable new functionality into an existing site.  This kind of platform enables Independent Software Vendors to improve upon the UI’s that the original sites created.

Facebook is doing this by allowing ISV’s to add new communications features to their site.  Google Maps is doing this through maplets that allow developers to create new ways to interact with mapping data from within the fabulous Maps UI.  Right now these are the only two examples of web 2.0.2 platforms that I’m aware of.

Building this kind of API is very challenging.  There are several very different ways to go about doing it.  Here are a couple of ideas:

• Provide a server-server API that includes content generated from the ISV’s servers into the main experience.  Facebook style.
• Allow developers to author XML files that define new algorithms that are interpreted on the primary host’s servers.  Yahoo pipes is a service in this style, but they’re not doing anything to enhance an existing service so it doesn’t really meet my 2.0.2 criteria.
• Allow developers to author javascript plugins to run on the client machine.  Greasemonkey is essentially doing this.  This strategy has the best shot for a lot of applications in the long term, IMHO.  But it comes with some serious problems right now.

Doing this correctly would allow ISV’s to add new features to Gmail.  Think about it — if I wanted to change the way gmail messages were displayed, or how addressing happened, or whatever it was, this kind of platform could provide hooks for making gmail better in a way that a POP interface never would.  And even though a POP-style interface theoretically could do this, there would never be momentum because having a high-level base to build upon means that there are network effects from the extensions.  (Rails achieves a similar advantage over other web frameworks — just having a standard, any standard, means people will build upon that standard rather than argue over which library to use and extend none of them.)

3rd-party javascript

The big problem with this approach is security.  There is none.  You need to completely trust the ISV before you should allow their code to run in the context of your site.  The kind of editorial review required to do this today would completely kill the democratic goal of such a platform.

The world needs a security sandbox to run third-party javascript code inside.  This way primary site hosts could allow ISV’s to run their code on client machines safely.  Here are a few examples of places this kind of tool could be used.

ISV’s could…

• Add UI features to Gmail
• Create alternate ways to share and discuss images on Flickr
• Define new mathematical formulas to run client-side on a web spreadsheet
• Create new playlist selection / shuffling algorithms for Rhapsody

… and much more.  Even better, individual users (not developers) could pick which UI extensions they wanted to use.  Any site which provides such an API has democratized the feature development process in a very important way.  Not only does it provide a distributed mechanism to figure out which features are best, but it allows users to self-segment as to which features work for them.  Without such a mechanism the entire service must have the same features for everybody, which means product designers must play a political game where they’ll never make everybody happy.  Right now I think really only Facebook has solved this problem.

Building a security sandbox is an area that Microsoft could probably do best and fastest.  They are good at code API’s and layered security models,a nd they have a perfect place to do it with Silverlight and the CLR.  They’re trying to position Silverlight as a faster way to run DHTML, which is something else the world desperately needs right now.  But I just can’t imagine them doing anything this innovative or generally valuable.  Doesn’t sell more Office.  Doesn’t sell more Windows.  They don’t even really have many services that could use third party extensions, and they’ve lost touch with the ISV’s who might build such extensions too.  Google Gears could conceivably add such an extension.  There’s precedent there considering the javascript threading extensions they provide.

This will be a difficult problem to solve, I have no doubt.  But I hope somebody with the resources to leverage a solution takes it on, because I think it would really make the world a better place.

I access my gmail accounts through POP3 from my phone.  The problem with doing this is that all messages get exposed through POP, even the ones that are filtered out of the inbox.  This means that my phone which has much lower HCI bandwidth gets cluttered with all this list-mail that is less useful to me.  I’ve configured gmail to filter this stuff out to be lower priority I’m using the web interfaces, but when I’m using a POP client, this filtering is lost.  What I’d really like is the ability to configure the POP3 access with a checkbox saying I only want messages in the Inbox to be exposed out through POP3.  I thought gmail used to have this option, but I can find no record of this and have to wonder if I was perhaps imagining this.  The gmail mobile web interface is smart enough to do this — maybe that’s what I was thinking of.

Other alternatives include forwarding list-mail to another list-only account and deleting it, but that is frankly kinda lame.  Or if there was a way to create a filter that runs only on messages left in the inbox after the other rules have run, then I could forward the inbox messages to another account that I read with my phone.  But I don’t think that option is currently available either.

Gmail feels like it is slowing down to me.  Maybe my standards are going up.  Or maybe gmail’s user base has grown to the point where the servers to run it cost real money to Google, and they’ve throttled the computing resources to an "acceptable level of performance."  But it bothers me when I hit the "archive" button and I have to wait half a second for the UI to respond.  Sometimes even a couple of seconds.  Why does it take so long?  Just to get that line off my inbox screen?  The answer lies in computer science.

Gmail is written using a classic MVC pattern — Model, View, Controller.  The View reflects changes in the Model, and the Controller tells them what to do.  Clearly the View is our web page, and in this implementation, the Model is stored on Google’s servers.  What this means is that when you do something like archive a message, you’re not going to see the results until a message is sent to Google’s servers and the response comes back.  Now Google has really fast servers, but networks are slow.  By following this design pattern, Gmail is easy to code new features for and maintain relatively bug-free, but it’s never going to be all that fast.

Gmail engineers could code up optimizations for special cases.  For example, when I’m looking at my inbox and I hit archive on a message, they could detect this case, and just remove it from the page and then tell the server afterwards.  This kind of coding will quickly make the Gmail hard to maintain and result in lots of bugs.  Especially when you consider that multiple clients can connect to a single gmail account at once.  Strictly following MVC makes it easy to resolve conflicts in one place — the server.

A Proposed Solution

There is a solution though.  Google Gears can help.  The Gmail UI could be (and for all I know currently is being) re-architected to use Google Gears as the Model in the MVC pattern.  This means any operation in the UI would be committed very quickly to the SQLite database on your hard drive.  Then another thread would synchronize these changes in the background with the master model on Google’s servers.  Everything works — UI operations are reflected to the user extremely quickly.  We don’t lose all the benefits of storing all our data on the server.  And as an added bonus, we can still work on our e-mail when our computers are offline.  Yet another reason why Google Gears is important.

So when is this coming?  Synchronization and it’s evil twin, conflict resolution, are complex software tasks, so it could take a while.  But if I were placing bets, I’d guess we’ll see this in the first half of 2008.