Apparently this person would be happier to pay for Red Hat Enterprise Linux if we removed open source code from the Fedora Project and included it only in Red Hat Enterprise Linux under a proprietary license. He says we don't understand "value add," but maybe this is one of those RMS is right moments (see the joke about "freedom subtracted").
The technical points in the article are often off-base too - hint, the Red Hat Enterprise Linux 3 feature list was driven by the most common enterprise customer requests, and the things on the list aren't in this article... but I can live with that. I'm just blown away that he's complaining that he could use Fedora Core 1 for free.
I realized today that all the talk about Longhorn is "look how cool the technology is" - Avalon, XAML, WinFS, blah blah. This includes the noise coming from Microsoft. There is some small amount of Aero user experience info, but most of it describes building blocks - a sidebar that can hold tiles, a notification feature, WinFS. The user functionality shown for WinFS is not that exciting; search, sort, and filter. Yay.
People seem to be saying "here's a ton of code - imagine the user experience possibilities!" but not really talking about any specific concrete enhancements the OS will include. How do real user tasks get better: calendars, email, document collaboration, whiteboarding, etc.? How does this thing help me get my work done? If I'm not a developer, why should I care about Longhorn?
I don't doubt that Microsoft has some ideas, but I think it's interesting that they aren't talking about the OS in these terms. Am I just missing the relevant information? The Longhorn home page links to a bunch of developer stuff.
More importantly, why is GNOME talking about Longhorn on Microsoft's terms? We've been talking about "competing with Longhorn" in terms of matching all the technical gizmos. But shouldn't we instead be talking about the most expedient way to get similar user experience enhancements? Our desktop offers similar functionality to Windows XP today, but is implemented completely differently. But for Longhorn, we're talking about competing with the implementation before we even know the functionality.
I'm sure everyone will agree with the principle that we should plan the Linux desktop by starting with what we want users to be able to do, and ending with how to implement it. But in thinking about Longhorn, at least I haven't been doing that.
I'm kind of amused by this discussion of kernel backports.
As I pointed out earlier, we should hand the kernel hackers a copy of the GNOME release process. Asking vendors not to backport is conceivable if you have regular releases. If you don't have regular releases, then there's no way vendors can ever work on HEAD without backports - because nobody can invest money to develop a feature that may not be usable for an unknown number of years.
The "fragmentation" issue is totally bogus anyhow - backports aren't the same as dead-end patches that the mainline project rejected.
Glynn, unfortunately fascinating isn't the only metric. ;-)
I should clarify exactly what I think James Gosling gets wrong: he says the Gnome world has "formless dreads," I think the concerns are in fact very detailed, rational, and well-understood, though there's some noise and some inability to post legal advice that may make this hard to see.
One thing I skipped in my post is the discussion of the pragmatic reasons why open source has to be defined as it is, and why its definition enables a particular development model and set of customer advantages. This model and these advantages are genuinely lost if you use an "almost but not quite open" license. It's not a matter of religion.
Dr. Gosling also compares the Java license to the GPL, but it's worth noting that none of the GNOME or common Linux libraries are under the GPL; they're under the LGPL or less-restrictive licenses. In other words, if we compare apples to apples, when he says:
Unlike GPLd software, the Java sources don't come with a viral infection clause that requires you to apply the GPL to your own code. But the sources for the JDK do come with a license that has a different catch: redistribution requires compatibility testing.
In fact the GNOME and Linux platforms don't come with this "viral infection clause" - only the applications have that. And you aren't going to use an application in your own code. So comparing the JDK license to the GPL is wrong. You have to compare it to the less-restrictive licenses used in the platform.
I just remembered that I wrote an article about the SCSL 5 years ago, before I worked at Red Hat: here it is, still on my web site. I no longer agree with some of what I said and how I said it, in fact the article sort of sucks, but it's interesting how little has changed in some respects.
James Gosling claims that there's a patent grant for Java, but he does not understand the issues fully. Here is what he says:
There has been a big debate about implementation languages in the Gnome world. It's been all over the map, but one point of concern has been a set of formless dreads about the usability of the Java language specification. We've been very clear about this, but it seems like few have read the spec: if you look in the frontmatter, it contains an explicit statement that anyone is free to implement the specification. It goes much farther than most other specification documents: it actually includes a patent rights grant.
Here is the Java specification license. I am not a lawyer, but to me this says that you only get the patent grant if you pass the compatibility suite. The terms of the GPL used in the existing open source codebase prohibit this compatibility requirement. If you have this requirement on your Java implementation, and you link for example gnome-panel to Java, then the result is not distributable under the terms of the gnome-panel license. Because gnome-panel has hundreds of copyright holders, we can't change the gnome-panel license, even if we wanted to.
It's also worth noting that the only working open source implementation of Java (i.e. Classpath) is partial, and thus would not pass the compatibility suite. Without a usable open source implementation, we have a showstopper for using Java in GNOME, because we can't use the proprietary implementations. This leaves us having to wait for a complete implementation before we can start using Java at all. Surely it would be better if we could use some core subset immediately, as that would at least go down the Java path instead of an entirely different direction such as .NET cloning. Classpath does have full Java compatibility as an explicit goal, they just aren't finished yet.
I think a lot of people feel that the open source world is being unreasonable in insisting on open source for all dependencies. Aside from the practical issue that we can't relicense due to the sheer number of copyright holders, to me this is like saying a company is unreasonable for insisting on making a profit. It's simply the premise of the GNOME organization that we're building an open source desktop. That's the whole point of the undertaking; otherwise we'd use Windows or Mac or BeOS. If you don't stick to the premise of the organization, you don't have a reason to exist; in this case we'd simply become what we're trying to replace.
For GNOME specifically, the project was founded as an alternative to KDE back when Qt was proprietary - a situation exactly analagous to a dependency on proprietary Java. So it would be exceptionally strange if we added a proprietary dependency after founding a project specifically to avoid having proprietary dependencies!
Of course, you could say that compatibility is the same sort of founding principle with respect to Java, and perhaps it's equally out of the question for Java to add extra risk of incompatibility. But perhaps there are creative solutions, or ways to make that risk inconsequential.
I'd be interested in the arguments for and against Sun enforcing compatibility via trademarks, rather than licenses and patents. That's how Red Hat Enterprise Linux works and it works very well. Overall I think it would be fascinating to be inside Sun and be able to fully understand all the issues surrounding Java licensing.
In the meantime though, to me it looks increasingly like we need to go down the road of Python, XPCOM/UNO, GObject introspection, and other half measures; hopefully stay out of the .NET clone trap; and maybe in time create an open alternative to .NET and Java both. It's a shame however, because Linux and Java are natural allies that could both be more successful in combination.
D-BUS development looks like it's moving again, at least a bit: Michael Meeks, Jon Trowbridge, Olivier Andrieu, Thomas Leonard and others on the lists. Also, we're hoping to assign some of the new Red Hat guys in this direction. With all this help it might even get done for GNOME 2.8, could happen if everyone keeps at it.
Of course I have to agree with Luis that sticking as close to trunk as possible is best - that's one of the big reasons we switched to the 6-month time-based releases, to keep "what the developers are working on" and "what users are using" as in-sync is possible.
If you want to see wasted effort, have a look at the enormous backport-fest in the vendor kernels... the kernel project is really pretty broken in this respect. With GNOME, even if people ship 2.6 rather than 2.8 it's not that bad. Or not as bad as the GNOME 1.4 days when we spent a year trying to get people to stop piling patches on 1.4 and finish 2.0. ;-)
I think the main reason much of XD2 didn't make it upstream was that it was done behind closed doors without buy-in and much of it was done in a pretty hacky way (for understandable reasons). If we instead take the approach of first making the change in 2.8 in an upstream-acceptable way and then backporting to 2.6, then we know stuff won't be lost.
It's a little bit dangerous to have people planning to ship 2.8 when 2.8 is released well into the OS freeze cycle; what happens is that if 2.8 is for any reason delayed, you can't back down to 2.6 during a freeze, and you would be forced to ship a 2.7 beta (or put a big unexpected delay late in the OS release cycle, which may not be an option in a still server-driven world). GNOME is safer than any other project I know of to do this with, but it's still a little scary.
This whole discussion may be opaque to others: context is, Luis and I were discussing earlier whether to base the next OS releases on 2.6 or 2.8. Red Hat hasn't really decided yet.
BTW, I agree 100% that the foundation should hire people to do admin work; it just pains me to see Jonathan and Owen spending a bunch of time on that. Hiring developers is different.
Four new desktop developers joined Red Hat in the last week; keeping me busy.
One of the slides at my linux.conf.au talk on the desktop was Commercial Involvement Will Grow, and I had these bullet points:
The issue comes up all the time, here are some examples large and small:
Just a sampling. It's not new to have this issue; many of us "old timers" are still battle-scarred from the days when Eazel and Ximian first appeared, and the GNOME Foundation was largely motivated by the desire to control and limit commercial interests.
There aren't any easy answers. No matter what organizational structure you build, companies have a couple of inherent power advantages over independent developers.
Companies in turn though are in large part required to follow customer, partner, and legal requirements, and are not free to do anything they choose to do. Sometimes the people most actively against company-advocated directions are those who are happy with a UNIX-geeks-only sort of project and dislike moving in directions with broader appeal.
Because the GNOME Mission Statement defines the project goal to create a platform "for the general public," working with companies to find out what customers want, get wide distribution, and offer support becomes more or less essential. But "working with" should be on the right terms, in a way that preserves the nature of the project.
Honestly I think GNOME has the commercial relationship more right than the vast majority of open source projects. One thing that tends to happen though, and also happens in the kernel world, is that independent contributors are regularly hired by companies. I'm hoping that as GNOME grows the number of companies doing hiring like this will grow as well, as it has for kernel. Because companies tend to disagree with each other, this reduces the influence of each one.
A model I'm not a fan of is the Mozilla Foundation or old-style X Window System model, where a nonprofit organization employs developers. To me it's better to have companies employ people directly, because it's more transparent where the influence is coming from, and as corporate interests become irrelevant their influence naturally disappears. Companies are also more directly responsible to customers, which is generally a good thing for the software, with the occasional exception of customers with out-there special-case demands.
One thing that helps avoid conflict is to clearly state the goals of a project, so that everyone involved knows it up front. It's tough for incompatible "visions" to exist in a single project; for example, GNOME had a lot of growing pains deciding that a project goal was usability for regular people. Very often a "companies vs. volunteers" conflict is really a "what is the project about" conflict. If you have some goals up front, nobody can complain about them later.
Luis's post gets at one of the most important priorities: to be sure discussions of project direction are public. Including both small and large issues. So I hope we'll be able to do interaction design "in the open." The Mono/Java argument is a real mess in this respect - we discussed it some in public, but it turns out all the relevant facts aren't public. :-/ What one does at that point I don't know.
I suppose this log entry has no conclusion, I was just thinking about the topic. I do hope GNOME's results speak for themselves in many ways, showing that we do at least some things right.
That article is spot-on when it talks about how usability is more than adding some easy config tools on top of an existing system. I also love the accurate point that technical users don't like the broken bits either.
But after two years I continue to believe that the causes of poor free software design are not intrinsic to the license.
Serious commercial support for the desktop is just starting up, in about the same place commercial support for the server was 3-4 years ago. Though we may expect the desktop to ramp up more quickly, primed by the server.
At Red Hat, we're building the desktop team around a top-down design-first approach, driven by professional interaction designers. We'll see how it works out. It will take some time before the first results are visible.