Chris DiBona's job--manager of Google's open-source programs--is a balancing act.
Google consumes a lot of open-source software for its own highly profitable business. But as he oversees the search powerhouse's open-source work, DiBona has to ensure that the company reciprocates. It can't be all take and no give.
Chris DiBona, Google's manager of open-source programs
(Credit: Stephen Shankland/CNET News.com)Free and open-source software advocates can be powerful allies--but also vocal critics. For example, some have critized Google for its lack of support for the Affero GPL license, which can require those using software for a publicly available network service to share modifications they've made to an AGPL software project.
DiBona thinks Google strikes the right balance, though, by offering its own modifications back to many open-source projects, advocating the philosophy in general, and trying to nurture the next generation of open-source programmers.
DiBona has been steeped in open-source software for more than a decade. Before his job at Google, he worked for Slashdot, still an influential virtual water cooler for open-source discussion. Slashdot was part of Linux server maker VA Linux Systems, which had a spectacular initial public offering in 1999 followed not long after by a drastic cutback.
DiBona will be preaching the open-source gospel at the Google I/O conference Wednesday--"open source is too good to be true and thus must be magic," according to the agenda--but I sat down with him beforehand to hear his view of open-source software at Google.
What's the view of open source within Google?
I asked myself, "Who am I trying to address?" The world of open-source business? No. The world of the open-source enthusiast? No. I'm really looking to work with open-source developers. We came up with these goals for our group: to support open-source development in general, which means to support open-source infrastructure; support the release of open-source code, from Google and in general; and to create more open-source developers, because especially when I started, there was a perception that Google took a lot of people from the open-source world and then went away. It was partly true, because people would come here and say, "Wow, I've been working on my open-source project forever, and I want a new problem," and we have a very good class of new problem. So they kind of went away.
That was too bad. The last thing we wanted as a company was to hurt the release of open-source software, because we consider it pretty important. We use a ton of it. Every engineer we bring on--how much open-source do they want to use? We have new packages and new libraries being brought into the company all the time. It's our group's job to track that. As we brought people in, we wanted to be sure more open-source developers were being created. So that's where we came up with the Google Summer of Code, and now we have a high-school flavor of that as well. I think we've made a very real impact in creating new people in the open-source world.
I'm curious about maintaining a balance between contributing back to upstream projects vs. maintaining your own internal forks. How do you go through that evaluation?
Google considers some projects more important than others. Obviously the Linux kernel is incredibly important. Every time you use Google, you're using a machine running the Linux kernel. We have a fairly large kernel team, and we employ people whose job is just to work on the external kernel. Andrew Morton is a good example of that. We try to make sure those guys patch out (submit their modifications to the main open-source project) whenever they can. It's usually more dictated by the engineer's time than it is any lack of desire on our part. I always wish we were able to release more, but it takes time for an engineer to do that. For the larger efforts, it's a little easier because there are more personnel on it.
The same thing goes for our compilers (software that translates programmers' code into instructions a computer understands). The great thing about our compiler team is they patch as a matter of their jobs. They're always patching out things from the compiler work we do internally to the outside world. We recently released the new linker, Gold--Ian Lance Taylor works for us on our compiler team. He's been on the GCC team forever. He used to be at Cygnus (a company that developed GCC). We have a lot of ex-Cygnus people.
Then there are Googlers who just want to patch into an existing projects. They found a bug, they want to add a feature. That takes no time at all. Our team looks at the first couple patches an engineer wants to send out, makes sure the engineer knows what they're doing with the outside world, then they're basically given free rein to do that. They keep us posted on what they're patching. We want to make sure our code gets out to the projects as fast as possible because projects keep on iterating. If you don't get your patches in, they won't get accepted, because they'll be too old or won't matter. If you've got a patch, getting it out there fast is better for us, because then as that project iterates and comes back into the company, we don't have to reapply a patch.
What are the most important open-source projects you ingest?
The kernel, compilers--GCC, the Python interpreter. Python is very important to us. Google App Engine--it's a Python hosting system, basically. Java is very important to us, and that's become open-source now. We have some very good Java people working for us--Josh Block, Neil Gafter--they've got a great handle on that technology.
Once you get past those three projects--the compilers, the languages, the kernel--then you go to the libraries. For us that's OpenSSL, zlib, PCRE. MySQL is hugely important to us. Past that, it starts tapering off pretty quick.
Has the open-sourcing of Java changed anything for you?
Not really. I think it had more impact on the outside world than for us. Java is a fairly mature language now. We've been using it for a long time. Before, it was the JCP (the Java Community Process to govern Java's future)--it had the rubric of openness around it. It was never really not so open. There are questions around what open source means now around Java, specifically J2ME (Java's mobile edition for gadgets such as cell phones) and the TCK (the technology compatibility kit).
Are you using a super-uber-customized Linux kernel, or are you guys pretty much vanilla?
I don't think there's such thing as a customized Linux kernel anymore. The kernel is incredibly flexible. It's got all these different architectures. I think the Linux kernel itself is this ubercustomized thing.
But do you have a lot of in-house customizations?
Not a lot. Google is exposed to some interesting hardware before the rest of the world. So internally we'll be sampling code for that hardware. So that's pretty custom stuff. But eventually that goes to the outside world. We funded some work with a group in Berkeley called Xorp to bring high-speed Broadcom networking chip functionality to Linux. It's not in our interest to keep control of it ourselves. So is it customized? Absolutely. But is it heavily customized? I don't think it is as heavily customized as you might think.
Is it true you still use 2.4 kernels?
In some places, sure.
How about for the core search product?
I don't know how it's partitioned out. When you think of Google, you think of search being on top of a kernel that's static. It's not always like that. It differs on data centers. I think 2.6 predominates, though.
I do worry about this. I think it is a largely incorrect perception. You can always give out more, and there are always people who will never be satisfied. Could we be giving back more? Sure. One of the ways I ameliorate that problem is (through) projects like the Summer of Code. Google is releasing every year, not counting Android or the really large open-source projects like GWT, a new project every two or three weeks. Or patching hundreds of projects a month. I conservatively estimate we're releasing about a million lines of code a year from the company.
If you talk to open-source developers--people who are working on projects--I think they understand that. It came back to who do we want to interact with. I always felt the enthusiast community would understand that eventually, and I think that's true. There are some people who are upset with us because we didn't embrace the Affero-style GPL, but it's not practical for us to do so. When they had an Affero-style clause in GPLv3, the thing I told Eben was, "Listen, you can adopt whatever you want. We'll still keep on backing up the FSF and the SFLC as much as we can, but it means we won't be able to use that license inside, because it won't be practical for us to do so." I think that's a very realistic response. The Affero GPL is out there. That's great for the people who use it. It's just not for us.
That's the thing about free software. You're not obligated to use it. We have enough fine-grained control within the company that we don't use things we don't want to use.
What are your preferred licenses?
We generally release under the Apache License--Apache 2. We think it has the fairest language of the licenses. And the GPL requires a lot of management--more than we have time for to run a project well under that license--patch flow and all that. Apache 2 encourages people to take the thing and run with it. That's what we're going for when we release code, whether it's to have people adopt technologies we really like, or for API examples. That said, we've released things under the GPL, LGPL, GPL version 3, BSD. We default to the Apache License.
To what extent to you subsidize gurus to sit around and work on important projects?
We've got people like Jeremy Allison and Andrew Morton and some of Guido (van Rossom)'s time. He's been working pretty heavily on Google App Engine and Mondrian. It's more common that we...try to make open source a part of their job, so they're patching out to the libraries they use. We think that's more healthy than having people whose job is just working on an open-source project.
We do. There are two ways we do this. When somebody wants to bring a piece of code in from the outside world--open-source or commercial--you need to put it inside a special directory we call "third party." They're required to put in a file called readme.google (that describes) where they got that software, how it's licensed, what category that license falls under. We look for things that are obvious. There are some projects that have dubious intellectual property provenance, and we know those, and we know the people who run them, and we tend not to use those ever.
Since Google doesn't distribute a lot of software, we have it easier than companies that ship hardware and software. We have a couple situations where that does happen--the Google Search Appliance, some of the downloadable applications. Those get a little extra attention. Similarly, when we have larger projects like Google Android, we have a higher ceremony--every two weeks we get together and see if the license picture has changed.
The tracking model works really well for us. We have tools written where a program manager or a release manager can turn on a certain level of warning within the build tool and it will tell them what open-source software they have and how they have to comply with it. At that point we set up a mirror for them as they get closer to release.
So that's the first way we track things. The second way is whenever a Googler puts in a changelist now--this is something we're just starting to do--we compare it against all known open-source code on the Internet using our Code Search product. We compare the changelist that comes from your average Google engineer against that database of code and we look for intersections. When we find an intersection, we take a look and see if it's truly a copy. And if it is, we make sure it's in the right directory and that it's properly labeled. And we call up the engineer if it isn't and make sure it gets tagged properly so we can do the right thing by these licenses.
That tool is kind of in its infancy. We're trying to figure out ways to automate what it does. But it's great because it scales programmatically. Our group's goal is not to break builds or stop development. It's to enable developers to use as much open-source as possible. We think it's healthy, because then they're not writing that code, they're writing other code.
Do you vet code for patent or copyright?
No. We have legal people on our lists. We have two main lists that track these things. Open-source licensing for incoming code and open-source releasing for outgoing code. Legal has a presence there. Patents are incredibly tricky.
Is it easier to get hired at Google if you have experience maintaining your own open-source product or patch?
If you have made a name for yourself in open source, clearly it helps. If you have a healthy project in open-source, I believe it helps. One thing I see on hiring committees is when somebody has an open-source history, it's really great. You can just look at that history. Interviews are great, but they're not very deep. They're only 45 minutes long. So how can you really get a feel for if a person is good at programming, at computer science?
Or at social relations, for that matter.
Open source really reveals that incredibly quickly. You can look at their code, at their activity on mailing lists, how they deal with bugs from real people, and real user problems. That's an incredible resource.
The Summer of Code isn't really a recruiting program. If it is, it's a really expensive one. Last year we created about 2 million lines of open-source code across the 900 students who took part. Of those probably a third are going to stick around with their projects, because the rest have to go back to college.
We have a couple students who have been in the program two or three years. The whole point is to support kids over the summer so they can go and program and not get some other job that has nothing to do with computer science. It's our fourth year doing it. This year we've go 1,109 students doing it across 95 countries.
Releasing 8.6 million lines of source code and expecting open-source programmers to join Google in its development is a technological challenge.
But when Google does make its Android mobile phone software an open-source project later this year, it looks likely it will take a page from the Linux playbook and use a tool called Git to manage that part of the work.
Linux leader Linus Torvalds originally developed the Git source-code management software in 2005. He didn't like available open-source tools for the chore, but encountered resistance in using a proprietary tool, BitMover's BitKeeper.
Torvalds liked the distributed approach enabled by BitKeeper and Git, in which individuals could maintain their own "trees," variations of a project that branch off a main trunk. Git also can be used to track and manage software patches sent "upstream" by contributors working on code branches to the programmers responsible for maintaining various open-source projects.
Google currently uses a source-code management tool called Perforce to manage Android, but the company is moving to another code repository technology in preparation for moving Android into an open-source project, said Android leader Andy Rubin.
"We need an open-source repository. Currently we're on Perforce. That has to be moved to Git," and there's an effort now to make the transition, Rubin told me in an interview about Android.
That sounded to me like Android had settled on Git, but Rubin wasn't willing to go that far. "We have no announcements at this time," he said.
Maybe we'll hear more at the Google I/O conference next week for programmers interested in Google's work. One theme of the conference is Android.
Benjamin Lynn of Google's developer programs group offered a basic guide to Git on a Google open-source blog posting this week. And Google uses Git elsewhere, for example, to help Linux kernel programmers with support for Qualcomm mobile phone processors.
Junio C. Hamano currently maintains Git.
One choice Google won't pick for source code management is the centralized Subversion software.
"Subversion we don't think is enough of a repository to handle 11 million lines of code. If this is adopted, and there are 10,000 people checking out, it'll die," Rubin said. (Android today consists of about 8 million lines of Linux code plus 11 million lines of higher-level code; of the latter, about 8.6 million will become open-source software.)
Canonical will announce Netbook Remix, its version of Ubuntu Linux tailored for mobile devices, in two weeks, Chief Executive Mark Shuttleworth said.
"We're announcing it in the first week of June. It's called the Netbook Remix," Shuttleworth said in an interview with the Guardian. "We're working with Intel, which produces chips custom-made for this sector."
Ubuntu has been working on a mobile version of its operating system for months. In an April interview about the release of the new Hardy Heron version of Ubuntu, Shuttleworth said the mobile version is sufficiently important that developing it is worth pushing back the company's move to profitability. The company has engineers working on-site at Intel, he added.
Ubuntu still has plenty of buzz, a remarkable feat given how many new versions of Linux have fallen by the wayside over the years. However, it's not all smooth sailing: the Ubuntu Live conference that had been scheduled for July has been canceled, though some content from the show is moving to the Open Source Convention.
MOUNTAIN VIEW, Calif.--Google didn't invent open-source programming or pioneer the mobile-phone software market, but when it comes to its Android project, don't accuse Google of playing follow the leader.
Although the company has long used open-source software within its internal operations, Android is Google's highest-profile attempt so far to use the collaborative programming method to change how computing is done outside the company's walls.
_350x283.jpg)
Andy Rubin, head of Google's Android project.
(Credit: Stephen Shankland/CNET News.com)Google is hardly the first company to try using open-source software to shake up the industry. What's notable is Google's willingness to ruffle feathers in the open-source world, including those of potential allies such as Red Hat, with its approach.
Google is bucking some open-source conventions by avoiding the fashionable General Public License (GPL) to govern the software and creating the software internally before involving outsiders. At the same time, though, it's been easing gradually into the mainstream open-source fold.
"Initially their approach was almost like a proprietary product approach," said John Bruggeman, chief marketing officer of Linux seller and Android partner Wind River. "I think they have adjusted all elements of that strategy as they go. It's much more open-source friendly, more developer friendly."
And though Google's path might be somewhat different, the company has a decidedly ordinary open-source destination in mind: building a broad, cooperative community to thwart a Microsoft hegemony.
Andy Rubin, the Google engineering director leading Android, likens today's chaotic hodge-podge of mobile phone software to the early days of personal computers. In mobile phones, though, Microsoft has begun offering integrated software ranging from office applications and a Web browser at the high level down through the operating system kernel at the low level, and that full suite has a powerful appeal to phone manufacturers.
"It's a repeat of what happened in the PC industry. We want to make sure there's an alternative," Rubin said. But Google doesn't want to be the sole gateway to its software. "We wanted to make sure there's not a single source, (so) if a carrier or user or third party encountered a problem, they could fix it themselves."
Android is massive open-source project--or at least it will become one when the first phones start shipping later this year. The recent version 2.6.24 of the Linux kernel has about 8 million lines of code, but about 8.6 million lines of Android's 11 million are open-source, Rubin said.
Android components that will emerge as open-source software include Nuance's speech-recognition software and PacketVideo's music and audio decoder. Google also has been working to obtain hardware specifications to support mobile-phone chips from Qualcomm, Broadcom, and Sirf, he said. "You'll see our stuff being the first Linux on Qualcomm," Rubin said.
Closed first, then open
But that open-source release will be complex. Depending on how it manages the task, Google could face praise or scorn later this year when it unleashes that code upon the world. The hardest part is not just sharing the code, but in integrating outside developers into a project that's been growing within a company's confines.
There's nothing technically wrong with an open-source project that's solely run by a single company, but it's rarely any company's open-source goal. It's not likely to attract outside coders who want to make a name for themselves by adding important new features or corporate allies that might fund their own contributions.
Google's closed start doesn't sit well with Red Hat Chief Technology Officer Brian Stevens, whose company is among the most aggressive advocates of open-source software.
"I think that decreases their chance of success more than it increases it," Stevens said. "It's preventing the participation of many smart developers who want to get involved in the development of the Android platform...The community comes at the early inception of a product, not when you decide you're ready to ship a product."
Mike Schroepfer, Mozilla's vice president of engineering, added that in general, corporate attempts to make open-source projects out of proprietary software are often hampered by an unwillingness to share control.
"People think publishing the source code is the hard part, but the harder thing by far is having open participation in the decision-making--distributing authority outside your four walls," Schroepfer said. "Where some of these really go wrong is when people aren't empowered and their voices don't matter, they're not going to do participate."
Google won't face the challenges of full-on proprietary software going open-source, though, said Redmonk analyst Stephen O'Grady: the open-source move is part of the Android plan, not a development that arrived years later.
The open-source hand-off
Google has its reasons for the closed start.
"We want to get to the point where it's stable enough," Rubin said. Then, after the open-source change, "We want it to be thriving."
The software components that constitute Android.
(Credit: Google)The company is working on the hand-off to the outside world. Android already is a project whose development is distributed among the Open Handset Alliance members collectively backing Android, for starts, as well as among multiple international Google offices. "We're learning how to do a large-scale distributed effort," Rubin said.
The company also has a team more 10 strong working on external developer relations for Android, Rubin said. That team that will grow larger once the code is released and absorbs the Google "maintainers" in charge of Android components, such as its Dalvik virtual-machine software for running applications written in Java.
Google's team under open-source project manager Chris DiBona, combined with some from the Android project, will work with outside programmers, Rubin said. "The developers I have on core development of this, when it gets open-sourced, will move over and will be coding for the open-source tree," or code base, he said.
Google also is taking a community-centric approach to defining what Android is. Project maintainers get to accept or reject contributions, as is common in the open-source realm. What's new is that Google will offer a certification test suite that's based on those maintainers' work in order to maintain compatibility among different versions of Android.
"If it passes, then they get to use the Open Handset Alliance Android trademark name," Rubin said. "We're not saying you can't branch. We're saying you don't want to branch."
Licensing choices
Google has been criticized for not working with existing open-source projects. In addition, Sun Microsystems has expressed concern that Google's development of Dalvik could fragment the Java world so that Java software for running Android applications wouldn't work on other Java phones and vice versa.
A sample Android application, AndroidGlobalTime
(Credit: Google)But Google chose to go it alone with Dalvik and some other projects for one big reason, Rubin said: it wanted to avoid the GNU General Public License (GPL). The pioneering license that serves in effect as the manifesto of the Free Software movement requires that software projects derived from a GPL product also be released under GPL. That concept in effect requires reciprocity: if you use GPL code and distribute the resulting software, you must contribute your changes back to the GPL code base.
Google didn't want to raise that issue, uncharitably referred to as the GPL's "viral" nature, for phone makers that might want to add proprietary features as a way to differentiate, so it chose the less confining Apache License, Rubin said.
"The thing that worries me about GPL is this: suppose Samsung wants to build a phone that's different in features and functionality than (one from) LG. If everything on the phone was GPL, any applications or user interface enhancements that Samsung did, they would have to contribute back," Rubin said. "At the application layer, GPL doesn't work."
Of course, giving back is precisely one of the intents of the license, which Richard Stallman initially wrote to govern a clone of Unix that couldn't be made proprietary; many companies have embraced the GPL, including initial skeptics such as Wind River. And other embedded-computing efforts are using GPL software more widely.
"It's a pretty conservative interpretation," Bruggeman said of Google's GPL stance.
Open-source advocates long have wrestled over whether it's better to permit companies to make code proprietary, as the Apache License permits, or to compel them to keep it open, as the GPL requires. Even though Android uses the Linux kernel, which is governed by the GPL, don't expect Google's position to put an end to this debate.
For that matter, don't expect Rubin's present thoughts to be the final word. The company has shown itself willing to change.
"Here's what I think. No. 1, they're learning as they go," Bruggeman said. "No. 2, they learn really fast."
Red Hat on Tuesday released the ninth incarnation of its enthusiast version of Linux, making a move that rival Ubuntu couldn't: the inclusion of the KDE 4 user interface.
That's because Fedora and Ubuntu have different approaches to new projects such as KDE 4, which is new, significantly different from KDE 3.5, and not yet settled down.
(Credit:
Red Hat)
Red Hat has two versions of Linux, the free
There's only one Ubuntu, in contrast, and it's free; support can be purchased separately. Founder Mark Shuttleworth deliberately founded Ubuntu with that philosophy because he wasn't happy with the way Red Hat and Novell's Suse Linux had split their products into separate lines.
Ubuntu's Hardy Heron, though, Canonical's latest version of Linux and only its second to come with long-term support, couldn't support KDE 4 because the company needed it to be more mature. With no real support requirements and a short product lifespan, Fedora can accommodate bleeding-edge projects.
To address KDE 4 demand--roughly a third of Ubuntu users prefer it to the more widely used GNOME--Ubuntu programmers took a Fedora-like approach. They're working on a KDE 4 version of Hardy Heron, but it doesn't come with the support promised regular Ubuntu.
Fedora 9 also includes OpenJDK, the open-source Java software from Sun Microsystems, GNOME 2.22, the Firefox 3 beta 5 Web browser, FreeIPA to let sysadmins manage identity policy, and an improved NetworkManager package to deal with better use of multiple networks.
The software can be downloaded through the Fedora Web site. The site also has a link to the Fedora 9 release notes.
Update 4:15 p.m. May 12: The file was actually infected with a remnant part of code from the Xorer Trojan, not with the full Trojan itself, according to a follow-up Mozilla blog post. The remnant "does not infect the user's machine with the virus (and) is a remnant from a virus that most likely infected the language pack developer's machine," Mozilla said. "To minimize the potential of something similar happening in the future, Mozilla is now scanning all add-ons whenever the signatures for the antivirus software are updated."
A Vietnamese language pack infected with parts of a Trojan for the Firefox Web browser was available for download from the open-source Web browser's official add-on site for months.
Mozilla, which oversees the project, announced the problem on its security blog on Wednesday, saying people should disable the add-on pack for now.
"Everyone who downloaded the most recent Vietnamese language pack since February 18, 2008, got an infected copy," Mozilla said. "While we cannot determine the exact number of compromised downloads, there have been 16,667 total downloads of the Vietnamese language pack since November 2007, so we anticipate the impact on users to be limited."
The author of the add-on pack, who acknowledged on Thursday that his machine had been infected, isn't suspected of any intentional harm, according to the discussion of the problem. The author offered a cleaned-up version Thursday that so far appears OK.
Mozilla scans its files for viruses, Trojans, and other problems. But the file had been uploaded nearly two months before the antivirus software could detect the Trojan in question, called Xorer.
(Via SecurityFocus.)
An open-source project called CoreAVC-for-Linux is back up and running at Google Code after a copyright tangle with a company called CoreCodec.
Google removed the CoreAVC-for-Linux project after CoreCodec said the software violated its copyright in a Digital Millennium Copyright Act (DMCA) "takedown" letter dated April 30. "We have directly verified by downloading the file from the site provided by Google Inc. that the file does include CoreCodec's copyrighted software," the company said in the letter, available at the Chilling Effects Web site.
Now the project is online again, after the company sent a reinstatement letter to Google on Sunday and posted an apology to project leader Alan Nisota in a forum posting. Apparently, the misunderstanding had to do with reverse-engineering, in which the inner workings of software or hardware are deduced from its behavior.
"The DMCA does allow for reverse engineering for compatibility purposes and hence...the DMCA takedown request was wrongly sent," a company representative said in another forum post.
"Yes, we're back. CoreCodec has given their blessing to this project," a note on the CoreAVC-for-Linux project site said.
CoreCodec sells software for Windows called CoreAVC that lets computers play video encoded with the widely used H.264 standard. The CoreAVC-for-Linux project let existing open-source projects such as MPlayer or MythTV use the CoreAVC.
(Via Dana Blankenhorn.)
In response to a copyright complaint, Google has taken down an open-source project called CoreAVC-for-Linux it had hosted on its Web site.
Google didn't share details, but said on the project site that it removed CoreAVC-for-Linux from its Google Code site after receiving a complaint under the Digital Millennium Copyright Act (DMCA).
CoreAVC itself is proprietary software for Windows supplied by a company called CoreCodec. The software can play video encoded with the H.264 standard.
According to a cached version of the Google Code page, CoreAVC-for-Linux provides patches to open-source media player software such as MPlayer or MythTV that enable them to use the CoreAVC software on Linux. In other words, it's for programs that connect to the CoreAVC software but doesn't actually include CoreAVC itself.
It's not yet clear who filed the DMCA complaint.
The DMCA's Safe Harbor provision protects a Web site from liability for users' actions as long as the site's operator--in this case Google--fulfills requirements such as removing infringing material once notified by rights holders.
CoreCodec appears to be a company that's got some involvement with the opens-source programming philosophy. According to the CoreCodec Web site, "Our philosophy is to (use) open source when appropriate, and when we do choose to close source a product, we strive to open as much of it as possible for third-party access."
(Via Slashdot.)
Correction 8 p.m. PT: I included the wrong duration for regular Ubuntu releases. It's 18 months.
Canonical plans to release Hardy Heron, its newest version of Ubuntu Linux on Thursday, and Chief Executive Mark Shuttleworth isn't being shy and retiring about it.
"This is our most significant release ever," he said in an interview.
Ordinarily I avoid publishing such marketing superlatives, but Shuttleworth is right. Hardy Heron, also called version 8.04 for its April 2008 launch date, is Canonical's proof-in-the-pudding moment that will show whether the company can grow beyond its subsidized roots into a self-sustaining business. Ubuntu has a strong following among Linux enthusiasts, but it's Red Hat and Novell that still dominate the commercial Linux market.
The reason so much weight rests on the skinny legs of Hardy Heron is because it's only the second Linux product from the company to come with long-term support. The first LTS version of Ubuntu, Dapper Drake, arrived when the company was still comparatively immature and unknown.
Long-term support means the company releases bug fixes, security patches, and other updates for five years on the server version and three years on the desktop version, time frames more palatable to businesses than the 18-month life spans of other Ubuntu versions.
On the server, the new version has support for KVM virtualization built in and comes in a stripped-down version called JEOS (Just Enough Operating System) for software "appliances" that run on KVM or VMware. The company has been working on better hardware support--though it no longer supports Sun Microsystems' Sparc processors, Shuttleworth said. Also included are better integration with Windows' Active Directory for corporate users and a certified, downloadable version of Java software.
On the desktop, Hardy Heron now can be installed directly into the Windows file system so people can try it without having to reformat their hard drives. The software also deals better with online music and photo sites such as Flickr, he added. However, because of an upgrade timing disconnect, fans of the KDE user interface software will have to make do with only 18-month support for the older KDE 3.5 or an unsupported developer version based on the new KDE 4.0.
Still not profitable
Shuttleworth, who funded Ubuntu with wealth from his sale of an earlier start-up to VeriSign, cares about business success, but he's also willing to continue spending to help Canonical grow into new areas--such as the mobile version that's beginning in earnest with Hardy Heron.
"Ubuntu will require continuing investment from me and from others. We are on a trajectory that will make the company sustainable," Shuttleworth said. But he wouldn't say when he envisions profitability: "I'd rather not be on the hook...I keep finding additional areas to invest in."
What's a surprise to Shuttleworth, though, is that the desktop Linux is financially more significant than the version for servers.
"The desktop contributes more to Canonical's bottom line than the server," he said. The server business is still Canonical's primary focus for support revenue. But the company has been getting paid for desktop and consumer-electronics work, he said.
"On the desktop, we see strong demand for custom engineering and assurance programs as people look to Canonical to indemnify them against potential copyright or patent issues," Shuttleworth said.
Canonical also works on unbranded Linux for consumer-electronics companies, though Shuttleworth expects they'll eventually opt for something like Ubuntu. "The hardware vendors are leaping at the ability to do their own operating system. I believe over time they'll tire of the costs and risks of doing that," he said.
Regarding engineering work, he added that Canonical has a tight partnership with Intel, an "extensive on-site engineering relationship where we integrate support for latest platforms."
When writing earlier this week about Adobe's sponsoring of the SQLite project, I ran into a complicated issue: is software released into the public domain also open-source software?
I have an editor who hates headlines with question marks, but I'm afraid this time it's appropriate, because even experts disagree.
For background, software or other material in the public domain simply means that it's not copyrighted. Requirements to meet the official Open Source Definition are listed by the Open Source Initiative. Two programmers, Eric Raymond and Bruce Perens, founded the OSI about 10 years ago to formalize and codify the open-source idea as it branched off the free-software movement Richard Stallman founded in the 1980s, and OSI lists 68 compliant licenses.
Richard Hipp, who founded the SQLite database project in 2000 as a public-domain project, believes it does qualify as open-source software.
"I've had a number of conversations on this topic with corporate lawyers for companies that are actively using SQLite. The consensus there seems to be that 'public domain' is valid and is a proper subset of 'open source'--except in France and Germany where the concept of 'public domain' is not recognized," he told me in an e-mail discussion prompted by the Adobe story.
But not so fast. Take the view of Mark Radcliffe, the intellectual property attorney who's general counsel to the Open Source Initiative.
When I asked Radcliffe if public domain software was open-source, he was clear: "No. Truly public domain software is no longer protected by copyright, thus it cannot have a license which would impose the terms necessary to comply with any of the open source licenses," he said.
Agreeing with him is Louis Rosen, an attorney with Rosenlaw and Einschlag who previously led OSI's legal work and who still is involved. He directed me to an older but still relevant piece he wrote about why the public domain isn't a license.
"'Public domain' will never be a license. It actually means 'No license required,'" Rosen said. "Software that is 'dedicated to the public' or 'to the public domain' is pretty safe. I just worry a bit when people or companies give software away in such an amateurish way, without understanding that licenses or covenants are far more efficient and effective."
While "public domain" isn't a license on OSI's official list of open-source licenses, Perens said it's not far off: "Software that has been formally dedicated to the public domain through some sort of written statement meets the requirements of the Open Source definition only if the source code is available. Surprisingly, 'public-domain' binary-only software exists in some odd corners of the Net."
And Raymond added, "Public-domain software qualifies...The users are guaranteed all the redistribution and reuse rights that the Open Source Definition seeks to secure by the fact that there is no owner to enforce restrictions."
Moving from the theoretical realm into the practical, though, the SQLite project appears more open-source than not. The project's source code is available without restriction, and programmers who contribute code it to it must explicitly declare their contribution is given to the public domain for perpetuity, which appears to satisfy Perens' opinions.
