When the bazaar sets out to build cathedrals

Since its beginning KDE has grown to become one of the two most influential desktops. It is built on top of Qt (pronounced cute by trolls) which is a very powerful platform independent framework and toolkit for creating GUI and other applications.

The chapter starts with an extended discussion on factors that contributed to KDE's success. I loved this part which focused on social and political aspects of an open source project, the types of issues that are encountered and how KDE solves them. The chapter highlights how KDE has avoided a management team and instead leaves the decisions in the hand of those that do the work. This is a concept that I have heard being referred to as do-ocracy and I believe it is one of the most important aspects of an open source project. I doubt any large open source projects lacking this feature have ever been very successful.

Another interesting comment in the chapter was how they described the act of reaching consensus as as important as the consensus itself. This is to keep group cohesion and facilitates group "gelling". They also identify (free) software communities as first and foremost being social and not technical structures. I think this is something corporations should learn from as people are the biggest factor to software and a well function group is far more useful than adopting a new and better tool, language or methodology (tm) - software is peopleware and the two can't be separated.

They go on to describe the background and architecture of the Akonadi project. Akonadi is a platform for central storage, management and graceful interchange of personal information such as emails, address book information, etc. In the beginning such information was contained in separate applications that quickly became outdated due to unanticipated requirements. At first they resisted restructuring their code and attempted to meet these new requirements by patching the existing applications. The result is described as a messy code base and like with the messy metropolis the chaos seemed to flow out from the code and affected the social structure leading to an unattractive working environment. This effect was described as Conway's law in reverse in previous readings. The chapter was a bit vague here, but it seemed to me to suggest that what eventually pulled them out of this state was that the software increasingly needed to communicate and cooperate forcing them to do the same. The software had to come together so they did to. There were probably other factors as well that the chapter doesn't mention for political reasons, but I find it interesting to wonder about how much what we make in turn affects the makers.

In the end they came to a crossroads and decided to move the applications they had put so much effort into to the sideline and instead focus their hard won expertise on building the infrastructure for the next generation of PIM software. After some back and forth their new architecture adopted a client/server approach where a separate process would control all the PIM information and provide services to applications. These applications can communicate with the PIM process either through the multithreaded Qt-based libakonadi library or through any other third party libraries that can understand the protocol. Since communication with the server goes through a standardized protocol applications are not required to link against C++/Qt libraries meaning the server can be comfortably used by applications such as Evolution that is implemented in C. It therefore has the potential to reach its goal of being the one-stop shop for all PIM information. One thing I did find strange and unnecessary however was their decision to implement the server using Qt. I can not see any reason why it could not have been implemented using STL and pthreads and it means that a non-KDE system, for instance a Maemo-based phone, has to import Qt to use it.

The chapter ended with a discussion on the Threadweaver framework which is another task based parallel library that use a thread pool to accomplish task. Threadweaver allows users to specify tasks to be run in parallel as well as dependencies between these tasks. The former allows for embarrassingly parallel parallelism while the latter lets it pipeline tasks utilizing more of the inherent concurrency. Under the hood Threadweaver contains a scheduler that schedules these tasks and provide load balancing. Furthermore, the user can give tasks priorities that the scheduler will respect allowing them to tune the scheduling for increased throughput.