Monday, December 6, 2010

A week in the life of a KDE e.V. board member

Did you ever want to know how life as a KDE e.V. board member is? From the questions I get I know that at least some of you do. So here you go. I took some notes last week to give you a brief impression of what I did in my role as board member of KDE e.V.


Domains. As legal representative of the KDE community, KDE e.V. owns most of the central KDE domains, most prominently of course, but also a couple of other domains like the main KDE domains in some countries. This comes with a certain amount of administrative work, such as domain transfers and a bit of technical administration like updating of name servers. Today the domain of our wonderful Indian community needed some care. This also triggered a discussion with the sysadmin team and we came up with a way to simplify the domain handling by delegating the name server administration. Will make things easier in the future.

Diplomacy. The board of KDE e.V. is one of the few groups of people in KDE, which is formally elected. Thanks to German association law, which is the governing law for our organization, this is a very solid, well-founded, democratic process. So the board is well legitimated to represent KDE. This comes with responsibility, as sometimes the board is asked for official decisions and guidance. Today we had to deal with one of these requests. These issues are not always easy to handle. While they certainly are one of the more challenging parts of the board work, I think they are also one of the more important parts. Having the board to handle these issues allows the community to get things moving, where it would be much harder without officially legitimated people.

Administration. Running an organization like KDE e.V. with its 400 members, its 300k EUR budget, its responsibility to support a global community, comes with a good amount of administrative work. Fortunately we have Claudia, our business manager, in our Berlin office, to handle a good deal of it. But there always is something left for the members of the board, be it deciding about reimbursement requests, handling membership data, moderating the board mailing list, or something along these lines. This creates some steady inflow of work. I usually take some time on the weekend to handle at least some part of it.

Email. The board acts as a point of contact for KDE as a whole, and for KDE e.V. in particular. So we get a lot of email. Answering this is of course part of the daily routine of the job. We handle that as a team, and usually it works well. If you have to wait a little bit to get an answer from us from time to time, please bear with us. Sometimes it just happens that we are all busy. But we will get back to you, and in case it takes too long, please send us a gentle reminder.


Preparing board call. We have a bi-weekly conference call with the board and Claudia every second Monday. This is the place where we discuss our daily business and handle stuff, which is not as easy to handle on the mailing list. It also helps to align us as a team. Today I prepared the agenda for the next call, quite packed this time.

Writing dot story. KDE is a partner in the EU research project ALERT. We were looking for a few community members who work on this project and bring in their KDE expertise. So I wrote a dot story announcing the open positions.


Board call. Today we had our bi-weekly board call. It's not always easy to find a date and time for that which suits all board members with their different requirements in terms of other things to do and taking into account the different time zones in which we are. But we found a 45 minute slot in the early European afternoon, which seems to work quite well. The meeting minutes are sent to the members after the meeting. Amongst other topics we discussed the quarterly reports. We have a new design, which is coming along nicely. Should be ready to be published really soon now.

Reviewing dot story. Our promo team does a marvelous job with making dot stories ready for publishing and getting them out of the door. I reviewed a few iterations of the ALERT story until it was ready to go out.


Call with startup company. Today I had a call with the managing director of a German startup company. They are creating a product based on KDE, and I helped them to find their way into the community. This is one of the nice aspects about being one of the central points of contact, you learn about exciting projects first-hand. This particular one is interesting. You'll hear more about that in the next time.


Taking a break. Board work is volunteer work, and all board members have a day job, family, and whatever else real life provides for us. I took a break from KDE e.V. work today, and dealt with some of these other things I'm doing.


Desktop summit program committee. I'm part of the program committee for the Berlin Desktop Summit conference. It's not directly part of my board job, but it comes close, as organizing Akademy or the desktop summit as joint event with the GNOME community, is one of the most important activities of KDE e.V. So I spent some time on getting the KDE members for the joint program committee together and get this going. We have a great selection of people from the two communities, and I'm really looking forward to create a great conference program for the desktop summit.


Reviewing applications. As response to the dot story a couple of applications for the ALERT jobs came in. I reviewed them and prepared them for further selection in the hiring committee of the ALERT consortium. We got good response, high quality resumes, so we'll be able to fill the positions with competent community people.

Discussion on membership mailing list. Luckily our community is an active bunch of people, who enjoys some good discussion from time to day. So today one of these discussions came up on the membership mailing list. I felt inclined to chime in. But there already were a lot of good contributions to the discussion. Usually I'm pretty impressed by the quality of the communication in the membership. It shows that we are a mature community.

Call with Claudia. KDE e.V. has one full-time employee, that's Claudia Rauch, our business manager. She is responsible for interacting with our partners, organizing Akademy, handling KDE sprints, running the KDE office, and much more. It's a bit of an unusual situation, as with the board she has five volunteers as bosses, which are all remote. So this is not the usual management situation. We handle that by distributing the related tasks relatedin the board. One part of it is having a call from time to time to make sure things work well, issues are resolved, and to keep in touch.

So that's my notes for now. It turned out to be a relatively typical week. But I have to say that no two weeks are the same. That's part of the fun, and one of the reasons, why I'm doing this for more than five years now. If you have more questions about the work of a KDE e.V. board member, please feel free to contact me. I'm always happy to tell you more.

Finally, if you are a member of KDE e.V. or the wider community and would like to get involved with some of the tasks, don't hesitate to get in contact with the board. We can't delegate everything, as some things have to be done by the actual board, but there certainly are tasks where help is possible and very much appreciated.

Sunday, October 3, 2010

The role of KDE e.V.

I wrote this article for KDE e.V.'s quarterly report Q2 2010. I'll reproduce it here in case you haven't seen it yet.

From time to time we hear the question, what actually is KDE e.V., what's its role in the KDE community? Let me try to answer this question here.

In short, KDE e.V. is the organization, which represents, supports, and provides governance to the KDE community. It gives the community a legal body so it can participate in activities which require a legal representation, somebody handling money, or a way to legitimize individuals to speak and act for the community.

Before I go into some more details of this threefold role of representation, support, and governance, here is a brief explanation of how KDE e.V. is set up organizationally.

KDE e.V. is incorporated as a non-profit association according to German law. The e.V. actually stands for "eingetragener Verein", which means "registered association". This is a very common legal form in Germany, which is used by hundreds of thousands of associations covering all kind of different activities from sports to animal rights to free software. This organizational form provides a very solid legal framework, which makes sure that questions about who can be a member, how decisions are made, how representatives are elected, how budgets are handled, and many other things all have well-defined answers. It also ensures that members are in control of what's happening in the organization.

Many other free software organizations have foundations as representing organizations similar to how KDE e.V. represents KDE. KDE e.V. is also recognized as tax exempt by the German financial authorities as its goals and activities are targeted at the public good. This also means that at least in Germany donations and membership fees provide tax benefits for donors and members.

The membership of KDE e.V. consists of the core of the KDE community. New members are voted in by the existing membership and the goal is to have a good representation of the overall community as members. Currently there are 165 members which are elegible to vote about KDE e.V. decisions.

But now back to the three roles of KDE e.V. in the KDE community; representation, support, and governance.

Representation is the most formal aspect of KDE e.V. A community like KDE - dynamic, distributed, mostly made of volunteers - has no natural way to handle situations where it's required that someone officially speaks for the community, signs contracts, or accepts money. This gap is filled by KDE e.V. Because its members are representing the core of the community, and because KDE e.V. owns some of the central assets of the community like the trademark and the domains, it can act on behalf of the community. The legal structure of its incorporation makes sure that this is handled properly and KDE e.V.'s activities actually represent the intention of its members.

So whenever a formal representation of the KDE community is needed KDE e.V. becomes active. This can mean signing contracts in the name of the community, it can mean accepting transfer of rights, e.g. with the Fiduciary License Agreement, or it can mean providing a way to give money to the KDE community.

The second important role of KDE e.V. is supporting the KDE community in creating free software. Because KDE e.V. acts as central broker of resources, it's able to provide financial support for a lot of activities. This shows in developer sprints, the annual Akademy conference, travel support for community members to all kind of community events, and the people we employ in our office, who provide organizational and administrational capabilities to the community in all kinds of different ways. This support would not be possible without the many donors and supporting members of KDE e.V., help which is very much appreciated.

In addition to the material support, KDE e.V. also provides other support. It provides a forum for the core of the community to discuss and make decisions. It also acts as a central point of contact, and is of course also an important part of the identity of the KDE community.

Last, but not least, there is the governance part. This is dominated by one important decision KDE e.V. has made, which is the decision to not control the process of creating the KDE software. KDE e.V. explicitly leaves that to the proven open source development processes, with its focus on peer interaction, deciding by doing, and all the other meritocratic elements, which found the huge success of this model. So KDE e.V. does not decide about technical questions, release schedules, what software to include, or how the community is organized in terms of software development.

Sometimes it's still needed to have a way to legitimize individuals or groups of community members to act in some official capacity. That's where KDE e.V. takes on a certain degree of governance. One example of this are the working groups of KDE e.V. which include, the community working group, the marketing working group, the sysadmin team, or the board. They are endorsed by KDE e.V. and so are able to act for the community and sometimes make decisions in the areas where this is needed. This mostly boils down to a question of representation of support again, which somehow closes the circle.

The value of KDE e.V. for the KDE community can't be underestimated. A community of this size couldn't work effectively without a mechanism to bring together representation, support, and governance roles. KDE e.V. has grown and is still growing together with the community from its inception in 1997 to these days of 2010, and a lot of this common growth can be attributed to the healthy and effective relationship between the KDE community and KDE e.V. as organization behind it.

Sunday, September 26, 2010


Almost five years ago, at the traditional KDE PIM meeting at Osnabrück, I drew the first version of the Akonadi architecture on a whiteboard. It felt appropriate to put the server into the center and arrange the different layers of the system around it in circles. The result was a beautiful diagram.

Trouble stroke, when I tried to create a digital version of the diagram. Putting texts on rounded shapes and arranging partial circle sections in a nice way was too much for all vector and diagram drawing applications I tried. So as a hacker, how do you solve problems? Right, you do it in software. So I wrote an editor for the diagram in Qt.

The mission was accomplished, the diagram up on our web pages. So the code for the diagram tool got buried under a pile of other stuff on my harddisk. But last winter, again at the traditional KDE PIM meeting at Onsbrück Steve reminded me of the tool by showing me an updated version with the then current state of the diagram, and a bit later at FOSDEM Paul complained that Kolab didn't show up in the first version. So there clearly was a need for an updated version of my tool.

After a little bit of hacking the tool is now able to handle multiple versions of the diagram, and here is a view of Kolab in the Akonadi architecture.

While hacking on the tool I also moved it into a git repository and published it on github. So if you want to have look, or if you feel inclined to play around with the Akonadi architecture, go ahead and clone Archibald. Let me know, if you do something interesting with it. I'm curious.

Wednesday, July 7, 2010

ownCloud in a box

I had some free minutes today at Akademy, so I decided to build an ownCloud appliance. I did a few iterations in SUSE Studio and there you go: ownCloud in a box.
The screenshot shows the ownCloud web interface running in a testdrive on SUSE Studio. The appliances is available as live CD, USB image, virtual image for VMware, VirtualBox or KVM, or as disk image. This should make it really easy to run your own ownCloud server for just having a look or for quickly getting an instance up on some computer.

It's a first version, so don't be too surprised, if there are still some issues. Feedback is welcome as always.

Friday, July 2, 2010

Akademy 2010

I'm on my way to Tampere for Akademy 2010. It's my seventh Akademy, not counting Kastle in 2003, the first KDE conference, which became the predecessor for all the Akademy events following afterwards. I'm especially looking forward to Akademy this year, because there are so many interesting topics to discuss, which could make a big difference for KDE in the future. So here are a couple of the things, which I'm particularly interested in this year:

Conference: The conference program is excellent as always. It's great that there is a strong mobile track. This is a still uderused potential for KDE, and I would love to see KDE expand much more in this area. Many years ago I wrote KOrganizer/Embedded which ran on a PDA, but I'm still waiting for the moment where I have a device running KDE software, which I actually want to have with me all the time.

BoFs: The BoF sessions are always a very important part of the Akademy experience. This is where actual work gets done, and where plans are forged. I'm involved in running three BoFs this year about KDE documentation, one about the supporting membership program, and a session about KDE e.V., which the board would like to use to answer questions about KDE e.V. and discuss what people expect from KDE e.V., and how we can improve and excel. They all will be interesting and I'm of course looking forward to attend some other BoFs as well.

Meeting old and new friends: KDE is an amazing community. Akademy and other meetings always feel like meeting friends, even if you haven't ever seen the other people before, and maybe just exchanged a couple of emails. So I'm looking forward to meet older gentlemen as well as the young and wild new members of the community.

Thinking future: Akademy always is a place to think about the future of KDE, of our community, our software. This year this is particularly interesting. There are a lot of interesting developments, be it on the hardware side, where devices which could run KDE software are becoming much more diverse, or be it on the software side, where web applications and the associated technologies, or new platforms like MeeGo or Android are having lots of momentum. So I hope we can have some serious and creative discussions about how and where KDE can find its place in this universe today, and in the coming years. Our potential is huge, bit we also have to make use of it.

There certainly is lots more exciting stuff happening and going on at Akademy. Let's see what it brings. And now...

Friday, June 11, 2010

Hackweek V: Graphical SUSE Studio Client

Hackweek V is over and I can happily report success. My graphical SUSE Studio client is functional and has the first cool features implemented. The focus of the client is not to duplicate the functionality of the SUSE Studio web interface, but to provide those features, which are hard or not possible to do on the server. This is stuff like managing downloads, running and deploying appliances locally, or native access to testdrive. From this list I got the native testdrive done. On the click of a button, the client starts a testdrive on the SUSE Studio servers and then connects with an embedded native client. This gives great performance and a very smooth and integrated experience.

The client uses the HTTP API of SUSE Studio to talk to the server. This way it gets the list of appliances and builds of a user and can operate on this data. It does some local caching of results of HTTP request in order to provide a very responsive user interface. The client is implemented using the KDE development platform, which provides all the bits and pieces to do the UI, to perform the HTTP communication, and also the embedded VNC viewer. It's pretty much standard technology, but I'm still amazed of how well all these pieces fit together and how easy it is to write such a client, which allows to move into areas, which aren't covered by the web application.

One detail of the implementation is particularly interesting, that's the XML parsing part. The REST-like API, which uses XML over HTTP, obviously involves quite a bit of XML parsing. Usually this is tedious code to write. This always annoyed me, so I wrote a tool to generate the parsing code, KXML Compiler. It's one of my hobby projects I work on from time to time since a couple of years now. It takes an example XML file and generates C++ classes from that, which represent the data, including parsers and writers from and to XML. So the application developer gets a nice native API to the data represented in XML without having to write any code. The tool works well for my use cases, but of course there are quite some situations, where it could produce better results or where it doesn't cover everything, so it sometimes needs fixes and improvements when taking on new data. It's an ongoing project and quite some fun as it involves some mind-twisting metaprogramming. The code is hosted as part of the Kode repository on github.

The code for the client is hosted in the Studiosus repository on Some more information about the development during this hackweek can be found in my Hackweek blog.

Hackweek was fun. I'm happy about the progress I made. It also was great to see some of the other exciting projects which were done during this week. This is a fantastic way to stimulate innovation. I'm really looking forward to see more of what came out of this week and what future hackweeks will bring.

Thursday, May 6, 2010

The quest for the perfect permalink

For SUSE Studio we are looking into adding nice permalinks to appliances. This turns out to be an amazingly difficult problem. The implementation is not too hard, but getting the scheme of the links right poses quite some interesting challenges.

So what do I actually mean by permalink? A permalink is a nice and convenient way to point to objects on a web site from outside of the web site itself. In our case this would be links which point to appliances on SUSE Studio. To make this nice and convenient the link needs to have a couple of attributes:
  • Permanent. The link should not change or depend on the state of the site or attributes of the user session. If you publish the link on another web site, e.g. in your blog, it should not break after a while or for other users.
  • Pretty. As the permalink is meant to be suitable for publication, it should have a pretty format, so that you can integrate it into text without completely destroying formatting and flow.
  • Expressive. When you see a permalink, it should be recognizable where it points to, so you don't have to click it to find out what it actually is about.
  • Short. For sharing the link it's nice, if the link is short. This is especially important when there are limitations for the length of the link, for example when sharing it via Twitter.
Meeting all these requirements is not easy, but there are also some additional challenges:
  • Handling change. The objects permalinks point to are being worked on, so they change in various ways. For example the name of an object could change. Permalinks have to handle this conflict between permanence and change in some way.
  • Namespacing. A site might handle different types of objects, so they need to be addressed in a way which doesn't cause conflicts. As we are talking about user-provided content here, there also is a cause for conflict by different users trying to use the same names. So we need to do some namespacing to handle these conflicts.
  • Potential abuse. The permalinks are pointing to user-provided content. So depending on how much influence the user has on the link, there might be some potential for abuse by users who try to create links which misrepresent the site.
  • Non-ASCII characters. If you base permalinks on names, you have to deal with characters which are natural in names, but not in URLs. This can make it hard to create permalinks.
Let's use a fictive example to illustrate the requirements and challenges:

John Doe likes baking cakes. He also likes to share, so he publishes his recipes on His favorite recipe is the chocolate cake of his aunt Tilly. So he publishes it and the site creates the permalink John tweets the link. His friends get it, bake the cake, and everybody is happy. This permalink is short and pretty. It conflicts with all other recipes named chocolate cake, though. So the first to publish a recipe wins. This is good for John, but bad for other users, so not a perfect solution.

One way to avoid the problem of conflicting names would be to add a namespace for the user, so the permalink would become It makes it longer, though, and there still is the potential for conflicts in the user name. So when John's sister Jane Doe joins, she'll not be able to use her favorite user name, which also is jdoe, but has to choose something else. Still not perfect.

Now aunt Tilly is a modern lady. She reads the tweet and sends an email to John: "Hi John, I gave you this recipe. Be a good boy and mention this on your web site. All the best, Tilly". John is a good boy and changes the name of the recipe to "Aunt Tilly's Chocolate cake". The web site creates the permalink This makes aunt Tilly happy, it's still expressive, pretty and relatively short, but it breaks the link in John's tweet. So the site has to redirect the old link to the new one. It at least has to prevent that the old URL is used for something different. It makes the nicer URL unavailable for other recipes in any case. This is good for permanence, but bad for pretty and short links.

Another problem which is illustrated by the name change is handling of special characters. The apostrophe is hard to handle in an URL, so the site just removes it for the link. You can come up with all kind of rules to handle these special characters, but they will eventually fail to generate pretty URLs, e.g. when somebody uses a Japanese name. This means that either the user edits the link, which introduces lots of opportunity to change and the problems associated with it, you give up on pretty URLs for at least some cases, or you let users deal with the problems of encoding special characters in URLs and the issues you can run into, e.g. when using tools which don't properly handle all of this. Another stumbling block on our quest for the perfect permalink.

An easy solution to avoid most of these problems is to generate random permalinks. This also removes all complexity with user-editable content and changes, as the the link is independent of the content. So aunt Tilly's yummy chocolate cake would be referenced by This is short and permanent, but not pretty or expressive.

You can think of various variations and combinations of these schemes, but meeting all requirements really is very hard. Seems like there is no perfect permalink. But let's look at some real-world examples.

Real-world examples

Wikipedia provides short and pretty permalinks. They have the advantage that the number of terms represented in links is limited, pretty well-defined and not completely up to users. They still have to deal with conflicts and do that with their disambiguation pages. They take on the challenge of encoding special characters, which is nice.

Gitorious lets users choose the permalink (or slug as they call it). They forbid special characters. The permalink becomes a top-level path, which is nice. You can't name your project login, though. You can change your slug, but this breaks old URLs.

Github goes a slightly different path. They prefix all projects with the user name. This is nice as it avoids conflicts and it also stresses the social aspect of the site. Some URLs become a bit ugly, e.g. They seem to cleanup their users and projects from time to time, as a nasty URL, which used to exist, I wasn't able to find anymore today. is a site to provide links to various openSUSE resources. You can for example reference repositories by short links like This is nice and short and reasonably expressive. If it's pretty is a bit a matter of taste. It doesn't address changing links.

Markmail is an example for random permalinks. This is probably the only way to cope with the number of objects they manage as a mailing list archive and the links are still short and relatively pretty: Change is not an issue for them as objects are static.

There are tons of other examples out there. If you know of one which solves the problems of permalinks in a particular good or interesting way, please let me know.

What do you think?

My preliminary conclusion is that it's probably impossible to come up with a perfect scheme for permalinks, and we need to do some compromise. I like including user names in the URLs as it solves some of the conflict issues, is actually useful information, and makes for expressive URLs. But of course there are other solutions as well.

What do you think? How would you like permalinks to SUSE Studio appliances to look like?

Sunday, March 7, 2010

Are you up for a new challenge in the SUSE Studio team?

Last time I blogged about open positions in the SUSE Studio team we were just preparing the first public alpha of SUSE Studio. We were excited about our application, but we didn't know what users would say. Now we are running SUSE Studio Online with more than 50.000 registered users. We have released an onsite version as part of the SUSE Appliance Toolkit, have won awards, and we get a lot of fantastic feedback. We have achieved a lot. To sustain this growth and success we are looking for some smart people to join our team. This could be you.

We love to learn, we like challenges, and we are passionate about great user experience. We are a tightly knit team of a diverse set of people spanning the whole range of development, from user interface design over Rails and system programming to QA. We have people who just started their career and others who have decades of experience in the business. Technology, innovation, open source, team work, and meeting the goals of our users are important to us.

If you are interested, look at the job descriptions. We are looking for user interface designers, web developers, Rails experts, and all-rounders with a hang for backend programming. You will learn, you will grow, you will be working on exciting software. Apply now.

Saturday, January 23, 2010

Anatomy of a developer sprint

Two weeks ago I was at the annual KDE PIM meeting at Osnabrück. It was the eighth time that this meeting took place, and it was a blast, once again. This is amazing, so I'm taking the opportunity to reflect a bit on what makes this meeting so successful, how it evolved over time, and what we all can learn for running great developer sprints.

It all started in 2003. KDE PIM as a group didn't really exist yet, the kdepim module in CVS contained only a small collection of apps, mainly KAddressbook and KOrganizer, and some prototypes for what would become Kontact. The work on the Kolab server and clients had just started, and Intevation who was doing the project management for the Kolab project invited key people of the community and those who were working on Kolab to Osnabrück for some serious discussions, hacking, and community building. It was the first weekend in January and this date should stick as the traditional date for the KDE PIM meeting for coming years.

For many of us it was the first time we met each other in person. It's always amazing how much of a difference this makes. Of course we knew each other via mailing lists, IRC discussions or working together on code, but meeting face to face added another dimension. The astonishing thing was that it felt like meeting old friends. This is an experience I made again and again when meeting KDE people in person for the first time, and I know that many others have made the same experience. What a motivation!

One result of the first meeting was that KMail was moved from kdenetwork to kdepim. This was the birth of the KDE PIM community as we know it today. Even if it were mainly technical details which motivated this move, it had a big effect on how we felt as a group. The second big topic was the integration of the work which had been done on the Kolab client and how to combine that with the efforts going into a brand new application called Kaplan, which would later be known as Kontact as the central application of KDE PIM. So bringing all these people and different code streams together formed a new part of the KDE community, which had an unprecedented focus on creating great PIM solutions.

You see that already one meeting of the right people in the right atmosphere can make a big difference. But for KDE PIM it should quickly evolve into a tradition and constant source of energy to have these developer sprints. Over the next years we kept the annual meeting in January at Osnabrück and Intevation continued to kindly act as a host. This made organization of the meetings very easy and thanks to the support of KDE e.V., which provided us with financial support for travel and accommodation, we were able to get together most of the central people each year. In addition to the annual meeting some spin-offs started to happen, meetings at Akademy and the wonderful KDE PIM meeting in the Netherlands, and as we consciously always invited new people to the meetings they also became a source of fresh talent and energy.

While we developed some routine in having these meeting, in 2006 something special happened. Till came up with the idea for a new backend for storing PIM data. As we all felt the pain of the limitations of current solutions, this sparked a lot of interest, and over the time of the meeting we put together our combined experience in laying the foundation for this new framework.
We intend to design an extensible cross-desktop storage service for PIM data and meta data providing concurrent read, write, and query access. It will provide unique desktop wide object identification and retrieval.
Akonadi was born.

With Akonadi a whole new world was opened and the nature of the meetings changed a bit. They had grown in size and scope and while the early meetings were dominated by ferocious hacking, other activities like coordination, learning from each other, and strategical discussions became more important and took a bigger share of the meetings. So as a complement to the annual Osnabrück meetings we introduced a new set of Akonadi sprints as very focused small events dedicated to writing as much code as possible, taking advantage of having the central developers in the same room for an intensive weekend.

So where are we today? We just had the eighth Osnabrück meeting, the Akonadi port of all of the KDE PIM apps is landing in trunk for the KDE 4.5 release. Kontact as the central product of the KDE PIM community is running on an impressive bunch of different platforms, including of course Linux, but also Windows, MacOS and in the future also mobile platforms. The Kolab consortium is running commercial development based on KDE PIM for as long as the KDE PIM meetings exist. We have come a long way. This wouldn't have been possible without all the developer meetings.

Finally I would like to reveal one of the secret ingredients which makes our developer sprints so successful. It is having fun. Be it the snow ball fight before the group photo, the game of go after dinner, or meeting friends, having inspiring discussions, or the occasional grand hack. When you bring together passionate people with a common vision, who enjoy working on outstanding free software, great things happen. That's what we have our developer sprints for.

Governance on demand

I have talked about the Spectrum of Open Source Governance Models  before. After rereading Nadia Eghbal's excellent post Governance with...