Mark Cuban’s Simple Plan to Unseat Google Won’t Work

Mark Cuban has a plan.  He wonders what it would cost to deny Google access to the best search results.  What if you pay the top 5 results for the 25K most common searches NOT to be accessible by Google?  What if you paid the top 1000 sites $500K apiece not to be on Google?  It’s only $1B, which is doable for the likes of a Yahoo/Microsoft.

Here’s my problem with this.  Aren’t some of those most popular sites so popular that $500K means nothing to them?  Is it worth $500K to the world’s Global 2000 companies, for example, not to be seen in Google searches?  No, of course not.  What about the 1000 most important trendy and best selling brands?  I can’t see that $500K being attractive enough.  Would Nike or Apple stay off Google for $500K?  Would George Clooney, Madonna, or Britney Spears accept $500K to go dark on Google?  Maybe, but I’d think you need to go much further down the celebrity food chain before they’d opt out for that money.

People say that Google is the Internet’s front door.  What is it worth to your business to force people to go to the back door instead of the front door they’re used to?  How do you get enough businesses to switch to the back door when there is no history to show them it will be okay?

BTW, lest we forget, Google can monetize traffic better than anyone else to date.  Translation?  They can afford to pay these site owners more than Yahoo/Microsoft or whomever else Cuban has in mind to do this deal.

Google has the luxury of forcing all the risk onto the would be implementors of this plan, and then jumping in at the last minute to take it away from them if the plan works.

I am reminded of conditions in the oil industry during my youth in Texas.  There is a ton of oil in Texas to this day.  But for a time, it was shut down and manipulated until the oil patch practically turned into a ghost town.  How?  Well, a good Texas oil well produces about 100 barrels a day.  To get that out of one, you’ve got to pay to drill it, the well may be fairly deep, you have to pay for a pump on top, and you probably pay for a fair amount of “reservoir engineering” to help the oil to flow freely.  In Saudi Arabia, by contrast, an average well is shallow and flows perhaps 1000 barrels a day.  No pumps needed, just a valve on top.

What do you do if you become annoyed at competition and you are the Saudis?  You just open the valves, drop the oil prices, and wait until rigs have all rusted and the oil operators have gone out of business.  Then you crank the prices back up again.  What’s it today?  Well over $100 a barrel.  The oil business is back to gangbusters in Texas, and they’re even drilling new wells like crazy.  Not sure this time if it’ll work to crank open the valves.  There’s a lot more demand today than there was then.

Related Articles

Raganwald gives us a vintage 1977 speech by Carter on the energy shortage posted just as I finished this post.  This would be the point just before those valves were opened and the oil industry in Texas shut down.  Today there is not so much talk of a shortage (we should’ve run out by Carter’s estimation and usage is far in excess of what was predicted then).  Rather it is an issue of too much consumption leading to Global Warming. 

Of course then there are the various scuffles over sites that don’t want Google to have access to various aspects for various reasons.  I agree with Om Malik, this one is hilarious.

Is Microsoft Playing Possum for Yahoo? It Could Be Much Worse!

The prevailing wisdom is that Yahoo’s stock hasn’t totally cratered because Microsoft is simply being coy, and will inevitably be back after shareholders have made Yahoo management a little more pliable.

Personally, I’m not in that camp.  I think Yahoo fought so hard that Microsoft now views them as incompatible.  So what’s next in the Microsoft-Yahoo-Google love triangle?

Mike Arrington thinks Microsoft is just playing possum.  He writes recently of Gates’ apparent about face on strategy where he is no saying there’ll be no major acquisitions.  First, I would take that to mean they’re not looking at any at the moment.  But second, it made me think what that means for the Microsoft-Yahoo relationship if its true.  If Microsoft is determined to follow a go-it-alone strategy, how will they grow their search and advertising businesses?  It’s a safe bet they’re not suddenly going to hobble Google.  No, Microsoft has their own version of the scorched earth strategy. 

My bet is that it could be much worse for Yahoo than the investment community’s theory they’re just waiting to acquire them later.  The danger scenario for Yahoo is that Microsoft has decided the best approach is to spend up to the 40-odd billion bid taking all the market share they want away from Yahoo.

Why not?  Clearly Yahoo is in a severely weakened state.  Culturally, this is exactly what Microsoft has always done well.  Focusing all their energy on crushing the life out of a competitor is familiar ground.  And who wouldn’t want to view Yahoo as that competitior rather than try it against Google?

Even worse is that Google might actually decide they need to pursue a similar course.  Rather than let Microsoft have the share, they may feel they need to take it.

Tough position for Yahoo to be in, caught between those two giants.

Related Articles

No sooner did I post this did I read that Microsoft has now approached Facebook to see if they’re interested.  As I say above, Microsoft is done with Yahoo.  They are very black and white about who is an enemy and who is a friend.  Once you’re an enemy, they stop at nothing to crush you.  This is how it starts.

Sun Sees Amazon Changes the Game Even for Hardware Vendors

The announcement that Sun has partnered with Amazon to make Open Solaris available on Amazon Web Services is fascinating.  It’s free, so Sun sees no revenue from it.  One wonders if Amazon has charged them for the inconvenience, so it may carry a cost.  In fact somebody somewhere paid a cost to at least cover the testing and development of whatever provisioning is required to get it started.  So why do it?

At the moment, Amazon is running away with the cloud computing show.  Last I heard there are over three hundred thousand developer accounts there.  It’s a thriving ecosystem, and if Amazon sold no more new customers, one has to suspect that just the growth centered around those existing customers would be significant.

Suddenly, this is a platform that matters for everyone that is trying to establish their own platform.  If you want your OS (Open Solaris) to have a chance, you’d better look into Amazon Web Services.  There is no Microsoft equivalent yet, so that’s a problem.  As I’ve said, Ballmer would’ve done better to buy Amazon than Yahoo, so perhaps now he’ll give that a try.  If you want your database or application server (hello Larry Ellison) to thrive, you’d better look into Amazon Web Services.  If you want your language (hello Python, Ruby is already there with Heroku) to be ubiquitious, you’d better look into Amazon Web Services.

In fact, as if to underscore this realization, the Amazon partnership is just one aspect of Sun’s official launch of Open Solaris.  But, it is a critical one.  It will be interesting to see how well it does, and whether there are aspects of the Cloud Computing world’s needs that give it any special advantages.  I’ve heard of a few things, but it hasn’t really sounded compellling so far (see Jason Perlow for more).  There’s an awful lot of momentum behind Linux already.

The availability of Amazon Machine Images does another thing.  These are freeze dried snapshots of a particular collection of software installed on a machine.  This makes them easy to propogate.  The best practice combination of various pieces of software can be combined, converted to an image, and made available for broad consumption.  This lowers operating costs and helps ensure that the “good” combinations are more prevalent in this ecosystem.

Sun’s announcement is a fasciniating indicator of just how important Amazon Web Services has become.  Look for more indicators as we go forward.

Content Quality Matters (Enterprise 2.0 Take Note!)

No sooner did I pen Immediate Gratification Matters than I read Jason Menayan’s GigaOm post on 7 Things HubPages Did to Beat Squidoo.

HubPages and Squidoo are sites where people can write short articles about topics they care about.  Squidoo was founded by Seth Godin, a famous marketer whose blog I follow religiously.  Despite rapid initial growth, HubPages was languishing a year later, and trailed far behind Squidoo in terms of traffic as well as revenue generated for the company and its authors.

So what did HubPages do to beat Squidoo?  They list 7 things:

1. Remove all adjult content:  At the time they did it, adult content was 1/3 of all traffic.  Clearly they had to choose to get rid of one audience in order to encourage others to step up.  Would you company give up 1/3 of its sales for the promise of much larger sales later?  Something similar keeps a lot of companies from going SaaS.
2. Disallow spam:  No aggressively promotional articles were permited, and links to sites being promoted had to be toned down.  You couldn’t just publish your ads as pages.
3. Purely personal articles (like blogs) were eliminated:  The feeling was they were less likely to be useful to readers or to attract search engine traffic.
4. Copied content was penalized:  Ever come across content that is just a blatant republication of some other content?  Sometimes there is an issue of rights to use the content, but even if there is a right to republish it was felt that original content was more valuable.  Hence article scores were penalized though the article itself was not removed.
5. Articles Linking to Questionable Sites Were Flagged:  If they could see that a site might potentially phish, display obnoxious popups, or redirect to a different site immediately, the site is marked as such.  I just noticed Google doing a bit of this too, and appreciate it.  It’s never been a pleasant surprise to land on one of these obnoxious sites after clicking on an innocuous-looking search result.
6. Added a discussion forum:  This encourages real community and conversation, which was evidently lacking.  With a forum, users can help each other out, share advice, and socialize beyond simply publishing articles.
7. Up front payments for very high-quality articles:  Great articles attract significant traffic and create success stories that are a good example for others to emulate.  I’m not sure how those success stories are propogated, but I would make the propogation in some way very easy to make this more viral.

These are all ways of increasing the quality fo content and incenting people to build a quality-focused community around the content.  There is a lot to be learned from this for would be purveyors of content.  What is your strategy to increase your content quality?

Somehow I find this message to be strangely ironic.  As I mention, I follow Seth Godin religiously.  The idea to focus on content quality is definitely one of his core themes.  His book “Dip” is all about finding out what you can be the best person in the world at and focusing on that one area.  Yet, a competitor has gotten more focused about it than Squidoo.

Seth recently wrote:

In the face of infinity, many of us are panicking and searching less, going shallower, relying on bestseller lists and simple recommendations. The vast majority of Google searches are just one or two words, and obvious ones at that. The long tail gets a lot shorter when you don’t know what’s out there.

Organizations that can help us manage the infinite are facing a huge (can I say it? nearly infinite) opportunity.

To the issue of getting yourself hooked into “shallower” ways of finding content, one should add that when there is infinite content, it can be particularly differentiating to have better content.  This is something that has always bothered me about the crowd that says, “Content is a commodity.”  This has been such a popular meme lately, but it is so hollow. 

The next time you’re going through pages of Google search results just trying to find one good read about you topic, ask yourself, “Would getting to quality sooner have mattered to you on that search?”  I’ll bet the answer was “yes” for most searches.

P.S.  Why should Enterprise 2.0 take note?  Because these folks are going to be particularly sensitive to the kinds of content that HubPages eliminated.  Does your Enterprise 2.0 solution have a way to do that automatically, or are you going to leave it up to your customers to police their sites? 

Immediate Gratification Matters

When your users access your service on the web, how fast do you gratify them?  Do you think about response time, or is your view that so long as it gets there before “too long”, it’s not a problem?

Google has made a business case for slamming down latency.  They invest zillions of dollars and IQ points trying to make their service respond faster when you hit the search button.  Why?  Because they’ve found it matters for the user experience.  Here is a graph of their recent experience with latency:

Fred Wilson recently tried Slideshare.  He liked it, but his primary complaint was that it took 12 hours after he uploaded his .ppt file to convert the slideshow to Flash.  As he puts it, “I went to bed before it finished.”  I had the same reaction to Animoto.  Loved the service, but I made one slideshow and then forgot about it.

The debate on whether startups have any business focusing on scalability rages in the blogosphere in the wake of the Twitter shakeup as we speak.  People like Ted Dziuba say essentially, “Scalability is not your problem, getting people to care is.”  The trouble is, as the two examples above show, getting people to care is at least partially a function of delivering immediate gratification from the software.  Scaling does matter for that.

Immediate Gratification matters most of all when selling.  If prospects can try your application out online, make sure it responds blindingly fast so they can get as far as possible in the evaluation while they are in the mood to look.  If a site doesn’t perform well on the trial version, my expectation is that it will perform poorly in production too.  That’s not what you want. 

Process matters too.  How often have you gone to a site, seen a white paper or demo you wanted to get access to, and had to answer 20 questions before you could get in?  Worse, how often did you answer 20 questions and then get told they’d get back to you?

They’re protecting the ability of their sales staff to control the process and making sure they capture your lead info.  But it’s a mistake because it just kills the momentum of an interested viewer.  What kind of customer wants to be kept waiting before they can give you their money?  It’s one thing to be kept waiting because of overwhelming demand for a private beta, that’s exclusivity.  It’s quite another to do one of these hurry up and wait sales wonders.

Gather the least information you can (name, email, and company?) and then give immediate access.  What are you doing otherwise, preventing competition from seeing your app and sales materials?  Balooney.  They’ve already seen it.  Trust me on this one.  Every customer that winds up choosing them instead of you, every friend of a friend employee that moves on, and a hundred other potential sources has eventually given them access to the 411 on exactly what you have.  If your lead is so fragile that the information you give any qualified process can sink your ship in the competition’s hands, you’d better get going on some radical innovation or you’re not going to make it.

I recently came upon Rally Development’s site.  Rally makes a SaaS tool for Agile teams.  I loved the site because of all the Instant Gratification.  In fact, it may be the best non-consumer startup site I’ve seen in a long time.  They touch every base– traditional product + marketing, education/learning, and community/evangelism –with a well-organized low friction and content rich offering that tells me what I need to know.

In an age of real-time scalability with services like Amazon.com, there’s no good technical reason to keep your customers waiting.  At the very least you should run some tests to see if faster response times improve your sales.  Once the scaling and infrastructure side is handled, the rest of it is in your hands in terms of the processes you force your customers to follow.

Immediate gratification matters!

This Message Will Self Destruct in 5 Seconds… (But Why Would You Want That???)

Stowe Boyd wonders what the point of Big String’s self-destructing instant messages are:

I don’t know why someone would want a self-destructing IM. And couldn’t someone simply retype an IM if they wanted to spoof what you had said?

I guess Stowe has never been deposed on a legal case by lawyers.  In business, this happens a lot.  If you are in business for long enough and are successful enough, you will be deposed.  The opposing side’s lawyers job is to find every bit of documented evidence they can and use it to make you look evil. 

Many financial institutions these days can use neither email nor instant messaging precisely because it creates a paper trail.  While it’s true they may feel they have something to hide, what’s more common is a fear things will be taken out of context.

While this idea may not be ultimately successful, it motivated by a big pain area among large businesses with paranoid corporate counsels.

From TwitPitches to TwitQuiries…

Stowe Boyd is writing about his TwitPitches idea again.  This is his practice of using Twitter for people to send him their elevator pitch.

I didn’t like them coming in his blog RSS feed to me–as I wrote, it isn’t what I expected or wanted from that venue.  But I can see the value.  Stowe wants to get through a blizzard of incoming PR requests to pitch ideas to him quickly.  He doesn’t want to read lengthy PR releases or unneccesary chit chat from people he doesn’t know.  He just wants to evaluate as quickly as possible whether it makes sense to dig any deeper or whether he just wants to hit the delete key.

In many ways this sort of quick inquiry is what I’ve always used messaging systems for.  In one of my jobs my team was spread all over a building.  It was easy to use AOL IM (pre-Twitter days!) to find out if someone was busy or had time to meet if I headed over.  Messaging was faster and easier than the phone and it worked well.

Stowe is on to something here, but why stop at pitches?  And why put it all exclusively through Twitter? 

I’d love to have a “fast lane” for inquiries tied into my email account.  I’d love to have a special Twitter “channel” for these things.  It’d be great if I could be reached by either venue.  Ditto phone calls and voicemail.  The overriding consideration would be to keep it brief (Twitter’s 140 character limit is fine) and to the point.  Better, give some flavors.  a “yes/no” TwitQuiry has a built in Yes/No button.  Bang one and the sender gets their answer.  “Time” would be another goodie.  Works for, “How long until you can take a call from me?”  Or, “When will you be done with that preso you promised me?”

It probably makes sense to let people create their own Tweetlets (applets for TweetQuiries) that do these things.  I can imagine them being really useful even for certain kinds of business process, for example.  A tiny little bit of structure aimed at streamlining keystrokes will go a long way.  There are lots of tiny interpersonal transactions that could be facilitated in this way.

Could be something to this yet.

Bug or Architecture Flaw? (Fail or No Fail)

Blaine Cook, Twitter’s lead architect, has left the company.  Predictably, the blogosphere is flaying him pretty good.  Michael Arrington asks , “Amateur Hour Over At Twitter?”

Ouch!

Blaine, I feel for you.  People expect and are pretty tolerant of a few bugs, but the problems at Twitter have been going on for long enough that it’s clear there were deep-seated architectural flaws that were not going away very soon.  Twitter is taking the right steps–they’ve got a new VP of Engineering and Ops as well as two new scaling experts.  Cook, rightly or wrongly is firmly under the bus.

What follows next is important.  The new gang has a limited window in which to fix the problem.  This won’t be easy.  Fixing deep architecture issues on a live system that can’t keep up is one of those nightmare scenarios that’s painful beyond belief. 

What can we learn from this? 

First, Twitter is just the latest example of an important service that has all the ingredients for success except for the ability to scale properly. 

I gave up for the last time on Technorati not long ago for similar reasons.  For a long time it was my blogging hub.  I used it for search and to monitor how well my own messages were penetrating the blogosphere.  But it was wildy inconistent.  It was easy to switch to Google for Blog Search, after all, they are the search experts?  But that Technorati Authority seemed like it was worth hanging around for. 

And then one day my Authority dropped almost 100 points.  In one day I went from over 300 to just a little over 200.  What’s up with this?  I waited for it to come back–at various points in the past, something similar had happened and then corrected itself in a day or two.  No such luck.

Eventually, I stayed away long enough, that it was time to log in again.  I didn’t remember my account info, so I simply searched for SmoothSpan to find my blog.  There was my answer for what had happened:  I saw two SmoothSpans!  One had my old over 300 authority, one the new authority. 

But I could tell neither was really right.  In other words, the true authority was some mix of sites from one and some from the other.  Thinking about how this could happen revealed a classic architecture flaw: Technorati had created more than one record for the same thing and couldn’t keep them straight.

Twitter’s situation is similar.  Supposedly they were rolling out a new caching system of some kind when their latest troubles hit.  Caches create more than one copy of the data intentionally, to make it easier to scale.  The trick is to keep it all running smoothly and to feed the cache from the one true version of the data.

Second learning point:  It may be a bad idea to worry about scaling later.  This topic has been debated from time to time.  Some have advanced the notion that to worry about scaling up front is a premature optimization.  Scaling is not a premature optimization!  It is fundamental architecture.  The number of developers who can deliver a highly scalable web property is a tiny fraction of the number of developers who can get “almost there”.  The difference between having one architecture versus the other is a healthy heaping of FAIL.

My last company, Callidus Software, understood scaling.  We got it so well it became a major differentiator for the product.  We could literally go to customers where the likes of Oracle and SAP (who supposedly understood scaling) could not go because their systems wouldn’t handle the scale.  There’s nothing quite like being the only game in town for a big customer that has to have a solution.

Scaling is something the Cloud Platform world may eventually deliver for us.  So far, they are more about Utility Computing, which is the ability to add more machines quickly and easily.  That’s Amazon’s model.  Whether your software can use more machines (i.e. whether it scales), is up to you.  Teasing apart the aspects of an application that make it scalable and handing them over to a platform will be a ticklish business.  It’s likely to a good deal of rewriting.  But either way, your team can get it right the first time, do a rewrite under fire, or rewrite for a Cloud Platform that shows how its done.

Does your team understand scaling?  Really?  How do you know?

Related Articles

A recent interview with Blaine Cook.  Interesting note on eventual consistency: Twitter only allows API’s to update once per minute.  The team is 5 full-time developers and that includes 1 new person.  Tight team, but that’s good.

Michael Arrington mentions he read this post in a Seesmic video.  Scan down through the comments to see it.  He’s involved in a big slugfest over whether this was character assassination on Cook, whether the fault lies with Ruby on Rails, and so on and so forth.  It’s important not to lose track in all of that emotional content of the main issue here, which is that scaling matters, a relatively small set of developers have lived through it and know what to do, and it is hard to fix after the fact.

Despite the fact that there’s basically a flamewar on Techcrunch over this, others seem to reach a similar conclusion.  Larry Dignan has a good post over at ZDNet.

Microsoft Mesh: All Your Devices and Data Are Be Ours

I’ll bet your blog reader is probably overflowing with posts about Microsoft’s Mesh announcement this morning.  Sorry to add one more, but it is an important announcement and there is some analysis I want to get out onto the table.

Mesh Product Director Mike Zintel sums up the Mesh vision well: 

“The coolest thing about Live Mesh is how it smashes the abrupt mental switch that I have to make today as I move between being ‘on the web’ and ‘in an application.”

“At the core of Mesh is [the] concept of a customer’s mesh, or collection of devices, applications and data that an individual owns or regularly uses. The Mesh Account Service persists the relationship among these resources and authorizes access to them. The mesh is the foundation for a model where customers will ultimately license applications to their mesh, as opposed to an instantiation of Windows, Mac or a mobile account or a web site. Such applications will be seamlessly installed and run from their mesh and application settings persisted across their mesh.”

Ray Ozzie adds to this that the Web is “the Hub of our social mesh and our device mesh.” And goes on to say that, “in scenarios ranging from productivity to media and entertainment, social mesh notions of linking, sharing, ranking and tagging will become as familiar as File, Edit and View.”

Mesh starts out for individuals, which I suspect is intended to minimize adoption friction.  Lots of cool sounding functionality has been considered and incorporated into the design.  There are objects that range from data to applications, and data is not limited to files.  There is some sort of role-based security around these objects, and objects can be stored in all sorts of places.  Most importantly, there is pub/sub synchronization, replication, and update alerts and feeds to keep people aware when changes are made.

At the moment, Live Mesh is an invitation only “Technology preview.”  The current version only does synchronization of Windows computers, but its intent is to extend to other devices.  Mobile and Mac are promised within the next year.

How is this really different?  Josh Catone mentions similarities with Dropbox, SugarSync, and Microsoft’s own FolderShare.  Interestingly, I’ve seen a demo of software that syncs across PC’s and mobile devices not long ago from SoonR as well.  It works today for a number of devices.  Their motto is “The Anywhere Workforce.”  I vividly remember a couple of years ago seeing a PowerPoint slideshow played back over a Motorola Razor at my home using SoonR.  How long before Microsoft has made it that far?

As Catone points out, the difference is that Live Mesh is intended to be a platform.  It is feeds of all shapes of sizes plugged into your data and applications.  These feeds are used to sync your data objects, and to keep you and others abreast of when these updates are happneing.  Since its a platform, the feed mechanisms are open and accessible to third parties.  There is a demo, for example, of Twitter tweets being synced to the Mesh Notifier.  Clearly Microsoft will want a piece of the burgeouning feed aggregation world.  FriendFeed and friends look out!  In addition, there is an offline component too, which provides one possible answer to the likes of Google Gears or Adobe AIR.

In a nutshell, that’s what Live Mesh is, now what does it mean?  Will it work?  What can we do to prepare for it?

Analysis

Scoble loves it.  A veritable toolbox of feeds going every which way.  Everything is a feed, including your, um, feeds.  I’m not surprised Scoble loves it, but his description doesn’t make it sound like the one highly differentiated must have thing that will keep Microsoft a vital part of all our lives.  In particular, if your promise is connectivity ala feeds between all things, how does that reconcile from this passage from Scoble:

Unfortunately they aren’t even close to being finished. Mac support? Coming in the future. Nokia support? Unclear. iPhone support? Ask Steve Jobs (translation: will be very limited due to Apple’s complete control of that platform). Firefox support? Yes! Linux support? What’s that?

Can a ubiquitous “operating system” to store all your data, manage all your feeds, and connect it all to every computer and mobile device you own succeed if it is owned and operated by a company whose reputation is to take unfair advantage of any access you give it?  Isn’t this the very poster child of what you would want to have be very Open Source and very Swiss in its dealings?

Phil Wainewright sees this issue clearly when he brings up “how the company seems to lurch from launching fresh, Web-savvy solutions one day but then falling back into its crusty old server-centric habits the next.”

Clearly such a platform will rely on third parties to get excited about supporting it.  Will Steve Jobs let it onto the iPhone when he hasn’t even allowed the Flash Player?  Will Sony support it wholeheartedly when they see the XBox team has a huge lead on them because of the usual Microsoft “our guys get all the early advantages” ploy?

Erick Schonfeld captures the flavor of a nagging doubt that has been in my mind.  He sees Live Mesh as a response to efforts to take browser-based apps onto the desktop and into Microsoft’s face.  Live Mesh is taking applications off the desktop and pushing them into the Web’s face.  They demo geneology changes being updated whenever a family member makes a changed, but Erick points to web-based Geni which already does this automatically.

Which one is better?  Do you want lots of copies of data being synced, or one copy being edited collaboratively by many?  This debate has been waged for years, but the general consensus has tended towards one copy with collaborative editing.  Desktop-think wants to keep going the other way.  And, it is very convenient if it’s just you in charge of your data–this blog with me editing it coming to many of you via RSS.  But, if many of us have to work on it, a Wiki is a better idea.

The Live Mesh vision is then useful, but probably overreaching.  It isn’t the “one great thing to restore Microsoft’s dominance.”  There are a lot of questions about whether Microsoft will reach a critical mass in getting others to play along with it.  Suppose they follow their standard playbook (and I see no deviation yet):

- Get their teams early exposure.

- Preannounce to freeze the market.

- By the time others can get there, the Microsoft apps are all doing it better than anyone else will be able to emulate for some time.

- Use this as the competitive edge to increase share for Microsoft apps and position the others as being “not quite up to the Windows standard.”

That strategy doesn’t work in the web world and will backfire mightily if they try it.  Imagine LiveMesh with nobody but Microsoft’s apps talking to it along with whatever files they can drag along and other open API’s that their own engineers tie into.  It becomes a modestly useful feature, not a platform, provided it is well implemented.

Here is my next concern.  There are 100 engineers at work on Live Mesh already, and lots of key functionality (like version control) nowhere in sight.  Aside from the Tactics of Monopoly, the other Fail mode is creating a giant monolith of software.  Vista is a painful example of how far things can go wrong.  Mesh is, at its core, another attempt to rework the document and folder file system.  Microsoft promised this in Longhorn for years but never delivered.  Now Microsoft is adding to that challenge the need to build something that (sorry!) meshes well with the web.  That’s no small order.

Many are saying this is all Ozzie and is his third iteration of a vision that started with Lotus Notes.  Groove is another one, lest we forget that.  Is this the right vision to be on?  Did the first two iterations demonstrate enough goodness that we want to build this stuff into the OS and fabric of every PC and device we own?  It doesn’t seem like it, but perhaps.  OTOH, what if we were all using an online backup service of one kind or another (Mozy et al), and we could access the backups from any device, publish an RSS feed of the versions, and so on. 

The world used to say Microsoft gets it right by the Third Try.  Microsoft is a little slow.  After the Third Try comes Fourth System Effect (with appologies to Brooks’ Second System Effect) where they go way overboard and manage to produce a Vista.

Lest I leave on that purely negative note, it’s always helpful to ask what they should have done or what they should now do.  It’s the “What would Google do?” sort of game, although it’s more like, “What do modern web companies in general do?”  Google’s recent AppEngine announcement is a prime example that touches all the bases:

-  Start small:  one language (Python), one application type (web apps).  You can build something small quickly without 100 cooks in the kitchen and make it tight.

-  Involve the community:  10,000 betas, first come first served, no special favorites and ramping up almost immediately to 20,000 betas.

-  Be open:  SDK was open sourced day 1.  It didn’t take long for the community to take the SDK and bring it up on Amazon Web Services.  Google doesn’t care, it’s all good.  It’s Open.

-  Piggyback on an innocuous beginning:  AppEngine is built on technology Google had created to do lots of other things internally.

-  No special advantages:  Google usually integrates after the launch of a new service so that everyone is on an even playing field and the service gets out the door faster.

There are lots of ways a service like LiveMesh could’ve followed this formula.  I’ll let you fill in the blanks, but consider this too:  there are a fair number of organizations out in the wild that can follow such a formula (and some are already far along the path).  We don’t really need Microsoft to get there.  That’s the piece Microsoft needs to wrap their heads around better.

BTW, the mental barrier between being on the web or in the application (going back to Mike Zintel) is already broken.  I don’t feel it a bit when I spend most of my day in the browser using web apps. 

I guess this is what Microsoft is worried about.

Do You Belong to Any Micro Communities?

Recently, I was invited to join the Enterprise Irregulars, a Micro Community of thinkers, bloggers and doers that are focused on the Enterprise world and where it’s going.  There are folks that range from blogger Zoli Erdos to SocialText founder and president Ross Mayfield and many other fascinating personalities.  I was extremely flattered as I’d been following many of these people for some time. 

It’s a great community, and active discussions flourish among them.  Collective bargaining is also a possibility, as they work together to do a mass WebEx and interview call with companies they’re interested in understanding better.  A lot goes on underneath the surface, not visible to the general public.  EI is an invitation-only organization as are many Micro Communities.

Micro Community is the name I’ve just given to small communities created for a special purpose or interest.  I’ll bet you belong to several.  If you don’t, you’re missing out.  They are everything from groups on Social Networks, such as the the Oracle Alumni I belong to on LinkedIn.  They may be stand-alone special purpose Social Networks such as you can create with a service like Ning.  Ning excels at creating Micro Communities. 

Interestingly, the vast majority of Micro Communities are not on such whizzy new technology.  Most are hosted on Yahoo Groups with a few on Google Groups.  They just basic discussion forums that can feed your email.  Their ubiquity and the means of interacting with them is probably another reason why email is not dead yet.

If you’re not part of a Micro Community, you should inventory your interests and go looking for one.  If you can’t find one, maybe you should start one.  There’s bound to be others looking for kindred spirits too.  These days it’s easy.  Go the traditional “groups” route or fire up something more recent like Ning.

Given the popularity of services that search or aggregate blogs, I wonder how long it’ll be before we have Micro Community search and aggregation?  It’s probably already here and I just haven’t found it.