battling misconceptions, even within KDE :)

Stuart has written a rather nice blog entry on misconceptions around what KDE is and how the community works.

One of Stuart's points was that KDE doesn't have top-down leaders that can tell random other people what to do in a way that they are beholden to follow. This is quite true, and it's a strength in that it prevents KDE from hijacked by any one interest, or requiring that we bet our future on any one group consistently and always making the best decisions.

It isn't, however, pure anarchy as one might get the impression it is from reading Stuart's blog. He notes that we do share commonalities such as the software libraries in the KDE Platform which create some bottom-up driven consistencies. We have similar "consistency creators" that aren't technical in nature, as well.

Stuart noted that we do have prominent community members, and many of those community members are prominent within KDE even if not so visible outside of it. These are people who are recognized at having great skill, wisdom and/or insight into issues relevant to KDE. These people often hold discussions that cross project boundaries within KDE to help create consistency and share their expertise.

People within projects also often seek each other out to discuss matters and find through patterns of challenge and consensus common directions. Our annual Akademy gathering is perhaps the most visible, if time and space limited, example of this.

Stuart is correct, at least according to my understanding of KDE, that "if you wanted to change our software significantly then you would have to contact key people in every team and convince them of your vision." This sounds a lot more difficult than it really is since projects talk to each other, we share information, we share links, we get together in person and knock ideas about, etc.

For institutions that have more resources to bring to bear in a more traditionally monolithic fashion, such as a company looking to productive parts of KDE's software offerings, we also often provide a well defined human interface for them that does the "contacting key people in the relevant teams" bit for them. So while that work does get done, the question is "by whom" and "how" and it varies from case to case. I would also echo Stuart's suggestion that using KDE e.V. as an initial contact point can be very useful for organizations looking to build an interface with KDE.

Is weird good, as Stuart asks? I agree with him on this point too: it is when it works. In the case of KDE it tends to work more often than it doesn't (and we try to constantly improve the areas that aren't meeting reasonable expectations), and in large part that's because while it is highly decentralized, we have a tight and vibrant network of people who work together to create an organic structure that provides a useful level of global direction and consistency.