You know that scene in movies where the doctor comes out of the surgery with a mask dangling around their neck and a solemn look in their eyes to greet the family who has been waiting what seems like forever in the waiting room? This is that scene. I'm that doctor. freedesktop.org is the patient. You are the family.
freedesktop.org is in really bad shape. There, I said it. Most of us knew it, but now it's been said. The good news is that it's rescuable. The even better news is that people want to rescue it, and some are actually doing things to make it happen.
Let me back up a bit, though. What is freedesktop.org supposed to be? Well, it's supposed to be a place for people working on F/OSS desktop projects to come together and collaborate on shared designs and shared software. It's been successful in bringing together drag and drop, window manager hints, application menus, icon themes, bookmarks, D-Bus and much more. This is valuable work and freedesktop.org is, or at least should, be vital to the F/OSS desktop platform.
It has seen better days, however. Currently it suffers from two major illnesses: administritus and anarchiosis. ;)
First, the administritus. freedsktop.org has infrastructure related to it: a website, cvs and git hosting, a bugzilla instance. This infrastructure is overseen by a group of administrators. These people are expected to be around whenever needed to set up accounts, approve projects and specifications for entry and do general sys admin type stuff as well. This means that they not only have to have lots of time and energy, but have to have a good idea of what's going on in the F/OSS world for each and every topic brought to freedesktop.org. They need that knowledge because it is them who gives the final "yes" or "no" to something being hosted on freedesktop.org. This is a completely irrational set of expectations, and the admin team is therefore performing as one would expect: below the par of what we need.
Now, I don't blame them as individuals .. I just think the expectations are insane and we, the projects, haven't given them enough support. We ought to have more KDE, GNOME, XFCE, etc. project people with admin privileges to help out. We don't, and that probably needs fixing.
However, that's just infrastructure. freedesktop.org isn't, however, infrastructure. freedesktop.org has infrastructure. It is the people who come together to work collaboratively who are freedesktop.org. Think of it this way: if KDE's svn server disappeared tomorrow, a new system would get set up in short order as best the community could manage and we'd get on with it. New infrastructure would emerge. If the KDE contributor community disappeared tomorrow, the existing infrastructure would not magically create new community. Therefore KDE is the community, not the infrastructure. freesktop.org, indeed any F/OSS project, is the same.
So while we work on solutions to the administritus, we are already working on the anarchiosis. What is that?
Right now it's very hard to get things on freedesktop.org, and not everyone trusts the freedesktop.org hosting due to past outages. The result is that we have work being done all over the Internet with little transparency to others.
There's also no way to know who has implemented which specification or uses which pieces of software associated with freedesktop.org. That's bad enough for those of us in the related projects that participate in freedesktop.org, but it's a deal killer for third parties on the outside looking in who'd like to implement support for the platform.
The admin team has the final say in what goes in and what doesn't, which means that people are not allowed to just work on what they want and let things bubble up. It's a top down approach that discourages people and prevents the best decisions possible from being made.
Finally, there is little to no leadership or process applied to freedesktop.org. When two people have a problem with each other, it's up to them to duke it out. When someone wants to use org.freedesktop for a D-Bus service name, there's no way to figure out if that's Ok to do and, if it isn't, no way for the rest of the participants to veto that.
The result is an inefficient system that is completely opaque to most would be participants that revolves around politics, bad decisions and arguments. Anarchy, and the bad sort at that. Several specifications are in danger of becoming defunct, forked or simply never see the light of day because of this case of anarchiosis.
So .. what do we do? We damn well fix it.
To bring some stability to the ills of freedesktop.org I gave it a swift kick in the nuts this past week in order to wake up the slumbering souls that populate the xdg list. This came via Plasma's implementation of the galago notification spec in 4.3. At issue were some very poor moves that accompanied the creation and maintenance of that specification, starting five years ago and continue to today. (I won't go into the details, it's been hashed through enough on the list and there's nothing to be gained by airing it even more publicly.)
Simply put: we had had enough of the shenanigans that are a direct result of the structure, or lack thereof, within freedesktop.org and we put our collective foot down. I wanted to make people own up to how broken things are. I think that was accomplished. Awareness alone isn't enough, though.
To bring some transparency to the process of specification writing, I've gone ahead and created an xdg-specs gitorious project that enables anyone who wants to get involved to do so. I started this a while ago, but it seems more critical than ever now and people are actually using it. If and when the freedesktop.org administration issue gets sorted and it's as easy as gitorious makes it to get involved with the specs process, this repository will move there. In the meantime, there's a README file explaining the proposed process in the repository, people are free to clone and work and I'm happy to add any specification author to the xdg-specs team to manage their spec in the main repository.
We can finally put all our work in one shared place, work together and document it in a way that third parties will know what we are up to. Which drafts are specs and which specs are standards can be deduced in future by simply measuring things in that documentation, such as how many, and which, projects implement which versions of that spec. You don't have to ask for permission to get involved, you just do. That's how F/OSS should work.
There are also the social ills, of course. Since nobody seems to have wanted to do much more than deepen the politics or bitch at each other or sit quietly and try to get something done amidst the chaos, I've done the silly brash sort of thing I do ... I've stepped up and have begun playing the role of facilitator on the xdg list. Nobody asked me to and I didn't ask for permission, but that's why it hasn't been done up until now: nobody is going to ask and there is nobody to grant permission. Catch 22? Nope. Sometimes you just have to step up and do it.
I'm not sure I'm the best person for the job, but at least I'm a person who will do the job. I'll stand in between people when needed, get out of the way when I can and generally make sure things work. However, I have no interest in control, title or even administration rights within freedesktop.org. (I make a crappy sys admin anyways. ;) I just want some oil applied to the moving parts so there's less friction and more movement that we can all live with.
I strongly urge the people who are attending GCDS next week to discuss these issues in person. Come up with some commitments between the projects. Get some people putting effort into these things. Stop screwing around and get your hands moving.
Save freedesktop.org, together. Or continue watching it die, day by day. It's our choice.