“From the beginning of time two forces have vied for influence over us. One is bottoms-up, decentralized, and emergent. The other is top-down, centralized, and directed.

The first force catalyzes change and divergence, while the second tends toward order and convergence. The first gives birth to new ideas, and the second enshrines them.”
- Adam Ludwin, From LOLcats To Occupy Wall Street, Everything Is Happening From The Bottom Up Now

Traditionally, industry analyst firms have been oriented around top down adoption patterns. CIOs and other IT decision makers comprise both the research subjects and purchasing audience for the majority of firms in this industry, large and small. Which was logical given traditional procurement patterns. When hardware, software and services are available only at high prices, command and control is an appropriate management structure. Attempting to scale the decision making process for big ticket items across a large body of middle managers is not likely to yield acceptable outcomes.

An approach that makes sense in one context, however, may be misapplied in another.

The technology purchasing landscape today looks very different than it did even five years ago. Where once CIOs might reasonably expect to have the clearest understanding of what technologies are leveraged within their own organizations, today they are, as Billy Marshall put it, “the last to know.” This pattern manifests itself every day within the majority of businesses. Not because CIOs are failing, but because of trends that have fundamentally and likely permanently disrupted their ability to centralize the technology adoption process.

The four trends we see as most important in driving this are arranged here in rough chronological order.

Open Source

In the late nineties, startups and enterprises alike were effectively beholden to commercial suppliers for the majority of their software needs. Because each piece of the requisite software infrastructure had to be licensed, the capital expenses associated with new initiatives was high. This represented a barrier to entry, and thus a brake on innovation.

With the popularization of open source software, developers from enterprises and startups alike were able to operate independently. For the first time, the actual software practitioners were free to choose their own software rather than having it selected for them and subsequently imposed upon them by upper levels of management. Even in situations where the ultimate production infrastructure targets remained commercially licensed software, open source software like Linux and MySQL allowed for prototyping and rapid development without the attendant costs, both financial and in procurement latency.

This was the first major shift affecting procurement, and perhaps the most profound. None of the infrastructure we take for granted today – Linux, Apache, MySQL, PHP, etc – were originally adopted from the top down. Their adoption was, instead, a fait accompli. CIOs – the last to know – gradually became aware that increasingly significant portions of their infrastructure, unbeknownst to them, were running on free and open source software. The inevitable demand for production support options for this software is what fueled, in time, the valuations of MySQL, Red Hat and others.

Bring Your Own Device

In October, Apple CEO Tim Cook asserted that 92% of the Fortune 500 were “testing or deploying iPad in the course of less than 18 months,” which may help explain why the iPad revenue stream by itself would place within the top third of that group. The interesting thing about this is that the majority of businesses appear uncertain about precisely why they’re deploying tablets: “Most participants, 51 percent, indicated that they did not have a clearly articulated strategy.”

The answer, in most cases, is that there isn’t one. iPad adoption, much like the penetration of iPhones and Android handsets is being driven by users who simply want the device. Faced with a choice between users – chief executive officers among them – who will employ their own devices for work purposes with or without the permission of IT, many businesses are compelled to support the platforms even without concrete business justifications for them.

The consumerization of the enterprise is decentralizing the process of technology selection, but its importance may lie rather in design. Like all products, technology is designed and built to be sold to a specific buyer. For enterprise products, historically, the actual user has been a secondary concern; the buyer – typically centralized IT – was the priority. Consumer technology companies like Apple, however, are designed for a user. What they give up in IT friendly features they more than make up for in usability and the ability to delight.

The Bring Your Own Device trend, therefore, may well improve user productivity by driving devices designed to be used rather than managed into organizations, from the bottom up.

Software as a Service

Software as a Service is a classic case study in timing with respect to market acceptance. Not many remember today that the model actually failed the first time around, when its practitioners were known as Application Service Providers. Pyschologically, few enterprises were prepared for either the idea of renting software or externalizing critical data like that stored in customer relationship management systems. By the midpoint in the last decade, however, these concepts were sufficiently commonplace to see Salesforce.com a publicly traded company with a valuation north of a billion dollars.

Consumer markets, meanwhile, had adapted much more quickly. Hotmail debuted in 1996, Yahoo Mail the year after and Gmail dropped in 2004.

Some of those same consumer services were pressed into service by enterprise workers, in fact; it was once common for Exchange users to forward all of their email to Gmail due to the disparity in storage limits between typical Exchange implementations and Google’s webmail product.

This pattern has played out repeatedly over the years, from webmail to CRM to project management software to website hosting to online helpdesks. All were adopted from the bottom up. By making applications available to anyone with a browser, often at low or no cost, SaaS has surged up through the ranks of enterprises. The inexorable nature of the model is reflected by the growth of providers large (Salesforce.com) and small (37signals).

Cloud

The single most important feature of the cloud has nothing, or at least very little, to do with technology. It is, rather, the pay as you go economic model. As Flip Kromer puts it, “EC2 means anyone with a $10 bill can rent a 10-machine cluster with 1TB of distributed storage for 8 hours.”

What this means in practical terms is that for the first time, hardware procurement is democratized. From an accessibility and availability standpoint, cloud is the hardware equivalent of open source software. Where open source allowed developers to bypass traditional procurement channels by making quality infrastructure and development software freely available, so does the cloud allow the growing class of devops technologists to leave the world of high latency hardware procurement – where same day server provisioning is a feature – behind. Armed with nothing more than a credit card, instances can be spun up and ready for use in ninety seconds.

Cloud is the final piece of the bottom up puzzle. Open source software and to a lesser extent SaaS allowed for the decentralization of enterprise technology development, but at some point hardware would become necessary which was the insertion point for IT. With public clouds, it is possible for the first time to entirely bypass the traditional gatekeepers.

The Net

It should be evident that traditional procurement and purchasing is not dead, just increasingly bypassed by a more efficient process. Also, that a great many enterprises continue to function largely as they always have: top down. More important than the question of whether this model is sustainable in the face of the trends above is whether it should be.

Before lamenting the fact that the above forces are disrupting and destabilizing your enterprise IT, consider that that may be a net gain. If the primary drivers of BYOD, Cloud, Open Source, and SaaS include ease of use, lower costs, frictionless availability, and speed of provisioning, are these trends worth opposing? Particularly since efforts to do so will, in all probability, fail?

Or are they instead assets to be strategically leveraged? There is little debate that businesses that move the most quickly have a competitive advantage. It’s not clear how businesses that prohibit the same tools that enable this will benefit.

Either way, bottom up adoption is here to stay: use it or lose.

For about five years now, I’ve been anticipating the rise of application and developer marketplaces. It baffles me that no one has perceived commercial opportunity in the massive inefficiencies in a customer’s ability to discover, procure and purchase apps or services for a given platform. I’ve done Q&A’s on the subject, I’ve used speaking engagements to evangelize the topic, and I’ve even articulated the pieces you might need and how most of them are available from Amazon. What has been the response to my business model for the 21st century?

Crickets, mostly.

Mobile’s an obvious exception. Once Apple built themselves a (massively successful) marketplace, vendors couldn’t build their own fast enough. And we’ve seen steps in the right direction here and there, such as the Eclipse marketplace or the Ubuntu Software Center. But the enterprise market has largely yawned at the concept of marketplaces,

But as of Tuesday, it would appear I finally have an answer to this question. The answer, at least for now, is Google.

As predicted by the Wall Street Journal last month, Google announced this week the immediate availability of what they call the Google Apps Marketplace. To explore what this means, let’s turn to the Q&A.

Q: Before we begin, do you have anything to disclose?
A: For once, not a ton. Some of the vendors who might be impacted by this announcement, such as IBM and Microsoft, are RedMonk customers, as are the mentioned Canonical and Eclipse, but Google is not a RedMonk customer, nor is Amazon. RedMonk, however, is a Google Apps customer.

Q: What is a marketplace?
A: There is no set definition, because it depends on the nature of the platform. But here are some rough stages of evolution for marketplace type offerings.

• The Repository:
  An aggregation of applications, libraries, themes and other packages appropriate – and generally packaged for – a given platform. Optimally, installation is integrated as in the case of Linux distributions (apt, Portage, YaST, Yum, etc), but it may simply be a central portal collecting related assets, as is the case with WordPress. Users can browse, discover and (optionally) install free applications which will improve their platform, but the experience essentially ends there.
• The Store:
  The Store also aggregates platform related applications and packages, but introduces the commercial element. Paid applications are made available, and generally the purchasing process is integrated. The canonical example in this category is the iTunes Application store. Users can browse free and paid applications using the interface, acquiring/purchasing and installing either type.
• The Marketplace:
  The Marketplace – a true marketplace – includes all of the above, but adds one critical element: people. While Repositories or Stores make the process of acquiring and installing applications more efficient, they offer little to no benefit subsequent to that process. Need help with set up? Configuration? Tuning? Integration? You’re on your own: try Craigslist or eLance. A true Marketplace, however, adds the critical element of people to this equation, connecting customers to individuals or companies with related expertise.

Q: And you think Google’s built a true marketplace?
A: They appear to be pretty close, yes. It’s not quite a wide open marketplace for human resources yet; there don’t appear to be multiple individual implementers for the different software options, for example. But just look at the Small Business Implementation services: lots of small shops in there competing on pricing for implementation. And that single example illustrates to me why this is a good idea for everyone involved.

Q: How’s that?
A: Consider the small business market. Many SMBs are using ISP based email to run their business, which is why you email them at something like joesflowershop67@comcast.net. They’re doing this not necessarily because they believe it’s the best solution for their business, but because everything else is too hard. But what if you could tell them that they could have mail, calendaring, online documents and everything else that comes with Google Apps for around $20 or $30? How many would go for that? Quite a few, I’d bet, and I doubt Google would take that bet.

But the set up for Apps, which involves making changes to domain MX settings and such, is a little too much to ask from the kind of people that are trying to login to Facebook from Google.

For someone who’s experienced at it, however, the setup is trivial: about 30 seconds work. So you arbitrage the delta in difficulty and come up with a fair price (as determined by a competitive market), and everyone wins. The SMB gets a better infrastructure at a very reasonable cost, the implementer gets a decent margin on a few minutes worth of work. Google, meanwhile, gets a $100 per developer/org and customers that may or may not pay them but will provide them with more data in the meantime while not using a competitor’s solution. Everybody wins.

Q: But as popular as Gmail and Apps might be, isn’t their ecosystem dwarfed by that around products like Exchange?
A: Undoubtedly. And that’s one reason the Marketplace is so interesting.

How do you find solutions if you’re using Exchange? Where do you go? If you’re relatively knowledgable, you might think to visit the Exchange homepage and search for partners. Which might lead you here, to an uninspiring partner search page. If you keep hunting, you might wind up at Microsoft’s version of the Solution Marketplace. Perhaps from there I find a listing: what are my options at that point? Show a phone number, send an email inquiry. The pricing? Per seat, that’s all I’m told.

Contrast that with similar products from its Google counterpart, where the pricing is described, you can read actual reviews of the product or services and – most differentiating – you can click to install the product. The SaaS nature of Google Apps has its disadvantages, particularly for conservative buyers, but ease of installation is not one of them.

Q: The primary advantage of Google’s Marketplace then, vs something like Microsoft Exchange, is in product acqusition?
A: The advantages of a true marketplace as Google’s built it exist at every layer: inefficiencies are significantly reduced or eliminated in discovery, acqusition/implementation, purchase, and experiental ratings/context.

Q: So do you think that Google’s community is going to approach the size of Microsoft’s soon?
A: Rome wasn’t built in a day, and Google’s got a long way to go before it can rival the size and scope of competitive communities like Microsoft’s. That said, if I was competing with Microsoft, this is how I would do it.

Q: What didn’t Google get right?
A: It’s a little difficult to discover more general resources: I have questions or needs, say, around complex spreadsheets, or the construction of templates in Docs. It’s also vendor focused at the expense of individual practitioners. Nor is it obvious what the Google Qualifications mark is. And as far as the applications implementation experience goes, it can be a bit clunky: our TripIt installation is still hung up.

Q: What’s in it for developers?
A: Access to the market. Say you do Google Apps implementations; how do you do customer acquisition? Locally or regionally, you might employ traditional mechanisms such as print or radio, but it’s probably just as easy for you to set up apps for a customer in Auckland as it is next door. By listing yourself in the marketplace, you have the opportunity to access a wider and more targeted market than you would with, say, AdWords.

Q: What about the competition? Won’t it be difficult to be heard? How differentiated can you be as someone who sets up Apps, for instance?
A: That’s an excellent question, and the answer is we don’t yet know. It will be interesting to see how Google manages the volume of developers. They’re already acting to throttle participation with the one time $100 signup fee, which should keep out most of the drive-by, non-serious implementers.

But whether they manage the volume tightly or loosely, this will be an important channel, simply by virtue of the volume that apps can generate.

Q: What about the applications space? Is it in a provider’s best interest to list with Google?
A: Why wouldn’t you? Google’s claiming that 2M businesses have already chosen Apps as their platform, and even if that assessment is inflated by 50% you’re still talking about a sizable market. Even better, a sizable market that is likely underpenetrated relative to more traditional marketplaces.

Q: Underpenetrated how?
A: The businesses running on top of platforms from IBM or Microsoft have had years, decades in some cases, to build up solutions around Notes or Exchange. Google Apps, on the other hand, is a relative greenfield simply because the integration of applications on the server side is new. It’s kind of a gold rush, in that respect.

Q: Big picture, what does all of this mean?
A: Let’s look at it by audience. For the customer, it means either a streamlined route to implementing Google Apps, an exponentially more accessible portfolio of resources once you get there, or both. For developers or application providers, it’s a relatively less crowded channel opportunity, one where the infrastructure for both installation and payment is already built for you. And for Google, it’s nothing less than an opportunity to dramatically expand their ecosystem, which – in addition to the obvious direct benefits in terms of customer acquisition and partner opportunities – acts to reassure conservative enterprise buyers that this platform is for real.

Q: And for competitors?
A: It means that they should have been building marketplaces all along, as I’ve been saying

Really, all I wanted to do yesterday morning was find a copy of the del.icio.us Chrome extension I was used to on my old machine. Paging through the Chrome extensions repository, however, all I turned up were a bunch of glorified bookmarklets. Eventually I turned up the “official” Chrome extensions Google Group. The last update for which was August 6th, 2009.

That moment is, more or less, why I’m leaving del.icio.us. The del.icio.us part of it, anyway.

My history with the del.icio.us service is long. I’ve been using the tool since 2004 or so, and in that time I put 7102 bookmarks up there. With notes and tabs included, the export came to 2.2 MB. Which doesn’t sound like much, until you consider that it’s just links. We used to test browsers, actually, by trying to load my del.icio.us bookmarks page: before they used to page things, it would crash pretty much all of them. Ah, the old days of the web.

On one occasion, at the kind invitation of its creator, Josh Schachter, I had the opportunity to visit the del.icio.us NYC HQ, prior to its acquisition by Yahoo and subsequent transition to California. Small office, small team, rag tag architecture – one box of which we helped acquire for them – and yet a product superior, I think, to what we have today.

To say that I have a personal affection for the service, then, is understating things.

But with Josh now departed, less than enthused about the direction Yahoo has pursued with del.icio.us, that attachment has waned. Like some other Yahoo properties like Flickr, the social bookmarking service has seemed to get but little attention from its Yahoo parent in recent years. Innovations have been few and far between, and where they have tried to update things – most notably with the UI – I haven’t appreciated those changes. Periodically, features like the blogging autoposting have broken, to be repaired eventually.

When I looked at that Chrome extension last updated in August, then, I had to ask myself whether I really had confidence that del.icio.us was the right tool for my needs going forward. The reluctant answer was that it was not.

Which left the obvious question: what would I replace it with, and how?

While I briefly considered more robust solutions like Evernote as well as radically simpler approaches like a dedicated Identi.ca, Posterous or Tumblr account, I’ve instead decided to proceed with Pinboard.in. Pinboard has its own views of why you might prefer Pinboard to del.icio.us, as well – interestingly – as why you might prefer del.icio.us to Pinboard.

But here’s why I switched.

• Triangulation:
  Here’s how I’ve described this before:

  The concept is simple: a single pointer to a new technology, service or whatever – even from a trusted source – is likely to have minimal impact, particularly if it requires effort to explore. But the second notice, from a trusted party, triggers a little click of recognition, and is far more likely to register. Further mentions only escalate this, until the interest to skepticism ratio tilts in favor of a trial.

  Pinboard’s been on my radar for a while, but the more reviews I read like Nat’s, the better I felt about it as a potential replacement. Even one that I didn’t know I was looking for.

  I originally discovered del.icio.us through alpha geek triangulation, so it seems only fitting that its replacement be discovered in similar fashion.

• Twitter:
  My linking behavior has changed significantly since the introduction of Twitter. As I’ve grown to use that service more, there is a certain class of links that I was posting to Twitter but not to del.icio.us and vice versa, meaning that there was no longer a single service that collected everything I pointed to.

  Pinboard, unlike del.icio.us, has a feature that monitors my Twitter feed and will automatically collect the links I post there. Problem solved.

• Speed:
  Speed, remember, is a feature. One Pinboard has in spades: the UI is just fast. No other way to describe it.
• Link by Mail:
  Speaking of Twitter, one of the use cases that’s been bothering me has been stories that I read via Twitter but on my iPhone. Invariably, someone will link to something on Twitter, which I’ll read about on my iPhone using Tweetie, and it’s long enough that I don’t want to read it on the small screen. My solution to date? Mail it to myself. Which is a poor idea, since I’m no more likely to read my own email than anyone else’s.

  Pinboard, meanwhile, provides me with a Posterous-like email address from which I can mail the story in to be automatically collected. Simple, but very nice feature.

• Other Sources:
  If I want to bookmark or otherwise mark links via other services such as Read It Later or Google Reader, Pinboard will automatically collect those as well. It will even monitor del.icio.us in case I wanted to use them in parallel.
• del.icio.us Import:
  Speaking of del.icio.us, one of the obstacles to leaving the service was the content I’d amassed there. But to their credit, del.icio.us allows you to bulk export your entire archive. Pinboard, meanwhile, allows you to import your entire history, so in a minute or two I was up and running on Pinboard as if I’d been using it since 2004.
• Export:
  And speaking of export, Pinboard allows me to export everything I put it, via the same format as del.icio.us or simply RSS.

What about the downsides? Well, there are two from what I can tell.

1. Autopost:
   Unlike del.icio.us, Pinboard does not natively support the collection and publishing of links nightly to a blog. While I’ve fallen out of this practice lately, I do still use it from time to time and some folks do appreciate them, so the lack of it is a potential issue. That said, it shouldn’t be too difficult to aggregate the links and publish them if I like, or I could move – as a lot of folks have – to a more manual, potentially higher value links post.
2. Price:
   For some, this is undoubtedly a concern: Pinboard is not free. As its creators describe the pricing:

   Users pay a one-time signup fee that goes up by a small amount with each new signup. In return, they get a fast, spam-free service and prompt support.

   It’s about $6 at present, though I paid for the $25 service which fully archives all the pages I link to.

   I certainly respect the rights of users to advantage free services over those that are paid. For my purposes, however, I am happy to pay individual developers to help fund services that are useful to me: I offered the same to Josh when he was launching del.icio.us.

   I also find the pricing model interesting, in that it attempts to align user psychology with the costs of scaling. In the beginning, a low price acts to throttle drive by, low value users but keeps the barriers to purchase reasonable for legitimate early adopters. As the volume of users grows, however, and the costs of scaling increase, the pricing escalates both to offset the increased costs as well as keep adoption at manageable levels. It’s not clear how the model itself will scale over time, but it’s creative, and I give them credit for that.

Will I stick with Pinboard as long as I have with del.icio.us? Or will I revert to that service? Should you switch?

Who knows. Personally, I’m quite happy with Pinboard and recommend it if you’re in the market for a (new) bookmarking service. If you’re happy with del.icio.us, by all means stay.

In the meantime, if you’re interested in what I’m reading, check me out over at Pinboard. If you’d prefer to subscribe in a reader, the feed can be found here.

Time was, when you were talking about enterprise client software you were talking about Windows. End of story. One of the major takeaways from Lotusphere this year, however, is that those days are pretty much over. Make no mistake: Windows is still The Platform amongst many platforms. But the days of it being The Only Platform appear to be at an end.

This isn’t exactly a revelation. Google, Salesforce.com and the rest of the SaaS crowd have been pushing this rock up a hill for years. And IBM began this journey itself years ago when it sought to eliminate its dependence on Internet Explorer, and continued with client releases for Mac and – shockingly enough – Linux. Even Ubuntu. Their recent efforts to market alternative desktops in various geographies is likewise indicative of a shift in the client strategy. Away from a Windows centric world towards one more platform agnostic.

Consider what Lotus was talking about last week. Their first iPhone client, the announcement of a future Andoird client (to big applause) and what was termed “a bit bet on HTML5,” in Project Vulcan. And this is IBM, mind you. Not exactly the most aggressive vendor when it comes to pushing the envelope.

If we use IBM’s direction as a proxy for the future enterprise client – just for the sake of argument – what does it all mean? A couple of things, I think.

1. The enterprise client is going to be heavy on the web (we knew that)
2. The enterprise client is going to be heavy on HTML 5 (that one’s kind of new)
3. The enterprise client is, via Android & iPhone builds, going to be more consumer friendly – that’s a genuine surprise
4. The enterprise client UI is going to depend largely on the hardware form factor
5. The enterprise client is going to be available to consumers in ways it never has been before

None of this, remember, means that Windows is dead, dying or going away. Windows 7, the release that’s what Vista should have been, seems to be selling just fine. Nor does it mean that Flash or Silverlight based clients are dead ends: they are not.

But IBM’s announcements do paint the landscape as significantly more heterogeneous and less platform centric than it has been in years. And to the extent that IBM’s interests are aligned with the likes of Google and Mozilla around HTML 5, it may even be an open standards based approach.

Either way, the takeaway from Lotusphere from a client perspective is simple: things are getting a lot more interesting.

Disclosure: IBM is a client, as are Adobe (Flash) and Microsoft (Silverlight/Windows).

You heard it here last. As always.

As all of you undoubtedly know by now, Google yesterday took the wraps off an open source project called Chrome, which is its Internet Explorer analogue. While the release of a browser is not ordinarily accorded as much fanfare – as many have wryly noted – several aspects of this launch make it worth commenting on, in my view. The fact that a firm like Google felt compelled to build it, not least of them.

As a result, I thought it worth indulging in a Q&A to explore some of the questions that I and others who’ve written in have about Chrome, its future and its potential for impact.

Q: Before we begin, do you have anything to disclose?
A: Microsoft, the author of a browser competitive to Chrome in IE, is a RedMonk client. Besides that, I’m unaware of any potential conflicts, as neither Apple (Safari) nor Mozilla (Firefox) are RedMonk clients, nor is Google itself.

Q: Can you summarize the details of the product announcement for us?
A: Google, as indicated by the premature release of Chrome documentation, launched on Tuesday an open source browser called Chrome. It is built from code taken from the open source project labelled Chromium, which in turn draws from Firefox and Webkit, the project upon which Apple’s Safari browser is built. The source code can be found here.

Q: Has anyone looked at the code yet? What have the reactions been?
A: Mostly positive. Miguel, for one, was impressed. Oddly, however, the source tree, as an individual noted on #redmonk yesterday, appears to include Cygwin.

Q: What differentiates the browser from Firefox, IE, or Safari?
A: Several things. It’s very lightweight on the traditional features – bookmarks, for example, are not enabled by default – but does some interesting things with tabs and such.

The more important differences, however, are fundamental. Architecturally, it’s distinguished by its counterparts (with the exception of IE8, reportedly) in its process-per-tab approach. Rather than spawn a single process per browser instance, as does Firefox, Chrome generates a process per tab – and plugin, if I understand correctly. This is unusual. As John Resig describes it:

If this is true and there’s a process manager which allows you to see how many resources are being consumed by a particular browser tab (including plugins!) this will be a 100% killer browser feature.

It simply isn’t possible to implement with current browser architectures which brings up two points: 1) Browsers haven’t tackled it due to the extreme amount of code rewrite that it would cause and 2) that there’s a general consensus that this architecture will actually consume more resources than the current architectures.

This is important. Since there’s no sharing going on between the tabs of the browser it’s not possible to easily reduce the amount of duplicate resources. For example, within the Mozilla Gecko engine there’s a lot of code reuse occurring, which allows for significantly reduced memory consumption (and optimized memory collection and defragmentation).

In theory, the advantages of this approach should be multiple. One rogue tab or plugin will not jeopardize the browser, as they often do today with Firefox. Also, Chrome should be able to better leverage the multi-core chips that are fast becoming the standard. Most compelling to some is the assertion that Resig makes: “The blame of bad performance or memory consumption no longer lies with the browser but with the site.”

In practice, however, the performance may not be as universally improved as we suspect. Talking to Mozilla’s Christopher Blizzard, Ars Technica’s Ryan Paul said “you were right about the memory implications of process-per-tab. Chrome is really a hog.”

Because Chrome is Windows only at the moment, I have done only cursory testing in a VMWare instance and thus cannot comment one way or another, but it will be interesting to see how the different architectural approach taken in Chrome proves itself over time.

To some extent, this is just cyclical history applied to software.

Q: What does that mean?
A: Well, in some sense Firefox is a victim of its own success. The plugins make Firefox successful, but they also introduce potential instability for users and they can hinder development (the transition to 3.0, for example, negatively impacted most of the plugins I use regularly). The platform ecosystem, as is nearly always the case, is both its biggest strength and its biggest weakness. This is not unique to Firefox, of course: every platform of a certain size and critical mass faces this. For example, there’s Windows and its struggles with legacy application support.

Q: Speaking of the Windows only decision, why would Google choose that approach for the launch? Tim Bray and many others had little affection for the single platform release strategy.
A: Not having seen an explanation forthcoming from Google, I can only speculate that they’d reached a stage of development where the Windows version was ready for release, while the Linux and Mac versions (that are planned) were further off. That, or they were compelled to launch before they were ready by leaks or something similar.

Either way, Windows will give them more than sufficient volume to assess both the appetite for and the performance of the project, even if their decision not to simultaneously ship versions for competing platforms raises the ire of the very audiences that would be the most welcoming to new browser technologies.

Q: What’s Chrome been like in your usage, limited though it may have been?
A: Exceedingly quick, as Michael Dolan and many others have noted, and Stephen Shankland’s initial benchmarking indicates. Apart from that, there have been some thoughtful tweaks of the browser UI – the Awesomebar-like type completion, for example – but nothing I would call revolutionary or killer. That said, Google has long recognized that speed is a feature, and Chrome is a chip off the old block in that sense.

While Chrome trounces the available browsers in the current speed tests, thanks in part to its C++ built V8 Javascript engine, I am interested to see how it compares to a Tracemonkey equipped version of Firefox. Tracemonkey, if you’re unfamiliar with it, is a much improved Javascript runtime that promises significant improvements for the forthcoming Firefox 3.1. Blizzard, in particular, disputes some of the claims that V8 is “many times faster,” and has run some numbers to back it up.

One minor personal nit with Chrome: some of the keyboard shortcuts from Firefox are functional in Chrome – CTL-ENTER to add a www and a .com to something typed into the location bar, as an example – but many are not. SHIFT-ENTER for .net, CTL-SHIFT-ENTER for .org and others have not been preserved, affecting its usability for me.

Q: How about the rendering?
A: In the 20 or 30 sites I visited, I had few issues. RedMonk’s homepage and blogs rendered appropriately, as did the bulk of other properties I visited. Google asserts that it should be as compatible as Safari, so that sites designed for Apple’s browser should render appropriately in Chrome, thanks to their shared Webkit foundation. Still, sites are breaking Chrome already.

Q: Does Chrome allow for the same plugin architecture that Firefox has leveraged with great success?
A: My understanding is that it does not, but that a plugin API is planned for future releases.

Q: You mentioned that Chrome is an open source project: what can you tell us about the licensing, governance and so on?
A: The source is entirely available at present under the permissive style licenses that Google (and many other commercial entities) favors. As for the governance, I’m unaware of any active external contributors at this time, although they will be accepting patches and I’m told code is already coming back. My assumption is that this will require the acceptance of a joint copyright agreement, but Google should feel free to correct me on that subject (I’m on a plane and can’t check).

Q: What about the rumors that Chrome is phoning home to Google? Are there legitimate privacy concerns?
A: According to Matt Cutts, the information being transmitted back to Google is fairly innocuous and this is done under logical circumstances. Still, many are asking legitimate questions about the “unique application numbers” mentioned in the Google Chrome privacy notice, and separate questions about the Terms of Service.

Q: What about concerns like David Berlind‘s that Chrome continues a trend whose result will be multiple, siloed internets rather than seamlessly available content?
A: Most web developers, even prior to the launch of Chrome, would tell you that developing web applications is anything but write-once, run-anywhere. Lack of standards consistency, differing developmental priorities and more have made web development a veritable quagmire when it comes to testing and deployment.

But while Chrome is another platform that will undoubtedly have to be tested, its Webkit roots ensure that it shouldn’t be that different from one of the existing platforms in Safari. And the open source nature of the entire platform does mitigate against the type of proprietary control users of IE and Safari are subject to.

Q: Now to the $64,000 question: what does Chrome mean for the existing browsers?
A: That is indeed the question. Interestingly, many are arguing that Chrome is aimed at IE, when I expect it to have little impact on that market. The bulk of IE’s still majority share of the browser market, in my view, are users that have not historically and are unlikely to – in future – choose their browser. These are path-of-least-resistance users, and they are by all available measures, the majority of the market. The availability of Chrome, in my view, is unlikely to change the dynamic of the casual browser, save the future availability of some currently unknown killer feature.

Likewise with Safari, the default browser choice for many if not most casual Mac users. If anything, Safari is poised to benefit, because by tieing its compatibility story to Apple’s browser, Chrome is likely to introduce new users to the Webkit ecosystem, making the platform that much more compelling as a development target.

It is rather browsers that depend on choice such as Firefox and Opera that, to me, are most vulnerable to the introduction of Chrome. Firefox is likely to be more resilient, both because many of the casual users that were originally persuaded to switch to it are unlikely switch again, and so soon, but also because of the strength of its application-like plugin ecosystem.

Q: What does this do, then, to the relationship that Google has long enjoyed with Mozilla?
A: The kind words from both sides following aside, I cannot see but how the introduction by Google of an offering directly competitive with Mozilla’s flagship project will do anything but strain the ties. It will not sever them, particularly with the financial relationship between the two recently renewed through 2011. But it can, it is, making the relationships more interesting on both sides.

Q: What does this mean, then, for the two market leading browsers in Firefox and IE, in terms of product plans?
A: Probably very little, tactically. IE development will proceed apace, as usual, and while Firefox may see the introduction of Tracemonkey sped up, I doubt you will see a dramatic re-architecture of the browser along the lines of Chrome.

Until, of course, that product wins significant share at the expense of one or the other. If the recent history of browser development (see IE’s stagnation and revival post-Firefox) is any guide, a competitor’s success is the surest path to radical change.

Q: What’s in this for Google?
A: Well, as a few people have commented, the flip answer is that more people using the internet more frequently is more better for Google, if you’ll pardon the phrasing. But the question, I think, is better phrased as “why would Google build another browser?”

My guess is that the answer to that comes in two parts: first, the impending threats posed by RIA environments, and second the ability of the existing browsers to respond to the RIA threat.

Google, you’ll recall, is built principally on the sale of advertisements. They have other revenue streams, yes, and I’m counted among those that believe the value of the data they’ve aggregated is both immense and underappreciated, but they’re day to day financial performance is predicated on the ability to effectively monetize browsing traffic through ad sales.

They can do this, and do it with remarkable efficiency, via most traditional browsers; AdBlock or similarly equipped browsers excepted. They are significantly less effective, however, at monetizing traffic deriving from RIA platforms such as AIR or Silverlight. It’s not that they can’t technically can’t monetize ad track on those platforms; they can and do. It’s rather that it’s less intuitive, less native than monetizing the browser. RIAs, after all, have the ability to transform the browsing experience into something more application-like. And how many ads do you have running today in your rich clients?

An RIA dominated internet, then, could well prove to be anoxic to Google, depriving them of the oxygen of ad sales. Browsers, therefore, are important to Google. Which should be obvious, given this launch. Hence their longstanding commitments technically to IE, Firefox and so on, and their less longstanding but no less important financial arrangement with the Mozilla corporation.

With the advent of the Olympics, however, the once far off threat of RIAs in general and Silverlight in particular became clearer. From the Wired account, the work that resulted in Chrome began at least two years ago, but I’m sure that the widespread distribution of the Silverlight player was yet another shot across Google’s bow, demonstrating once more that the need for Chrome was growing more acute.

Q: What need? Isn’t Firefox, at least, doing a good job of competing in the browser market?
A: Indeed it is. Firefox is continuing to show strong, sustained progress in its marketshare, and as I’ve been humorously reminded, its reach into aggressively non-technical userbases is impressive indeed. But with the introduction of Chrome, it seems self-evident to me that Google is attempting to solve a different problem than Mozilla.

Q: How so?
A: Consider the relative targets. Mozilla’s big competition, still, is IE. Credible efforts like Xulrunner and Prism aside – and I use it every day – the rich client story from Mozilla is still fundamentally immature. Not so, clearly, its browser story.

Google, on the other hand, is not only intent on sustaining its browser based ad revenues, it harbors ambitions of expanding the browser into application territories. Gmail, Google Apps, and so on are all alternatives to rich client based applications.

But two can play at that game, and it strikes me that Chrome indicates that Google is worried far less about the browser market, and far more about protecting that market. In a way, in fact, Chrome could counterintuitively be seen as an attempt to shield Firefox, rather than attack it.

Q: How so?
A: Well, what’s one of the principal advantages of rich client applications, in your experience, relative to the browser based competition? Speed, probably. “Rich clients are faster,” says the conventional wisdom. And for once, the conventional wisdom is right.

Not always, and not enough, in many cases – certainly not in mine – but enough that a rich client that was better integrated into the web could be a significant threat to the browsing experience that has come to characterize most internet usage while making Google a mint.

Firefox is fast relative to its browser competition, of course, but is it fast relative to a rich client? That’s debatable. Chrome, on the other hand, while far less ambitious in scope, should be reasonably competitive on that front. It also will include, natively, features to make it competitively in other areas. Think Gears: despite the availability of that piece of technology, and other Firefox efforts, Mozilla’s browser is still fairly stupid when offline (as I’m reminded as I write these words on a plane en route to San Francisco).

Q: How does that “shield” Firefox, then?
A: Remember that Chrome is open source, and permissively licensed. Consider Sergey Brin’s own words, “I hope big chunks of Chrome can make it into the next generation of Firefox.” My guess – and that’s all it is – is that Chrome is what Google believes Firefox should shoot for, performance-wise, to be competitive in a market that could soon be less browser vs browser, but browser vs rich client. If Firefox chooses to take the code and move Firefox to where Google thinks it should go, great. If not, they’ve hedged themselves against the continued incursion of rich clients.

Q: What do you predict, then, for Chrome as far as aspects of it being incorporated into other browsers?
A: It’s too early to say; I’ll wait and see what the various browser developers have to say on the subject. And remember that that doesn’t just include Firefox or other open source browsers: as a permissively licensed asset, bits and pieces of Chrome could well end up back in IE.

Q: What does this mean for Android?
A: Judging by the tiny size and the effort involved, it’s undoubtedly a platform as suited for the handset as the desktop. How, precisely, it will be implemented on top of Dalvik, the JVM reimplementation, I’m not sure.

Q: Will you, personally, use Chrome?
A: Not until they have a working Linux version, no. And even then, I’m somewhat wedded to a few key Firefox plugins. Will I install it and keep an eye on its progress, however? That I will. As soon as it’s available on Linux.

Once besieged by basic questions ranging from “is it open source?” to “will it make money?,” the open source world is increasingly facing more mature, nuanced questions and assertions.

One such that has been picking up steam of late is that open source licensing is less important than commonly assumed. Reacting to a piece from the 451 Group, Eclipse’s Ian Skerrett makes the case that trademarks are the real strategic weapon. Tim O’Reilly, for his part, has famously declared that “open source licenses are obsolete,” largely due to their irrelevance (the Affero and such licenses presumably excepted) to those – like Amazon, Google, et al – that do not distribute software in the traditional sense.

While I understand both arguments, I don’t entirely subscribe to either. From my perspective, the choice of license has far reaching implications on adoption, business models, community size, and more. It’s simplistic to imply, I’d agree, that the choice of a particular license precludes commercial success – or conversely, ensures it. But the license is one of the most fundamental choices any project can make because it dictates – potentially in perpetuity – what users will be able to do and not do with a particular asset.

The Permanence of a License Choice

Even should a project owner decide, for whatever the reason, to shift licenses, there are certain rights and privileges – whether an asset is licensed permissively or restrively – that cannot be revoked or taken back. If you permissively license an asset to me, and I incorporate it into my proprietary software product (as Microsoft did with the networking stack in pre-Vista versions of Windows), you cannot retroactively impose restrictions on the code that I’ve incorporated into my offering. I retain the original rights, even if you decide to license future developments differently.

Likewise, if code is reciprocally licensed under, say the GPL, the rights granted by it to the users cannot be removed legally; with the notable exception of dual license scenarios which may act to remove the restrictions for the licensing entity. For all other consumers and developers of the asset, the rights and privileges granted by the original application of the license must remain.

Licensing decisions, beyond the immediate strategic impact, have relatively permanenc implications. Which, I would argue, makes them important.

The Implications of a License Choice

It’s not debatable that different open source licenses carry different rights and restrictions. And while it’s not unusual for members of various open source communities to prefer one license or license style over another, the market has shown little appetite for a single approach. The LAMP stack, as an example, includes two permissively licensed assets (Apache and PHP) and two reciprocally licensed assets (Linux and MySQL).

Personally, I’m a believer that a license is, ultimately, just a tool. Much as I might choose one tool for one job and choose another for a different task, differing licenses can and should be employed towards different ends. Here’s how we’ve discussed some of the available options previously in an excerpt from an interal report produced for a RedMonk client:

Platform Licensing:

Of particular interest in this case are the strategies employed by platforms. While the GPL remains the overwhelming license of choice for applications in general, and is the choice of perhaps the most popular open source platform in Linux, platform technologies trend towards permissive style licenses as opposed to reciprocal approaches. The BSD distributions are perhaps the most obvious example, but the licensing for PHP – perhaps the most ubiquitous dynamic language at the current time – is another.

At one time, PHP was dual licensed under the GPL and the PHP license, but dropped the GPL as of PHP version 4 because of the reciprocal restrictions. Python’s license is similarly permissive, as it employs its own custom BSD style style license. Mozilla’s Firefox, additionally, was as previously mentioned trilicensed specifically to address the limitations imposed by its original reciprocal-style license.

Generally speaking, the preference for permissive licenses by platform technologies is that they impose the least restrictions on users and developers, thus offering significant advantages should ubiquity and adoption be an important goal. These advantages, however, come with a price: permissively licensed technologies can be easily and legally forked, or incorporated into proprietary code, or repurposed. The lack of restrictions is both its biggest strength and biggest weakness.

For a commercial entity, then, permissive licensing is best applied to platforms when the vendors wants to grow the market around the platform, monetizing other parts of the market rather than the core platform. For example, the platform may be “free” but tools to interact with and create “content” in the resulting ecosystem may cost.

The permissive class of licenses, including the Apache, BSD, and MIT, are chosen for an entirely different set of reasons than those that would compel the selection of a reciprocally style alternative. This will come as news to few.

What may be less obvious, however, is that these choices are no less important than they were years ago.

Trademarks vs Open Source Licensing

As discussed above, Eclipse’s Ian Skerrett has argued that trademarks are more important strategically than the license choice. Those that argue this case might cite the example of Oracle’s Linux foray, which clones Red Hat’s Enterprise Linux offering as is their legal right by virtue of the GPL. The protection afforded Red Hat then, it’s asserted, is primarily due to its trademark rather than its license.

Personally, I disagree. If the Linux codebase were available under the BSD, Oracle would still not have the right to the trademark, but they would have the right to take the entire stack – or perhaps merely portions of it – and make it proprietary. What would the business benefit to such an approach be? Perhaps nothing, but it seems at least possible that Oracle would be able to introduce proprietary extensions – similar to the approach that EnterpriseDB currently takes with the PostgreSQL codebase – and sell them at a premium. More to the point, Oracle would be potentially be in a higher ground position, in which they would have the right to borrow from Red Hat while Red Hat would have no such rights in return.

Before the Apache people begin arguing that the above is unlikely, let me acknowledge that that may well be true. But it is possible, given the differences between the rights afforded by the licenses.

While some might point to Oracle Linux, then, as an illustration of the value of the trademark over the open source license, I’d argue precisely the opposite: the trademark’s value hinges on the protections afforded by the choice of license.

Web 2.0 vs Open Source Licensing

In his piece claiming open source licenses are obsolete, O’Reilly mentions Google and its stable of ubiquitous SaaS – or Web 2.0, if you prefer – applications as proof positive that licensing is obsolete. And certainly, he’s partially correct. The stack that Google runs off includes both permissive and reciprocally licensed assets, which is consumed with little distinction between them because – as previously mentioned – Google is not distributing software and thus has to worry about running afoul of neither style’s restrictions.

But nevertheless, I think O’Reilly’s contention that open source licensing is obsolete because of a Google is incorrect for two reasons.

• First, and most importantly, all software is not Web 2.0. It would be difficult to make the argument, in fact, even that most software is Web 2.0. In his piece, O’Reilly qualifies his remarks somewhat, saying:
  

  Because [open source software's license] conditions are all triggered by the act of software distribution, they fail to apply to many of the most important types of software today, namely Web 2.0 applications and other forms of software as a service.

  Most of which I agree with. But the fact is that the world’s top two or three largest software vendors are not fueled generally speaking by Web 2.0 applications or software as a service. Nor are the hundreds of millions of desktops or billions of mobile devices powered – at an OS level – by SaaS. Until those things change, open source licensing – to me – will be far from obsolete.

  I’m as big a believer in Web 2.0 and SaaS as you’re likely to find in the analyst ranks, but last I checked both needed operating systems and browsers to function. And last I checked both OSs and browsers are subject to traditional distribution, and therefore licensing restrictions.

• O’Reilly’s point is well made in that SaaS vendors are indeed able to construct large businesses off of software released under open source software licenses, but that should not be taken to mean that there every open source license is vulnerable to such usage. If preventing usage from SaaS providers is the goal – and to be clear, O’Reilly does not argue that it should be – I think it highly unlikely that Google will ever strategically rely on code licensed thusly. Which is one reason I was entirely unsurprised that the quote unquote ASP loophole was not closed in the revision of the standard GPL. Open source licensing is not so obsolete, apparently, so as to prevent a license response to precisely the concerns that O’Reilly mentioned.

The License is the Foundation

None of the above should be read as an indication that open source licensing is or should be the only concern for those developing it nor those consuming it. Nor even that it’s the most important consideration in every case. And certainly not that the success or failure of a particular project is Calvinistically preordained by its choice of a particular license.

But I am of the belief that the choice of a particular license is important, carries long term responsibilities, and is the foundation upon which business and defenses of those businesses are built.

fire eagle Screenshot

Originally uploaded by sogrady

It is true, what you have heard: I’m a huge fan of GPS. It successfully navigates me up to the Chops and around Westport Island, and it fetches me back to the car even when the visibility’s not so good. I’m so in the bag for GPS, in fact, that I’ve been campaigning for it on my next laptop.

So it’s natural that I would be excited by a location platform such as the newly minted fire eagle. But I genuinely think that you should be, too. Or, more accuately, you should be soon.

At the moment, fire eagle is an intriguing platform (not least for their choice of Rails), but one short on applications. The Application Gallery tab within fire eagle, in fact, features a couple of applications – prefaced with a bright yellow label reading “You can’t get these yet, but they’re coming soon.” So for now, fire eagle users can log in and update their location, and then, uh, it will know where you are.

Which is less than compelling, obviously. As with most platforms, the utility derives not from the foundation, but from the pieces that are assembled on top of that. If you’re skeptical of that claim, I invite you to uninstall all of the available browsers for your operating system of choice. And enjoy.

From the looks of it, however, fire eagle users are not going to have to wait long for applications to spring up. One of my favorite web applications, Dopplr, is already on board. And if you’re on OS X, here’s a dashboard widget and an application that routes from Plazes to fire eagle. Yahoo is apparently toying with the idea of aggregating some of the best applications, which is a no brainer as far as I’m concerned. The applications make the platform: ergo, making them easier to discover is imperative.

The real value, I suspect, will derive not through any single application, but rather in the application to application integration that’s enabled by the underlying fire eagle platform. As Michael Arrington describes it:

This is perfect for services like Flickr, which still struggle to get users to add lat/long information to photos (With FireEagle, Flickr could just look at the time stamp on photos and note where you were on FireEagle at that time). FireEagle can also benefit by working with established place-blogging services like Plazes, both by giving and receiving geo information on users.

And take it even further: what if Dopplr knew not only my location, but the particular business trip associated with that trip and could apply that data to, say, expenses filing?

I know it’s trite, but the possibilities with respect to location data really are endless.

One feature that I hope the fire eagle folks reconsider is history. Currently, the platform is amnesiac in its ignorance of the past. With the appropriate privacy controls in place, I would unquestionably appreciate the ability to track my location over time. Even if it’s just to cry about how much I travel. So if the Yahoo folks read this, yes this is a feature that I want. As would, presumably, anyone who documents their Year in Cities.

It’s still very early days for fire eagle, but I’m definitely watching.

Three years ago, Doc Searls discussed the idea that “it’s far more important (and interesting) to make money because of our blogs, rather than with them.” The elephant in the room for that particular conversation was advertising, the implicit question being should the blog be a profit in and of itself, or merely a means to enable profit.

While the issues therein are of great interest to those, like me, that blog on at least a semi-professional basis, its ultimate resonance is limited by its self-selection of an audience. What I’m beginning to wonder, however, is whether there isn’t a lesson therein for those authoring software rather than blogs.

More specifically, is it advisable to make money because of software rather than with software? The question is largely rhetorical, because for every arguments for, there’s one against.

That said, it is self-evident to me that software houses will increasingly seek network revenue streams to augment or even replace the traditional software income derived from licensing, support, and maintenance. I make this argument based on the following:

• Customer Conversion:
  The difficulty that open source software vendors have had in the monetization of their wares is well known and understood; roughly 1 in 1000 MySQL users, for example, becomes a paying customer. What’s less acknowledged is that closed source vendors suffer from exactly the same problem. Whether their software is pirated or users simply switch to freely available alternatives, the software market has never been more competitive – and thus difficult to convert customers in – than it is today. Augmenting traditional offerings with network based complementary or stand-alone services potentially offers the ability to convert a higher percentage of would-be customers into actual customers.
• Customer Demand:
  When Microsoft feels compelled to introduce software that over the longer term potentially impacts the sales of one of its two licenses to print money, it’s a good bet that there’s demand behind it. Because even strictly client products are increasingly competing with online counterparts, it’s necessary to add online or network components to the offering to remain relevant to customers from a demand perspective.
• Lower Barriers to Entry:
  Tim Bray, as is so often the case, says it best:
  

  The reason the Web worked so well is that nobody had to ask anybody’s permission to build a browser or a crawler or a search engine or an auction site or a dating service. Anything in the system that requires central authority, that’s something that holds you back.

  While the friction involved in the usage of network applications and services varies widely – compare, say, Amazon’s new SimpleDB service to something like Gmail – the lesson of the web is that the ubiquity of network access and availability trumps client installation in many if not most cases. Ergo, introducing additional functionality and exposing it via a network interface is an obvious win.

• Higher Retention Rates:
  Under appreciated at this point is the potential of value add network services to help retain current customers. Consider an offering like Canonical’s Landscape; while I might, at some point, be incented to defect to RHEL or SuSE or another distribution for cost, compatibility or other reasons, those distributions would have to replicate the functionality currently available to me in Canonical’s offering. While it can be done, it requires effort and disincents me from switching.
• Network Effect:
  Most important, perhaps, are the implications of the network effect. Enterprise software in particular massively underleverages the value of the network effect, but it’s a failing common to software generally. For example, Splunk’s Splunkbase adds significant value over the the pure client, harnessing as it does the collective intelligence of the software’s users. While efforts to incorporate this and other user telemetry are merely in their infancy, it seems clear that over time this will become standard practice rather than a differentiator. As Google proves with its “did you mean” function, even the most basic pattern matching can produce useful functionality: such is the power of the network effect.

Beyond the direct monetization of network services, it’s also likely that we’ll see additional creative models emerge that subsidize the cost of the software via other means. Spiceworks, for example, is able to provide its systems management software application to SMBs at no cost, monetizing it via advertising. Much as Google does with search.

It would be the height of folly to predict the end of traditional software revenue streams, of course, but it seems equally illogical to contend that network revenue will be anything but an important part of software economics going forward. Particularly in cases where direct monetization is a challenge, vendors should consider making money because of software rather than with it.

Disclosure: Canonical, Microsoft, MySQL, Spiceworks and Splunk are RedMonk clients, while Amazon and Google are not.

No VMWare from Rackspace

Originally uploaded by sogrady

“Red Hat on Wednesday announced a significant departure from its current business plan, saying its flagship Linux product will be available on Amazon.com’s Elastic Computing Cloud online service.” – Stephen Shankland

That was one month ago today. Buried under the above news was word that the latest rev of RHEL included Xen 3.1, capable of – among other tricks – live migration. The kind of thing, in other words, that customers typically pay VMWare for.

As Red Hat and other vendors seek to encroach on VMWare’s territory using Xen, KVM and a variety of other open source tools, the virtualization giant will be pushed to seek opportunities to differentiate and innovate. While the Xen release is not comparable with VMWare on a feature/function basis, there’s little debate that the technology is maturing rapidly and becoming a more viable option for real production workloads. Or don’t you think EC2 qualifies as a real production workloads?

Regardless of what you think of it, Amazon’s cloud computing platform is both differentiated and innovative. To the extent that I think that eventually VMWare will be forced to respond, partner, or both.

The shortest distance between VMWare today and a VMWare with a credible cloud story is, in fact, Amazon. Witness technologies such as Enomalism’s VMWare to AMI migration toolset. Could VMWare partner with Amazon, then, and permit VMWare customers to seamlessly deploy their VMWare images within Amazon’s datacenter? Sure, they could. VMWare users would probably be pleased; I know I would.

Such a scenario seems unlikely, however. EC2 is as alluded to above a platform based on Xen, a technology that represents a clear and present danger to VMWare’s own virtualization portfolio. It is unlikely in the extreme that VMWare would be well pleased by the prospect of seeing their workloads being deployed and run on a platform powered by a competitive virtualization technology.

But what is the alternative? Hosted VMWare, in all likelihood. Announced in June, its Virtualization Service Provider Program (VSPP) is intended to bring VMWare virtualization to the cloud, the idea being to make VMWare a viable option for the same audience that might run RHEL on EC2. Which makes the $64,000 question this: will that be enough to compete with Amazon’s platform?

Acknowledging up front that six months is not enough time to judge the longer term potential of VMWare’s outreach to hosting providers, I suspect the answer will be no. Not least because they are hosting providers.

Dismissive as traditional hosts tend to be of Amazon’s entry into their market, the fact remains that EC2 and S3 have significant advantages in cost, friction, and billing logistics over legacy hosted offerings. Meaning that VMWare’s chosen partners are disadvantaged versus Amazon in certain use cases. Add to that the traditional limitations of a partner led approach: fragmentation, an overabundance of choice, and most damningly a lack of a symmetrical commitment. Rackspace, as an example, is one of VMWare’s cited VSPP partners, and yet a search of VMWare of their site turns up nothing.

Eventually, we’re going to see more competitors to Amazon’s cloud based platform, whether it’s from traditional hosts seeking to close the gap or from larger players like eBay, Google, Microsoft or Yahoo following in Amazon’s footsteps with regard to making available their infrastructure and the economies of scale that built them. It’s even conceivable that VMWare itself could be the technology that enables a traditional host to make the leap, much as Xen permitted the creation of EC2.

Either way, I’m a firm believer that VMWare should be investing and investing heavily in cloud computing strategies and partnerships. Not – or at least not strictly – because its competitors are, but rather because its customers will eventually demand it. The good news is that the virtualization technologies required to deliver on the vision of seamlessly migrating workloads to remote infrastructures are largely available. The bad news is that finding an infrastructure capable of implementing them at an Amazon type scale is a non-trivial endeavor.


Disclosure: Neither VMWare nor Amazon or Red Hat are RedMonk clients.

As the interviews that are beginning to make their way up onto RedMonk TV can attest, our stay in Stamford for IBM’s annual analyst get together was something of a free for all of information. A bit of concurrency and dynamic languages here, some analyst relations chat there, the requisite Web 2.0 discussion, and more. All of which could have been predicted, since this event is the one occasion on the year that brings together executives and practictioners from the entirety of IBM’s Software Group. The question I find myself asking, however, is whether that’s enough.

True, the firm has immense resources at its disposal. Also worth mentioning that it’s one of the largest software organizations this side of Microsoft. Short of application software, there are few markets in which they don’t compete. But in a world which is seeing the increasingly artificial barriers between hardware, software, and services collapse, should Software Group be partnering more closely with other IBM divisions?

Before you reply that Software Group does indeed partner with STG and IGS, let me say – “I know.” Cross-brand interests like Linux have done yeoman’s work blurring the lines between the different businesses within IBM. But more is needed, if Software-as-a-Service (SaaS) is any indication.

Consider IBM’s history with the trend. To its credit, Big Blue saw the opportunity here early. It’s the rare SaaS business today that will not at least privately thank IBM for heavily marketing “On Demand,” lowering customer resistance to software hosted off premises. And many IBM partners have effectively transitioned from a strict client-server deployment model to SaaS with the help of IBM, be that services, software, hardware or all of the above. All of which is good.

And yet the story is not nearly what it could, and probably should, be.

Whether one is judging by Google queries, visibility in the blogging world, or otherwise, IBM is not leveraging its assets as well as it might. Microsoft, as an example, dominates the Google results for “hosted messaging,” and yet they’re concerned enough by Google to issue a statement questioning the viability of Google Apps. Meanwhile Amazon, an online retailer, has emerged as the leading purveyor of “On Demand” platform and storage technologies, which IBM’s sometime partner, sometime competitor Red Hat is in the process of fleshing that out with a legitimate software stack. And speaking of Amazon and Google, IBM – like many of its large enterprise software brethren – is increasingly dealing with sizable web entities that are built entirely on software that is not theirs.

So it’s all doom and gloom, then? Hardly.

IBM, of all of the larger firms, is perhaps the best equipped to seize the opportunity neatly described by their “On Demand” branding. Virtually every piece that’s required, they have. Software? Lots and lots of software. Hardware? Everything from mainframes to x86 servers. Services? Only a couple hundred thousand people. Hosting infrastructure? Check. The pieces, then, IBM has.

What’s needed now is an overriding, cross-divisional imperative to bring them together. Questions of revenue recognition and divisional branding and resource allocation need to take a back seat to the opportunity which, in case it wasn’t already obvious, is substantial. IBM’s done very well for itself the last few years focusing on the trees; now might be a good time to step back and look for the forest.