Thomas.tex

\chapterwithauthor{Thomas Pfeiffer}{Defining a Vision and Mission for KDE}

\authorbio{Thomas Pfeiffer is mainly responsible for usability matters within KDE's Visual Design Group, where he works to keep developers, designers and his fellow usability professionals focused on our common goal: Creating the best possible experience for our users! Recently, he has taken up an additional focus: Trying to move KDE forward as a community, both in terms of helping us find a direction and in terms of communicating with the outside world.}

\noindent{}In spring 2015, Lydia Pintscher started the initiative ``Evolving KDE'' with the goal of ``helping KDE and KDE e.V. get a better understanding of where we are, where we want to go and how we want to get there''. One of the central actions of this initiative was to run a survey asking members of the KDE Community why they are a part of it, what they want to achieve and what they think is currently missing.

One important result of that survey was that many in the community felt a lack of a common Vision driving KDE forward. To fix that, a group of people formed during Akademy to write a Vision draft for KDE. The team collected a lot of ideas and went through several iterations of a Vision draft. However, around the end of the year, the process was stuck. The team was unsure about the scope the Vision should have (should they immediately go for a Vision for all of KDE or start with one for the KDE e.V. first?) and whether the whole community could ever agree on a single Vision in the first place.

Andrew Lake, who had supported the team with his experience in Vision creation, had just started a new, very demanding job and could not find the time to drive the project forward anymore. Since I was still convinced that a Vision was crucial for KDE, I took over that support role. Discussions with the team showed that at first, we had to decide whether we want a Vision or a Mission for KDE. In the end, we decided that we needed both: A Vision to define what we want the future to be like, and a Mission to determine how we want to get there.

With that settled, we agreed on a first draft for a Vision and opened the discussion with the rest of the community. Pretty quickly, two groups formed within those joining the discussion: One group (which included the original drafting group) wanted the Vision to focus more on overarching goals like freedom and privacy for software users. The other group wanted the Vision to focus more on practical aspects like client software written in Qt, and created a counter-proposal to our Vision draft.

After long and heated debates and more and more tension building up between the two groups, we came to a realization: The world we wanted to live in was actually the same, what we disagreed on was just how to get there. With that realization, we decided that we should postpone the debate about the means for the moment, and first express our shared goals.

From this point on, it all went much easier, and after a few more iterations, the discussion converged onto a Vision which everyone who participated in the discussion agreed with: What KDE wants is
\begin{quote}
 A world in which everyone has control over their digital life and enjoys freedom and privacy.
\end{quote}
Glad that we had put our differences behind us for the moment, we published our Vision. The article with which we published it already hinted at the next step that we'd need to take: Writing a Mission statement describing how we want to work towards our Vision.

The Vision as such was received very positively, but since it is - purposefully - vague, people were eager to know what it means in practice. To answer that question, we set out to create a Mission statement. Since we had merely postponed discussing the differences in the community regarding the ``how'' to the Mission discussion, I had feared that these differences would now bubble up again. To my surprise, this did not really happen. It turned out that once we had agreed on the ``what'', when it came to the ``how'', the differences were not as big as we expected. We agreed on many aspects of our Mission, yet there were many important details where we disagreed. The problem was that far fewer people participated in the Mission discussion than in the Vision discussion during its most active phase.

In the end, the differences often boiled down to ``your opinion against mine''. Since individual opinions can hardly be a good basis for a Mission which guides a whole community, I wanted to give everyone in the community a chance to voice their opinion on the points we already agreed on, and especially on the ones which were still debated, so I did what more then a decade of research training and experience had taught me: I set up an online survey. Since the Mission has to come from the community, of course that was the main target population for the survey. I also opened the survey to the outside world (capturing for each participant whether they are users of KDE software or active contributors to KDE), however, so that we can also see whether the community's priorities align with our users'.

Now we have 200 responses from (current or former) contributors, and almost 1200 responses from users, so we have a pretty good picture of what is important to both the contributors and interested users.

When the results are analyzed, they will feed back into our Mission statement which we want to have published well before QtCon in the beginning of September.

In the meantime, it delights me to see that the Vision is already used in practice: KDE contributors as well as users have used it on various occasions to remind us of the values that KDE stands for, which is exactly the purpose of a Vision. Especially the aspects of control and privacy seem to be of most importance to those who quote the Vision. 

One way we aim to give users control is through our design mantra ``Simple by default, powerful when needed'': In order to make users feel in control of an application or a desktop environment, it has to be simple on the surface to not overwhelm them, but it has to provide them with the necessary features and configurability to still keep them in control even in more complex tasks. This is why, when people (users or contributors) use the Vision to justify an advanced feature or configuration option in a piece of KDE software, we as designers have to make sure that this is possible without any negative impact on the simplicity of the default experience.

The privacy aspect is equally important: Even though Free Software is generally more trusted to respect its users' privacy than proprietary software, it does not guarantee that automatically. Often data needs to be sent over the internet for a software to function, and sometimes we want to collect some data to for example know how many users we have. Our Vision does not forbid us to send or collect data, but it reminds us that we must always make sure that we do so only when necessary and only with the user's consent. I remember two examples of where the Vision was used to remind us of privacy as a goal: One was when a user noted that KMail was writing more information than necessary into email headers, for example the User-Agent header containing the version number of KMail and KDE Frameworks used, as well as the full uname string, which for most Linux distributions reveals both the kernel version and distribution used. Although putting such information in the User-Agent header is not uncommon among email clients, it would indeed be in line with our Vision if our client did not reveal any unnecessary information about the user's system. The other occasion when the Vision was used as an argument was in a discussion about KDE neon wanting to send the machine ID to our servers during software updates in order to allow them to count the number of active neon installations. This was discussed quite extensively, because while everyone agreed that it makes sense to count the number of active installations, it would theoretically allow us to connect the information that someone is using neon with other information connected with the same machine ID. In the end, what we agreed on as a minimum standard was clearly informing users about this data collection before they download a neon ISO, along with explaining to them how to disable such collection. The neon team plans to explicitly ask users to allow this data collection during the installation process in the future.

These very practical examples show that our Vision is not just empty words, but can already guide us in very fundamental questions. Even though the road to the Vision was rocky, this shows that the result was worth the effort!