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.
One of the interesting threads within this year's O'Reilly Open Source Conference (OSCON) was a variety of collaboration tools and platforms aimed at what might be called "mid-weight" collaboration. Which is to say, collaboration that is something more than mailing lists or user forums but something less than the code repositories that primarily target a core group of developers.
Here's the basic issue. Some popular projects, such as the Linux kernel, have a pretty broad range of contributors. However, many other projects--even successful ones--are the product of a much more constrained group of people. With open-source software specifically, a big part of the problem is that it usually takes considerable effort even for experienced developers to understand a code base well enough to make useful contributions, And, of course, not many people are experienced developers.
Even beyond software development, as shown in the Gartner Group graphic in this post, only a small minority of any community is highly active. To use Gartner's terminology, "Contributors" and "Opportunists" significantly outnumber "Creators." (Unsurprisingly, the largest group are "Lurkers," which is to say basically users.)
Thus, the challenge is to harness the diffuse energy of a community in addition to the energy concentrated in a relatively small number of core individuals--the "Long Tail" of content creation if you would.
Here are a few examples of the work in progress.
JasperForge is perhaps the project that's most explicitly about harnessing the contributions of nondevelopers. The community here are those associated with Jaspersoft (Open Source business intelligence) and related projects. (There are currently 227 public projects and 70 private projects.) Individual projects setup a portal that includes only the components they need. For example, a documentation project could have a wiki and shared files but not a code repository.
Launchpad is the creation of Canonical, the commercial entity behind Ubuntu. It recently got a major redesign for its 2.0 release. For our purposes here, one novel feature is a Web-based translation and review component that allows contributors to provide translations of strings in the program into any of up to 265 languages. It also includes a community support component that lets users create FAQs and build a searchable knowledge base of previous answers.
Finally, Sun's Zembly--currently in private beta--is a collaborative tool for building applications for social media, such as Facebook. A lot of these applications are pretty small and simple and they often lend themselves to reusing code from other similar applications. For example, if you have a widget that displays a group of photos from Flickr, another widget that displays a different set of photos, but in a similar way, can pretty much just cut and paste a lot of the first widget's code. In short, it's oriented for the lightweight code sharing and reuse that characterizes many of this type of application.
The need for sophisticated version control and code repository systems isn't going away. However, we're starting to see those systems complemented by new techniques that either layer tools for more casual contributors on top or that explicitly target lighter-weight collaboration from the get go.
With its scheduled April 24 release of Ubuntu 8.04, which also goes by the alliterative moniker "Hardy Heron," Canonical will ship its second "long term support" (LTS) version. But the first, really, since the company and distribution became widely popular.
There's always been a bit of a flavor-of-the-month aspect to Linux distributions other than the big two: Red Hat (along with its Fedora community version) and Novell's SUSE. Gentoo grabbed headlines one year; Mandrake was supposed to make the Linux desktop a widespread reality another year. It might be tempting to paint Ubuntu's current popularity in a similar light but I think that would be unfair. Ubuntu is really a more consumable flavor of Debian--which has long been a popular non-commercial alternative to Red Hat and Novell but has equally long held a reputation for being geeky (as in hard to install and configure) and for having a often prickly community.
The relationship between Ubuntu and Debian is more fully described here, but in a nutshell, Ubuntu is built on top of a Debian foundation but has its own community and release process. Ubuntu is also supported by a company, Canonical, whereas Debian is an (aggressively) volunteer effort.
Hardy Heron comes in two builds, one with packages oriented around server use (Ubuntu 8.04 LTS Server Edition) and another around desktop applications (Ubuntu 8.04 LTS Desktop Edition). The two different builds also have different support windows during which Canonical commits to release security fixes and other updates. For the server it's five years; it's three for the desktop. Gerry Carr, Canonical's marketing manager, told me that's it's also possible that the server edition could also end up shifting to a longer cycle between releases than the desktop version--although no decision on this has yet been made. The idea is that the balance between stability and having the latest and greatest tends to tilt harder towards stability in the server world than on the desktop.
Gerry also said that Canonical has started putting more focus on the server edition and its associated community than it has over the past couple of years. Today, Ubuntu is generally perceived as an easy-to-install desktop Linux distribution. Outside of some specific areas, such as its (unsupported) port for Sun UltraSPARC hardware, Ubuntu isn't viewed so much as a server distro. Canonical wants to change that.
Ubuntu's release schedule is currently configured to have an LTS release about every two years with non-LTS releases (which have 3 year and 18 month support windows for server and desktop respectively) filling in the gap about every six months. Thus, in 2006, we saw the release of Ubuntu 6.06 LTS followed by Ubuntu 6.10, Ubuntu 7.04, and Ubuntu 7.10. The interval between LTS releases is similar to that for Red Hat's and Novell's Enterprise releases. The difference with Canonical's scheme is that there is no separate stream of community releases. Rather, certain releases are designated LTS to give hardware and software manufacturers longer cycles for their certification process. Both LTS and non-LTS releases can be downloaded and distributed at no charge with the option for a support subscription also available in both cases.
Canonical says that they have relationships with more than 30 PC manufacturers (many of them regional) as well as dozens of commercial ISVs, Open Source and otherwise (IBM Lotus Notes, Parallels, VMware, Alfresco, Zimbra, etc.). The nature of the relationships vary. Essentially, support in this context means that Canonical guarantees that the package will install smoothly on their distribution. However, whether a given application is supported, by Ubuntu or the ISV, in the sense of "I want someone to fix my application because it's crashing" will depend on the specific commercial relationship. Thus, not all supported applications are necessarily "certified" in the sense that term is typically used in support contracts for commercial operating systems and applications.
However, at this point in time, I don't see a lot of call for another Linux distribution in the Red Hat Enterprise Linux or Novell SUSE Linux Enterprise vein anyway. These companies put a lot of effort and resources into getting lots of applications fully-certified for their platforms. At Brainshare last March, Novell's Linux marketing director Justin Steinman told me that getting even more apps certified, and thereby close the gap with Red Hat, was one of his highest priorities. And you pay for that effort and the peace-of-mind it brings when you purchase a support contract. Canonical's offer is softer and cheaper--more pitched to those who have been running Debian either unsupported or through a third-party support contract with the likes of HP.
You can read an interview of Canonical CEO Mark Shuttleworth by CNET News.com's Stephen Shankland here.
- prev
- 1
- next
