“Building web apps is not getting easier. The fragmentation of operating systems and browsers is getting worse, not better.”
- Fred Wilson, “Fragmentation”

With a few caveats, the above statement is obviously true.

We don’t see quite the same level of fragmentation that Wilson does; his property has five operating system and browser combinations with better than a 10% share, while we have only three. No platform has better than a 17% share there; we have two north of that figure. But if we split the metrics, our data shows the same trajectory. Here’s our browser system share for January of this year, for example.

No real surprises, at least for us. Firefox is dominant, IE a distant second with more Chrome traffic than Safari. But now look at the numbers from the past thirty days.

Things are much tighter. Firefox is still the leading browser, but its advantage has been eroded substantially by Chrome, which in the same span passed IE for second place. There are a variety of browser specific conclusions that might be drawn from this data, but what we’re interested in is this: we’re heading towards multiple platform parity. Witness the standard deviations.

For those of you who are unfamiliar with standard deviation, the concept is simple: it measures how far values are from the average of all of them. Practically speaking, that means “how widely distributed a sample is.” If the standard deviation is large, the values are all over the map. If the standard deviation is small, the differences between them are smaller.

The standard deviation in January? 16.11. The past thirty days? 11.49. What this means is that the differences between the marketshare of each browser is decreasing. The implications from a developer perspective are obvious: it’s easy to support one or two dominant platforms reliably. It’s much harder, however, to support four or more platforms that have roughly comparable adoption.

The differences from an operating system perspective are more slight. Here’s January of last year.

And the last thirty.

Some growth for Linux at the expense of – apparently – both Mac and Windows, but overall the delta is minimal. As the standard deviations indicate: 27.31 for January against a 26.21 the last month.

Still, slow as that process might be, the trajectory for operating systems is towards a flatter, more diverse landscape. And we’re not taking into account here the rise of new mobile platforms because the cut off for the above is platforms with at least 5% share. The iPad, as an example, has gone from 0% traffic in January to ~2% in less than 12 months. Android, meanwhile, is about 1%, a figure likely to rise once tablets running that platform begin hitting the market Q1/Q2 of 2011.

The data, then, concurs with Wilson: fragmentation – or parity, if you prefer that term – is accelerating. And actually, it’s a far bigger problem than those numbers indicate. True, web application development is (still) a problem. Also, as Wilson points out, developers and enterprises alike are increasingly vexed by the choice between native mobile development – Android, iOS, RIM, Windows 7, etc – versus web applications.

But traditional server side development is at least as challenged.

Start with languages. The days where businesses picked one of Java or .NET – or at least the perception that that was the case – are long gone [coverage]. Likewise, the era of LAMP being the default stack for web startups has come and gone. Enterprises are increasingly augmenting their officially sanctioned Java and .NET stacks with PHP, Python and Ruby. Today’s startups, meanwhile, have moved on from those to Clojure (e.g. BankSimple), Scala (e.g. Twitter) while returning to Javascript with a vengeance.

In between these languages/runtimes and the application sit a host of frameworks. From the established (e.g. Django, Rails, or the Zend Framework) to the up and coming (e.g. Lift, Node.js), frameworks are an additional abstraction developers are turning to to eke out incremental time to market gains, to maximize performance, to eliminate repetitive development, or all of the above. By my count, thirteen of the top fifteen Interesting repositories on Github are framework projects of one kind or another; the two exceptions are mirrors of the Git and Linux trees.

Even the data layer has not escaped this Cambrian explosion in diversity, to borrow Brian Aker’s metaphor. Time was when the question came to data persistence, the answer was a relational database. Today, we have, effectively, at least one option per workload type, from relational to document to columnar to key value store to graph to distributed file system.

Nor is hardware a straightforward selection. While the market has largely trended towards x86 from a server perspective, issues concerning power efficiency are beginning to raise questions about the viability of alternative server side chipsets such as ARM. The cloud, meanwhile, forces developers to compare the capex advantages offered by pay-as-you-go hardware with the potential opex benefits to owning your own gear.

We could keep going, but the conclusion is clear: it’s turtles all the way down. At every layer, developers have more choice. Which, as Barry Schwartz reminds us, is a mixed blessing at best. It’s easier to get building on LAMP, for example, than to evalute the relative merits of Node.js vs Twisted.

This explosion of choice will, inevitably, trigger a reaction, which is likely, in turn, to be reactionary. Consolidation will not eliminate choice, but it will reduce it as the lack of available oxygen eliminates or compels the merger of adjacent projects. In the meantime, however, life for the developer should be at once rich and complicated. The toolkit has never been fuller, which means that the benefits of improved tooling will in some circumstances be offset by the challenge of evaluating and selecting it. At least initially: over time and at scale, even marginal performance wins can add up.

Fragmentation is real, fragmentation is here, and fragmentation isn’t going anywhere. Adjust your strategies accordingly.

As a long term believer in application marketplaces, it has been rewarding to see the success that offerings like the Apple iTunes store are having. A billion apps makes a convincing argument, and all that.

But I admit to still being absolutely mystified by the absence of marketplaces that incorporate, you know, actual developers. Clearly I’m talking about something distinct from the mobile app stores: if I need a developer to help me configure an application for my iPhone, whoever built it has already failed miserably. For enterprise software, on the other hand, this is the expectation rather than the exception. What’s the last piece of software you rolled out for your business that didn’t require some setup?

Exactly.

And yet while we have perfectly good models for marketplace one-time or recurring payments, buyer and seller ratings, elastic pricing and so on, enterprise software vendors have yet to perceive the massive potential that exists in marketplaces. Instead, they leave the task of finding, vetting and engaging qualified resources to the customer. For some, this is no doubt a shortsighted attempt to protect their own services divisions: by introducing or participating in an efficient marketplace around the after-purchase product experience, vendor service offerings would potentially be at risk. Think what vendors could do, though, simply by facilitating connections between their customers and the developers and third parties that work around these products. eBay for the enterprise undersells the concept, in my view.

Most bizarre is how many of the pieces some of the would-be marketplace providers already have, which are simply waiting on someone who can see the potential.

Consider Microsoft’s Web Platform Installer and Web Application Gallery, for instance. According to a release we were sent this week, the WPI has been downloaded 1.5 million times while users have downloaded 100,000 applications. Setting aside the delta between those numbers, which is admittedly curious, it’s difficult to argue that this initiative has been anything but successful. In spite of the fact that it does little to tackle the last mile of development and implementation: the connection of application users to qualified human resources.

Of the pieces the marketplace I envision would need, an Application Repository, Hardware, Identity Management system, Jobs Marketplace, and a Payment System, Microsoft’s already got one of the hardest to construct: the repository. Azure could be leveraged for the hardware, Geneva for identity, and they have to have some payments infrastructure sitting around somewhere, as long as they’ve been talking about it. Leaving jobs, which they could either build or buy relatively simply, I should think.

Not that Microsoft’s alone in its ability to target this opportunity, of course: there are half a dozen large vendors that could. Even Amazon, not an application vendor, has most of the requisite pieces.

Apple’s iTunes store has demonstrated quite convincingly that when you lower the barriers to application discovery and acquisition, volume is the inevitable result. Which is why it’s surprising that vendors looking to increase their volume sales aren’t doing everything in their power to reduce the friction of the same process with their enterprise wares.

Sooner or later, of course, someone will be the Apple of the enterprise market, and if they get it even half right they’ll be successful. Which in turn will inspire competition, just as iTunes led to the Blackberry Application Marketplace.

We’ll have a battle of the marketplaces, in other words. The only question is when, and who’s going to be first and who’s going to be second.

Who knows? Maybe it’ll be Sun.

Disclosure: Microsoft and Sun are RedMonk customers, while Amazon and Apple are not.

To be perfectly honest, I can think of several things I’d rather do than deconstruct yet another Linux vs OpenSolaris/Solaris flamewar. Including having a few of my fingernails pulled out. But given the volume of inbound requests for comment, both public and private, I feel obligated to comment in some capacity.

That said, this discussion is largely a waste of time for both sides, so unless you’re the kind of person that slows to observe traffic accidents in some detail, this is probably one to skip. With that, the Q&A.

Q: How about we begin with the usual statements of disclosure.
A: Of course. This discussion is fraught with such considerations; from the OpenSolaris/Solaris side, Sun is a RedMonk customer and I know personally – and respect – many of the developers and marketers of the technology past and present. On the Linux side of the equation, IBM – the employer of several of those commenting – is a RedMonk customer, as are other Linux oriented businesses such as Canonical. In addition to knowing and respecting many of the employees of said firms involved with the Linux ecosystem, I also know and respect the folks from the Linux Foundation who are also have their part to play in this “debate.” So I’m getting it from both sides.

Lastly, Linux is the operating system of choice for the RedMonk production server, as well as my laptop and workstation respectively.

Q: Before we jump in, why is this all a waste of time?
A: Because it is my belief – like Savio’s – that competition is generally good, and that Linux is good in that respect for Solaris and vice versa. Making these dustups pointless, like pretty much every other flamewar.

Q: So take us back to the beginning; how did all of this start?
A: Going back to the very beginning would take forever, so I’ll restrict myself to my abridged version – which may differ, please note, from those of members of the Linux or OpenSolaris communities. Your mileage may vary, as always.

The gist of the situation, as far as I’m concerned, is this: OpenSolaris, like a great many open source projects, has internal factions that do not always agree with each other. When discussing the hiring of Ian Murdock, I characterized this as a new school / old school problem. Views of the nature of the divide may differ, of course, but even a cursory review of the OpenSolaris lists will reveal deep differences of opinion concerning the OpenSolaris project, Sun’s relationship to it, and the role of the OpenSolaris distribution called Indiana.

If you’re curious about the gory details of the latter dispute – that of the role of the project termed Indiana – I’ve got excellent news for you: I’ve written them all up here. Excellent for me, as well, because I don’t need to rehash it. Suffice it to say that the idea of anointing Project Indiana with the OpenSolaris moniker was anathema to some. To others, it was the process of naming that was distasteful more than the naming itself. And to still others – myself among them – it was merely the logical decision to make, given the lack of a quote unquote reference distribution for the project designated OpenSolaris.

Ultimately, per Sun’s wishes, Indiana became OpenSolaris and – predictably – the elements within the community that didn’t care for the name, the process, or both, were furious. Just as unsurprisingly, some members walked out the door as a result, the most notable defection probably being Roy Fielding, whose public resignation from the OpenSolaris Community has been pure fodder for internal critics and Linux advocates alike.

Q: How so?
A: Well, let’s take this out of the realm of the abstract and look at two in particular. From Michael Dolan, we have “‘I told you so’ in order? Roy Fielding resigns from OpenSolaris.” In that, Michael makes a couple of assertions. First, he argues that “Sun is not an open source community or development player.” Second, that nearly three years into the project, development is still done behind the Sun firewall, contributions require the approval of a Sun engineer, contributors have to sign a Joint Copyright Agreement, and that there are essential parts of the operating system that are not available under the CDDL license. Lastly that anyone arguing that Sun is “great, open, etc.” is “brainwashed.”

The Linux Foundation’s Amanda McPherson was no less critical, saying:

This is why the L in Lamp is Linux and Literal. Linux has the broadest and most active development community of any open source project. Linux has over 3,000 developers contributing to just the kernel in the last year, while Sun has announced 70 non-Sun engineers. (This doesn’t even account for the vibrant development communities around Linux community distributions, desktop toolkits and other upstream projects outside of the kernel.)

The Linux development community keeps getting stronger while Sun’s is seeing public defections of some of its most important members due to Sun’s control.

You getting the feeling that the Linux folks don’t have much love for Sun, Solaris or OpenSolaris? Because I am.

Q: I’m not even sure where to start, but how much of that is accurate?
A: Setting aside the question of whether or not Sun is “great” or “good” – which is a pointless question to me when it concerns publicly held companies – let’s tackle the points I believe to be true. First, most if not all of the claims made with regard to the openness of the OpenSolaris development process are true, to the best of my knowledge. Second, the number of external contributors to Linux – which is approximately all of them – dwarfs those contributing to OpenSolaris.

Q: So Sun is not an open source company?
A: To me, that question, and much of the discussion above, boils down to a philosophical question: are Linux and MySQL both open source? Or do you believe that anything short of the Linux model does not qualify? That was, in fact, the question I asked Michael in a comment. His reply was this:

I do not consider MySQL to be an open source development community which to its credit, MySQL has never claimed; unlike Sun/OpenSolaris.

While noting that the response doesn’t actually answer the question, it does point to the fundamental disconnect between our two viewpoints: I’m judging open source by the availability and licensing of the code, while Michael, Amanda and other critics seem to prefer a community based metric. As should be expected, since it favors their platform of choice.

For my part, I believe that MySQL is in fact an open source company and an open source project, in spite of the fact that the development of the codebase is not open but rather done entirely (or nearly so) by MySQL employees. So, assuming that Amanda is correct and that there are 70 external OpenSolaris engineers versus Linux’s 3K, that still leaves OpenSolaris as “more open” than MySQL. Whatever that means.

Logically, then, if MySQL is open, and OpenSolaris more open still, I’m fundamentally unable to conclude that Sun is not an open source firm. But then again, maybe I’m just brainwashed.

For what it’s worth, however, Roy’s own resignation acknowledges that this model is in fact open source:

Sun should move on, dissolve the charter that it currently ignores, and adopt the governing style of MySQL. That company doesn’t pretend to let their community participate in decisions, and yet they still manage to satisfy most of their users. Let everyone else go back to writing code/documentation for hire.

There’s nothing particularly wrong with that choice — it is a perfectly valid open source model for corporations that don’t need active community participation. IMO, the resulting code tends to suck a lot more than community-driven projects, but it is still open source.

His problem, then, isn’t fundamentally with the model – as is the case with Amanda, Michael, and others – but rather the fact that he feels he was mislead as to the end goal of OpenSolaris.

Which is obviously his right.

Q: But is he right?
A: Without knowing who promised what to him and when, I can’t say one way or another, but I don’t doubt that Sun’s stance vis a vis the OpenSolaris asset has changed. Substantially.

But that does not surprise me, particularly.

Q: But how is that different than Linux?
A: Frankly, I think the comparisons to Linux are misplaced outside of a technical context. The projects are governed by different licenses, developed under different models, and are at significantly different points in their respective lifecycles. Comparing an 18 year old project developed by a consortium to a 3 year old project maintained principally by a single organization is the definition of apples to oranges, in my book. So too does Apache have more contributors than nginx; I’m not sure this tells us much besides the fact that one is younger than the other.

Q: Is it me, or do these issues boil down to control?
A: It’s not you. Ultimately, the critics – within the project and without – point to the above as mere symptoms of an inability to relinquish control.

Q: Is there truth to that assertion?
A: Sure. Sun has been accused on multiple occasions in the past of refusing to let go. See, for example, the dispute with Apache on the field of use restrictions, the long running but recently resolved divide between IBM and Sun concerning OpenOffice.org, and so on. None of those situations, nor the current Solaris flareup, were particularly straightforward, but I’m on record – with the Apache situation in particular – as disagreeing with that reluctance. But neither would I contend, as some have, that the issue is simple and that the answer is always open development. Particularly when we’re talking about a core asset of a commercial organization, as opposed to that of a Finnish graduate student.

Q: To return to it, what about the naming issue? Isn’t that proof that Sun has acted in bad faith?
A: Well, my flip answer would be to simply point you over to Mark Pilgrim’s comment over on Tim Bray’s piece, which reminds us – as only Mark can – that naming disputes are more or less par for the course in the open source world.

But to answer the question more seriously, do I understand why people are upset? Of course. But do I think it’s ridiculous that Sun should want to assert its rights with respect to such an important brand? No. And more to the point, I think there have been individuals within the community on both sides of the Sun/anti-Sun divide that have been terribly nonconstructive in their conduct. I’ve lost track of how many calls on list there have been for perspective, understanding and peace.

In that respect, it’s just like virtually every Linux distribution I know.

Q: Speaking of Linux, why does that community seem so concerned with the doings of OpenSolaris?
A: Well, the two operating systems are competitive in a variety of contexts, and there is substantial bad blood on both sides of the divide. All’s fair in love and war, as they say, and for some years it’s been war between the two technologies.

What I do find interesting, however, is that Linux advocates will simultaneously tell me that OpenSolaris and Solaris are dead technologies, representing no further threat, going nowhere. And yet they’ll expend the kind of energy attacking that I doubt would come into play if the dispute were within BSD or Minix.

Doth the lady protest too much? Mayhap.

Q: So where does Sun go from here?
A: If the question is where they will go, my answer is that I’m not sure. Sun has asserted certain rights, and debates are currently raging as to what that means for the community at large.

Many of the Solaris and OpenSolaris engineers remain passionately in favor of truly open development, but candidly, Michael is right to point out that the lack of greater progress nearly three years into the project can only indicate a lack of a commitment to that end.

It may well be that Roy is right, and that Sun should move OpenSolaris towards a MySQL model of development, a scenario that many find abhorrent but that personally I’d be fine with. It’s also possible that with this issue behind the community, and some of the diametrically opposed philosophies departed, the community will be less prone to internal strife and make better progress.

Either way, the community will have its say, but so will Sun. And I don’t have an issue with that, as long as it makes a decision and sets expectations appropriately.

BitNami Trac Installer

Originally uploaded by sogrady

Thanks to old friend Stephe Walli, I had the pleasure of meeting with Bitrock CEO Erica Brescia bright and not too early (it was the day after our Bday party, after all) last Thursday morning. What I expected based on the initial introduction was a reasonably interesting packaging story, but candidly, little more.

What I heard was something at once broader in scope and more compelling: a legitimate network enabled application installation, management and monitoring story. One that’s cross-platform (Linux, Microsoft, OS X, and apparently Solaris as well) no less.

For those of you that have followed my Quixotic attempts to drum up interest in a network application with the ability to refine and evolve the application installation and management experience, Bitrock is worth a look as it provides several of the fundamental pieces (package management, monitoring, etc) one would need to construct such an offering.

The basic value proposition, then, to an ISV is that Bitrock can package your application such that it’s suitable for cross-platform deployment, thus freeing application vendors from the burden of delivering multiple builds themselves. Examples of their application stacks can be found here.

As an aside, when I say cross-platform, I don’t mean Adobe AIR-style “sure we’re cross-platform – you know, Mac and Windows,” but rather truly cross-platform. Both dominant commercial distributions, Solaris and Linux. Even better, the Linux support is not limited to the dominant commercial distributions, in Red Hat and SuSE, but is inclusive of Debian, Ubuntu and other commercial and non-commercial variants.

Bitrock has, in other words, replicated a portion of the basic package management functionality and dependency handling common to Linux but absent from OS X and Windows. Other similarly targeted efforts include the pre-tested and certified stacks sold by Sourcelabs and SpikeSource, or the virtual appliances championed by VMWare and partners.

By way of comparison, Bitrock lacks the central repository GUI common to distributions like Ubuntu and the comprehensiveness of Debian’s 25K+ packages, but it’s cross-platform while the package management approaches within Linux remain not only operating system specific (with rare exceptions like Nexenta) but distribution specific. As are the respective packaging formats.

Bitrock’s flexibility, however, does not come without a price. The primary cost of appears to be a lack of visibility into the existing resources, and an inability to manage them outside of application specific silos. While I was able to install a Bitrock-based BitNami Trac stack on Ubuntu Gutsy moments ago (see inset), the installer didn’t look for existing Apache, Python instances or other Trac requirements, instead dropping in its own. Some of these resources – Python2.5, specifically – were also left behind when the uninstaller had finished its work.

That’s the bad news.

The good news is that Trac was up and running in about 30 seconds, in 6 clicks – including an initial project setup. There are trade-offs, clearly, but for certain constituencies Bitrock’s abstraction of the installation process will be welcome. Particularly on operating systems like OS X and Windows that do not have centralized dependency handling.

Much of a prospective user’s appetite for Bitrock’s brand of packaging depends on context: their operating system, their skill level, their application needs, and so on. It’s not really aimed at a user like myself, who is content to leave the application installation, configuration and management process in the capable hands of apt. But on a volume basis, there are far more users not like me than there are like me – if only because Windows is still dominant in desktop and server contexts, and BitRock packages are well suited for the less technical and/or those that do not have systems like apt available to them.

With application installation a solved problem in some contexts, however, a product limited to that space would be of limited interest. Fortunately for BitRock, the installer is the least of what they’ve built, in my opinion (though likely not the developers’). Far more compelling to me is the network infrastructure behind the prebuilt stacks they make available.

Like many applications, including Flash or Java SE, the BitRock installer has the ability to “phone home” basic data: version information, for example. Which is nice. But certainly not differentiating.

What does potentially set BitRock apart, however, is the other telemetry that can be recovered from the client: everything from the expected installation data to useful systems management like information such as available disk space.

This ability to connect a simply packaged application back to a central network repository opens interesting new doors for a variety of audiences. What would it mean to ISVs, for example, to have active connections to and visibility of not just to their own application, but the dependencies it relies on? Or to be able to answer the “my server doesn’t work” question by pointing out that the machine in question is out of storage?

Or, nearer and dearer to my heart, what kind of developer ecosystem could be assembled around these connected application stacks?

As much as the potential utility of the telemetry impresses, however, it also has potentially profound ramifications vis a vis privacy. BitRock is apparently well aware of this, and devotes significant attention to safeguarding their install base. Good news, as I believe that’s a third rail issue for telemetry oriented firms. Lose the trust, once, and you’ll be working forever to get it back.

My one criticism in that area was with the delegation of control. Like pre-iTunes DRM providers, BitRock seems somewhat content to let ISVs implement that technologies as they see fit. Not only does this potentially jeopardize the consistency of the user experience, it also opens up BitRock to negative feedback for decisions that their ISV customers make. To wit, while the restrictions on early DRM offerings were a manifestation of outdated and nonsensical RIAA business decisions, that didn’t prevent users from blaming Microsoft and others for them. My own view is that BitRock would be best served by taking a strong pro-user stance, even at the risk of upsetting their customers, because as Apple’s iTunes success has proven the perception of being user friendly has substantial long term benefits.

It’s also worth noting that issues of telemetry are highly dependent on context: for many major enterprises, it’s a non-starter, while businesses further down the spectrum might be convinced if the returned value can be made immediately apparent.

Consider the consumer experience that many of us are familiar with: Internet Explorer, Google Desktop, and other desktop applications will occasionally ask for permission to share information about a crash or general usage with the developers. But there’s no instant gratification for users; they’re required to trust the data is put to good use. BitRock, on the other hand, can provide immediate reporting and aggregated data as an incentive to permit the return of application data to their network.

In any event, I’m looking forward to where the folks at BitRock take things; the convergence of application installation and network functionality is a trend that I’ve championed for some time.

“The network is the computer” – Sun Microsystems

I concur. So where is it?

In the fine tradition of Good News/Bad News wrapups from the Sun analyst conference comes today’s note.

Sun’s been positive at this, their annual collecting of us analyst types, and from this vantage point they have reason to be. Though it hasn’t set the world on fire, progress towards righting the financial ship is evident. They went after – and got – Ian Murdock to effect change on Solaris. Which they also got. Solaris, via Indiana, is now accessible to audiences that would not have considered it previously. Which was timely, because two of the larger hardware vendors in Dell and IBM both decided to ship (and support it). As if that wasn’t enough, IBM also agreed to work with Sun on the OpenOffice.org project, an outcome that seemed doubtful once upon a time. And then there’s the pending MySQL transaction, which will be in my view profoundly transformative. Hell, even El Reg is calling them the premier open source vendor.

Clearly, the Sun folks have been busy, and in spite of forks in the eye like Dalvik, have generally had a year to be proud of. But lest they feel inclined to rest on their laurels, let’s ponder the future for a bit.

Will said future, for example, include a computing landscape largely dominated by four or five big computers – Amazon, Google, Microsoft, and so on? And if it does, will Sun be one of those big computers, or merely a supplier?

Narrowly focused efforts like Network.com aside, Sun has to date shown little ambition to be the former. Which would worry me, because success with the latter assumes to some extent a reversal of the general preference among the big computer folks for non-premium, whitebox hardware. If there are going to be four or five big computers, and you don’t have a history of selling into them at volume absent significant subsidies, I’d consider that an issue.

As I’ve been saying publicly and privately for some time, I think it’s important – vitally so, in fact – that the vendor that coined the “network is the computer” tagline offer a network of its own.

Call it what you will – Sun CTO Greg Papadopoulos does not care for the term “cloud,” preferring instead the venerable “network,” – it’s a trend with clear momentum and direction. Consider just the latest examples of EnterpriseDB, Zmanda, Red Hat and – yes – MySQL.

Success in technology is (typically) a function of volume, which is in turn a function of the barriers to entry. It’s all about barriers to entry, remember. Consider Solaris: the open sourcing of the codebase removed one barrier to entry. The changes wrought in Indiana yet another.

But the availability of a Sun cloud offering would remove a significant barrier to entry not only for Solaris, but the entirety of Sun’s hardware and software portfolio. Which is necessary, in my view, given the stated ambition for Sun to sell more directly and the continuing problem the channel represents to would be customers. What’s more direct, after all, than the type of credit card enabled push button procurement that Amazon’s EC2 and S3 offer?

In his closing remarks at the conference, Sun CEO Jonathan Schwartz told the gathered analysts to “watch this space in the next 12 months,” and I will dutifully keep my eyes peeled. Maybe between Project Caroline, Project Kenai, and Network.com we’ll begin to see some cloud infrastructure emerge. It would be a shame, after all, for the firm that first saw the potential for the network to become the computer not to realize its original vision, while others cement their future importance doing so.

Disclosure: EnterpriseDB, IBM, Microsoft, MySQL and Sun are all RedMonk customers. Amazon, Google, Red Hat, and Zmanda are not.

Given my travel schedule of late (the very same one that prompted more than one “are you dead?” pings), I’m operating on a bit of a time delay, so if you’re wondering whether something has gone terribly wrong considering that I’m covering “news” dating back to early November, do not adjust your dial. I’ve just been that busy.

But I could not let the Red Hat news pass without comment. Because the November 7th briefing call overlapped with the IBM conference I was attending (more on that one later), I almost skipped the call but fortunately was tipped to its significance in the nick of time by a commenter in #redmonk. Eschewing lunch, I retreated to my room and dialed in for the latest on Red Hat’s plans. I was not disappointed: Red Hat’s news transcended the usual pedestrian product updates. I’m hesistant to call them revolutionary, as none of it is precisely new – particularly from a technical perspective, but it was at least worth the price of admission. Though that, admittedly, was zero.

To explore the news in more detail, let’s try a Q&A.

Q: Before we continue, anything to disclose?
A: Well, Red Hat is not a RedMonk customer, but certain competitors of Red Hat are, including Canonical, Microsoft and Sun. As for the Amazon component of the news, they are not a customer but our production backup solution is based on their S3 offering. I think that’s about it.

Q: For those that missed it, can you summarize the news?
A: Well, there were a couple of releases accompanying Red Hat’s call on the 7th, but the two most interesting pieces of news as far as I’m concerned were the announcement of its Appliance Operating System (AOS) and the revelation that Red Hat would be available on top of Amazon’s EC2 platform.

Q: What is your expectation of the impact of these developments?
A: Before we get to that, it’s worth considering what Red Hat itself expects. Senor Shankland apparently heard the same thing I did on the call, as he quotes Paul Cormier (EVP worldwide engineering) as saying the following: “We will more than double our market share to power more than 50 percent of the world’s servers by 2015.” It’s the lack of qualifiers there that’s of particular interest. He’s not talking about specific operating system markets, or workloads, or other contexts that would play to Red Hat’s strengths; he’s seemingly talking about better than half of all servers, anywhere. Aggressive, despite the firm’s admitted dominance of the commercial Linux marketplace, especially here in the US. Windows, after all, is still growing apace in spite of the best efforts of a variety of competitors, Linux-oriented and otherwise.

Q: Let’s dig into some of the details, then. Let’s start from the back: what’s the significance of the Amazon/EC2 partnership?
A: While some are inclined to dismiss EC2 and other competitive offerings as little more than tweaked hosting, I’m convinced that the model represents the – or at least a – future of hardware consumption. In awarding the Amazon folks my technical achievement award for 2006, I outlined the promise of Hardware-as-a-Service (HaaS) as follows:

Software-as-a-Service is – somewhat justifiably – all the rage these days, with even mainstream customers increasingly comfortable using online services to make up for the shortcomings of rich client systems. That they have succeeded to the degree that they have is proof positive that convenience – low barriers to entry, in RedMonk-speak – wins more often than it won’t. Software-as-a-Service applications, after all, have serious limitations when compared to their client side brethren, but they’re just so easy to start using.

So why should we doubt that the hardware equivalent of SaaS has similar potential? If the latency between “I need storage” or “I need a server” is a credit card and downloading and installing something like JungleDisk, well, how could that not be of interest?

In other words, EC2 represents an extremely low friction solution to the problem of hardware provisioning.

Q: Why has it flown so far beneath the radar, then?
A: A variety of reasons, including the fact that the toolsets available for the Xen-based platform at launch time were, to put it kindly, basic. But undoubtedly questions of commercial support are a factor; without Red Hat, EC2 was relegated to serving a minority of the enterprise commerical Linux market, because that’s a market more or less owned by Red Hat.

This announcement, of course, changes that, and is therefore a potential win not just for Red Hat but for Amazon as well. The former is now able to expand its addressable market; at worst Red Hat is now an option for the startups and other early adopters flocking to EC2, at best it’s one of the first commercial players to offer customers of all shapes and sizes the ability to embrace a next generation architectural model, whether that’s on a tactical or strategic basis.

As for Amazon, well, obviously they’re viable players in markets where they were not previously.

Q: So the news here is purely technical?
A: No indeed. The economics are, if anything, more interesting. While the math is not likely to be universally in favor of the Cloud – Red Hat’s designation for the offering – or traditional models, it’s certain that the former introduces pricing flexibility that was previously absent. In addition to a monthly fee, Red Hat will charge hourly rates – at a premium over the vanilla EC2 offerings – along with bandwidth fees. Will this be preferable in all situations? Hardly. But it does give potential Red Hat customers a pay-as-you-go offering to be deployed alongside of, or in certain cases in lieu of, traditional models. It’s also encouraging that some of the relatively artificial distinctions in enterprise software pricing – per socket, per CPU, etc – will have more value based alternatives to compete with. The collapsing of hardware and software pricing will be an interesting trend to watch going forward.

Q: Pricing, then, is likely to be the driving factor in when or if customers choose the Cloud offering?
A: No. The nature of the workload must also be considered, because for all of the advantages of EC2 from a flexibility standpoint, it does not come without a cost. Unlike machines deployed locally, as an example, the virtual images located in Amazon’s datacenters will have a higher latency to access. It’s difficult to imagine, as an example, using a remote EC2 image as a database slave for production-type workloads. But for each use case for which EC2 is not a viable candidate, there’s likely to be another for which it is eminently suitable. A reasonable expectation is that forward thinking larger institutions will consume at first a small percentage of cloud based services as an experiment to determine where and for what they are appropriate, then up their commitments as their comfort levels with the technology rise.

Q: Changing tacks for a moment, what can you tell us about the AOS news?
A: Very little thus far, as due to my schedule of late I haven’t managed to connect directly with Red Hat on the subject, but it seems that Red Hat is targeting much the same opportunity that rPath and Ubuntu’s JEOS version are: a platform version optimized for a particular use case, be that virtualization or something else.

The idea behind these technologies is simple: general purpose operating systems like RHEL, Solaris or Windows bring with them significant advantages in simplifying the certification, maintenance, and support problems, but bring with them significant disadvantages. Most obviously, they suffer from the classic “Jack of All Trades is the Master of None” problem. As an example, what is the purpose of including software dedicated to specific hardware support if the platform won’t actually be running on hardware, as is the case in virtualization settings? These and similar arguments are trotted out by advocates of virtual appliances and custom operating systems, but while I acknowledge the logic I have serious concerns about the model’s sustainability.

Q: Sustainability in what sense?
A: Well, think of it like Kant’s Categorical Imperative, which boiled down essentially contends that individual actions may become problematic in aggregate. One person littering, as an example, is of minor consequence. A thousand people littering, on the other hand, is a serious problem.

Such is the case, to me, with virtual appliances. Just because it makes sense to embrace a virtual appliance in for an application does not mean that it’s appropriate to adopt it for applications, pluarl. For one, you’re effectively introducing a 1:1 ratio between the applications and operating systems you support, as each customized operating system instance is different from the next, which bucks the long term trend towards general purpose operating systems. For another, you’re likely to be increasingly relying on the provider of an application for operating system type support, which they may or may not be qualified for.

All of that said, however, Red Hat and Ubuntu may be making progress towards mitigating some of the concerns.

Q: How so?
A: Well, in Ubuntu’s case it comes down to focus. Rather than support a myriad of operating system variations, they appear to have focused on a particular use case – virtualization – which does indeed benefit from a customization.

Red Hat, on the other hand, seems to be taking the approach that it will allow application providers to build as they see fit, and yet remain certified for RHEL. The latter distinction is the important piece; if vendors can certify once for both RHEL and AOS flavors, and customers are supported with equal facility in either case, the case is very compelling.

I’m skeptical that there will be no impacts to support and service, but it’s a solid move on Red Hat’s part if they can pull it off.

Q: To get back to the original question, what is your assessment of the potential impact?
A: It’s early, but November’s news was a good indication that innovation amongst economic models and deployment scenarios is still possible. Not to dismiss the importance of some of the new features of RHEL 5.1, but over the longer term I think AOS and the Cloud offering are far more important than mere bells and whistles, because they make Red Hat a competitor in markets where its penetration is currently low. Even if its success in those areas, then, is minimal, the news remains very significant.

“Tis but thy name that is mine enemie.
Whats Mountague? It is nor hand nor foote,
Nor arme, nor face, nor any other part.
Whats in a name? That which we call a Rose,
By any other name would smell as sweet” – William Shakespeare

Brilliant as the bard may have been, my suspicion is that the OpenSolaris community would beg to differ with this particular line of inquiry. At least, if one is to judge by the discussions currently raging.

This debate, ultimately, can be distilled down to a simple question of grammar: is OpenSolaris an adjective, or a noun?

At the present time, OpenSolaris is the former. There is an OpenSolaris project, an OpenSolaris community, and there are OpenSolaris related distributions, but if you visit this page you will not find a tangible “thing” to download termed “OpenSolaris.”

A successful execution on the Project Indiana vision, however, would prompt the question: should it be a noun as well? To explore that, let’s turn to the Q&A.

Q: Let’s get the disclosures out of the way first…
A: Certainly. Sun, the organization where the original Solaris code was produced, is a RedMonk client. More particularly, I know and have great respect for a variety of Solaris and OpenSolaris community members that are of different minds on this question. Otherwise, a variety of Solaris and OpenSolaris competitors are also RedMonk clients, including Canonical, IBM, and Microsoft. That’s it, I think.

Q: For those that don’t follow the OpenSolaris/Solaris worlds particularly closely, can you give us a quick primer on Project Indiana?
A: Fortunately, I’ve already done a Q&A on the subject, which you can find here. The short version, though, is that Indiana is a project intended to result in a binary distribution of OpenSolaris technologies to be released on a regular timeframe, and which will include a variety of improvements such as package management aimed at making it more accessible.

Q: So will the resulting binary distribution carry the name OpenSolaris?
A: That, ultimately, is the $64,000 question. As you might expect, there are a variety of opinions on the matter. Critics of this idea contend that it will unfairly advantage the Indiana bits, wounding – perhaps critically – existing distributions such as BeleniX, Nexenta et al in the process. Some go on to conclude that the likely fallout from the demise of OpenSolaris distributions would be devastating to the OpenSolaris community, spawning disaffected groups of betrayed developers that would depart never to return. At the opposite end of the spectrum, those favoring the branding of Indiana as OpenSolaris point instead to the potential for user confusion, where newcomers to the community are forced to navigate between unfamiliar choices because there is no simple OpenSolaris downloadable image. In between those viewpoints are some that would favor a compromise approach, either by the usage of OpenSolaris as a modifier in the distribution name or, in some cases, by the explicit inclusion of Sun’s brand (i.e. Sun’s OpenSolaris).

Q: Of the anti-OpenSolaris-as-a-noun contingent, are there objections beyond the impact to existing distributions?
A: Yes indeed. While the question of distribution futures seem to be the paramount concern, there are many other issues involved. Trademark, for one. If the name OpenSolaris is ultimately applied to the output of Indiana, the question goes, how would other distributions or related technologies – some of which would undoubtedly be competitive – be permitted to use the term, or not? There are also, as could have been predicted, issues with respect to Sun’s relationship with the OpenSolaris community. For all that it’s dependent on Sun – the overwhelming majority of OpenSolaris developers, after all, are employed by Sun – the relationship between the corporation and the project can be prickly at times. Understandably, the open source project would prefer to not have terms dictated to it. Equally understandably, Sun has interests – both product and trademark – at stake. In as much as those needs align, things have the ability to function smoothly, but there is periodic friction.

Q: And where do you personally stand on the issue?
A: Well, with the necessary if tedious qualification that I do not presume to instruct a community of which I am not a part in how to conduct itself, and speak only for myself, my own view is that both Sun and the OpenSolaris project are best served by having a binary distribution branded OpenSolaris.

Q: Why?
A: Simply put, it’s about users. If I were a member of the OpenSolaris project, my primary mission in life would be to drive adoption of the technology using any and all means necessary. Well, almost any. Part of that response, obviously, must be technical improvement and innovation. Two items which are, not coincidentally, a big part of the Indiana mandate. But that’s only one part of the equation; there is much to adoption beyond the technology. As things stand now, the current array of options is at once bewildering and intimidating to new users. Consider the experience for someone who hears about “this open source Solaris thing.” They visit downloads, and are required to choose between the following:

• Solaris Express Community Edition
• Solaris Express Developer Edition
• BeleniX
• MartUX mBE
• NexentaOS
• SchilliX

In the words of Austin Milbarge: “and how.”

But surely, you ask, the descriptions are sufficient to educate users as to their choices? Well, even if one assumes (where I would not) that users have the patience to successfully navigate the array of options available to them, the descriptions themselves unhelpfully leverage OpenSolaris terms, such as “Nevada” or “/opt/csw.” More problematically, those showing up looking for OpenSolaris are likely to be perplexed when trying to decide amongst distributions that variously claim inclusion of the OpenSolaris “source,” “source base,” “bits,” “kernel,” and “runtime.”

Suboptimal, I think most would agree.

Q: And what of the distributions?
A: Well, to begin with, I think it’s a bit fatalistic to predict that the mere application of a name to the Indiana bits dooms them permanently. Not to mention that whatever Indiana ends up being called, they’ll be forced to compete and adapt to it regardless of what it’s called. If I were behind one of the existing OpenSolaris distributions, I’d be bending all of my efforts to differentiating against what will be Indiana. I might aim for a JEOS-style distro optimized for virtualized scenarios. Or perhaps a mobile and embedded flavor. Even as is, a distribution like Nexenta still has a considerable advantage over the forthcoming Indiana bits, as it is able to leverage existing packages and packaging resources while Indiana – according to my current understanding – will regrettably be forced to reinvent that particular wheel, package by package.

But more to the point, I don’t perceive any of these distributions as entrenched enough to defend at the expense of the user experience. Put another way, the users would be my top priority: the technologies, branding, and so on should be in service of them – not for its own sake.

Q: Implicit in that statement, of course, is the assumption that a multiple distribution world necessarily negatively impacts users…
A: Not quite. The Linux world demonstrates amply the advantages – and disadvantages – to a multiple distribution environment. What I am arguing, instead, is that the OpenSolaris/Solaris world is distinct from that environment, and cannot tolerate the lack of an OpenSolaris branded reference platform, as the Linux world can.

Q: Why is that?
A: A variety of reasons, but principally it’s because Linux and Solaris are really apples to oranges. Obviously they are both operating systems, and competitive ones at that, but the nature of their communities is very different. I would be the last one to argue, as some critics have, that the OpenSolaris project isn’t truly open source or simply open, but the reality at the current time is that vast majority of the development is done by a single organization: Sun. This is a stark contrast with the Linux world, where the development – not to mention brand value – is ammortized across multiple organizations. The Linux and OpenSolaris “brands,” therefore, are very different animals, and what works for Linux is not guaranteed to work for OpenSolaris and vice versa.

The Linux brand had both the opportunity to build slowly and the benefit of being a mutual focus for otherwise competitive organizations (e.g. IBM & Oracle). Solaris, IMO, doesn’t really have either of those.

In one recent conversation on the subject, someone pointed out to me that OpenSolaris is not behind Linux at all in its community development, as Debian only emerged 2 or 3 years after Linux did. To which I say, true, but that was 15 years ago; OpenSolaris does not have the luxury, as Linux did, of funtioning in a relative vacuum (yes, I know about FreeBSD et al, that’s why I used relative) with respect to open source operating system competition.

Q: In a sentence, how does allowing the Indiana bits to use the OpenSolaris name make life easier for users?
A: In simple fashion. If that’s permitted, any user that hears about “open source Solaris” can visit opensolaris.org (which needs a fair amount of work, while I’m on the subject), click “download” and pick a downloadable ISO called “OpenSolaris.” As trivial as that sounds, it’s vital to win over borderline users.

Q: But what’s in a name? Why not just call the distribution “Indiana” or something equally random? Ubuntu, after all, isn’t called Linux…
A: Well, see the comments on Linux above, but consider the educational challenge that represents. Users show up looking for open source Solaris and download something called…Indiana? Which is listed alongside of half a dozen other distributions they’ve never heard of? While you’re educating them on what the various options are and what they mean, they’ve walked out the door and you’re talking to dead air. The story needs to be simple.

Q: What of the claims that the assignment of an exclusive right to brand OpenSolaris to the Indiana bits will irreparably damage the fledgling OpenSolaris community?
A: While I understand them, and have a great deal of respect for some of those that harbor such concerns, I don’t personally subscribe to that notion. I’d readily concede that there would be initial pain for some of the distributions if they were forced to compete with an OpenSolaris branded distribution, I believe that the long term influx of new users would ultimately be of benefit to everyone. The rising tide lifts all boats, and so on. It’s easy to imagine a scenario, for example, where I show up to opensolaris.org as someone completely unfamiliar with the technology, download the OpenSolaris distribution and like what I see, yet pine over the lack of GNU tooks, apt, and Debian packages: wherein lies an opportunity for Nexenta. Maybe I make the jump straight to Nexenta today, but just as likely I can’t navigate the existing options and default back to Linux.

Q: Besides, I thought choice was good? Isn’t community important?
A: Well, that question presupposes that choice and community are the same thing, and that’s a leap, in my experience. It is true, certainly, that choice is generally understood to be welcome: the alternative, after all, being the lock-in that users instinctually fear. With good reason.

But it is also true that choice has negative consequences. As r0ml explains so eloquently in this deck (PDF warning), choice means that “decisions require more effort, mistakes are more likely, and blame is more severe.” It’s the first point that I see as the real concern with respect to OpenSolaris, but they’re all relevant.

So while it’s true that the biggest community wins – at least as far as I’m concerned – it’s not necessarily true that the biggest community is the one offering the most choices. In some cases, in fact, the reverse might even be true. I don’t want to choose between different flavors of WordPress, for example, unless there’s a compelling reason to do so – as is true with WordPress MU.

Q: Well, what of the trademark concerns?
A: That would indeed be a critical question, because while as stated above I’m for a singular branded OpenSolaris distribution, granting it exclusive license as an adjective would be – to me – a serious problem. Fortunately, however, it’s my understanding that the Sun folks have worked things out such that trademark can be extended to outside projects, with the hows to be worked out in future.

Q: Anything more to say?
A: Well, there’s a great deal that I’ve glossed over here simply as a function of time, but if there are specific questions, objections or comments folks would like to throw out there, I’m all ears.

For someone that doesn’t even like the word, Caroline got to one of the most pertinent platform questions quickly when we spoke for this piece. Though the context in this case was social networks, the question is one that every would-be platform has to face at some point: what’s the difference between an application and a feature?

The success of a platform, after all, is with but few exceptions gained by virtue of the ecosystem that surrounds it. The type of platform is relatively unimportant. Whether it’s Microsoft Windows – which gets my vote for the most successful software platform in history – or social networking applications of a more recent vintage, the canonical example being Facebook, ecosystems are the metric by which all are judged. Or should be.

Few would dispute the fact that winning platforms command developer attention and application traction, but even fewer would challenge the assertion that – for better or for worse – platforms tend to accrue functionality like a boat picks up barnacles. The conflict therein may be obvious to some of you, but to spell it out: a certain percentage of the applications developed for a given platform are destined to become nothing more than a feature of that platform. If the application developers are lucky, their technology is acquired by the platform purveyor in what effectively becomes development outsourcing. If they’re not…well, they can go from hero to zero, overnight.

For an example of what I’m talking about, consider the overlap between Twitter and Facebook’s “status” feature. Yes, Twitter is more feature rich – but Pownce betters Twitter in the feature department, and no one I know uses it actively. Why, many have asked, will Facebook not allow the Twitter Facebook application to populate the Facebook status feature? Not knowing the Facebook folks, I can’t say, but I’d be very surprised if they hadn’t discussed whether or not – from the Facebook perspective – Twitter was an application, or merely a feature of their social networking platform.

If you’re of the enterprisey mindset, perhaps the example of IBM and web content management will resonate more clearly. Years ago, IBM was content to leave the business of web content management to vendor partners like Documentum, Interwoven, and Vignette, focusing its own portfolio on more esoteric and complex content management challenges. Over time, however, customers grew less and less excited about the idea of buying a separate product from a separate vendor to manage each type of content, and as a result IBM began turning web content management – once a stand alone product category of its own – into a feature of its various content management and portal products.

IBM is no stranger to this line, of course. Its current and maybe future software strategy, in fact, is built largely on its promise to application ISV partners that it will not compete with them. Unlike Microsoft (Great Plains, Navision, etc) or Oracle (Peoplesoft, Siebel, etc), IBM tells them, we’re not going to encroach on your territory. By keeping its focus solely on the infrastructure portion of the equation, IBM aims to encourage application development by very explicitly drawing the line between feature and product.

Back in consumer land, Apple is perhaps the most (in)famous for crossing the fine line. See Karelia’s Watson for one example.

While popular, the David v Goliath tone to many of the discussions of this trend are misplaced, in my opinion. Occasionally, of course, platform vendors may be guilty of a lack of sensitivity, a lack of appreciation for the importance of their developer community, or both. But honestly, what are they to do? Preemptively freeze the platform? Cast a blind eye towards innovations that occur elsewhere? Acquire everything in sight to preserve their development “rights”?

My vote is none of the above. Developers need to use common sense about where and what they build, and keep their eyes open. Oh, and keep innovating; if you’re small, the odds are that you can do that quicker than your erstwhile platform partner.

Disclosure: IBM and Microsoft are RedMonk clients, while Apple, Facebook, Oracle, and Twitter are not.

To be blunt, my justification for attending the Salesforce.com conference last week had little to do with, well, Salesforce.com. More precisely, the Salesforce.com application. While my past includes hands on exposure to CRM and SFA applications, my present duties do not include coverage of same. [1] So why fly all the way to San Francisco, for the third time in as many weeks? I’ll let Marc explain it:

In a completely different domain, Salesforce.com is also taking a Level 3 platform approach — Salesforce now provides quite sophisticated ways for users and developers to create and upload code and program the Salesforce platform from a browser.

Salesforce provides a Level 3 platform both because it lets users easily customize Salesforce to do whatever they need, and also because it definitively trumps the criticism they historically got from packaged software vendors like Siebel who accused Salesforce of not being as adaptable as a piece of software you install on your own servers.

You probably don’t see this in action much — unless you’re a Salesforce user — but they’re doing really interesting work in this area and getting great results.

In other words, it’s the platform, stupid.

As Marc elaborates – read the whole thing, it’s brilliant – talk of platforms is all the rage these days. We have OS platforms, virtualization platforms, browser platforms, developer tooling platforms, mobile platforms, publishing platforms, social computing platforms, hardware platforms, hardware-as-a-service platforms, and – like Salesforce.com – software-as-a-service platforms. Everywhere you look, someone’s pushing a platform.

Which is, of course, nothing new. Everyone always wants to be a platform. Probably because the tactic worked so unbelievably well for the largest software company in the world that the DOJ and EU were forced to get involved. On a list of problems for a software company to have, that’s counterintuitively a good one: it means, essentially, that your platform has been too successful.

As Adam says in “What is the Platform?”

When I was at Microsoft, the prevailing internal assumption was that:
1) Platforms were great because they were “black holes” meaning that the more functionality they had, the more they sucked in users and the more users they had the more functionality they sucked in and so, it was a virtuous cycle.
2) To get this functionality, they had to be as extensible as possible so that extensibility, not ease of development was the priority for the API’s.
3) Since the rest of us often found aforesaid API’s complex/arcane, and since the rest of us built the “apps” that the corporations used, there needed to be a layer above the API’s called a Framework which hid the complexity and provided a kindler simpler gentler programming paradigm. (Think VB or MFC)
4) If everyone who could code could use this Framework, then they would build a plethora of applications locked into the platform and, hey presto, “stickiness”. Thus building an IDE and a Framework was the sine qua non of a platform even if it lost tons of money.

But as Adam notes, the world today is not the world as it was. If you read the piece, you’ll see that he’s betting on “services,” and – naturally – I’m inclined to agree. And while the navigation from current state to future state is likely to be hideously awkward (see Dilemma, Innovator’s), it’s a good bet that Microsoft does too. Or is anyone going to argue that Ozzie was handed the keys for a different reason?

To ground the discussion, let’s consider what the word services actually means. That, after all, is the interesting question. Not to mention the reason that I think the Force.com brand launched at Salesforce.com might ultimately supercede the Salesforce.com parent that spawned it – but let’s come back to that.

For Adam, services are browser based, mass market, and predicated on “access to community, collaboration, and content.” Setting aside the three C’s for the moment, it’s worth emphasizing the “mass market” bit. If you’re going to build a platform, then, your ultimate ambition should be DOJ intervention. Or, if you prefer, falling just short of that. That’s real mass market. That’s real volume. And volume will win far more often than it doesn’t.

The web doesn’t, of course, guarantee volume. But the lack of it probably does preclude it. You can have the web and no volume, but volume without the web? Not likely. Hardly an original assertion, we have to start somewhere.

The logic, then, should be simple: platforms contenders need volume, ergo platform contenders will be built on – or at least around (e.g. Skype) – the web. This assertion is certainly born out by recent history, not to mention recent valuations.

One of the keys for anyone with platform ambitions, then, will be buying or building the infrastructure required to support the necessary volume – the critical mass that incents the virtuous cycle of participation that is characteristic of successful platforms. The big guys mostly have this down, red shift challenges notwithstanding. It’s the little guys that are likely to have trouble.

As we often say when speaking with small software as a service (SaaS) vendors, the good news is that your potential customer pool is infinite. The bad news is that your potential customer pool is infinite. Scaling, as anyone who’s tried it knows, is difficult. Harder for some things than others, but always hard. In a piece from December of ’05 entitled “Scalability: Damned if You Do, Damned if You Don’t,” I said the following:

One interesting question that I’m beginning to ask from all of this: is it even possible for smaller players to scale competitively? As good as the del.icio.us, FeedLounge, et al guys are codewise – and many of them are very, very good – there’s the non-coding aspects of scalability to consider. Networking, hardware, etc require capital investments that can be onerous when bootstrapping, and it’s a simple fact of life that the smaller guys don’t benefit from the economies of scale that say a Google or a Yahoo will. They buy hardware piecemeal, and get run-of-the-mill bandwidth deals, all of which adds up to high entry costs.

But might there be an opportunity there? Might there be an opportunity to aggregate lots of these Web 2.0 (for lack of a better term) services in one place, and offer them an affordable, scalable infrastructure? Maybe. There are lots and lots of hosts out there, but are there any that provide specific expertise in scalability? None that I’m aware of.

As true today as it was when it was written? Not quite.

Scalability is still hard. But the weapons with which smaller would-be platform players can attack the challenge of volume are far more numerous. For just the reason I predicted: a few players have seen the opportunity for aggregating the smaller players, almost like a co-op. Which, as an aside, is a model that could have relevance for smaller technology firms in the near future.

The most elemental of these weapons is bare bones hardware-as-a-service (HaaS); rather than buy and build your own infrastructure, you rent it from larger players that can realize economies of scale on both the purchasing and management fronts. Think Amazon’s EC2/S3 or Joyent’s Accelerators. You’re given a basic hardware and OS base to build from, and after that you’re on your own. While the model has its drawbacks, it’s my belief that it will become increasingly compelling as more competition lowers prices and increased refinement of the technology lowers barriers to entry.

One level up from that, then, we have Salesforce.com’s recently announced Force.com offering, which they suggestively refer to as “Platform as a aservice.” It’s distinguished from HaaS by way of several additional assets that you can draw upon: a preexisting, managed database, UI framworks, browser based design tools, and so on. The question Salesforce.com would like to ask would be ISVs is simple: if you don’t want to manage your hardware and OS, why would you want to manage the rest of it? It’s more economical, they argue, to leave that to them.

Which indeed it might be, depending on your situation. Certainly there’s interest: Salesforce claims that better than 44 thousand applications run on their platform now, and that customers have made 18.7 billion calls into their APIs.

The catch is that, like Windows before it, you’re writing into a single, proprietary platform and a proprietary API. With, notably, a custom language. The question to be determined, then, is whether the benefits – making the majority of a given infrastructure someone else’s problem – outweigh the risks of lock-in. Those writing to Windows could soothe their concerns on this point by reminding themselves that the operating system in question virtually owned the market. Those writing to Force.com will not have the same assurances, but to what extent the virtually infinite audience promised by the web mitigates those concerns remains to be seen.

If Salesforce.com can effectively make that transition, however, from a mere SaaS provider to a SaaS platform, it seems inevitable to me that Force.com as a brand would eventually eclipse its parent. It’s far too early to see how things will yet play out, but with Salesforce throwing its hat clearly in the platform ring along with Amazon, Google, et al it should be fun to watch.

The $64,000 question, though, is whether or not hardware, operating system, and general system players can afford to not play in this space. Are you content to be a mere arms supplier to the next generation platforms, or do you need a platform of your own? Virtualization is already disintermediating the hardware; HaaS and now Salesforce.com’s PaaS take that one step further. The risks – and rewards – are potentially immense.

Disclosure: Salesforce.com is not a client, but they did comp T&E for last week’s conference. Nor are Amazon, eBay, Google clients. Joyent is not a client, but its founder host a personal website of mine gratis.

[1] Huge thanks to Stephen Naventi and the folks over at Outcast for proactively realizing that and scheduling me accordingly.

Google Reader, Meet Google Gears

Originally uploaded by sogrady

With apologies to Dave Johnson, but continuing in my fine tradition of being the last to bring you news, I offer you the following commentary on the recent announcement of Google Gears. Given the breadth of coverage you’ve likely already seen on the announcement, I can’t promise anything new, but I’d be remiss if I didn’t address the question given my long running interest in offline browser persistence approaches. On to the Q&A.

Q: Before we begin, anything to disclose?
A: Let’s see. Well, Google is not a RedMonk client, and I have not been officially briefed on the Gears technology at this time. IBM and Sun, which both currently support versions of the Apache Derby database (originally developed by IBM under the Cloudscape moniker), are RedMonk customers, as is another embedded database supplier, db4objects. Neither Joyent nor Zimbra are RedMonk clients, but they host a personal site of mine and our RedMonk email respectively, gratis. I think that about covers it.

Q: For those that haven’t yet seen the news, can you summarize the announcement?
A: Well, David Berlind’s already done an excellent job describing the technologies in his post here, so I’d recommend you start there. And definitely listen to the podcast interview with Linus Upson, a director of engineering at Google; I’m not a podcast guy, but it’s worth your time.

For the link and/or podcast averse, however, the basic summary is this: Google is introducing in Gears a cross-platform set of technologies that intend to facilitate the construction of Ajax applications that can function in a disconnected – i.e. offline – state.

Q: Any applications enabled yet?
A: Just one, as far as I know, Google Reader – see the inset picture. It’s a bit klunky, in that you seem to have to press a button to go offline before you actually go offline, but it’s compelling nonetheless.

Q: What is the problem space Gears is aimed at?
A: One most of us know quite well. Try using Gmail, as an example, in the absence of a networking connection. Or Yahoo Mail. Or Hotmail. Or, well, you get the idea. While Software-as-a-Service, as embodied by regular consumer facing apps like Gmail or more enterprised focused packages like Salesforce.com is a massively transformative application delivery paradigm, it’s been hamstrung at times by its inability to deal with disconnected or intermittently connected application consumption scenarios. Or, to shelve the consultant speak, the fact that network applications don’t work all that well without the network. It’s what I’ve described in years past as the “Offline Problem.”

Q: How important is that problem, still, with network availability getting better and more pervasive every day?
A: Perspectives vary. when discussing this problem in the past, Alex once joked that we’d solve the offline problem just in time for it to be made obsolete by ubiquitous connectivity. And Rails’ David Heinemeier Hansson apparently is not a big believer in the importance of offline persistence.

With both wifi and EVDO cards built directly into my laptop, I certainly understand the point of view that sahys offline persistence is a lot less important than it used to be. But that’s a far cry from saying it’s not important. As SaaS applications increasing compete against rich client or Rich Internet Application (RIA) alternatives that offer persistence, it will become a more significant limiting factor to adoption. Further, as ubiquitous as connectivity might eventually become, it’s not ubiquitous now. I should know, as I’m spending the summer in a location where the only broadband access is satellite and my best connectivity option is the barely better than dial-up GPRS. Then, of course, there are the planes, the hotels, the office buildings where there is no connectivity. Or, just as often, the convention centers, hotels, airports and so on that do offer wireless – just not wireless that actually, you know, works.

As a result, my personal opinion is that offline persistence for web applications is both laudable and necessary from a strategic competitive perspective. Just because we can endure the pain of not having offline access to web apps, doesn’t mean that we should endure it. If you disagree, here’s a good acid test for you: would you be comfortable delivering a presentation at a conference, relying solely on an online presentation tool? I certainly would not, but YMMV.

Q: Is that a recent opinion? In other words, have your recent application consumption trends affected that opinon?
A: Not particularly. I am, in fact, spending more and more time in the browser; I’ve gone from using Evolution daily to monthly – if that. But the issue bugged me as far back as September of 04 (which, you might notice, immediately preceded the magical October of ’04), when I was disappointed by the fact that the synchronization of my web reader at the time, Bloglines, was only possible to offline rich clients for the Mac and Windows platforms. As of today, I don’t need to worry about that. Took a couple of years, but better late than never and so on.

Suffice it to say that this is in fact a problem that’s bugged me for a long, long time. If you’re really bored, you can take a gander through some of my older entries related to the subject (earliest first): Turning Dross into Gold: Alchemy and Offline Browser Access, Presentation Tools: Offline, Online and Something in Between, So You Want to be an Office 2.0 Provider?, Zimbra: Derby for Offline Persistence, Grand Desktop Ambitions: The Q&A, Is Google Ring Fencing IBM?, and so on.

Q: Bringing it back to the actual Gears announcement, can we examine that in a little more detail? Starting with the technology?
A: Sure. As the initial announcements didn’t specify much in the way of what the individual pieces were – nor did the FAQs appear to – I was curious. But, as they always do, interested parties soon ferretted those out. Here’s John Herren’s breakdown on the individual components to Google Gears:

Google Gears uses three components:

• LocalServer- Handles caching of URL resources on the local file system.
• Database- Gears uses sqlite databases for storage. You can even find the databases on your file system and browse them with any sqlite compatible tool. I did. It works.
• WorkerPool- A job threading API to perform asynchronous operations so your app stays snappy and doesn’t hang. Check out the Fibonacci demo to see it in action.

Gisting this down, you essentially have a local web server (which one, does anyone know?) that serves cached content out of a SQLite database, with a threading mechanism that ensures that abnormally strenuous tasks – say, downloading and caching several thousand email messages – doesn’t bring your browser down while it waits. It’s pretty straightforward, actually.

Q: Is this the first such instance of this technology?
A: Nope, not at all. We’ve had building blocks for a while. Dojo, as an example, has leveraged the storage capabilities of Flash to deliver offline persistence for some time. In this post, Ted comments on a demo of Derby, or JavaDB in this case, being used as the persistence mechanism for an offline web application back at ApacheCon 2005. In November of last year, for example, the folks from Zimbra demoed a very similar Derby based solution to persisting Zimbra data offline; a solution that they’ve since released and that I’m an occasional user of. Not to be left out, two months ago the folks from Joyent announced Slingshot to the world; a framework for allowing Rails applications to persist data in disconnected settings.

In terms of future offerings, the plan for the 3.0 release of Firefox was actually – as I understand it – to include a very similar SQLite based repository for offline persistence.

Google is very much the follower in this space, rather than the first mover.

Q: What’s different about the Google offering? What differentiates it?
A: Most obviously, it’s from Google. None of the other competing alternatives can compete for reach and breadth.

Technically, it also differs from the Flash or Java based approaches, choosing instead to deploy its own, lightweight cross-platform persistence store in SQLite. Unlike some of the alternatives, it would appear that Google’s spent a lot of time on application performance; each application instance has its own sandbox, its own database, and can spawn its own background threads. As a result, according to Google, the performance impact for many applications should be neglible.

The most important differentiator, however, is its ambitions. I didn’t fully appreciate them until I listened to Berlind’s podcast linked to above, but Google would like for gears to become the de facto standard for offline development, a “single, industry standard” approach for delivering offline Ajax applications. Zimbra’s approach was to solve the problem on its own, while the Joyent folks widened the aperture a bit more targeting Rails applications. Google’s intention is for Gears to become the platform for offline apps, and has apparently designed and definitely licensed it as such.

Q: How do you mean?
A: well, let’s take the technology side first. Upson, in the interview above, was very unambiguous is his desire to have a great many developers use the technology. Start listing around 13:20, and you’ll get the picture, as Upson says:

“Clearly we’re very interested in offline enabling all of the interesting Google applications, however, we really want this to be a developer focused release, and it’s still at the experimental stage and we want to get feedback from the broader community, and we know this is going to evolve and change as we learn. I think we’ve done some clever things here, we’ve probably done some things that aren’t so clever, and so we want to be able to change how this works and evolve it over time, based on the partners that we work with and the web developer community. We wanted to have a real application, but we didn’t want to go beyond the development community at this stage.”

From that, it’s clear that Google has attempted not to deliver the once and future framework, but something that really is a beta (rather than a label, as it seems to be with so many of Google’s other offerings). Something that will draw feedback, and evolve towards real deployment scenarios.

Q: And the licensing? How does that encourage adoption?
A: The Gears technology is permissively licensed under a BSD style license, which is the least restrictive and offers the fewest barriers of entry to potential communities. As we recently put it in an internal report delivered to 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 decision to apply the BSD style license, then, can be viewed as an attempt by Google to encourage ubiquitous adoption and consumption.

Q: What are the likely impacts to some of the Gears alternatives?
A: From an application provider perspective, I tend to agree with Berlind, who said:

Where companies have committed to an offline architecture as Zimbra has with its Zimbra Desktop (whose offline capability is powered by Java), those companies may be forced to completely reconsider that architecture if Google Gears gets market traction.

If you’re Zimbra, and your resources are limited, it would make sense to at least ask the question as to whether or continued investment in a redundant offline infrastructure was justified. It could be, for technical reasons, but it might not be as well.

If you’re a Joyent, the question is more complicated. They’re targeting a far more specific niche than Google Gears, in Rails apps, so the question will come down to whether or not Slingshot can offer enough differentiating features to Rails devs to justify their usage of it. Compromising their argument is the fact that Slingshot is not, as yet, available on as many platforms as Gears. Still, they appear content to play David.

Interestingly, Adobe seems to be partnering quite closely; willingly aligning their SQLite efforts with Google’s. That bodes well for Google’s ultimate aims.

Q: Who will be anti-Google Gears?
A: Well, some of the aforementioned alternatives are probably not blissfully happy right now. And there are a variety of players that could ultimately be threatened by the technology. But the least likely to play along, handing Google a de facto standard for offline persistence, would be Microsoft, IMO. I’d be somewhat surprised if we don’t see a similar Windows-like technology emerge. The question, as always, will be their cross-platform story, which Google’s gotten very right here.

Q: How about Mozilla?
A: I was interested to see how they’d react, given that similar ambitions were on their roadmap for 3.0. But they’re apparently partnering with Google on this endeavor, and I actually wonder – pure speculation on my part – whether or not Google’s de facto standard could ultimately replace some of the planned work within 3.0. Either way, Mozilla appears to be on board.

Q: Is Google Gears likely to lead to an explosion of offline applications?
A: Explosion’s probably a little overambitious. One of the things that’s clear as you begin to parse offline application scenarios – and as Upson discusses – is that no two are the same. An offline email client is not the same as an offline feed reader is not the same as an offline CRM system and so on. The application calls, the application storage demands, the application performance implications, even the very utility of offline data access – vary widely. What I expect to see, at least initially, is experimentation. Trials to determine what data needs to be cached, what doesn’t, and so on.

My colleague is of the belief that Web 3.0 will be about synchronization, and he’s taken to calling Web 3.0 the Synchronized Web. Whether you agree with that or not, or like *.0 designation system, there can be no debate that in increasingly online/offline use cases, synchronization – a difficult task at the best of times – will be one of the most significant challenges to tackle.

Q: Couple of questions coming in from #redmonk – was this a 20% project or is it being developed for a specific product?
A: Good question – don’t know the answer. It sounds like the latter, but perhaps one of the Google folks can check in and tell us.

Q: Another set of questions from the #redmonk channel, more technical – “Is WorkerPool positioned against Microsoft’s BITs service for asynchronous IO? Is IO from WorkerPool using the browser connections or its own? If WorkerPool does not have DOM access, does that mean that the JavaScript is being executed in the browser’s JS interpreter or is Gears providing its own? Will other non-browser applications be able to read/write to the local store thus enhancing the user experience?”
A: Don’t have the answers to most of those, but let’s see what we can parse. As for BITs, I suspect that WorkerPool is like it, but that they won’t compete with each other because of a.) scope and b.) the fact that one’s cross-platform and one’s not. As for IO, I don’t know. I’d guess that WorkerPool is using it’s own connections because of the aforementioned issues around multi-threading, but that’s all it would be, a guess. On the interpreter question, I’m fairly sure Gears is using the browser’s because I haven’t heard anything about it incorporating a second, and that would seem to be unnecessarily redundant. Lastly, on the topic of whether non-browser applications can read/write to the local store, I know they can read the DB’s – John Herren’s said as much above. And Adobe and Google appear to be coordinating their efforts on that front to some degree. Whether or not applications can access the pieces more deeply, however, is a question I don’t know the answer to. But would like to, because it has implications for RIA and rich client strategies that could transcend the browser.

Q: Last question from #redmonk: why Gears?
A: Excellent question. I’ll leave it to Google to answer that one officially, just noting that the Gears Firefox Add-on’s caption is “These are the gears that power the tubes!”

Q: Any last thoughts or conclusions?
A: Just that, like the Joyent guys, I think that offline, persisted information is a legitimate game changer. This is the biggest piece of news I’ve heard in a long while.



Update: Had some versioning issues, so had to re-merge some content. Sections originally missing were the enabled applications, and a different version of the “what differentiates Gears”. Apologies.