A Look at Kernel Cousins and KDE MythsJul 19, 2002, 14:30 (3 Talkback[s])
(Other stories by Dee-Ann LeBlanc)
Many people believe that open source is a good thing. The whole teamwork and community aspect is what draws most of us into open source, Linux, and that whole other slew of terms in the first place. There's only one little problem with having so many helping hands about: an overwhelming load of communication.
Aaron J. Seigo ran into this problem in two different areas involving the KDE project. As a result, he started two sites of his own: the KDE Kernel Cousin, and KDE Myths.
What is a Kernel Cousin?
Anyone who tries to follow the main kernel development mailing list knows that it's a busy, busy place where even the most dedicated reader will have a hard time keeping up with posts--if you can even understand half of them. Now, let's assume that you're following the main kernel list because you're interested in helping to make sure that particular features work or get implemented, such as a specific type of hardware or some other favorite item. If you're interested in a particular topic then you've probably subscribed to not just the kernel list, but any number of lists devoted to drivers, interfaces, documentation, and other aspects of that bit of technology.
A few years ago, Zack Brown decided to do something to help collate his particular area of interest's discussions into a central location. He created the first Kernel Cousin, called Kernel Traffic (http://kt.zork.net/kernel-traffic/). This Kernel Cousin is specifically devoted to the main kernel development list, linux-kernel, and its purpose is to produce weekly summaries of the various discussions on the list. Specifics of who said what are maintained, and posts are quoted where necessary.
Since then, a number of other Kernel Cousin sites have sprung up, and they all reside on http://kt.zork.net/. Existing Cousins include: Zack's own Kernel Traffic, one for the GNU/Debian Hurd kernel, one for the WINE project, one for KDE, and one for the GNU Enterprise project (called GNUe). There are also others that are considered "asleep," where the topic covered is still going strong (such as Samba) but no one's currently maintaining the Kernel Cousin site associated with it. The sleeping cousins include one for the Debian distribution, the GIMP, Samba, and SLUG (the Sydney Linux User's Group in Australia).
Some of these Cousin sites are run by a single person while others are maintained by a team of volunteers. The Kernel Cousin Authorship page (http://kt.zork.net/author.html) includes instructions on how you can get involved with the group-run Kernel Cousins.
The KDE Kernel Cousin
Our spotlight here is on Aaron's KDE Kernel Cousin. Aaron started as "a happy KDE user." But he wanted more. He wanted to get involved in the KDE project himself, so to him that meant getting to know as much about the people, culture, and goings on as possible. Soon he found himself on not only kernel issues for KDE, but also on more than a dozen other lists related to various aspects of KDE development. Several thousand pieces of mail a week flooded into his mailbox.
Now, some people would have set up elaborate filters so they could just read what they wanted. Or they would have scaled back their reading selections. But not Aaron. Aaron followed the kernel issues by reading the Kernel Traffic Kernel Cousin. What better way to "contribute to the [KDE] project while achieving [his] goal of learning about the people and culture around it" than to do summaries of the KDE lists and build a KDE Kernel Cousin?
Making an official Kernel Cousin site involves getting in touch with Zack, and learning all of the proper bits and pieces of how a KC site works. All Kernel Cousin sites are in a standard format. There are scripts to use that analyze mailboxes and make note of threads that have recently died, which means they are "ripe for summarization" as Zack puts it on his Tools page. There's also XML under the hood, so you have to learn how to work within the existing tag structure and how to play nice with XML's strict rules.
Once he had the KDE Kernel Cousin up and running, Aaron got to the regular work of producing the regular issues that included summaries and more. At the height of his solo effort, he spent ten to fifteen hours a week on this single project, and it sounds like if he had to do it all over he'd do the same: "It was very rewarding and educational, if not a little labour intensive." But even the best of us burns out. Rather than letting his Kernel Cousin die, Aaron brought in help.
Today, Aaron has reached his goal, and spends more time on KDE development than he does on the Kernel Cousin. However, a dedicated team of editors, authors, and translators keeps the site going, using an email list to coordinate their efforts. It's paying off, as this site is tracked by any number of Linux and KDE news sites, including Linux Today.
Due to the spread out nature of distribution it's difficult to gauge how much readership the KDE Kernel Cousin has, but with an educated guess it sounds like they're getting 8,000 or even 10,000 views or so per issue, and that's just in English. Then there's the German and French translations (and perhaps others that Aaron doesn't know about). Hopefully this makes all of that effort worth it!
One itme of note the KDE Kernel Cousin site, in the latest issue (as of this writing), there's a call for more authors to join the team. See issue #40 if you're interested It's a great way to get involved even if you're not heavily into coding.
And Then There's the Myths
Aaron puts it best: "KDE is a very large, very successful project with a rather complex history." Anyone who's spent any real time in a real life or online forum where there's a lot of new people wandering in and out, and a lot of outside interest, knows that you end up spending a good part of your time answering the same questions again and again. It's maddening. It makes a lot of group old timers grouchy. And if you're trying to explain to someone who doesn't speak your own primary language, it can be downright difficult.
When he saw how often the project members had to try to explain KDE history or current facts, Aaron had his usual reaction. Why spend all of that time and frustration when he could just set up a KDE Myths web site? That way anyone who asked could be pointed there for an answer, it would cut down on flame wars, and the project members would have time for actual coding and productive discussion.
A trip to KDE Myths (http://kdemyths.urbanlizard.com/) is an interesting ride through both history and the inner workings of the KDE project. Most readers are sure to learn something new while there.
And learning something new is what the Kernel Cousins and their offspring are all about.