So I've been thinking recently about KDE's overall marketing strategy, and I think that I've got a handle on my own vision of KDE Marketing, which is malleable and adjustable to accommodate varying strategies. I won't spam the whole planet with the details, since it might be lengthy, and only a few people will care enough to read the whole thing. This strategy is what I will be focusing on with my work within KDE over the next while, that is, if I don't get too distracted by the allure of coding :) ( Read On )

This last Friday, I had the pleasure of attending a lecture put on by one of the professors at the NRI (Natural Resources Institute) at my university (U of Manitoba) as part of our homecoming lecture series. The talk was about environmental/resource conservation projects in so-called third world countries where they were trying to provide a way to define a successful project.

The method they came up with was by measuring the number of entities involved in any given conservation project, be it local governments, international NGOs, universities, etc. They threw up some slides showing the networks that existed for a number of the more successful projects versus the networks for the less successful projects. The conclusion was that the conservation projects that were successful were not only well networked vertically, but more surprisingly, they were very well networked horizontally.

Now if I've lost anyone yet, vertical networking was in this case defined as links between the various levels of organization, such as local->regional->national->international government support. This example would have 4 levels of vertical networks, which is pretty good to get a project started, but not enough to sustain it for the long term as it has many points of failure. If any one member of a vertical network stops supporting the project for any reason, the whole project would collapse.

On the other hand, horizontal networking refers to links between entities that are on the same level. This would refer to multiple local governments all having a shared interest in a single project, or having the support of several regional institutions (like universities) rather than just one. Having horizontal links in the network would substantially improve the resiliency of the network to any single entity dropping out.

Now here's where I had an 'aha!' moment. I started to contemplate how open source communities function, and the open source world in general vs. traditional software development.

In a business, if there were horizontal links at every level, each working on essentially the same thing, the business would be considered inefficient. Any good manager would start to work right away to remove the redundancy in order to save money. And in fact, we have a lot of people who think like this when observing the open source world, telling us that there is no good reason for multiple projects to exist that tackle the same problems.

The answer to this is that open source is infinitely more resilient due to this redundancy. Now there are a lot of examples of this within the open source world that occur in almost every single project type.

Just consider, for a moment, KDE's multimedia support. Previously we had a pretty hard link to the aRts project, but it was definitely not the only multimedia project that existed during KDE's history. There has been a wide array of suitable libraries that could have done the job, but KDE was pretty concretely linked to aRts. This would be a sort of vertical link between KDE and aRts. The problem was that aRts was no performing the job that KDE needed, so we started to form more vertical links to other projects, like Xine or GStreamer to circumvent aRts. This would not have been possible if these projects were not simultaneously working on a more-or-less similar goal. In a company, if that portion of the software project had failed, we would not have had such a readily available backup plan (management would have axed it years ago!).

This same thing happens on a number of levels all throughout the open source community. People wonder why PostgreSQL and MySQL are always locking horns. Why we need ulibc when glibc already exists. How come we keep developing zsh when bash is almost ubiquitous. Why does KDE really benefit from GNOME's existence?

Well, just like our multimedia example from earlier, imagine that one day GNOME fails for some reason (why? I dunno, I'm talking hypothetically). Well, if GNOME was the only desktop project that existed, open source would take a huge blow. Thankfully, it isn't the only project. KDE would step in to fill the whole right away with little long-term implications to the health of open source in general. And while in this scenario, it would seem that we'd be down to one desktop, it wouldn't actually be the case at all. Other desktop projects are always nipping at the heels of KDE and GNOME, projects like XFCE or ROX would rise up to meet the challenge.

The open source world will always be fractured, with multiple projects for any single task, but in this lies the strength and longevity of the world-wide community. These horizontal links provide redundancy which allows projects that live above or below you to come and go without the whole thing going to hell.

One side-effect of looking at it this way is that the project that communicates the best with it's vertical links (KDE's dependencies upstream, and distros downstream) will likely be the most popular selection amongst the choices at any given level. The CMake team communicated really well with KDE, incorporating suggestions from KDE into later versions and so forth, which made CMake an excellent choice for KDE. The same was not true of some other build systems, which may have been able to handle a large project like KDE, but were less communicative.

Turn this scenario around and we have distros that are choosing a desktop environment. They will choose the desktop environment that is more willing to listen to their needs. We (and even I am guilty of this) have been of the impression that this communication is the distro's responsibility, but this philosophy will only drive distros away from KDE. We need to behave like the CMake developers and go out of our way to ensure that the distros are happy, and KDE will thrive.

We ought to create a working group entitle Downstream Relations or similar, where people actively seek communications with the distributions. Now, I know that there are hundreds (thousands?) of distros out there, and this is a huge task, but KDE penetration can really drive forward in the long run with this ideal. I will do my part.

So, I know I'm not alone on this topic but I will represent these opinions as my own for the sake of taking the brunt of the fury upon myself alone. I recently wrote an article about the complex relationship that exists between various open source projects, especially when it comes to dealing with upstream projects.

Now, the reason I wrote this article in the first place is to compliment a few distributions on how they are (as a result of KDE 4.0) sending some of their better work upstream to KDE. Some examples include: Ark Linux's recent announcement that they'd be moving all of their hardware stuff into Solid (which is awesome and I hope all the other KDE distros follow suit), and Kubuntu's contribution of System Settings to fill the void of KControl being mostly decommissioned. We, as the KDE community really need to applaud these distros when they take steps in the right direction and keep the upstream happy, and I for one would be happy to give press to any distro making contributions to KDE *nudge nudge*. This is really the only positive reinforcement that I can offer to the distros to take this action as I am only an individual.

But the way that the distros deal with KDE is not always rosy, and there are a lot of examples in the past where a distro has done its own thing to KDE and their own detriment. I will provide a few example here, but what I'm really looking for is comments on what the KDE developers and users consider to be the worst examples.

Example #1: OpenSuse managed to make it so that KDE 3.5.x does not depend upon aRts for multimedia, which is nice. But instead of making a KDE 3.6.x branch or similar within KDE's sources, they did it in an internal fork of 3.5.x. Now I recognize that KDE is moving fast towards KDE 4.x and would not really want to deal with releasing a KDE 3.6 series at this point, but it would have at least been nice to have it live somewhere within KDE's source trees so that other distros can more easily take advantage of this rather useful improvement. But instead, we now have users joining #kde with multimedia problems on opensuse that we cannot help in any way, since they are using a fork. (On a side note: Phonon should put this problem to rest once-and-for-all in KDE 4, finally!)

Example #2: Kubuntu changes many of the menus in Konqueror, which is designed to simplify the whole interface. This is a noble objective, and is good for their users (as long as their users don't need any support from the KDE community, or don't want to file bugs against KDE). The problem is that they've broken a number of things as a result. For example: in the default Konqueror menu, there's a "Save View Changes per Folder" checkbox in the "Settings" menu - this menu item was removed, and set to True by default. Now the only way for Kubuntu users to change this setting is to edit the config file by hand. A better solution would have been to put this setting into Konq's config dialog, and removed it from the menu upstream, in KDE, so that all users could benefit from removing a seldom used menu item.

These are only two examples, and many distributions are guilty behaving in this fashion. With KDE 4.0 here, it is the perfect chance for these distros to cast aside their patches, or to get them into KDE proper, and I really want to encourage the distros to accomplish this goal.

So, as part of my gentle nudging, I am looking for comments. What do you find are the worst changes that distros have made to KDE in the past (as well as a note if the problem was resolved or not)? What are some of the best changes made by distributions that should have been merged into KDE proper?

And to the distributions, what are the prospects of getting this work moved into KDE? (Remember, I can give good press for these contributions, which makes your distro look more appealing to the general public - mindshare and so forth.) I don't really want to negatively reinforce the major failures so much as I want to positively reinforce good behaviour via press.

Cheers folks

Edit: Oh, by the way, the 'recent' article I refer to in the first paragraph is available at Ars Technica and is only like a day old. It's probably worth reading as I talk about KDE a lot in that one. Inge Wallin tells me I should blog here every time I have an article worth reading, just to draw attention to them - but I'm not sure if that's shameless self-promotion, or just allowing people to find my stuff easier :)