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.)
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.
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.)
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.
Sun Microsystems said Tuesday that it has completed its acquisition of open-source database company MySQL for about $1 billion--and now is turning its attention to other acquisitions.
"In my view it's the most important acquisition in Sun's history," Sun Chief Executive Jonathan Schwartz said on a conference call Tuesday.
Sun paid about $800 million in cash and $200 million in stock for MySQL. Although it's a big open-source acquisition for the server and software company, it won't be the last, Schwartz said.
"Those companies that have built good high-integrity communities, broad distribution, and some measure of commercial success are those we're going to be interested in," Schwartz said, and there are many that fit that bill. "We believe we're a natural home to a lot of them, and we're going to be putting our balance sheet to work to make that the case."
Marten Mickos, who had been MySQL's chief executive, now is senior vice president of Sun's database group, reporting to Rich Green, Sun's executive vice president of software.
MySQL may have been Sun's most important acquisition, but it wasn't its biggest. In 2005, Sun spent a net amount of $3.1 billion to acquire StorageTek, a tape storage system maker with a large customer base and revenue stream.
Schwartz wouldn't compare the merits of the two acquisitions, but indicated that MySQL has a strong potential: "The customer base it brings to Sun measures in the millions if not the tens of millions. There are very few companies on Earth that have that capacity to create opportunity for Sun," he said.
Mickos estimated that there are 12 million instances of MySQL installed at present. It's impossible to know exactly, since copies may be downloaded for free and distributed any number of ways.
Sun still will support Derby, PostgreSQL
With the new title, Mickos will lead not only MySQL work, but also other open-source database projects that Sun supports, including Derby and PostgreSQL. Sun will continue its work with those projects, Green said in an interview.
"We fully intend to keep those programs going at the same speed as we did before," Green said. Developers want different packages for different situations, and "Sun is big enough to have more than one going at the same time."
However, MySQL is clearly the priority. For example, the sales support will be much broader than with PostgreSQL when it comes to selling MySQL support subscriptions, Green said.
"Those subscriptions will be sold by the entire Sun software sales force. We've amped up the scale and reach of the sales organization that previously was a much more limited size," Green said.
Schwartz argued the acquisition will make MySQL more palatable to big customers. "The single biggest impediment to success in the marketplace (has been) their comparative inability to provide peace of mind to enterprises that want global service and support," Schwartz said.
For his part, Mickos chose to look at the potential rivals more as allies. "I believed always the enemy is not another open-source database," he said. "We always had a good relationship with the PostgreSQL team."
PostgreSQL is often positioned as more of a traditional database package comparable to Oracle's dominant and proprietary product. MySQL, while steadily accumulating more features useful for that area, has been geared more for what the company has seen as new database usage such as new-generation Internet sites. MySQL is used at the core of Facebook, Google, and YouTube.
Mickos said Sun doesn't plan to move MySQL more toward the traditional database market. "We're following Wayne Gretzky's advice: skate to where puck will be," he said, mentioning "Web services, Web 2.0, telecom, and mobile spaces" as examples.
Faster development, and eventually GPLv3
Being part of Sun will speed development of new features such as Falcon, MySQL's project for a new storage engine used within the overall database, Mickos said. "We now get access to abilities and resources we didn't have before--scaling, performance, memormy management, input-output. That's why we hope to be able to accelerate the road map."
It won't change MySQL's multiplatform approach, though; the database runs on Linux, Windows, Solaris, AIX, Mac OS X, and many other operating systems.
MySQL is governed by version 2 of the General Public License (GPL) since 2000, but the company likely will move to GPLv3, Mickos said.
"We've been part of drafting GPLv3. We like the license. We think it's better than GPLv2 and takes care of some of its weakeness," Mickos said. "But (GPLv2) is the most successful license ever. It will take time to replace it and to move over to next generation, GPLv3. I believe we'll do it at some point, but we haven't decided on a specific point in time yet."
Update 9:15 a.m. PT: I added more details about Sun's acquisition plans. Update 10:30 a.m. PT: I added more information about Sun's acquisition history, MySQL integration details, and licensing and product plans.
Linus Torvalds, leader of the Linux kernel project that's among the best-known open-source threats to Windows, has words of praise for Microsoft's announcement last week that it would share some previously hard-to-get technology with open-source programmers.
"I may make fun of Microsoft occasionally, and yeah, I think they do stupid things at times, but I think this one was a step in the right direction," Torvalds said in an e-mail.
"Could it have been even more? Sure. But give them credit for at least seeming to open up a little, even if it probably was at least partially ."
Torvalds' opinion goes right down the middle of the mixed reactions various people in the open-source software area had to the news.
Some praised Microsoft for making it easier for programmers to get access to technology such as communication protocols and file formats, and to get their software to work better with Microsoft's; others griped about Microsoft's continued desire for open-source companies to obtain patent licenses.
Torvalds isn't in the castigation camp. "Does it mean people should trust and love them? No," he said. "But I also don't see the point in flaming them over what is clearly at least an incremental improvement."
Sometime last night, Firefox downloads crossed the 500 million threshold.
Mozilla congratulated itself on attaining 500 million downloads of the Firefox Web browser.
(Credit: Mozilla)It's an arbitrary but interesting milestone for the open-source Web browser, whose development is overseen by Mozilla but that's also developed and extended by a large number of outside programmers. In September 2007, Firefox crossed the 400 million download mark, indicating an average rate a bit shy of 20 million per month at present.
According to the Spread Firefox site, there had been 500,168,448 downloads as of 6:15 a.m. PST. About 12 hours earlier, there had been more than 499,900,000.
Firefox has spread widely in the years since its release. The project originally was named Phoenix to symbolize a rising from the ashes of the Netscape open-source browser project that began in 1998 but languished for many years as Microsoft's Internet Explorer solidified its lead.
Now Firefox programmers are working on version 3, which brings performance improvements and interface changes, and Mozilla also is working on a mobile version of the browser for handheld devices.
A sister subsidiary of Mozilla, Mozilla Messaging, is working to reproduce the successes of Firefox with the open-source Thunderbird e-mail software.
Open-source fans can be a skeptical bunch, but I've seen their collective opinions shift--for example in the gradually diminishing loathing for Sun Microsystems as that company stopped deriding Linux and started moving its portfolio to open-source software.
So it's not a surprise that various representatives had a mixed reaction to Microsoft's move Thursday to share details of its technology with open-source programmers.
The move could make it easier for many projects to work well with Microsoft products and potentially replace them--for example the Thunderbird e-mail software could communicate better with Microsoft Exchange servers and also displace Microsoft Outlook on PCs. But Microsoft also made it clear that a pledge not to sue open-source programmers only applied in "non-commercial" contexts, so open-source fans didn't get everything they want.
And even though Microsoft said it now will share the specific list of patents it says it has on technology it wants to license to others--something open-source fans have sought once Microsoft asserted last year that Linux and other projects violate 235 patents--some see signing licenses as incompatible with open-source license requirements.
For its part, Microsoft is pledging to move beyond its historically adversarial treatment of the open-source realm. "As Microsoft takes this significant step forward into the interconnected world of the future, we aspire to doing so with members of the open source community by our side now and for the long haul," said Bill Hilf, Microsoft's general manager of platform strategy, on his blog. Hilf previously ran Microsoft's Linux lab and was an Linux deployment specialist at IBM.
I surveyed various companies and individuals about the move and received some other thoughts unsolicited. Here are some reactions:
• Jim Zemlin, Linux Foundation executive director: "The world of software development has been marching in a steady direction toward being open and transparent. As Linux's use continues to rise, so does the demand for customers to enable it to interoperate with Microsoft products. This announcement by Microsoft seems to indicate they want to participate in that march. Even if some of the announced details still seem less than ideal for open source developers, at least it's a first step."
• Michael Cunningham, Red Hat's general counsel: "Red Hat regards this most recent announcement with a healthy dose of skepticism. Three commitments by Microsoft would show that it really means what it is announcing today:
"Commit to open standards: Rather than pushing forward its proprietary, Windows-based formats for document processing, OOXML, Microsoft should embrace the existing ISO-approved, cross-platform industry standard for document processing, Open Document Format (ODF) at the International Standards Organization's meeting next week in Geneva...
"Commit to interoperability with open source: Instead of offering a patent license for its protocol information on the basis of licensing arrangements it knows are incompatible with the GPL (General Public License)--the world's most widely used open source software license--Microsoft should extend its Open Specification Promise to all of the interoperability information that it is announcing today will be made available...
"Commit to competition on a level playing field: Microsoft's announcement today appears carefully crafted to foreclose competition from the open-source community. How else can you explain a 'promise not to sue open-source developers' as long as they develop and distribute only 'non-commercial' implementations of interoperable products? This is simply disingenuous."
• Miguel de Icaza, founder of the GNOME project and a Novell programmer working on Mono, an open-source implementation of Microsoft's .Net software: "As a chess move, it is a fascinating one...On the surface it looks very good. (There are) lots of things that we want to interoperate with--Office, SQL Server, SharePoint. Getting the documentation to everyone sounds great, and it seems like they are serious about doing more interoperability work...When the full list for patents becomes available, the question is what will open-source vendors do if they find pieces that have historically infringed: will they choose to license and be the recipients of the community wrath, or will they hold their grounds and risk a lawsuit?"
• Jeremy Allison, a founder of the Samba open-source project: "The devil is in the details. If they can follow through with this, the world will be a better place...It doesn't mean any change for us (Samba) as we already had all these documents, and the promise not to sue is only for 'non-commercial' open source, which is a bit meaningless. At least everyone now gets access to the same info, which I'm very happy about. Hey, should we ask for our money back ? :-)."
• Matt Asay, vice president of business development for Alfresco and a writer for CNET's Blog Network: "The really big news is Microsoft's commitment to open APIs (application programming interfaces) and open protocols...It's great news, and it's big news. My company has been seeking this API and protocol information for months (years, really). But Microsoft's pledge doesn't obviate the need to negotiate patent royalties, if required, with the company."
• Andi Gutmans, a co-founder of Zend: "I have no doubt Microsoft is doing the right thing for their business. I believe Microsoft has finally understood that their closed nature has significantly hindered the growth of their ecosystem...Microsoft has had a strong Microsoft-centric ecosystem, but going down this path they are able to extend their applicable market beyond today's reach...I believe the PHP community can only benefit from this move. With PHP being a heterogeneous solution which works on pretty much any operating system, any database and any Web Server; the more interoperability capabilities it has with all open-source and proprietary solutions the better...Microsoft's all or nothing approach has been an accelerator for the adoption of open-source operating systems. While I am a big fan of Linux, I do believe that this is going to put an increasing amount of pressure on the Linux/Unix backers to deliver innovation and value on top of these systems."
Update 5:32 p.m.: I added commentary from Microsoft's Bill Hilf.
