simple suggestions for FD.o and aspiring KDE devs

first, the quick topic: aspiring KDE devs often seem to have a hard time coming up with an idea of what to create. i think they often stub their toes trying to come up with that really awesome idea that's going to kick ass and do all kinds of crazy things. my advice: don't bother. write something simple with a single purpose and a clean interface the first time around. you can conquer the world with your never-seen-before killer app on your second run. ;) users love neat little applications that do one thing well and it's a great way to toy with kde development without becoming overwhelmed.

and now the less quick topic: freedesktop.org. i was reading p.g.o and came across this blog entry by sven neumann where he details why klipper sucks. i totally agree with him that x11 clipboard semantics are still poorer than they ought to be. it seems after getting over the initial hump a couple years ago nobody has had the gumption to go the final few miles with it. it's good enought™ for the hackers, but trust me (and sven): it sucks for the users. of course, i haven't stepped up to fix it, so i can't really bitch too much, right? anyways, so i was nodding along with sven until i got to this:

It looks as if GNOME 2.12 will have clipboard manager functionality integrated into gnome-settings-daemon. It implements the Free Desktop Clipboard Manager Specification. Let’s hope that the KDE apps and Klipper adopt this standard as well.

can you spot the problem here? sven refers to the clipboard manager draft spec as a standard.

remember the bruhaha last time i wrote about fd.o and how havoc and waldo both took time (something i respect and appreciate) to communicate that freedesktop.org doesn't create standards? well, the tribes aren't groking it.

as long as only gnome or only kde or only $environment implements something it isn't a standard. it's a proprietary implementation. and if nobody implements it, it's just a nice idea. publishing your design in fd.o's collaboratory doesn't change that, though that is a great way to open up an implementation so others may decide to join hands with you and thereby start the process of creating a standard.

how can fd.o help get this message out to the members of our tribes so that it becomes part of the cultural vocabulary? looking at the freedesktop.org website, some things popped into my mind:

• note on both the spec summary page and the specification itself what the current standing of that spec is. rfc's have been doing this forever because it makes sense. our specs ought to note on them whether they are to be considered a draft or a mature spec and where, if anywhere, they are used and implemented. no, a version number doesn't communicate any of this useful and even necessary information. if the spec maintainer can't be bothered to do this, remove the pages.


• replace the word "standards" from the urls in the wiki on things that simply aren't standards with something more accurate


• rename the "standards" page to something that reflects the true goings on


• communicate clearly the purpose of fd.o to the public. they still don't understand the point of fd.o. people who stumble upon my blog entries about fd.o and read the various blog replies often leave with a new understanding that is closer to the truth, but blogs hidden away aren't enough. those at the centre of fd.o ought to step up and do a bit of public communications. some time back waldo said to me, "so you're saying that fd.o needs a pr department". i couldn't agree more. 95% of cooperating is communication.

as you can see, the fd.o site isn't helping at all with the "we aren't a standards body" concept as the s-word is visible all over the place and there is little to no communication outside of fd.o-land to the rest of the world. this is probably because we're all overly busy, but we ought to have had at least a few hours over the course of the last couple of months since this was all discussed via blog right?

many of our users and outside developers have unrealistic expectations for fd.o, and they are asking why reality isn't matching up to those expectations. some developers are trying to use fd.o as a means to push their ideas into being standards because that's what they perceive fd.o's function to be. the resulting disappointment, confusion and dissonance that comes from those perceptions not being met is not optimal.