So it's been pointed out that since I'm no longer terribly involved…: mjg59

So it's been pointed out that since I'm no longer terribly involved in Debian, I possibly shouldn't be on Planet Debian nowadays. So unless there's any violent objections I'll ask to be removed at the end of the week - my RSS gunk is at http://mjg59.livejournal.com/data/rss for those who want to read my delightful prose in any case.

Anyway. Some token Debian-related content. Mozilla corp are unhappy with Debian providing a package called "firefox" unless every patch provided has been approved by Mozilla in advance (there's also some stuff about the logo, but that's basically a bizarre corner aspect of the same problem). I'm not going to argue against this on philosophical grounds - it's clear that that isn't going to change anybody's mind. Instead, let's compare this to some other major applications:

Linux. Pretty much every vendor patches Linux. Part of this is for hardware support (adding out of tree drivers, and so on), but a great deal of it is feature development. A lot of patches that appear on LKML have already shipped in vendor kernels.
X. Arguably one of the most forked applications shipped by any distribution - almost every X server shipped by any vendor ever is based on the reference X11 code. Without the right to fork X and maintain its name, we wouldn't have the X.org implementation[1]. No composite, no accelerated indirect 3D rendering, no input or monitor hotplugging.
Gnome. Vendor patches to Gnome have largely been concentrated on branding and defaults, but in some cases we've seen major functionality changes. The new menu applet in SLED 10 is an example of this, and depending on how it's received it's likely to influence upstream development.

On the Mozilla side of things, the closest I can really come up with is cdrecord. There's some pretty strong parallels (upstream being unhappy about various patches, requiring a sufficiently different work to have a different name), but the end result in the cdrecord case was that we ended up with an application that was poorly integrated with the rest of the Linux environment for the sake of remaining consistent across different operating systems.

I'm not saying that that's going to happen to Mozilla. But we've seen numerous cases where allowing vendors to distribute derived versions has encouraged development and testing of new ideas, and I think in most cases that's resulted in benefits to the upstream project. The fundamental problem with refusing to allow patches that cause significant deviations from upstream behaviour is that it makes it impossible for anyone to actually get things like UI experiments into the hands of users. With Gnome, if upstream don't like your idea you have the opportunity to prove them wrong and possibly change their mind. With Mozilla, if upstream don't like your idea you're pretty much screwed. Most distributions are going to be unhappy about losing the magic Firefox branding, so you're unlikely to sell them on it. And you're not even allowed to provide binaries or source on your website unless you've renamed it away from Firefox.

I think the Mozilla corporation are missing something here. We shouldn't be prizing cross-platform consistency over integration and innovation, and we certainly shouldn't be doing our utmost to make it difficult for people to experiment with code. There's a reason that cd writing under Linux has been sucky for years, and it's not because people lacked the technical ability to make it better.

[1] Ok, the X.org case is slightly confused by the fact that they are upstream now. But without the ability to fork under the same name, they wouldn't have been.

Log in