This morning, while having my usual Cafe Latte (albeit this time in Berlin instead of at home sweet home in Nijmegen), I read about the Trinity project, which is an effort to revive KDE 3. I think this project nicely shows the advantages of Free Software. While the vast majority of KDE contributors agrees that KDE 3 is a dead end, technologically, these two guys (according to the somewhat sparse information on the website) are trying to continue to support and feature development on KDE3. Now I see a couple of real challenges for this project:
- Maintainance – KDE 3 is a large codebase. You need a good amount of people with domain knowledge of many different areas to effectively maintain a project like KDE. I see some of the first roadmap tasks for Trinity are updating the build system to deal with all the updated developer tools (e.g. newer autotools versions).
- Upstream Support – Official support for Qt3 ended on July, 1st 2007. nearly three years ago. Now this is not necessarily a problem (as Qt, too is Free Software), but it puts additional stress on the maintainance team — you have to provide support for Qt as well, not only KDE. This is also true for many other upstream components
- Community Support – KDE has many applications, and their developers take conscious decisions wether or not to support a specific version. Moreover, developers take great pride in their creations. Patches made to those components (even if it’s just maintainance) should be reviewed by their developers (who also happen to know the codebase best, have domain knowledge, and so on). Now the resources of these subprojects are also limited, and many decided to effectively end of life the support for their KDE 3 versions and fully concentrate on the KDE 4 version.
- Interoperability – In KDE 4, we introduced a couple of new technologies, D-Bus as our inter-process-communication mechanism, and the FreeDesktop icon naming scheme for Oxygen, KDE4’s artwork pillar. This was (and is) not possible with KDE3, and is actually only the tip of the iceberg of many improvements that have gone into KDE4, and which cannot be taken advantage of by programs based on KDE 3.
- Testing & QA – While the whole KDE project switched to KDE 4, we realised that releasing KDE 3 would be a lot harder in the future, since we heavily rely on the community testing the code before releases. This assures that the code is of sufficient quality and actually works. This process is not quite trivial, it needs testing, but also reviewing of changes that go into the codebase. For reviewing code you need familiarity with the APIs used by it, the actual codebase that’s being changed, and on top of that domain knowledge of the area your program is used in (for example if you’re writing a mail client, you should know mail protocols, and so on.) Again, you need a larger team to assure sufficient quality of the code you release.
For the above reasons, the KDE community has decided to not do releases of KDE 3 anymore. Technologically, it’s a dead end since many architectural, structural and environmental aspects of KDE 3 couldn’t be solved in KDE 3. If we just kept releasing KDE 3, we wouldn’t be able to assure sufficient quality and enough support so people wouldn’t be left out in the rain. Or put in other words, it would give KDE a bad name. The KDE3 branch in our SVN source code repository remains frozen for new features, bugfix patches are allowed but make very little sense, since there’s no plan to release new versions of KDE 3.x. That’s why the Trinity developers are using a work branch.
Those are challenges the Trinity team is facing now. Some of them can be solved by pouring enough manpower, tender love and care into it. Others aren’t easily solvable (think IPC) within KDE 3. Whether or not the Trinity team will succeed in maintaining and developing KDE 3 remains to be seen, but it’s certainly not an easy task. Then again, easy tasks are boring, and the Trinity team is validating the Free Software development and licensing model. In any event, the KDE community supports the efforts (for example by offering infrastructure in the form of source code repositories), and would like to see Trinity as another blooming subproject inside the KDE community.