Notes From the PIM Sprint: A Vision for the KDE PIM Framework

Notes From the PIM Sprint: A Vision for the KDE PIM Framework

I know I know, the PIM sprint has already been last November, but in my defence (@David: !!!), the VDG and KDE as a whole has been so buzzing with activity in the meantime that I didn’t find the time to write the blog post I had meant to write about it. So here it is, better late than never.
Now, what did I do at the KDE PIM sprint?
There were two topics I brought to the table:

1. Developing a project vision for KDE PIM in general and/or Kontact in particular
2. Making KMail’s search useful again

In this post I’ll cover the first topic.
A project vision is something that has proven to be useful in product design and development in general, and maybe even more so in Free Software projects. The KDE Human Interface Guidelines define a project vision this way:

A vision describes the goal of the project. It can be emotive and a source of inspiration, for instance by outlining how the final product makes the world a better place. Describe the project’s final goals. Explain who will use the product, and how he or she will take advantage of it. Make sure the vision is shared between all project stakeholders. Leave room in the vision for creativity. Keep it short.

The reason why I (and others) think a project vision is especially useful for FOSS projects is that since the typical FOSS project community is a bunch of quite diverse individuals, each with their own goals and ideas. This is of course one of the great strengths of Free Software, but it also means that, without communicating about those goals and ideas, the members of the community might all march in different directions without even noticing. That is what can lead to what users perceive as a lack of consistency and a lack of common direction.
A project vision can help make the individual ideas and goals explicit, and allow the community to agree on a common goal and direction. That does not mean people are not allowed to add features which are not consistent with the vision, but that the community should think carefully why such a feature should be added anyway. It also helps telling users who keep asking for features which are not consistent with the vision why those features won’t be implemented.
So, I suggested to the KDE PIM community to come up with a vision for their project. Since the KDE PIM project actually produces a whole range of products, the group decided to have specific visions, at least one for the KDE PIM Framework and one for its desktop client Kontact. The time at the sprint was not sufficient for a draft vision for Kontact, but for the framework, we now have a vision draft:

The KDE PIM Framework allows to easily create personal information management applications ranging from personal to large enterprise use, for any target device and major platform.
It seamlessly integrates data from multiple sources, while aiming to be rock-solid and lightning-fast.
The PIM framework focuses on supporting open groupware servers like Kolab, but can be extended to access information from various sources.

Now there are some very important points in there. First is a commitment to broad applicability (it’s a framework, after all!) across usecases and target platforms, as well as a commitment to speed and stability. If the community at large (i.e. also those whop were not present at the sprint) agrees on this vision, this means, for example, that if someone wants to use the framework to create an enterprise application but finds that it currently lacks for example scalability to do so, the team cannot say “But it was never meant for enterprise use!”.
The second part is a commitment to the current driving forces between the PIM Framework: It makes clear that Kolab and similar open groupware servers are what the team cares about most, without excluding other backends. In practice, that means that if someone for example wants the framework to support Microsoft Exchange, the team can say “Please refer to our vision: Exchange is not our focus. So, if you want to integrate support for it in the KDE PIM Framework, you will have to find someone to do it. We’re open to it, but we have other priorities.”
Now as a next step, this vision draft will have to be presented to the whole KDE PIM community, perhaps iterated upon, and finally agreed upon and published officially.
In the same vein, a vision for Kontact should be created. Some input for this formulated by Aaron Seigo:

A high-quality, featureful, scalable, multi-platform groupware suite that provides unified access to groupware data from multiple sources with a focus on full-featured groupware servers.

Now I’d like to see the idea of creating project visions spread to other projects (for example Krita already has one, KDE Telepathy also has a draft which awaits publishing, and the KDE Visual Design Group has committed to creating a vision as a first step when designing or fundamentally redesigning applications). If your project would like to create a vision, feel free to ask any VDG member of your choice or start a thread on the VDG forum.
So, what’s your take on this? Do you think a project vision can be helpful? What do you think about the proposed vision of the KDE PIM Frameworks? Let’s hear your opinion in the comments!

 project vision