In early January, I released my annual set of predictions for the upcoming year. Among them was the contention that “Ubuntu will emerge as the de facto alternative at the expense of SuSE.”

As might be imagined, the people at Novell had questions about this assertion. These we discussed during a briefing on January 26th. To their credit, the SUSE team was polite and respectful, even as we fundamentally disagreed.

Their view – bolstered subsequently by high profile wins such as the London Stock Exchange and Watson – was that SUSE was performing well across a number of metrics from revenue to ISV recruitment.

My own is that SUSE faces some fundamental challenges.

The disconnect is simple to explain: we advantage different metrics. Our belief at RedMonk is that more often than not, sustainable performance is most strongly correlated with developer traction, visibility and usage. Revenue, shipments and profit are excellent at measuring how you’re performing now; they are less adept at anticipating future direction.

Developer adoption, on the other hand, is, in our view, highly predictive. It is difficult to identify cases where volume adoption of a given technology has not resulted in its success. Profit potential varies, of course, according to a number of variables from licensing model to addressable market size. But historically, optimizing for developer adoption is a sound strategy; it is arguably true that this correlation is becoming stronger.

The metrics we look at at RedMonk, then, are intended to quantitatively assess developer opinion. There is no single metric for accomplishing this; instead we employ – depending on the subject – varying combinations of public and private data sources to form a larger narrative. Even trivia like Google Trends search data has significance when used in context.

Sometimes the conclusions reached merely validate the conventional wisdom; Amazon Web Services is one such example – it is just as popular as commonly believed. More often, our explorations of developer traction turn up less understood strengths, weaknesses and areas for improvement.

We perform these analyses regularly for research aimed at particular developer communities; my FOSDEM talk “The Rise and Fall and Rise of Java” [coverage] was one such. But we also perform them regularly on behalf of clients, whether they want us to measure them at a corporate level or to look at specific products or platforms.

And while Novell is not currently a RedMonk client, having prepared a few of the charts in preparation for my call with the firm, I thought the embedded slides might be useful both for those wondering how I came to the conclusions I did regarding Novell and for those curious about how RedMonk tries to quantitatively measure developer traction. This is just a sample report, and does not include the executive summary, remediation recommendations or backup data, but it communicates the essence of what RedMonk Analytics Custom offers.

As W. Edwards Deming once said, “In God we trust; all others must bring data.” The State of Novell and indeed all of our “State of $YOURCOMPANY” reports are us attempting to comply. The slides above are a measurement of how we see the firm performing according to a few of the metrics we believe are important. As such, it is a complement to, rather than replacement for, your traditional research services. We do not discount wholesale cited revenue performance metrics, marquee account wins and so on. We simply believe that relative to bottom up adoption and usage, they are less likely to be predictive.

If you’d like to see how your company or product is performing, we’ve got RedMonk Analytics Custom packages available for existing clients and a la carte options for those who aren’t working with us.

For the developers in the audience, we hope you find this research of interest, and feel free to let us know if there’s something you want us to look at.

Disclosure: Novell, as disclosed above, is not a RedMonk client. Mentioned competitors Canonical (Ubuntu), Microsoft, and Red Hat (Fedora) are RedMonk customers.

We’ve received a lot of questions and comments on the above graph we published yesterday, not all of which could be addressed within the confines of Twitter’s 140 character constraints. Let me provide some additional context then on what we feel the graph asserts, and conversely, what it does not.

First, let’s clarify the source. The data for that chart is taken directly from our RedMonk Analytics product, and represents the net change by percent in operating system share from January 1, 2010 through December 31, 2010. For internal data like this, the idea for RedMonk Analytics is simple: we publish a lot of free content aimed at developers. Developers consume that content. By watching for patterns in that volume consumption and applying analytics, we are able to form certain conclusions about developer behaviors.

One of the patterns RedMonk Analytics monitors is operating system traction [RedMonk Analytics subscribers: see the "What is Being Used?" report]. With the caveat that we’re merely monitoring consumption behaviors – what developers are reading our content on rather than what they’re actually coding on – a pattern is emerging. Mobile’s gaining, which is not a surprise. What was less expected was the fact that it appears to be gaining primarily at the expense of Windows.

There were hints of this trending when we began examining our year end data, but it wasn’t until we put together a RedMonk Custom Analytics report for a client in the mobile tablet space that the picture became clear.

As the graph indicates, RedMonk properties saw the relative share of Windows usage decline by 8.1% in 2010. The Android, iPhone and iPad platforms gained 6.28% collectively over the same period. Given that Linux and Mac platforms were essentially static on the year, both growing less than 1 percentage point, it seems self-evident that as developers use more mobile platforms, they’re using less Windows.

The data does not support conclusions beyond this, however. Even after the observed decline, Windows leads Mac, the second most popular platform, by nearly thirty percentage points. The trendline should not obscure the absolute performance numbers, which argue that Windows remains the most popular choice amongst developer constitutiences, although its margin varies from developer community to developer community [coverage]. Remember also that our data here reflects consumption based usage; while not probable, it is possible that our data underrepresents production oriented platforms.

Accepting the data as presented, the obvious question is why? If Windows is disproportionately losing share to mobile platforms, what is the cause? It is hardly likely, after all, that Windows machines are being replaced by smartphones, be they of the Android or iPhone variety. Capable as that hardware has become, even its advocates wouldn’t position it as a legitimate alternative to the traditional PC. And yet it declines while Linux and Mac show minimal impact, though potentially less growth. The data suggests no obvious explanations for this trend, but anecdotally it’s worth noting that the developer advocates of both Linux and Mac tend to be more invested in those platforms than their Windows counterparts.

Whatever the explanation, this is a trend worth following. It is clear from our data and market context both that internet users broadly and developers specifically will be increasingly be accessing the network via mobile devices. And while internet consumption is not a zero sum equation in that a portion of mobile usage – time spent reading Twitter while at the supermarket, for example – will be additive, it is clear that one or more operating systems will be losing share if only on a relative basis. At present that operating system is Windows, whether that continues to be the case will be important to Windows’ future.

Android handsets and even Apple’s mobile hardware are rounding errors next to the share that Windows currently enjoys. But given the trajectory on display in our audience, itself ahead of the curve, there is cause for concern for Microsoft.

Mobile, as the data indicates, is growing, quickly, and will produce winners and losers. And it is not a category in which any of the varied players can afford to lose.

Disclosure: Microsoft is a RedMonk client, while Apple (iOS) and Google (Android) are not.

When we founded RedMonk in 2002, we made a conscious decision to focus on qualitative analysis at the expense of quantitative research for the simple reason that we didn’t believe there was representative data available about our core constituency, developers. Traditionally, analyst firms had worked backwards from observable metrics such as server shipments and license revenue estimations. While these numbers were effective for measuring the performance of commercial suppliers, however, they were entirely unable to assess the performance of non-commercial alternatives. The growth of free software was largely opaque to quantitative analysis, for example, visible only in the corrosive effects it had on commercial software revenue.

Over the past few years, however, we’ve begun to gradually introduce quantitative analysis into our portfolio – culminating in the fall launch of our RedMonk Analytics product. We’ve begun incorporating numbers because we believe that, for the first time, we have access to quality data from which we can reasonably infer developer behaviors. Some of that data is generated in house: this is the initial basis for RedMonk Analytics, although our system is rapidly incorporating third party data.

But there are many sources for relevant developer related data today. One such is the Hacker News dataset collected by Ronnie Roller, creator of iHackerNews.com. Consisting of 1.7M entries from the site, the dataset is an interesting snapshot of developer commentary and interests.

Our first pass through the data in November looked at programming language popularity. Since then, we have been continuing to crawl the dataset regarding other topics. This dataset is interesting not because it is representative of developers as a whole, but rather because it’s a community of technologists who are collectively ahead of the curve.

DVCS

Consider the following data we derived back in November from Ohloh regarding usage of version control systems, for example.

Subversion dominates, clearly. As do centralized repositories, generally.

On Hacker News, however, the data reflects a different distribution. Even given the caveat that this data reflects mentions rather than observed instantiations, we find the trends illuminating. Here, for example, is a chart of DVCS options:

Note the reversal of the observed trend; Git dominates Subversion, rather than vice versa. Similarly, the observed preference on Ohloh for centralized repositories over decentralized alternatives inverts.

Again, the Hacker News reflects the discussion of technologies rather than actual implementations. But given that each of the technologies is freely available, it would be a mistake to conclude that the distribution of mentions has no relationship to actual adoption.

Vendors

One of the other interesting queries was for vendor names. Because they may appear in a variety of contexts, this graph is more for curiosity’s sake than actual analysis.

Like Oracle, Microsoft’s performance in the above is likely something of an artifact because of its often controversial standing with developers, but its showing is nonetheless impressive. Other surprises were that the underperformance of VMware relative to its peers and the better than average visibility of Cisco.

Frameworks

One of the requests on Hacker News was for a look at the distribution of framework mentions. Here’s the data:

The dominance of Rails is unsurprising, as is Node.js’s strong showing – we’d expect nothing less from Node given our own internal metrics. I was mildly surprised by Grails’ poor numbers; Zend Framework’s result is likely a byproduct of the two name structure.

Operating Systems

Operating systems, meanwhile, were another mixed bag. Windows, as ever, dominated, but Ubuntu’s outperform was a mild surprise, if only because the perception exists that Hacker News can be CentOS centric. That may be true, but the data certainly doesn’t reflect it. In case you’re curious, SUSE’s position relative to Red Hat was not influenced by discussion of the Attachmate acquisition [coverage]: the dataset predates that.

NoSQL

As with distributed version control, NoSQL is a subject that typically finds a welcome audience within the Hacker News community. While conservative enterprises may express little appetite for non-relational tools, developers have been far more pragmatic. Crawling their comments on the subject, we find the following distribution of mentions by datastore.

No real surprises. Mongo is slightly more popular than I would have expected, Hadoop slightly less, but the balance of the data is consistent with our experiences in the marketplace.

Cloud Providers, or: Just How Popular is Amazon?

Very. Even heavily discounting the number of mentions of Amazon as references to its retail businesses rather than its cloud computing stack, Amazon is dominant. Also notable is Heroku’s performance: as above, this dataset predates the acquisition by Salesforce, so the frequency here is unrelated to that event.

Thus concludes this round of Hacker News analytics. If you have questions you’d like to see answered in future, leave a comment or drop me a note. If you’re a RedMonk client, your available hours can be used for custom, on demand crawls of this data. Contact us for details.

Update: By request, we have added Gentoo to the list of operating systems surveyed, Neo4J and FlockDB to the non-relational stores graph, and Joyent to the cloud providers surveyed.

Disclosure: Adobe, Apache (Cassandra, Hadoop, etc), Basho (Riak), Canonical (Ubuntu), Cisco, IBM, Membase, Microsoft (Azure, Windows, etc), Red Hat (Fedora, Makara, RHEL, etc), Salesforce.com (Force.com) and Zend (Zend Framework) are RedMonk clients while Amazon (AWS), Engine yard, Google (GAE), HP, Oracle and VMware are not currently.

“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.

Never in recent memory has there been less focus on the operating system, a subject we examine periodically (coverage, coverage, coverage). With the exception of mobile, where the adoption of Android versus iOS is a subject of intense interest, operating system inquiries have never been fewer.

We see this qualitiatively, as the nature of our engagement shifts to the layers above, below and around the operating system; from the virtualization substrate to the middleware equivalent abstractions for application deployment to the management tools that both provision the above and keep it running.

We also perceive the shift quantitatively. In October of 2009, “opensolaris vs linux” was the #1 incoming query to RedMonk properties according to RedMonk Analytics; “linux vs opensolaris” was #7. In October of this year, “opensolaris vs linux” is #13; “linux vs opensolaris” is not in the Top 100.

The simplest explanation for this might be the decline and acquisition of Sun, and the subsequent deemphasis by new owner Oracle to the Solaris brand generally and OpenSolaris specifically. But for this to be true, we should have expected to see commensurate gains to other operating system related terminology, be that Windows, Linux or combinations of both.

We see no evidence of this. Our data shows instead a profound shift in inquiries to layers of abstraction above the operating system; Node.js, for example, is massively trending over the past six months, occupying three of the top four spots. As are terms such as “PaaS,” “cloud fabric,” and “saas cloud.” We can even observe in real time the difficulties developers are having in digesting the implications of the new development paradigms and related terminology via queries like “cloud & saas & difference” (#23 last six months).

The obvious conclusion is that the operating system market is in transition.

The deemphasis of the operating system is even apparent from a resourcing perspective. The team originally responsible for DTrace, a still differentiated piece of observability technology built into Solaris, have all left Oracle. Rather than attempting to build another operating system or helping to build a competitors, many have joined Joyent. They may continue to do operating system work there via the illumos project, but their business will be the cloud, not distributable operating systems.

There are a variety of reasons for the decline in visbility for the OS; most are likely familiar to you. The ascendance of cloud, the delivery of applications in a network context, open source led shifts in availability and procurement, the accelerating fragmentation of application development, historical trends towards further abstraction, platform consolidation. All are contributing to a shift in the way that applications are designed and deployed, which in turn impacts the role of the operating system [coverage].

The question of whether operating systems still matter is probably a wrong one: the new platforms, cloud included, cannot function without the core functionality an operating system provides. The better question is who operating systems matter to, and what this means for the industry.

It is self-evident that operating systems matter – intensely – in the mobile space. Clever solutions like PhoneGap aside, developing for Android is not like developing for iOS. Which in turn is not like developing for the BlackBerry Tablet OS. The mobile landscape is akin to server side development circa 1995, where applications are written directly to the operating system with portability an expensive afterthought.

It’s also true that operating system adoption on the desktop remains highly stratified; with the long predicted Year of the Linux Desktop yet to arrive, consumers PCs are still primarily either Mac or Windows.

The enterprise server world is a more mature market than either mobile at least, and has therefore already weathered the rounds of consolidation yet to arrive in the world of handsets and tablets. There are fewer legitimate contending platforms in the server market, even as at least one of those (Linux) shows signs of pending fragmentation.

Even these fewer choices, however, are increasingly abstracted from application developers. What is the operating system behind Microsoft Azure, Engine Yard, Force.com, Google App Engine, or Heroku? The answer is, in varying degrees, none of your business. These and other PaaS vendors are aggressively distintermediating the operating system by removing it as a choice.

Nor is Infrastructure-as-a-Service, which generally still implies a choice of operating system, reflective of traditional enterprise operating system adoption patterns. What the available cloud metrics suggest is an environment where traditional drivers for operating system adoption – commercial support, certified application compatibility, etc – are second to convenience. According to the Cloud Market, which provides relative volume metrics on the Amazon AMI catalog, this was the approximate composition of major operating systems on November 9th.



It’s true that this is a survey of available images rather than deployed images. But it’s equally true that this distribution would have been unimaginable even twelve to eighteen months ago: the leading commercial distributions make up only 18.5% of the catalog. Given that we’re still seeing a distribution in the catalog, it’s clear that the operating system matters to cloud deployments. People value choice enough to have created better than 7200 different options. Precisely what matters about those operating systems, however, appears to be in transition.

Within the datacenter, on the other hand, little has changed. Which is fortunate for suppliers, because the majority of revenue is still derived from infrastructure maintained and run by businesses themselves. Enterprise purchases still overwhelmingly favor traditional operating system suppliers: Microsoft (Windows), Red Hat and to a lesser extent Novell (Linux), with the majority of the remaining share divided between Unix vendors (HP, IBM, Oracle, etc). The dramatic spike in interest in Red Hat Enterprise Linux 6 speaks to the continuing appetite for new operating system features in a variety of markets.

As long as the enterprise markets remain the dominant revenue source, then, operating system vendors have little to fear. The challenge – still theoretical – will be when the shift in developer interest we are beginning to observe begins to manifest itself within an enterprise context. At present, definitive statements that the importance of the operating system will be as diminished as the commodity hardware platforms they most frequently run on today are purely aspirational. On the other hand, who would have predicted fifteen or even ten years ago that one of the major players in the market, a $750M business, would be an entity that sells software that’s available for free?

The data we have argues that change is coming. That it is, in fact, already here; it’s just unevenly distributed. It will be interesting to see how the various operating system suppliers leverage, fight or succumb to it. Just as fascinating will be whether the incumbents are able to pivot neatly from one dominant role to another, or whether that process will advantage the contenders. History is no guide here, as we’ve seen both scenarios play out repeatedly.

Disclosure: Canonical (Ubuntu), Microsoft, PhoneGap and Red Hat are RedMonk clients. Novell and Oracle are not.

“Is this Silicon Valley or Hogwarts School of Witchcraft and Wizardry?

They are part of a new wave of highly specialized technology — both software and hardware — built by and for Web titans like Facebook, Yahoo and Google to help them break data into bite-size chunks, and present their Web pages as quickly and cheaply as possible, even while grappling with increasing volumes of data. Facebook, for example, created Cassandra to store and search through all the messages in people’s in-boxes.” – Ashlee Vance, “Big Web Operations Turn to Tiny Chips”

If you study the French Revolution, the odds are good that at some point a professor or author will invoke the pendulum metaphor. The aptness is clear, as history adequately demonstrates a tendency for human events to swing back and forth from one extreme to another. Which is precisely what we’re seeing in technology today, as we swing from general purpose back towards specialization.

From the mainframe’s heyday to the Unix wars’ fragmentation to the ascension and dominance of Windows, technology has periodically vacillated between extremes of general purpose computing infrastructure to more specialized hardware and software combinations. As ever, what is old will be new again.

What’s new these days, then, is the old preference for specialization. Just a few years ago, application development was a simple proposition. You picked an operating system – general purpose, of course – a relational database (duh), a programming language, middleware to match and you got to work. It may yet be that we come to remember those with wistfulness, a nostalgic remembrance of simpler times.

Even the most basic of decisions today is fraught with the paradox of choice. Consider the long time standard LAMP stack. The explosion of options for persisting data has been well documented (coverage): the time when storing data meant choosing which relational database you wanted are, for all intents and purposes, over. Relational databases like MySQL remain a popular choice – and absolutely the most popular for the backing of existing applications – but it is no longer the only choice. General purpose operating systems like Linux remain the dominant deployment option, but that preeminence in increasingly threatened by cloud platforms which abstract the operating environment and appliances which make it irrelevant. Programming language fragmentation meanwhile, has been well underway for decades, so there’s nothing new there.

But what about Apache? Surely the venerable web server remains the most popular platform for deploying web applications? Well, yes, it is. Here are Netcraft’s numbers for overall web server share.

And yet there are signs that Apache’s dominance is challenged for what Netcraft terms “top sites.” See the following:

Some will undoubtedly argue that Netcraft’s numbers are imperfect, and they will be right. But the fact is that developers are increasingly weighing the merits of Apache versus new, built-for-purpose alternatives such as nginx, Node.js (coverage) or Tornado. Ryan Dahl’s presentation on Node examines some of the potential limitations of the Apache thread-per-connection model versus event-loop based alternatives, and some very bright developers are listening. The success of Node et al doesn’t mean that Apache isn’t still the most popular choice, of course: it simply means, in what is becoming a familiar refrain, it’s no longer the only choice.

Because there are an ever growing library of more specialized alternatives available.

Nor is the specialization bug merely infecting the software world. As Ashlee’s piece documents, there are more and more hardware startups popping up. Their raison d’etre, almost universally, is that current hardware models are not ideally suited to scale out workloads. Besides the SeaMicro’s and Schooner’s of the world, there is evidence that firms like Google are acquiring ARM expertise with the intent of leveraging it for specialized servers. Microsoft is reportedly exploring similar hardware, as is Dell.

Doubtless many of these efforts are better classified as experiments than actual commitments to specialized hardware. And the marginal benefits of the specialized hardware, in many cases, may not outweight the costs, whether those lie in design and production or lengthened development and deployment cycles. But as we see in software with projects like Facebook’s compiled PHP, HipHop (coverage), if the scale is sufficiently large even incremental gains in power, performance or both can be financially material.

Purveyors of specialized hardware are quick to point out that the benefits may extend beyond mere performance and power gains, however significantly differentiated it may be in either. Custom-fitting software to hardware can introduce benefits that are either impossible to achieve on general purpose infrastructure, or not economically feasible. Certainly this was one of the guiding principles behind the Sun Fishworks project (coverage), which stands for Fully Integrated Software and Hardware…works). Presumably new owner Oracle agrees, given the depth of their commitments to the appliance form factor in Exadata.

How all of this plays out in a market context is yet to be determined. Clearly, developers are actively embracing the shift back towards specialization, but the traction for specialized hardware either on a stand alone or appliance basis is still small relative to the current market size. As I told Schooner’s Dr. John Busch when we spoke a week or two ago, various players have tried to push appliances as a mainstream server option in the past: all have failed. Outside of categories like networking, security and storage – each quite large, to be sure – specialized hardware has been a difficult sell.

What might be different this time around is that on a macro basis, the market is showing an increased appetite for specialization at every level. Combine that with a driving need to maximize performance while minimizing the expense, both in power and datacenter floor space, and the opportunities may be there where they traditionally have not been.

As to when the pendulum will shift back towards general purpose, all I can tell you is that it will at some point. The inevitable result of an explosion of choice is a reactionary market shift away from it. All this has happened before, and all of this will happen again.

Only the foolish attempt to measure a publicly held firm strictly by its share price. Given the capricious and myopic nature of public markets, they’re at best an imperfect reflection of a company’s current performance and future potential.

That said, it would be even more foolish ignore the share price. Whether you agree with market perception or not, they must be considered, representing as they do public valuations. To make this point and properly incent executives, in fact, many comp packages are tied to the performance of the company’s stock.

I bring this up now because the graph above seems as plausible an explanation as any for VMware’s purchase of SpringSource, made yesterday. Like Red Hat before them, VMware seems to have decided to expand upwards from its revenue base in platform technologies to capture a greater percentage of the enterprise IT budget via a Java stack. They’re no longer content to leave that money on the table, in other words.

Why? My guess is growth. True, VMware is facing increasing competition, in the virtualization space from competitors ranging from open source projects to Microsoft to systems management vendors. But they still, for all intents and purposes, own the enterprise virtualization market. Which is great, and got them a nice big IPO. But on Wall Street, greed is good, and greed is not content with dominance in a single market – growth is the unrelenting demand. Just ask Microsoft. Or look at the graph above of their share price.

So while VMware has, as discussed previously, charted themselves a long term growth strategy in the cloud, it’s just that: long term. Judging from the recent market performance, the street’s looking for something more immediate and more obvious. Which is why SpringSource makes sense: the enterprise Java middleware business is as well understood on the street as it is in the technology industry. Not every IT manager will understand why Spring overwhelmed more traditional J2EE alternatives, of course, but they’ll understand its ubiquity. That, as much as anything else, is what SpringSource has traded on. It was built for many of the same reasons that the more popular dynamic language frameworks were created, but it speaks Java, and that’s comforting for the enterprise. Where comforting translates as easy to sell.

To explore this acquisition in greater detail, let’s turn to a Q&A.

Q: Before we continue, do you have anything to disclose?
A: Yes, SpringSource and a number of the other firms discussed here, from IBM to Microsoft to Red Hat to Sun, are RedMonk customers. VMware, meanwhile, is not. I think that about covers it.

Q: Can you sum up the news for those that haven’t seen it yet?
A: Sure. Yesterday afternoon, VMware announced its intention to acquire SpringSource for about $420 million in cash and other financial instruments.

Q: Is this about the cloud, as multiple outlets – the founder of SpringSource included – have claimed?
A: In time, yes, quite possibly. And there’s little question that SpringSource offers VMware an intriguing opportunity to be what 10gen, Project Caroline, et al have to date failed to be: the EngineYard or Heroku for Java, permitting seamless deployment of Java applications to on or off premise cloud infrastructure. But this is, to me, a longer term revenue opportunity, as VMware’s cloud pieces are still coming together and its hardware and datacenter capabilities are neglible relative to competition such as Amazon, IBM or Microsoft.

In the short to medium term, then, I think this is primarily about growth in a market with few barriers to purchase.

Q: What about SpringSource promises growth? Are they doing massive sales numbers to jusify that valuation?
A: Matt Asay’s claiming about $20M in sales, but whatever the actual number is, there’s little question that it can be grown strictly through acquisition. Like MySQL tapping Sun’s client base, SpringSource would, via acquisition, gain immediate credibility and a larger addressable market.

And the addressable market, in this case, is one that commands budget. Whatever your opinion on the current status of Java the language and platform relative to competition from dynamic language, Microsoft or other competition, the fact is that the enterprise as a category has made truly massive investments in Java over the past two decades, both in infrastructure and personnel. Thus it is that Java is, within many enterprises, the strategic development platform. The Spring framework allows enterprises to embrace this, but with a more modern and developer friendly approach – kind of a best of both worlds approach.

If that doesn’t make sense, think of it this way: with this acquisition, VMware has significantly expanded the percentage of spend for traditional enterprise stacks that it can realize revenue from. And don’t underestimate here the importance of the former Covalent pieces; Tomcat’s the ultimate lightweight Java experience.

Q: One more cloud question: how does SpringSource improve VMware’s ability to deliver a Platform as a Service offering?
A: The easiest way to answer that is to examine the nature of Platform as a Service. Ultimately, PaaS is an abstraction, a veneer on top of an Infrastructure as a Service offering – what I have previously termed a fabric. This fabric obscures the underlying complexities of the hardware and software infrastructure underneath; gone is the need to worry about provisioning hardware, clustering and load balancing application servers, and so on. This is the fabric’s problem.

VMware, with but a few exceptions, has traditionally focused its efforts on technologies below the fabric; VMware can abstract the hardware, of course – that’s the point of virtualization. But it typically still presents users with the operating system, as well as the need to manage these new virtual instances.

SpringSource by no means offers a complete fabric solution to compete with, say, Google App Engine or Salesforce’s Force.com, but it does offer a capable, powerful and popular application layer compatible with a programming language that’s immensely popular within VMware’s install base. This is how Rod Johnson of SpringSource describes the potential combination in his post:

Combined with VMware’s vSphere and other cloud-enabling technologies, we can innovate in frameworks and infrastructure to deliver a joined up experience. SpringSource application frameworks, servers and management software can give the VMware platform eyes and ears throughout the stack, allowing it to apply its uniquely advanced ability to migrate workloads and manage VMs for maximum efficiency and minimal hardware resource cost.

That’s a bit optimistic in a few areas, but it’s an indication of how they see the potential combination of these technologies going forward.

Q: Optimistic how? Where do you think the combination falls short?
A: Well, neither SpringSource nor VMware is bringing hard core persistence skills to the table – the ORM compabilities notwithstanding – which makes me wonder if commercial entities like Cloudera or committers to projects like Cassandra, Drizzle, Tokyo Cabinet, or Voldemort are being eyed. Hell, maybe VMware will continue its tradition of poaching from Google and go after their database folks; too bad for them Facebook got to Mark Callaghan first.

Q: Besides the cloud technology development and integration, what do you think VMware should be focusing on assuming it closes the acquisition?
A: Tooling. When Cote and I met with SpringSource CEO Rod Johnson at OSCON a few weeks ago, one of the primary topics of discussion was the development experience. This could wind up one of the unheralded benefits of the acquisition: Rod gets the tooling story. He understands that Microsoft, again, is setting the bar for the development experience by allowing its developers to localize the cloud environment via Visual Studio. With VMware’s virtualization capabilities, the tooling story for SpringSource could get very interesting vis a vis cloud development and deployment.

Q: What about management? What do you think VMware intends to do with the Hyperic pieces?
A: I’ve heard all manner of speculation; everything from Hyperic will be decommissioned to Hyperic was the reason for the aquisition, neither of which I subscribe to. Cote’s take on it seems the most rational I’ve seen:

The last area of interest for the IT Management minded of you out there, dear readers, is Hyperic, one of the open source IT Management vendors categorized under the infamous term “The Little 4.” One would think that Hyperic could help beef up VMWare’s ambitions to become more of a management vendor than just a hyper-visor vendor. In the area of open source and standards, I wouldn’t say VMWare has a terrible or golden reputation, they’re pretty neutrally perceived – though their open source hyper-visor competitors will tell you otherwise. Their space doesn’t “require” open source in the same way that middle-ware, where SpringSource operators does.

That said, it’s seeming like open source based IT Management tends to be, at least, more interesting and fast evolving than closed source IT Management…when it comes to new applications and platforms at least. (SaaS IT Management offerings provide a nifty loop-hole here.) If there’s any benefit to open source IT Management software, then, we’d hope VMWare would look towards Hyperic to figure them out more, beyond interoperability. Of course, it goes both ways: big name, largely closed source IT Management vendors (like VMWare) have yet to connect with the open source vendors (like Hyperic) in a major way, and I’d wager (complete) access to the executive wash-room would create some interesting Amdahl mug discussions.

Q: What would your concerns be for the acquisition?
A: Focus. Red Hat’s certainly proven that a platform company can pretty seamlessly integrate a middleware business, but VMware’s focus and commitments are to some extent far more broad than Red Hat’s prior to its acquisition of JBoss. The integration of SpringSource and its diverse-for-its-size businesses will present VMware with challenges in focus, but probably nothing that’s not manageable, given the typical Spring account.

Q: Who should be concerned by this acquisition?
A: Most are pointing to Red Hat as the firm most obviously impacted by this announcement, and I would tend to agree. VMware’s virtualization play is, ultimately, about disintermediating the operating system by abstracting it from the underlying hardware. SpringSource, on the other hand, abstracts the application from the operating system. By loosening the coupling at both ends of the spectrum, VMware is in some sense attempting to descrease the importance and relevance of the operating system itself. And in spite of the performance of JBoss, that’s a problem for Red Hat, far more so than the fact that VMware acquired a competitive open source stack.

Others too, from HP to IBM to Microsoft to Sun should probably be at least moderately concerned. VMware could be handled – or so it’s been said to me – when they were relegated to the thin layer between the operating system and the underlying metal, but between its growing management ambitions and its new foray into the Java middleware space, VMware represents a growing threat to some of the established enterprise vendors. Particularly because, at least in the Java space, it has very little legacy to contend with, and can thus be both nimble and aggressive in righting some of the J2EE wrongs.

Q: Having speculated that this is all for growth and for the street, how do you think they’ll appreciate the news?
A: Well, the stock’s trading lower after the news – potentially on the valuation – but I think if VMware can deliver on the short term promise, we’ll see that come back up.

One of the most interesting byproducts of the transition, fully underway around the world, to XML based document formats from binary alternatives, is the ability to treat the asset as a container of items rather than a discrete item itself. Both ODF and OOXML allow applications to manipulate the contents of assets that were previously opaque at a minute, granular level, even as their respective proponents would doubtless argue their respective superiority at that particular game.

For those of you – and there are one or two at least, I’m sure – that are not office format wonks, here’s the English translation of the above: the files that you today produce in Excel, Powerpoint, or Word can now be carved up, dynamically reassembled and presented. Annual reports can contain continually updating economic data, mortgage applications real-time interest rates, or – nearer and dearer to my heart – baseball scouting reports, moving performance data.

Documents today can have, as IBM’s Doug Heintzman noted last Wednesday at IBM’s annual analyst event, more in common with a web page than the document you or I might have authored a few years – or a year – ago. Parts of it might be static, parts of it might be dynamic, but each of those parts might arrive from separate, external sources of record. The days of static documentation are drawing to a close, thanks to innovation – finally – in an area that should have seen it years ago.

While we at RedMonk are so far out on the bleeding edge that we can’t even see the mainstream when it comes to our own work habits (though not our coverage, hopefully), it’s nevertheless worth noting that I really don’t create documents at this point. Customer, expense and other operational spreadsheets are kept in Google Docs, and frankly they’re more webpage – even database – than they are spreadsheet at this point. At no point in their lifecycle, generally, are they transmitted as ODF, OOXML, or PDF: I can’t honestly remember the last time I exported one for the purposes of sending. When we need to collaborate with an external party, we simply share the asset. Even the pieces I author for this space are documents only in a nominal sense. Each is composed in emacs, then pasted to WordPress. There, it is reforged as an entirely different asset, pulling in pictures, videos, or other embedded assets, all while collecting comments, trackbacks, and revisions to become something new and distinct.

Is that a document? I’d argue not.

The closest I come to creating documents, at least in the traditional sense, is in Impress – the OpenOffice.org Powerpoint alternative. This I use to create the presentations I deliver at conferences, customer events and the like. The presentations tend to be discrete, unevolving assets that I “share” simply by posting them to the web. We do reuse presentations (occasionally) and slides (frequently) within RedMonk, but for the most part presentations are not living documents in the way that a customer spreadsheet is.

But that’s the exception to the rule, which is living assets, and it’s driven primarily by technical limitations. Limitations that I hope are removed. Soon.

For us then, settling on the definition of a “document” is problematic, because it reflects a lifecycle and a lifespan that are, at best, antiquated. Much, if not most, of our output is collaborative, rather than singularly authored, and most of it has a life expectancy far beyond any of the Word documents I authored in my capacity as a systems integrator. Particularly the content that lives on the web. A document, for me, has become a snapshot of the real, living asset, rather than an asset in and of itself. If our Google Doc’s spreadsheet is the Platonic ideal, the ODF capture of it is merely the shadow on the wall.

Which begs the question: are we creating documents, really, anymore? What does document mean in a networked, composable, and programmatically manipulable age? Or perhaps your natural inclination might be – like mine – to view the above as splitting hairs, a pointless, unresolvable debate of semantics.

Whatever my natural inclination might be towards such questions, however, my considered opinion is that the question matters. Maybe a lot.

Not to me, personally. First, because as mentioned, I live on the cutting edge and I’m not terribly relevant relative to the average office user of today, or maybe three to four years out. But more because I’m in a position to realize how documents are evolving, and what they might be capable of if we can get creative. The terminology is not going to have much bearing on what I think of a given technology.

Not everyone is so lucky, however.

As I see it, the danger in continuing to call the content we’ll be creating – using a rapidly evolving set of tools – over the next few years “documents” is that it will stunt the imagination. An example: when I was approached, years ago, about attending the ODF Summit, I had to explain in detail why I believed that messaging (email) and collaboration (wiki) vendors should be included in thee discussion. So tight was the focus on an “office productivity” format, it was non-obvious even to some ODF experts that wikis might, at some point, become consumers and producers of ODF.

The term document, in my view, is a legacy term, and as such, it brings with it preconceived notions of what a document is, should be, and can be. My concern, then, is that these preconceived notions end up predetermining the perceptions of what the assets are capable of.

To be sure, we should not – must not – try to reframe the traditional definition of a document. For those mainstream folks that will make up the bulk of the user population for the foreseeable future, their definition of what a document is is set, and it would be folly to try and change this.

But neither should we let that definition carry forward, tainting more capable formats with the legacy of its limited capabilities. No, we need a new definition or term, I believe. Something more accurately descriptive, and yet non-threatening. Database? Too intimidating, too misleading. Web page? Likewise. Container? I don’t love it.

So I don’t have the replacement term worked out yet: sue me. That doesn’t change the fact, in my opinion, that we’ll need one.

And if the format advocates have their way, probably soon.

Three years ago come August, O’Reilly’s Nat Torkington, interviewing Sun’s Jonathan Schwartz, pressed the CEO on the issues of patents generally and DTrace patents specifically.

Torkington’s question? “So if the Linux kernel were to implement DTrace, Sun wouldn’t employ the patents against them?”

Schwartz’ answer? “Knock yourself out.”

That was 2005. Fast forward to 2008. As one of the DTrace engineers has noted, Paul Fox is taking Schwartz up on that challenge.

As the FreeBSD and OS X engineers can tell you, the task of porting DTrace to a platform other than Solaris is non-trivial in the extreme. On the other hand, as they’ve both been successful (or in progress, in the case of FreeBSD) – with the kind assistance of the DTrace team – it clearly can be done. Where there’s a will, there’s a way and so on.

Making Fox’s work more compelling is the code. Or rather, the fact that there is code. That alone elevates this from an interesting but ambitious idea to potentially fascinating project.

Merely potentially because the appetite for DTrace within the Linux ecosystem would be, how do I put this, uncertain. Some view the technology as marketing coolaid, some argue it’s far ahead, and others, well, they’re undecided.

Undecided, at least in part, because there’s already a project within the Linux ecosystem to provide DTrace like functionality. SystemTap is a project we’ve discussed in this space before: a little over two years ago, to be precise. At that time, I said the following:

Anyhow, still undetermined for SystemTap is when/if a.) SystemTap makes its way into mainstream commercial and non-commercial distributions and b.) the required kernel modules, KProbes and RELAYFS (both of which I had to add to my kernel, necessitating two separate compiles) become standard. Until that happens, DTrace has an advantage over its Linux counterpart.

How does SystemTap score on those metrics? Well, on the Ubuntu Hardy machine I’m writing this on now, SystemTap is available for install. Which is good. Less so is the fact that kernel developers called the technology, on list, “klunky and prone to break in unexpected ways” (see Frank Ch. Eigler’s response to that charge here) just four days ago. As a related aside, I was interested to read that with respect to user space probing – an ability I’d believed to have been added – is not there yet (“We’re finally getting very close in this“) two years later.

What does this tell us? That the problem that DTrace and SystemTap both are trying to solve is hard; exceedingly so. Further, that DTrace merely by its production availability and accessibility to mere systems administrators owns a significant edge over its Linux based competition. Whatever the marketers on either side might say.

What we don’t yet know, however, is where things go from here: there are too many variables to make predicting a reasonable exercise. Can DTrace be successfully and completely ported to Linux, technically? Assuming the licensing issues cannot be resolved via technical workarounds, are Schwartz’ 2005 words sufficient legal grounds to stand on? If not, what does that mean for Fox’s project?

And even if DTrace can overcome the daunting technical and legal obstacles to find a new home in Linux, would anyone use it? Or would NIH preempt its adoption?

One answer, at least, we have. While many would probably argue that a DTrace port to Linux would be disastrous for Solaris and OpenSolaris – that DTrace was one the reasons the CDDL license was originally selected for the latter project, in face – the engineers that built it appear to be standing ready to help, should anyone be inclined to ask.

Technically, at least, the decision between DTrace and SystemTap would appear to be straightforward. While I know SystemTap advocates champion the greater reach of SystemTap’s guru mode among other differentiating factors, even the Linux kernel developers are admitting – implicitly and otherwise – that DTrace is the better choice at present.

When it comes to Linux and Solaris technologies, however, decisions are rarely if ever straightforward, and even more rarely made strictly according to the technology.

Which means that this should be an interesting space to watch.

Disclaimer: Many of the principals on both sides of the DTrace v SystemTap divide are clients, including IBM, The Linux Foundation, Red Hat, and Sun. On a personal level, I know many of the DTrace developers, and the SystemTap guys were kind enough to send me both a sticker and a mug after I complained that the DTrace guys didn’t have any.

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.