Improving freedesktop.org

[Havoc Pennington]

Frans Englich wrote:
> I think the wisest thing to do is to turn Free Desktop into a huge whiteboard 
> and push the specifications into standard bodies. The latter would indeed be 
> part of Free Desktop's mission, in order to ensure that it actually happen, 
> instead of them staying on FD's server(such as turning DBus into an RFC).

There are good reasons freedesktop.org is not a standards body; it would 
simply be too slow and too much work, and open source developers would 
not bother with it. The goal originally was and always has been 
pragmatic - the idea isn't "standards" but "people have a place to talk 
to each other and see they could share code or an approach."

I think you're right that the way to go if anything really needs 
standardizing is to send it through IETF or W3C or X.org or whoever else.

In many cases I have to say I don't see the point, simply because the 
only people who care at all are X-based desktop implementors, and 
there's no real value to expanding the audience or the number of cooks. 
You're right that it involves work and money, and we shouldn't blow 
either our own work/money or that of a standards body when it won't have 
real value.

Where I'd see the point of a formal spec: something that we'd truly 
expect to be widely reimplemented.

If you look at freedesktop.org successes, most of them are 
implementation standards (cairo, fontconfig, dbus, Xlib) that may happen 
to have a spec, but the real win was the shared implementation.

Formal specs usually have long lists of implementations, while 
freedesktop generally has 2 or 3 at most, and even in those cases we'd 
probably rather have 1.

So one question is which specs are these? Are there any specs that we're 
looking to have widely used outside of a short list of known open source 
desktop projects?

EWMH is the only freedesktop spec I can quickly think of that has a 
fairly large number of implementations.

Another argument for formal specs has been ABI/API guarantees, but 
personally I think stable ABI comes from good implementation maintenance 
and good compatibility testing, I don't think spending a lot of time on 
specs does much more than cover asses ("you relied on unspecified 
behavior!").

In particular there's a long history of people whining about ABI changes 
/ lack of guarantees and proposing various documentation/policy 
solutions, when the real problem is just finishing the code such that 
it's maintainable and we have something ready to be frozen and widely 
used. i.e. usually we need hacking, not specs, on the ABI front - 
whether fixing the way things work to be sane enough to freeze, or 
coding compatibility tests. IMHO of course.

A final reason I get the sense people like formal specs - they want to 
impose a spec top-down when it isn't getting "naturally" adopted. I 
think all the core maintainers are pretty against this, and it leads to 
deeply broken specs with no relationship to reality.

Again here I think the solution is code, not specs. Take the "font 
problem," we could have written specs (and whined about fragmentation) 
for years, but just pragmatically writing fontconfig was a better solution.

The same holds for current problems such as the "vfs problem" or "applet 
problem" or whatever. Coding work will fix these, specs will not.

Havoc