The Pervasive Data Center

[Update: Additional commentary from Stephen Hemminger added.]

Microsoft set off a barrage of commentary earlier this week when it released three drivers under the GPL v2 to be part of Linux. The main purpose for doing so appeared to have been to make Windows Server and Hyper-V more effective as a virtualization foundation for Linux guest operating systems.

I was less shocked by the news than some. It struck me as a smart business move by Microsoft to further dispel both the reality and appearance of not playing well with other operating systems and tools. From a practical perspective, offering technology to Linux that lets it work better with Windows pretty much had to be done in the form of open-source code. At the same time, the Microsoft of today is far more accepting of the fact that like it or not, Linux is going to be a fixture at many of its customers and they're going to have to live with that.

Thus, releasing these drivers seemed to make a lot of sense and, while it was clearly a big step on the part of Microsoft, it certainly wasn't inconsistent with the company's recent posture toward open source, especially since Sam Ramji came onboard to be senior director of platform strategy.

However, it now turns out there's another layer to the story.

On Monday, Stephen Hemminger made a posting to his blog, Network Plumber's Journal. Stephen is a principal engineer with Vyatta, an open-source networking infrastructure vendor. Prior to Vyatta, he was with the Open Source Development Labs (and then the Linux Foundation) and was one of the largest contributors of Linux kernel code (PDF).

This saga started when one of the users on the Vyatta forum inquired about supporting Hyper-V network driver in the Vyatta kernel. A little googling found the necessary drivers, but on closer examination there was a problem. The driver had both open-source components which were under GPL, and statically linked to several binary parts.

The GPL does not permit mixing of closed- and open-source parts, so this was an obvious violation of the license. Rather than creating noise, my goal was to resolve the problem, so I turned to Greg Kroah-Hartman. Since Novell has a (too) close association with Microsoft, my expectation was that Greg could prod the right people to get the issue resolved.

It took longer than expected, but finally Microsoft decided to do the right thing and release the drivers.

By way of brief background, the GPL under which Linux is licensed considers static linking--the combination of software components by a developer--to create a "derivative work" of those components. There are a lot of complexities, nuances, and ambiguities, but for our purposes here, the bottom line is that if you statically link GPL libraries or other GPL'd code into your program, the entire program has to be released under the GPL.

Which Microsoft had not done.

I had a conversation with Stephen Hemminger, who initially reported the potential issue with Microsoft's driver, and he provided me with some additional technical specifics. According to Stephen, the issue revolves around a feature of the Linux kernel called EXPORT_SYMBOL_GPL that allows for interfaces to be marked as only available to modules with a GPL-compatible license. From Stephen's perspective, Microsoft's proprietary code had to use some of these interfaces that "the kernel did not want to offer to non-GPL [code]."

If that all seemed a bit geeky technical, well it is. Very possibly a violation of the GPL but hardly one that is simply flagrantly flouting the law. And, from Hemminger's perspective, "once Microsoft was aware of it, they were eager to resolve." He said that he first discovered this in March, so four months is actually fairly rapid resolution as such things go in large companies.

Greg Kroah-Hartman, who is a fellow at Novell and was very involved in the open-sourcing of the Hyper-V drivers, certainly seems to believe the licensing problem played a role in Microsoft's decision. In an e-mail exchange with ZDNet's Mary-Jo Foley, he writes:

MJF [Mary-Jo Foley]: Hemminger is claiming Microsoft put the LIC code under the GPL because it was in violation of the GPL. Is this true? Did you have to suggest to (Microsoft Platform Strategy Chief Sam) Ramji & Co. that they were in violation in order to get them to agree to release the code under GPLv2?

GKH [Greg Kroah-Hartman]: I didn't have to "suggest" anything, I only had to merely point out the obviousness of the situation  :)

MJF: If this isn't accurate, could you let me know how to interpret (Hemminger's) comments on his blog.

GKH: No, that sounds accurate.

Microsoft itself hasn't commented on the matter.

Based on what we know at this point, I draw a couple of conclusions. The first is that if Microsoft were the Microsoft of five years ago, it would have found some way to mitigate the problem that did not involve releasing code for Linux under the GPL.

At some level, it is now philosophically attuned to working with Linux in a way that it wasn't when one of Sam Ramji's predecessors, Martin Taylor, could be described as "Microsoft's Top Anti-Linux General."

But that said, it seems more than likely that their little license problem provided, at the very least, a forcing function to make their GPL contribution happen.

I had planned to leave the Google Chrome OS discussion to others. It's not that I don't have strong opinions about it but with a commentariat noise level approaching the Michael Jackson ruckus of Tuesday, I figured I'd try to wrap up a client project instead. I did so and I've been getting questions all day, so I thought it would be useful to put down my thoughts in a systematic way rather than answering every query ad hoc.

Let me start out by making what is probably a controversial statement. I don't see this as a big deal. Microsoft is not now radioactive. The Force has not been disrupted. The computer industry does not look different than it did yesterday.

Look. Just about everyone has been assuming that Google was going to bring the Google Android operating system that it developed primarily for smartphones to low-end notebooks. While Chrome OS is different from Android, it's conceptually pretty much the same thing--an open-source operating system built atop a Linux kernel.

So now Google has pre-announced that it's going to do basically what everyone figured it was going to do. Sorry, but that doesn't make me want to run through the streets shouting and hollering.

This is, in many respects, just another Linux distribution. And Linux has (speaking charitably) not had the impact on the general-purpose PC market that its supporters once hoped it would. Sure, enthusiasts load Linux onto PCs and it can work quite well, but even at an open-source developer conference you'll often see far more Macs than PCs running Linux. I can't say that I understand why Chrome OS would succeed where Ubuntu has, if not failed, largely played to a niche.

It's Google we're talking about here to be sure. To which I say that Google has had plenty of failures: Orkut, Google Video, Knol, and Google Base anyone?

Fundamentally, I'm skeptical that anyone is in a position to seriously displace Microsoft and Apple from effective ownership of the general-purpose desktop and notebook space. There's so much ecosystem, most of all software ecosystem, in place that a new entrant would have to offer just overwhelming advantage. Which Linux didn't and doesn't.

There's a story here but it's not about displacing Microsoft.

Rather, I see Chrome OS as reflecting a change in the client and the way we access applications. To the degree that Chrome OS further illuminates and, by doing so, accelerates such change it may indeed be important in its own right. However, this is largely a change that's happening with or without Google--and certainly with or without anything Google does with respect to client operating systems.

And it's this macro-trend that's the real threat to Microsoft, not Chrome OS. Microsoft's franchise is built in no small part on having become the de facto standard API for programs running on another de facto standard that we colloquially call the PC. That franchise may be hard to crack (although Apple has had a degree of success) but that franchise doesn't necessarily carry over to new areas where far less software is locally installed and therefore a "standard API" becomes much less important.

The Linux desktop (whether Chrome OS, Ubuntu, or whatever) won't be your father's PC and it may not even look like a PC at all. That's the far bigger threat to Microsoft. Not that it won't be able to defend its existing franchise but that it will be cut off from extending that franchise into computing that happens over the Net rather than locally.

We most associate hypervisors and virtualization with servers from their beginnings as tools for development and testing, through their widespread adoption as a means to reduce the number of physical servers needed, to their current stage as a foundation for dynamic IT architectures. Virtualization on the client side has been more of a niche  although application virtualization continues to grow in importance and some specific uses, such as running Windows applications on Macs, have proven quite popular.

As for embedded devices, special-purpose computers, virtualization has had essentially no impact.

That's beginning to change. Wind River, one of the major players in embedded operating systems and recently purchased by Intel, today announced the availability of Wind River Hypervisor. From the press release:

Wind River Hypervisor enables virtualization for devices across a broad range of market segments, including aerospace and defense, automotive, consumer devices, industrial, and networking. Within these markets, embedded developers are adopting hypervisors to enable the replacement of multiple boards or CPUs with a single board and/or a single CPU, create innovative new devices that leverage multiple operating systems, and reduce complexity when integrating multicore processors. The benefits of using the Wind River Hypervisor include reduced hardware costs and power consumption, opportunity for innovation, and accelerated time-to-market.

This hypervisor can be employed in a number of different ways on a multicore processor. For example, it can be used to run multiple operating system (OS) and application instances on a single processor as a way of enabling single-threaded applications to access multicore performance.

However, what's probably the most interesting use case is consolidating different operating systems on a single processor--and thereby potentially reducing the otherwise need for separate chips or devices. This hypervisor targets two primary operating systems: Wind River's VxWorks and Wind River Linux. To understand why mixing these two might be interesting and useful, consider the differences between them.

VxWorks is Wind River's proprietary "hard real-time" operating system. It's widely used in places like aerospace and defense (think radar, avionics, and so forth) and the data processing of network gear.

Real-time, in general, refers to operating systems and software that have a very predictable response time to events. Predictability runs in opposition to overall throughput so commercial operating systems have historically not been real-time operating systems. Hard real-time typically refers to the need to have truly guaranteed response with the possibility of failure or damage if a response is not made in time.

Wind River Linux is the company's version of Linux optimized for embedded devices. In 2007, Wind River acquired FSMLabs, a real-time Linux vendor, to augment its Linux efforts. Wind River had earlier had a partnership with Red Hat, now discontinued.

Without going into all the gory details of schedulers and so forth, suffice it to say that the real-time characteristics of Linux have improved considerably over the years. Furthermore, various patches can further optimize Linux for real-time uses. Today, we see Linux in applications (such as this IBM/Raytheon deployment) that would have historically been well outside the realm of even customized general-purpose software.

That said, an operating system like VxWorks retains a specialized focus on real-time and comes in versions that carry stringent certifications. Thus, there are many situations where it may make sense to use VxWorks for those parts of an application that require those certifications or are otherwise better served by the specialized real-time OS. At the same time, Linux may be a better fit for other parts of the application that can leverage the Linux ecosystem for components such as user interfaces.

In addition to having different technical requirements, embedded systems make for a somewhat different virtualization use case than in enterprise IT. In embedded, operating systems remain far more specialized and bespoke and this makes the ability to mix and match them on increasingly powerful and multicore processors very useful. This is another face of increasingly pervasive virtualization.

The enterprises, vendors, developers, analysts, and journalists I speak with regularly are mostly pretty savvy about the basics of open source at this point. Even if they're not licensing geeks or otherwise expert in all the minutiae and subtle implications of open-source development, community, and usage, they generally have the important basics down.

However, as I read Rice University computer science professor Dan Wallach's detailed and thorough critique of an Election Technology Council white paper on open source in voting systems, I'm reminded that there are still a lot of misperceptions about open source among the broader public.

A lot of people are quick to dismiss such confusion as evidence of sinister plots to deliberately undermine open source. No doubt, some is indeed willful misunderstanding, or simply disinformation.

But certainly not all. I've personally heard longtime friends from outside the tech industry voice many of the same beliefs. Many of these fall into one of two buckets: open-source software depends on the support of some nebulous "community," and open-source is less secure because bad guys can use the code to find vulnerabilities.

With respect to the first point, this discussion in the ETC paper is typical:

Due to the volunteer nature of an open source model, the issue of accountability in this environment provides a stark contrast to the accountability within a traditional proprietary offering. In commercial product offering, the individual company is held accountable for delivering a product that meets all applicable standards and for meeting project milestones. Contract requirements are often used to establish performance milestones and clearly delineate the responsibilities of a provider. Within a corporate structure, liability is clearly delineated to the company. In an open source environment, a volunteer group of collaborators will not be so clearly subject to financial liability or have a clear line of accountability. It is possible that a hybrid approach could be undertaken for an open source project which is launched in partnership with a private company, but the issue of intellectual property investment and concerns over the long-term viability of the company's product will likely trigger a need to adopt a more restrictive licensing approach, one more indicative of a traditional proprietary model.

In part, this is a case of conflating open source of circa 1997 or so with open source of 2009. It also reflects that most of the people who are loudest about open source as a social movement emphasize hobbyist communities rather than corporate sponsorship and in-house professional development. Indeed, these people often decry the latter as a betrayal of free-software principles.

The reality for most commercially important projects is much different. The bulk of the development is directly funded by IT vendors for self-interested reasons. In the case of the Linux kernel, the work is shared by a large number of companies. Other software, such as JBoss and MySQL, are primarily worked on by developers at a single company.

Support for major open-source software is similarly commercialized. Although "community support" (that is, forums, blogs, Twitter, etc.) may often in fact be pretty good mechanisms to track down fixes, they're not the only one. A Red Hat Enterprise Linux customer, for example, can get support in exactly the same way that someone with a support contract for Microsoft Windows would.

As for the security question, I look at it largely as a case of analogies gone bad. Typical is this line from a paper on Linux security by a public policy expert that I was asked to review a few years back: "it would seem to stand to reason that if keeping passwords, access numbers, and other aspects of system security secret, keeping code secret might be one way to enhance security."

It all sounds reasonable. After all, even if I think I have a solid security system installed in my office I don't stick its specifications and layout on a piece of paper and nail it to my front door.

However, as Wallach notes:

What we learned from the California Top-to-Bottom Review and the Ohio EVEREST study was that, indeed, these systems are unquestionably and unconscionably insecure. The authors of those reports (including yours truly) read the source code, which certainly made it easier to identify just how bad these systems were, but it's fallacious to assume that a prospective attacker, lacking the source code and even lacking our reports, is somehow any less able to identify and exploit the flaws. The wide diversity of security flaws exploited on a regular basis in Microsoft Windows completely undercuts the ETC paper's argument. The bad guys who build these attacks have no access to Windows's source code, but they don't need it. With common debugging tools (as well as customized attacking tools), they can tease apart the operation of the compiled, executable binary applications and engineer all sorts of malware.

In short, access to software (whether open source or just disclosed source) is not the unlocked door that many non-developers assume it is.

Cryptography provides another example. The mechanisms used by most protocols to encrypt and decrypt data are well-documented. They don't depend on secrecy to work. They depend on an untenable amount of computational power being required to decrypt in the absence of private keys.

And the converse offers further proof. Weak encryption algorithms that depend largely on secrecy are often compromised relatively easily; the Content Scramble System (CSS) used on DVDs is a textbook example.

I take all this as a reminder: don't assume things that "everyone knows" really are.

This post by Michael Dolan at IBM is spot on:

Here's the thing, everyone who hears "Linux desktop" has a knee-jerk reaction and thinks of all the things they do on their own PC, laptop, Mac. The reality is you're probably not the target market for virtual desktops. The market is large desktop environments that have thousands (perhaps tens of thousands) of users and who are not doing consumer-oriented work (or shouldn't be). The cost savings of moving from physical PCs in a 1 user to 1 PC model to a managed model with virtual terminals can be significant. We'll see where the market goes for this model, but I know of a few very large companies that want to make this model very real. The economic situation and the impact on IT budgets may act as an accelerant.

Much of the time when I write about the evolution of Linux or the evolution of the client, I get lots of comments revolving around the lack of popular games for Linux or whether the GIMP can replace Photoshop. And, of course, the partisans for whom it's important whether Linux "wins" or "loses" to Windows or Mac OS X jump in with their various ideological objectives. 

Idealogues and fanboys aside, however, part of the problem is terminology. "Desktop" gets used to refer to at least a couple of different things. One is the traditional, general purpose PC as we've come to know it over the past 20 years or so. The other is a shorthand for any client device with a keyboard and monitor. The former is a "fat client" with all that implies for a broad range of hardware support and available applications. The latter is more specialized. It may run only a limited subset of applications. Or it may run primarily network-based applications through an interface, such as a browser. Whatever the details, it's effectively much thinner--whether or not it's actually a thin client.

I'm not going to argue that Linux can't function as a reasonably general-purpose PC operating system. For example, developers who want a desktop, or more commonly a notebook, that runs Linux have lots of good distributions to choose from that (mostly) install straightforwardly. Ubuntu is a current favorite. But that's not mainstream mass market. And for reasons that I've gone into previously, such as the dynamics of independent software vendor support, I never expect it to be such if we're talking an operating system in today's Windows or OS X mold.

But the way that we access applications is changing. Many clients are predominantly platforms for browsers or they serve a very specific purpose. Virtualization could also change how we run an operating system or systems on our PCs and other devices. In short, there are plenty of roles for Linux on the "desktop," but it's not the desktop as we've historically known it.

About this time last year, I took a look back at some of the macro trends that hit their stride during 2007. I thought it would be interesting to see which of those trends are still noteworthy, which new ones are on the radar, and generally how the landscape has changed.

Server virtualization remains perhaps the hottest trend in IT. It may no longer be pegging the hype meter quite as hard, but that's only because server virtualization has moved into the mainstream. It's ever more clearly one of those fundamental developments that touches and transforms all manner of associated technologies, products, and processes.

To be sure, lots of virtualization customers are still using it for relatively straightforward server consolidation, but more and more are also implementing high availability and other services on top of a virtualization foundation. One notable event during the year was the ouster of Diane Greene from VMware's helm, but so far, neither this nor Microsoft's increasingly aggressive virtualization efforts have had a substantial impact on VMware's position as market leader.

Alternative clients are ways of provisioning applications and delivering software services that differ from the loading up of an operating system and clients on a traditional PC. This includes accessing applications through a browser interface. It also includes a variety of technologies that, collectively, keep desktop applications and/or operating systems in the data center, and push them out to user devices--including, but not limited to, thin clients--in a managed way.

This trend continues to gather pace, albeit in a relatively measured way, with security and compliance often the primary driving force. Most major virtualization players have steadily broadened their portfolios to encompass both client-side and server-side virtualization, taking advantage of one with the other.

Power and cooling, or more broadly, "green," remains at the same relatively nascent level as last year, when I wrote that "power and cooling is increasingly something that IT staffs think about--even if, in most cases, they're not the absolute top-of-mind worry that is sometimes suggested."

Running out of power or space in a facility remains the primary reason that companies take substantive action on major clean-technology projects. Because power bills are usually in someone else's budget, even operational cost savings--never mind generalized environmental concern--don't have a big impact on decisions absent high-level corporate mandates or governmental regulation.

Intel's resurgence continued in 2008, as it ramped its 45-nanometer processors. For its part, Advanced Micro Devices did take steps to repair the damage caused by its delayed "Barcelona" processors. Its 45nm "Shanghai" processor shipped ahead of schedule, lending credence to company claims that its development and manufacturing processes were back on track.

On the financial front, AMD put its Asset Smart plan in motion--essentially spinning off its fabrication plants and people as The Foundry Company, and taking a major investment from Abu Dhabi-based organizations. However, Intel retains a much stronger financial position during an economic period that is likely to be extremely challenging for the semiconductor business.

Open source and open-source licenses certainly didn't go away in 2008. But I don't really view them as a trend at this point any more than programming languages or databases. They're just part of the software landscape--a way to develop and market software.

Open source has, in a sense, won, and one of the consequences is that the license wars are largely over because of an implicit consensus that open source has proven to be a good development model that doesn't need a lot of protection through legalisms.

In particular, very few people are showing much enthusiasm for the Affero GPL, a license whose intent is to extend the GPL's restrictions (enhancements have to be contributed back to the community) to software delivered in the form of a service. Yet that's how an increasing amount of software will be used.

And that's really the trend that emerged in force this year: "cloud computing," a term that I use to refer broadly to using software services or infrastructure over the network.

To be sure, there's more vendor hype (and consumer use in the guise of Web 2.0) than there is enterprise adoption. And I strongly suspect that will remain the case for quite some time. Part of the reason is that deployments will tend to happen with new applications rather than legacy ones.

However, more broadly, enterprises will want to understand and have the tools to manage attributes such as security, compliance, and portability (including the ability to run applications on-premises, off-premises, or a combination of the two).

Is cloud computing a legitimate trend? Yes. And it will be a long-term trend, so just count this as a start.

If the license wars aren't over, they've certainly muted.

The adoption of the new version of the General Public License, used by Linux and many other open-source projects, was a long, loud, and contentious process. But after all the sturm und drang, it's not clear to me what real impact GPL 3 will have.

Depending on whom you ask, clauses concerning ideological sticking points such as digital rights management were either narrowed in scope or defanged almost completely. And it seems entirely possible that Linux, perhaps the best-known open-source project licensed under the GPL, may never move to the new license version.

More broadly, I just don't feel that there's a whole lot of interest, much less passion, out there in the various open-source communities for fighting license battles. That's not to say that everyone agrees that there is one perfect approach to licensing. Not all all! But there is, for the most part, a pragmatic understanding and a realization that the license for a given open-source project has to match up with its governance, collaboration, and even business model. It's just one piece of the puzzle.

In a similar vein, there are just so many accumulated examples of different approaches that have succeeded. Yes, Linux is successful, and it uses GPL 2. But the very popular Apache Web server uses a much more permissive license (in the sense that enhancements don't need to be contributed back to the commons). The Firefox Web browser uses a license that's somewhere in between.

We've also accumulated a lot of evidence that open source is simply a pretty effective development model that can bring a lot of benefits to those who use it. As a result, there's less of a sense that open source needs protection through a restrictive license.

None of this is to say that lawyers and license geeks don't sometimes get into squabbles over how various licenses interact, and so forth. But, in the grand scheme of things, these are micro issues, not macro ones.

I think the best evidence for the winding down of the license wars comes from what's happening around cloud computing, which I define generally as software and infrastructure accessed in the network.

As I've written about previously, the provisions in the GPL, and many other open-source licenses requiring that modifications and enhancements to source code be contributed back to the public, often don't apply in a cloud-computing world. That's because accessing software in the form of a service over the network isn't "distribution," the event that triggers the requirement to make source code available.

Some view this state of affairs as a loophole, one that a variant on the GPL 3--the Affero GPL (AGPL)--explicitly plugs by expanding the definition of distribution to encompass the delivery of services over the network. The AGPL effectively remaps the rules from the original Unix-like environment in which the GPL was born into a network computing one.

What's striking to me is how few people seem to really care about the AGPL and the supposed problem it's trying to solve. Yes, there are the zealots who go apoplectic at the thought of open source being used for profit-making purposes. And there's a fair bit of discussion about how to best protect portability, privacy, and so forth in a cloud-computing world.

There's also no small degree of what might be best called social or community pressure on large cloud vendors such as Google to make meaningful contributions to open-source projects. But forcing all this through licenses? Not so much.

Ubuntu has been making gains on the server side of things. And that's likely where Canonical, the commercial entity behind Ubuntu, will earn its profits--as it hopes to do someday.

But its initial efforts on the client side arguably are what really helped shift the limelight to Ubuntu in the first place. Ubuntu gained the reputation of being easier to install and use than other Linux distributions--factors that have kept even many open-source enthusiasts from adopting Linux on their desktops or notebooks. And user experience remains a significant focus area.

Mark Shuttleworth, who heads and financially backs Canonical, is on record with comments such as "I think the great task in front of us in the next two years is to lift the experience of the Linux desktop from something stable and usable and not pretty, to something that's art." Or more broadly, to surpass Apple, in terms of desktop experience.

I strongly suspect that there are inherent trade-offs between the flexibility and choice associated with open source, and the unified approach (epitomized by Apple) that tends to be associated with good user interface design. But the bigger issue with mainstreaming the Linux PC has nothing to do with design and everything with where we are in technology history when it comes to accessing and interacting with software.

Writers of heavyweight client applications (think Adobe Systems' Photoshop, for example) don't want to support additional operating systems. Getting the latest versions of applications for its platform is even a challenge for Apple--resurgent sales and market share notwithstanding.

While there's lots of open-source software for Linux clients, there's a very modest amount of closed-source software available. This is not especially a knock on Linux, per se--though low software costs certainly contribute to Linux's attraction in some cases--but rather reflect the decades-long winnowing of the number of platforms that software vendors are willing to support.

There's also a general maturation of the PC operating system. Linux desktop distributions, Mac OS X, and--dare I say it--Windows are far more alike than they are different. You may choose one over the other to make an ideological or stylistic statement, to gain access to specific applications, or just as a matter of personal preference. But both differences and advances are increasingly at the margins.

I think we see some of this in the relatively slow take-up of Vista. The Microsoft haters blame Vista; the blame at least equally sits on the reality that Windows XP is a good enough desktop operating system for most purposes.

In short, I just don't see a lot of enthusiasm for another desktop operating system in the Windows or Mac OS X mold. This is especially so because it represents the past in many ways. Many new applications are running in the network, and the client--in its myriad forms, from desktop to smartphone--is merely a portal to access them.

In a sense, this is an opportunity for Linux. In a world where all you need is a browser and some other standardized client components, why not Linux? And, indeed, I expect that we'll see Linux on a lot of thinner clients, where it will act more as the underpinning for a browser than as a more generalized operating environment.

But I think that it is important to distinguish this from Linux, the desktop OS--as that term is normally used. This isn't about running games or editing movies on the latest quad-core Intel processor. This is about powering lighter-weight clients in which the operating system--and, especially, the general application support enjoyed by any given operating system--just doesn't matter very much.

Ubuntu and Canonical, the Mark Shuttleworth-founded commercial entity that supports it, have done something that seemed improbable a few years back. They've emerged as a third Linux distribution to have commercial market momentum on a worldwide basis. Prior to Ubuntu, the distribution landscape consisted of commercial and community-supported versions from Red Hat and Novell's Suse--together with some regional and "flavor of the month" distros. (See my "The Scene at the Distro" from April 2006.)

Canonical and Shuttleworth have managed to make Ubuntu into a third commercial Linux distribution that's here to stay; "Intrepid Ibex," Ubuntu 8.10, is the latest release and will be available this week. In one sense, Ubuntu simply represents the commercialization of Debian, an aggressively noncommercial Linux flavor that was long the long-favored distro of the self-identified techno-elite. However, Ubuntu distinguishes itself from Debian by its willingness to include proprietary components when open-source ones aren't available. This is especially important on the desktop (for example, codecs required for certain kinds of media support). Ubuntu has also received all manner of usability and "fit and finish" upgrades that make it far more consumable than the notoriously difficult-to-install-and-configure Debian.

At the same time, Canonical distinguishes itself from Red Hat and Novell in that it offers a single product (in desktop and server flavors); it does not have "enterprise" and "community" versions that are effectively separate distributions. The advantage (for customers) of this approach is that they can deploy Ubuntu for free and then, without changing the "bits," simply start paying for support when they go into full-scale production.

The downside (for Canonical) is that they have to persuade users to actually buy support. Historically, getting a high enough "conversion rate" with this business model has been difficult for open-source companies. Indeed, this was essentially Red Hat's initial model, abandoned in favor of having a separate Red Hat Enterprise Linux version. In general, proprietary software or services factor into a lot of the revenue that companies make around open source.

Viable long-term business models are no small thing, of course. Although Canonical now has a respectable number of paying customers such as Wikimedia, Mark Shuttleworth (who founded security firm Thawte and sold it to Verisign in 1999) continues to support the company to a significant degree. Supposedly, at some point, Canonical has to become self-supporting. (Although Shuttleworth has said that he has no objections to funding the business for three to five years.) And low cost, which is a big part of Canonical's Ubuntu pitch against Red Hat, also means that it's harder to make money.

That (big) caveat aside, however, Canonical has established a legitimate worldwide presence as a Linux supplier for businesses. It's had wins on servers and Ubuntu has emerged as pretty much the de facto desktop and notebook Linux choice for developers. That's no small feat given how many others have tried--and largely failed--to do so.