Leading items

Oracle donates OpenOffice.org to Apache

The news that Oracle was proposing to donate the OpenOffice.org (OOo) code to the Apache Software Foundation (ASF) came as a surprise to many, though it probably shouldn't have. Many optimistically hoped that Oracle's plan to turn OOo over to an "organization focused on serving that broad constituency [the OOo community] on a non-commercial basis" meant that it would turn to The Document Foundation (TDF), which forked OOo into LibreOffice (LO) in September 2010, as the obvious repository for the code. But, for a number of reasons, that was probably never a very likely outcome; some discussions evidently took place between Oracle and the TDF, but there seems to be enough bad blood—along with licensing differences—that another home for OOo was sought.

Oracle's contribution

Oracle proposed OOo as an Apache Incubator project on June 1 with a post to Apache's incubator-general mailing list. The original posting from Oracle VP Luke Kowalski was done as an .odt file, which made it hard to comment on, so Greg Stein posted the text of the proposal. Shortly thereafter, it was turned into a wiki page which has been updated to reflect the discussions about the proposal.

Other than the proposal itself, and a press release with statements from Oracle, Apache, and IBM, there has been little said by Oracle about this move. IBM, on the other hand, has been quite vocal, with three separate, very favorable blog posts (Rob Weir, Ed Brill, and Bob Sutor) that came out more-or-less at the same time as the proposal. This seemingly coordinated response didn't necessarily sit well with some in the OOo/LO community, but TDF had enough notice to put out its own statement that was conciliatory, if disappointed.

Basically, Oracle has signed a license grant to the ASF covering a list of files that make up OOo. That allows the ASF to release the code under the Apache License. Oracle will also be transferring the OOo trademarks to the foundation, though there is a typo in the current transfer ("OpenOffice" rather than "OpenOffice.org") that is currently being addressed. There are some questions whether the listed files are actually all of those needed to build OOo, but the belief is that Oracle will work with ASF to address any deficiencies.

Apache incubation

The license and trademark grant is a "done deal", by and large, but where things go from there are still a bit up in the air. Apache has an "incubation" process that is meant to help new (to Apache) projects come up to speed on how Apache projects work and are governed. In addition, the incubation process is meant to allow time to handle any licensing issues with the code (as all Apache projects must be licensed under the Apache license), as well as to determine if the project has attracted enough of a community to be a viable project going forward.

As spelled out in the Incubation Policy, the project must have a "champion" who is an ASF member. For OOo, Sam Ruby will be the champion. In addition, there needs to be at least one "mentor" from the ASF for an incubator project. For OOo, there are eight mentors listed at the time of this writing. The role of the mentors is to assist the project through the process by providing guidance on Apache philosophy and policies. In order to get a sense for how much interest there is in the potential "podling" (as accepted incubator projects are called), a list of "initial committers" is being gathered in the proposal. "Committers" does not necessarily imply developers as it is meant to cover anyone who plans to do any kind of contribution to the project. There are more than 60 people listed as initial committers at the time of this writing.

Once the proposal is firmed up, a vote will be taken to determine whether the podling is accepted into the incubator program. That vote will likely happen quite soon, almost certainly before the middle of June. Based on the discussions in the mailing list, it seems pretty likely that the proposal will be accepted. The consensus seems to be that, while there may be substantial barriers to overcome before the OOo project could become an Apache top-level project, the incubation process is meant to shake those problems out. If that doesn't happen, the project will eventually be terminated, but there is no reason not to see if the problems can be worked out.

As might be guessed, that consensus (if consensus it truly is) used up a lot of electrons to emerge. There are multiple 100+ message threads in the mailing list that are discussing various aspects of the proposal. It is not only ASF members who are participating either, as various TDF members, OOo and LO community members, and other interested parties are chiming in. For the most part, it has been a polite conversation, as various commenters have been careful to steer the discussion so as to keep it on-topic and congenial—asking that flames be taken elsewhere. But it's also clear that there are some strong emotional undercurrents, at least partly because the TDF/LO community feels somewhat slighted.

It's not surprising that they feel that way. TDF and its community have done a huge amount of work in the last eight months to create a meritocratic organization to foster LO. In addition, there has been a lot of technical work done to clean up what is, by many accounts, a codebase that has the potential to inflict eye cancer, as well as work to add new features, set up build farms, and so on. Much of that work may need to be redone by any Apache project, so it looks an awful lot like a waste of effort to the LO community.

Licensing

The bigger issue may be licensing, however. When TDF formed, largely due to what it saw as mismanagement of the project, first by Sun then by Oracle, it took the OOo code under the only license it could: LGPLv3. In order to try to attract companies like IBM into contributing to LO, the foundation asked that contributions be made with a dual LGPL/Mozilla Public License (MPL) license. The MPL is a weaker copyleft license which requires that changes to existing code be released, but allows extensions and the like to be kept closed. By dual-licensing with the MPL, it would still allow companies to release LO with proprietary extensions if they could get a license for the LGPL-covered and Oracle-owned core.

At least one company has such a license, and that's IBM for its Lotus Symphony products. Prior to Sun changing the license for OOo version 2, IBM released its proprietary OOo-based products using the earlier Sun Industry Standards Source License (SISSL), which did not require that code changes be released. After Sun dropped that license for version 2, IBM had to negotiate a license separate from the LGPL so that it could keep its code closed.

The only reason Sun could issue that license to IBM is because it always required OOo contributors to grant Sun a joint copyright on the contribution. That means that Sun, now Oracle, can do anything it wants with the code, including licensing it for proprietary use. This contributor license agreement (CLA), which essentially made for an uneven playing field because only Sun/Oracle had certain rights, was another problem that caused the LO fork. It should be noted, though, that the CLA is what allows Oracle to grant ASF the right to release the code under the Apache license. Without it, all contributors would have had to agree to the change—which might have been logistically, and perhaps ideologically, difficult.

Ideology comes into play because there are two very different philosophies here when it comes to free software: copyleft vs. non-copyleft. The Apache license is a non-copyleft license that, similar to the BSD license, allows anyone to do what they wish with the code. The GPL, LGPL, MPL, and others require that modifications be released under various circumstances. Copyleft licenses restrict the ability of companies to keep parts of the code private, while non-copyleft licenses have no requirements of that sort.

The belief is that companies are more likely to contribute when they can keep some of their "secret sauce" to themselves. The BSDs have had some success with that philosophy, though GPL-covered Linux is often held up as a counter-example. It is Apache, though, that has arguably had the most success with building communities of both companies and individuals around non-copyleft code.

The ASF is, quite reasonably, proud of its license and accomplishments, so the ability to gain an Apache-branded desktop office suite is rather attractive. That said, OOo is also not an obvious fit for the organization. ASF has largely targeted server applications and, as noted by several commenters in the mailing list, is accustomed to making source-only releases. Users of OOo are unlikely to expect to have to build their own binaries, so some kind binary release will be needed. For Linux, this is less of an issue as there are distributions aplenty that will make binary releases for their users if they decide to ship OOo; in the Windows and Mac worlds—which make up the vast majority of OOo users—it's a more difficult problem.

It should be noted that, even in the Linux world, most major distributions have switched over to LO, or plan to, so some kind of a switch back to OOo would be required. Since many of the companies behind the larger distributions are also TDF supporters, that kind of a change is unlikely, at least in the near term.

Possible outcomes

One of the more optimistic conversations on the mailing list looks at ways that TDF and ASF could collaborate, without necessarily joining forces. Neither side looks likely to budge on its license choice, at least in the near term, so combining the two is simply not possible. There is something of an imbalance between the two, though, because TDF can adopt any of the Apache-licensed code (either Oracle's initial contribution or any further changes), while an Apache project cannot adopt the LGPL/MPL-licensed changes that TDF has made (or will make in the future). That one-way door is inherent in the nature of non-copyleft licenses; not only can the code be taken proprietary, it can be additionally licensed under a copyleft license.

Should the podling get accepted but fail to graduate to a top-level project, the Apache-licensed code will be available and presumably TDF will be the home of the community around the OOo/LO codebase. On the other hand, if Apache OOo takes off and the LO community largely moves over to the new project, one could imagine the LO code being re-licensed. The bulk of the LO changes were done by companies like Novell, Red Hat, Canonical, and others, so a change to the Apache license for those parts would just require the strokes of a few pens.

The other plausible outcome is that both projects thrive—or at least survive—presumably each smaller than the combination would be. The codebases would continue to diverge to a point where they would be completely different office suites that both natively supported Open Document Format (ODF). It would get harder and harder for LO to adopt OOo changes because of the divergence, so at some point, they would go their separate ways. That split is what worries many, because it would probably result in two less-capable suites. Others argue that competition between the projects may lead to both becoming better—it certainly wouldn't be the first such split in free software.

Looking at how the two projects can collaborate is an avenue toward avoiding the split, however. If the codebases could be kept in sync fairly closely, and perhaps some LO contributions also licensed under the Apache license, the divergence could be kept to a minimum. Whether the two communities can work together remains to be seen, but there are proposals for joint meetings and/or a summit of some kind. At least some cooperation in the near term seems likely, but there are some big hurdles for Apache OOo to clear.

Challenges

Numerous challenges for the likely podling have been mentioned in the threads, starting with the problem of creating binaries for end users—along with the bandwidth and server requirements to support those users. But there is more to it than that. While there are numerous initial committers listed for the project, from many different organizations as well as individual contributors, the bulk of the full-time, paid OOo staff will, at least initially, be coming from IBM. That worries some because IBM's priorities could change at any time, which might lead to a podling without enough of a contributor base.

There are also some questions about IBM's goals in pushing for an Apache OOo project. The company was never a large contributor to OOo, even after it joined the project with some fanfare in 2007. Many of its contributions have languished, and not been merged into the OOo mainline. On the other hand, IBM already has a license for the code that it needs so it's a bit unclear why it would go to the trouble of pushing Apache OOo if it didn't really have hopes of seeing a larger community grow up around it.

In addition, IBM doesn't have much of a track record in community-oriented free software projects. It has certainly contributed to various projects (notably the Linux kernel), but it lacks experience in leading a free software community—at least one that isn't directly under its control. Apache does have that experience, however, and has policies in place to ensure that its projects are governed well (starting with the incubator program itself).

There are also questions about external dependencies that may not be available under an Apache license, which might necessitate disabling some functionality or rewriting those pieces. Another missing piece from the list of files provided by Oracle is the translations that were done for OOo, which may just be an oversight. The ASF folks posting on the mailing list seem comfortable that these things can be worked out as part of the incubation process.

As a number of people have pointed out, there is a certain irony to this recent engagement between ASF, IBM, and Oracle. Apache certainly has reason to be relatively unhappy with IBM because of its abandonment of the Harmony project—something that has been cited several times as a cautionary tale regarding OOo—and Oracle because of its unwillingness to license the Java compatibility tests to Apache, which led to Apache resigning from the Java Community Process executive committee. It is a testament to the pragmatism and maturity of the ASF that it has seemingly not allowed those other problems to interfere with the current OOo contribution.

It will be interesting to watch this play out. It is unfortunate in many ways because an opportunity to fix the split in the OOo and LO development communities has been lost—or at least delayed further. It is tempting to speculate on what might have happened had Oracle made this move, say, ten months ago. But it didn't, and it owned the code, so it can make decisions that make the most sense for Oracle and its partners. At this point it seems like a face-saving move by Oracle, along with a poke in the eye to TDF, but it may be that Oracle has contracts with IBM or others that require moving the code to an organization with a non-copyleft outlook.

The decisions made by the podling going forward will likely give us a view of how interested IBM and the OOo community are in working with LO. There are presumably lots of cleanups that LO has done that could be adopted by OOo (it's hard to imagine that code and comment removals, for example, are covered by a license). That would make it easier for code to move between the two projects as it takes more than just compatible licenses (assuming some LO contributors are willing to do that) to make that work.

There seems to be a belief that some part, perhaps a large part, of the OOo community was left behind when TDF forked. Clearly Oracle employees were left out (presumably by Oracle fiat), but that doesn't really change as Oracle appears to have no interest in the project once the transition is complete. Perhaps there are constituencies that are not served well by TDF and will be by an Apache OOo project, but the progress made by LO vs. OOo since the fork doesn't seem to indicate that. We'll all just have to watch and see where things go from here.

Comments (30 posted)

Webian: A Mozilla-based web desktop

At first glance it looks like a typo, but Webian is in fact an experimental, open source desktop environment using Mozilla and Gecko as its core. Developer Ben Francis made the first public release last week, spawning immediate comparisons to Google's ChromeOS project, and even inciting concern that Mozilla would draw the search giant's wrath for wandering into its corporate territory. But Webian is Francis' personal project, not underwritten or sponsored by Mozilla. It does, however, show off some key concepts that the browser-maker is interested in promoting — namely Mozilla's belief that HTML5 and open web standards are the development platform of the future.

Essentially, Webian is a small set of applications written on top of Mozilla's Chromeless toolkit. Note that the name "Chromeless" refers to Mozilla's long-standing habit of calling its existing user interface layer "chrome," and is not taking a swipe at the Google browser. It strips away the entire browser interface (including the XUL and XPCOM used by Firefox) and replaces it with a layer written in HTML, CSS, and JavaScript itself. Chromeless is an evolution of Mozilla's Prism project from years past, and the current version has the same run-time features as Firefox 4, with JavaScript APIs for calling browser functionality. Mozilla Labs has demonstrated other Chromeless-based projects in the past, including basic browsers and a code editor derived from the SkyWriter (formerly Bespin) collaborative editor.

0.1 release

Last week, Mozilla Labs featured a guest blog post by Francis about the 0.1 release of Webian Shell, the basic "desktop" for Webian. The Shell is an integrated web browser that needs no other window manager or desktop trappings. It runs in full-screen mode, providing a "home screen," a row of tabs across the bottom, and a URL-and-title-bar across the top. Francis has been actively developing Webian since 2009, based on design concepts he cooked up while in college. The design concept document explains the scope and architecture choices in more detail than the project's wiki: the browser is the only application, there are stripped-down tools to access other functions (such as hardware settings), and only minimal borrowing from "thick client" desktop metaphors of ages past.

The 0.1 release is available in binary form for Linux (32- and 64-bit), Windows, and Mac OS X, as well as source. Not everything described in the design document is implemented yet; Webian Shell works as a full-screen browser, but the home screen sports only a clock and "shut down" button. Also missing is Francis' concept of "stripe" UI elements: notifications and queries that slip into place horizontally and stack on top of each other, pushing browser window contents down rather than layering on top of them. The goal, according to the design document, is to "remove the concept of 2.5 dimensions where possible and treat 2D as 2D."

It is important to note that Webian Shell by design runs on top of your existing operating system. While it does run full-screen (for Linux, that means it run over X, and does not interact with the window manager), it is not a full OS stack like ChromeOS is. Thus, at the moment, you can use it as a browser and a UI demo for the eventual desktop system, but not a replacement for your complete environment. As a browser, it runs quite fast — faster, it seemed to me, than did Firefox 4 itself. Partly that is due to not loading Firefox extensions, but simply shedding the heft of Firefox's own interface seems to give a noticeable speedup (installed plug-ins, it should be noted, do run in Chromeless and Webian Shell).

Webian inherits its security model from Chromeless. The latest version takes advantage of out-of-process plugins and out-of-process tabs (which debuted in Firefox 4), so one page crashing should not crash the entire app (or, in Webian's case, shell). However, Flash or Java hiccups in one page may force the user to re-load other pages in order to re-start a crashed plug-in. Privacy controls are another matter; Chromeless and Webian can technically maintain separate user profiles just like Firefox, but the interface for managing profiles is not yet implemented in Webian Shell.

Aggravatingly, at the moment several of the high-profile Google web services do not run in Webian Shell, due to an upstream bug in Chromeless that hits pages incorporating the X-Frame-Options HTTP header. Nevertheless, there are still plenty of functional web applications available in the wild, so you can can easily test out Webian Shell for long browsing sessions.

The long-term plan involves separate applications beyond the Shell, however. The project is working on desktop widgets for the home screen based on the W3C widget specification, and a photo management application that implements a local interface for tagging and organizing content, but still connects to remote, web-based services for publishing and storage. That choice is initially hard to get used to: the ChromeOS-like approach would be to write an entirely server-delivered photo organizer, then deliver it through the browser.

Chrome OS and other competition

Despite Webian's limited scope as a browser and (potentially) desktop environment, the comparisons to ChromeOS are inevitable. Francis' post on the Mozilla Labs blog led some online media outlets to describe Webian as a Mozilla project — an error Francis is quick to correct. He has received help and input from the Chromeless team (including work on the X-Frame-Options bug), but the project is not affiliated with Mozilla nor is he an employee.

Still, the project does line up quite closely with several of Mozilla's goals. It serves as an independent showcase for Chromeless, which is poised to take on a more prominent role now that Mozilla has announced the end of support for Gecko embedding APIs.

Mozilla is also pushing forward on the "installable web app" front, through apps.mozillalabs.com. While Firefox support for these apps is provided by an extension, native support built into a thin-client desktop like Webian would arguably be a better demonstration of their value. Google's Chrome team has independently developed its own installable web app framework, with a similar but not-quite-compatible manifest format for the browser to consume. Francis said he would like to support both, although he would prefer that both parties come to an agreement on a common format.

Another feature discussed in the Webian design documentation is a command-line interface implemented in the Shell URL bar / text-entry widget: supporting search queries is the first order of business, but arithmetic, app launching, and natural-language questions have been discussed on the mailing list and discussion forum. As several people in the Webian community pointed out, this type of functionality is already available in Mozilla Ubiquity, so here again cross-pollination with another Mozilla-based project seems natural.

But to really stage a direct challenge to ChromeOS, Webian would have to be bundled with an underlying OS. At the moment, Chromeless does not have the access to low-level system hardware that it would need to provide the hardware control described in the Webian Shell plan (although Mozilla's Rainbow does show signs of life in that area). Thus, to develop into a full OS replacement, Webian would almost certainly have to leave cross-platform compatibility behind, and pick a single stack to build upon.

Linux is the obvious first choice, and Francis alluded to that future direction in an email. "How much of Webian's functionality will be cross-platform is an unknown at the moment. The priority will be to build a Linux-based version but if some level of cross platform support can be maintained that would be great."

Of course, whether or not a full Webian-based OS offering would be successful competing against ChromeOS is a different question entirely. Francis and the other contributors are nowhere near the point where they could push Webian as a commercial offering like Google is doing for ChromeOS. Several contributors make the argument on the mailing list that Webian's non-commercial approach makes it more trustworthy for end users, who may be concerned over Google's user-tracking activities, or simply unhappy with ChromeOS's lack of transparent and meritocratic development processes.

No doubt, that stance makes sense to many free software advocates, but it does not do the work of bundling Webian with a Linux-based kernel and providing it as an installable image. The other argument common to the list is that Webian (like Mozilla) is dedicated to full support of open standards. Consequently, for example, it will feature HTML5 video playback of royalty-free formats only, rather than supporting royalty-bearing formats as well.

Frankly, that is a highly speculative line of thinking anyway, and threatens to overshadow what Webian Shell showcases here and now. At the moment, it is a showcase for Mozilla Chromeless — an idea that the browser vendor has been arguing for for years without a visible product to demonstrate. The notion that desktops are dead and the web is the new delivery platform gets considerable airplay in the press, often including the refrain that the open source community is behind the times as its desktop wars rage on. But up until now, ChromeOS was the only end-user-targeted attempt to build a "web desktop" at all, and it was intimately entwined with the proprietary web services offered by Google.

Thus it is good to take a close look at Webian, if for no other reason that to put the notion of the "web desktop" to the test in a Google-free environment. Personally, I certainly hope it continues to push forward, and to accelerate development of some of Mozilla's "lab experiment" projects at the same time. It could serve as a valuable motivator for the free software community on the web services front as well. But if nothing else, it goes to show how lean and fast a Mozilla-based browser can be, once all of that chrome is stripped away.

Comments (10 posted)

Android, forking, and control

Many words have been said about the relationship between the Android project and the mainline kernel development community. At LinuxCon Japan, James Bottomley took the stage to say a few more. There are, he said, some interesting lessons to be learned from that disconnect. If the development community pays attention to what has been going on, we may be better placed to deal well with such situations in the future.

James started with the statement that Android is, hands down, the most successful Linux distribution ever produced. Its adoption dwarfs that of Linux on the desktop - and on the server too. Android's success is spectacular, but it was achieved by:

• Forking the kernel,
• Rewriting the toolchain and C library,
• Developing a custom Java-based application framework, and
• Working from an extreme dislike of the GPL

In other words, James said, Android is a poster child for how one should not work in the open source community. They did everything we told them not to, and won big. While we would like the Android developers to change and do some things differently, their success suggests that, perhaps, Android is not the only group in need of change. Maybe the community needs to reevaluate how it weighs code quality against market success; do we, he asked, need a more commercially-oriented metric?

One of the big assumptions brought into this debate is that forking is a bad thing. Android started by forking the kernel and writing its own user space mostly from scratch, and the community has duly condemned these moves. But it is worth understanding what the Android developers were trying to do; Android started by finding adopters first; only then did they get around to actually implementing their system. At that point, the time pressures were severe; they had to have something ready as soon as possible. There is a lot to be said for the development community's patch review and acceptance processes, but they do tend to be somewhat open-ended. Google couldn't wait for that process to run its course before it shipped Android, so there was little choice other than forking the kernel.

Was forking the kernel wrong? In a sense, James said, it cannot be wrong: the GPL guarantees that right, after all. The right is guaranteed because forking is sometimes necessary, and rights are meaningless if they are not exercised. In this specific case, without a fork, the Android project would have had a hard time achieving its goals (with regard to power management and more) in a commercially useful time. The result would have been a delayed Android release which would have led to less success in the market or, perhaps, missing the market window entirely and failing to take off. Forks, in other words, can be good things - they can enable groups to get things done more quickly than going through the community process.

Is forking equal to fragmentation, he asked? It is an important question; fragmentation killed the Unix market back in the 1990's. James claimed that forks which fail do not fragment the community; they simply disappear. Forks which are merged back into their parent project also do not represent fragmentation; they bring their code and their developers back to the original project. The forks which are harmful are those which achieve some success, carrying part of the community with them, and which do not return to the parent project. From that, James said, it follows that it is important for the community to help forks merge back.

The Android developers, beyond forking the kernel, also took the position that the GPL is bad for business. The project's original goal was to avoid GPL-licensed code altogether; the plan was to write a new kernel as well. In the end, a certain amount of reason prevailed, and the (GPL-licensed) Linux kernel was adopted; there are a few other GPL-licensed components as well. So, James said, we can thank Andy Rubin - from whom the dislike of the GPL originates - for conclusively demonstrating that a handset containing GPL-licensed code can be successful in the market. It turns out that downstream vendors really don't care about the licensing of the code in their devices; they only care that it's clear and compliant.

What about Android's special application framework? James said that the Java-based framework is one of the most innovative things about Android; it abstracts away platform details and moves the application layer as far away from the kernel as possible. The framework restricts the API available to applications, giving more control over what those applications do. Given the structure of the system, it seems that rewriting the C library was entirely unnecessary; nobody above the framework makes any sort of direct use of it anyway.

So maybe Android didn't do everything wrong. But there were some mistakes made; the biggest, from James's point of view, was the lack of a calendar which can handle SyncML. That made Android handsets relatively useless for business users. One of the keys to the Blackberry's success was its nice calendaring. Motorola had seen this problem and implemented its own proprietary SyncML calendaring application for the Droid; that actually made things worse, as business users would get an Android handset with the idea that it would work with their calendars. If they ended up with something other than the Droid, they would be disappointed and, eventually, just buy an iPhone instead. Android had no SyncML support until 2.1, when a new, written-from-scratch implementation was added. The cost of this mistake was one year of poor corporate uptake.

The other problem with Android, of course, is its "walled garden" approach to development. Android may be an open-source project, but Google maintains total control over the base release; nobody else even sees the code until Google throws it over the wall. No changes from partners get in, so there is no community around the code, no shared innovation. As an example, Android could have solved its calendar problem much sooner had it been willing to accept help from outside. Google's total control over Android was needed to give the project its market focus. It was a necessary precondition for market dominance, but it is bad for community and has forced Google to reinvent a lot of wheels.

Another big mistake was being sued by Oracle. That suit is based on Android's rewrite of Java which, in turn, was entirely motivated by fear of the GPL. Had Android been built on Oracle's GPL-licensed Java code base, there would have been no suit; Google would have been protected by the GPL's implied patent license. If Oracle wins, rewriting Java will turn out to be a hugely expensive exercise in license avoidance. And the sad fact is that the license is entirely irrelevant: the Java runtime's API constitutes a "bright line" isolating applications from the GPL.

Lessons learned

So what can be learned from all of this? James reiterated that forking can be a good thing, but only if the results are merged back. The Android fork has not been merged back despite a great deal of effort; it's also not clear that the Android developers have bought into the solutions that the kernel community has come up with. Maybe, he said, we need to come up with a way to make merging easier. The community should have a better way of handling this process, which currently tends to get bogged down in review, especially if the fork is large.

Projects which create forks also need to think about their processes. Forks tend to create not-invented-here mentalities which, in turn, lead to a reluctance to show the resulting code. It's no fun to post code that you know is going to be panned by the community. The longer a fork goes, the worse the situation gets; fixing of fundamental design mistakes (which is what wakelocks are in the community's view) gets harder. Preventing this problem requires forks to be more inclusive, post their code more often, and ask the community's advice - even if they do not plan to take that advice. It's important to open the wall and let ideas pass through in both directions.

James talked a bit about "licensing fears," stating that the GPL is our particular version of FUD. The discussions we have in the community about licensing tend to look like scary problems to people in industry; less heat from the community on this subject would do a lot of good. The fear of the GPL is driven by outside interests, but we tend to make it easy for them. The community should be more proactive on this front to allay fears; pointing to Android as an example of how GPL-licensed code can work is one possibility. The Linux Foundation does some of this work, but James thinks that the community needs to help. The GPL, he said, is far easier to comply with than most commercial licensing arrangements; that's a point we need to be making much more clearly.

We should also design more "bright line" systems which make the question of GPL compliance clear. The kernel's user-space ABI is one such system; developers know that user-space code is not considered to be derived from the kernel. Making the boundary easy to understand helps to make the GPL less scary.

The community should do better at fostering and embracing diversity, encouraging forks (which can create significant progress) and helping them to merge back. Currently, James said, the kernel gets a "C - must do better" grade at best here. We only take code from people who look like us; as a result, the Android merge attempt was more painful than it needed to be.

Companies, in turn, should aim for "control by acclamation" rather than control by total ownership. Linus Torvalds was given as an example; he has a lot of control, but only because the community trusts him to do the right thing. In general, if the community trusts you, it will happily hand over a lot of control; that's why the benevolent dictator model is as common as it is. On the other hand, companies which try to assert control through walled garden development or by demanding copyright assignment from contributors have a much harder time with the community.

In summary, James said, Android was a fiasco for everybody involved; we all need to figure out how to do better. We need to find better ways of encouraging and managing forks and allaying licensing fears. Projects which create forks should be thinking about merging back from the outset. Then projects which (like Android) are a commercial success can also be a community success.

[Your editor would like to thank the Linux Foundation for funding his travel to Japan to attend this event.]

Comments (92 posted)

Page editor: Jonathan Corbet
Next page: Security>>