Keeping FreeDesktop.org working

In response to Aaron's blog about D-Conf I explained in my previous blog why I think a common configuration system is desirable. I didn't go into the issues that Aaron raised about FreeDesktop.org because I wanted to stay a bit focused and I found Aaron's blog a bit too confusing as to what his point with FreeDesktop.org actually was. This week I managed to dicuss the issue with Aaron on IRC and I think things have become more clear to both of us. Let me share me my new understanding here with you.

What Aaron somewhat correctly noticed is that there is a certain aversion growing among some members of the KDE community against FreeDesktop.org . The reason of the aversion seems to be a fear that FreeDesktop.org could become an unstoppable influx of bad technology. Although it may be easy to dismiss that, I think there is indeed reason to be concerned. In my experience open source projects are vulnerable to well intended people adding badly thought out code or concepts. Once added to a release a project is often doomed to maintaining such code until it is possible to drop it at the next major version. It happened to KDE and, acoording to Havoc, Gnome hasn't been spared either in this regard.

There are two factors that make this a bigger problem with FreeDesktop.org. Within a project like KDE there tend to be developers around that are comfortable enough to challenge bad ideas before they end up in a release, such challenge is often backed up by the reputation that the challenger has build up in the project over the years. But within an environment like FreeDesktop.org such safeguards are much less likely to work, challengers run the risk of being branded one-sided agenda-pushers and a reputation among developers of project A is less likely to bear any weight among developers of project B.

The other factor is that KDE can filter contributions based on the "show me the code" concept: show me the code first and then we can discuss whether it's suitable for inclusion in KDE. Although tempting to use the same approach in relation to FreeDesktop.org as well, I think that for a FreeDesktop.org project to be successful it's more important to build a solid mutual understanding about the problem and the direction to venture in before any code gets written at all. Having code out there without a solid mutual understanding only flames the fear that the codebase may not address the right problems and concerns but will somehow still invades other projects.

If the above is the problem that faces FreeDesktop.org, the question then becomes what we should do to let FreeDesktop.org overcome these problems? I think the first thing here is to understand and acknowledge that there will be FreeDesktop.org projects that are bound to produce very bad technology, be it misguided standards or badly written software. This is no different from KDE, we have large kdeplayground repositories, formerly known as kdenonbeta, full with software that is most likely never to see the light of day in a KDE release. Still we cherish the kdeplayground repositories because once in a while, out of maybe 20 failed attempts, one piece of software emerges that is truly worthwhile. And just as we have learned in KDE that along with such a success we have to deal with a fair share of failed attempts as well, FreeDesktop.org is likewise doomed to produce the really bad in the shadow of the really great.

So now that you know that FreeDesktop.org is going to produce some really bad standards and software, how are we going to prevent such bad technology from ending up in your software? There are two answer to that. The first one seems trivial and childish but is probably the most important one nonetheless: If you don't like it, don't use it in your software. It's important because the value of shared technology comes from the fact that it is shared. The fact that it is commonly used makes it extra valuable, if it isn't used it's sharing value drops to 0. Developers working on to-be-shared technology who realize this, will also realize that they will need to make a real effort to reach out to others to adopt their work for the sharing value to materialize. [1]

The second way to prevent bad technology ending up in your software is by being actively involved to make sure that the right technology decisions are being taken. After all, it's your software we are concerned about and you know probably best what the technological requirements and constraints are for your software and what, from the perspective of your software, makes the difference between bad technology and good technology. So go out there and make your concerns heard. If you don't raise them who will?

In all this there is a large responsibility on those who work under the FreeDesktop.org banner. There is a responsibility on all of us working under FreeDesktop.org to reach to others who could be affected by our work, to take note of their requirements, to acknowledge their concerns and then to work together really hard to address all that and make things work for everyone. I think it was Aaron's point that this sometimes doesn't happen enough.

I think the above explains a major problem that FreeDesktop.org faces and how to deal with it. I would also like to point how not to deal with it. That is by looking at FreeDesktop.org as a standardisation stamping organisation that blesses technology that everybody should be using. FreeDesktop.org mission page puts it like this:

The goals of freedesktop.org specifically exclude "blessing" or legislating formal standards, because freedesktop.org does not have the formal infrastructure for that. This site is about catching interoperability issues much earlier in the development process, ideally before code has been written, and providing a forum to work on specifications. Some of these specifications may be standardized by other bodies, but only after "de facto" acceptance most likely. You can look at freedesktop.org as a way to oil the wheels of "de facto" shared specifications.

Still, it's easy to mistake the platform defintion initiative as a blessing effort. I think Havoc provided a insightful view on this which I almost completely share. Any initiative in FreeDesktop.org aimed to create a formal defintion of a base platform should be very, very careful to limit itself to technology and standards that are truly established and widely adopted and stay far away from any controversy. We have established that FreeDesktop.org is bound to produce some bad technology, it would create tremendous damage to FreeDesktop.org's reputation if such bad technology would end up in the formal definition of a base platform. To prevent that from happening I think FreeDesktop.org should communicate very clearly, both internally and externally, that any base platform definition should be limited to technology that is widely adopted and without controversy.

1] This concept was lost on some participants in the recent D-Conf discussion but it seems that they picked up on it after several people pointed it out to them.