Authors Albert Vaca Aleix Pol i Gonz`alez Andreas Cord-Landwehr Antonio Larrosa Aracele Torres Baltasar Ortega Ben Cooksley Bhushan Shah Boudhayan Gupta Cornelius Schumacher Dani Guti ́errez Porset David Faure David Narv ́aez Franklin Weng Frederik Gladhorn Jens Reuterberg K ́evin Ottens Lydia Pintscher Mario Fux Martin Gr ̈aßlin Matthias Ettrich Mirko Boehm Nuno Pinheiro Pradeepto Bhattacharya Riccardo Iaconelli Richard J. Moore Sandro Andrade Sanjiban Bairagya Scarlett Clark Sebastian K ̈ugler Sinny Kumari Sune Vuorela Thomas Pfeiffer Tim- oth ́ee Giet Valorie Zimmerman Vishesh Handa Volker Krause Yash Shah
License CC-BY-SA-3.0
20 Years of KDE
Past, Present and Future
Editor: Lydia Pintscher
20 Years of KDE
Lydia Pintscher (Editor)
20 Years of KDE
Past, Present and Future
The information in this book is distributed on an “As Is” basis,
without warranty. While every precaution has been taken in the
preparation of this work, neither the authors nor the editor or pub-
lishers shall have any liability to any person or entity with respect
to any loss or damage caused or alleged to be caused directly or
indirectly by the information contained in it.
Copyright © 2016 Sandro Andrade, Sanjiban Bairagya, Pradeepto
Bhattacharya, Mirko Boehm, Scarlett Clark, Ben Cooksley, Andreas
Cord-Landwehr, Matthias Ettrich, David Faure, Mario Fux, Tim-
othée Giet, Frederik Gladhorn, Martin Gräßlin, Boudhayan Gupta,
Dani Gutiérrez Porset, Vishesh Handa, Riccardo Iaconelli, Volker
Krause, Sebastian Kügler, Sinny Kumari, Antonio Larrosa, Richard
J. Moore, David Narváez, Baltasar Ortega, Kévin Ottens, Thomas
Pfeiffer, Nuno Pinheiro, Lydia Pintscher, Aleix Pol i Gonzàlez, Jens
Reuterberg, Cornelius Schumacher, Bhushan Shah, Yash Shah, Aracele
Torres, Albert Vaca, Sune Vuorela, Franklin Weng, Valorie Zimmer-
man
This work is licensed under a Creative Commons Attribution-
ShareAlike 3.0 License. To view a copy of this license visit:
http://creativecommons.org/licenses/by-sa/3.0/legalcode.
ISBN: 978-1-365-35997-2
for gearheads
all around the world
Our vision:
A world in which everyone has control
over their digital life and enjoys freedom
and privacy.
ix
Thank You!
This book would not have been possible without the support of each
of the authors and the following people, who helped make it happen:
• Alejandro Daniel Wainzinger Mateu
• Aleix Pol i Gonzàlez
• Celeste Lyn Paul
• Frederik Gladhorn
• Valorie Zimmerman
• Volker Krause
• Will Stephenson
Contents
1 KDE Ceased to Be Software and Has Became a Culture 1
2 Serving the End User – a Brief Reflection on KDE’s
History 5
3 The Values Within 11
4 Continuity through Change 17
5 Did You Know? 21
6 KDE e.V. - the Backbone of the KDE Community 25
7 KDE and Qt 31
8 German Association Law as Secret Superpower 37
9 Who Does the Work Decides 43
10 Meet the Gearheads 47
11 Deals with the Devil 51
12 Defining a Vision and Mission for KDE 59
13 On Subtle Contributions 65
14 The Importance of Face-To-Face Meetings 69
15 Remote Places Make Magic Possible 73
16 KDE in Taiwan 77
xii Contents
17 Building KDE’s Community in India 81
18 A Revolution in Itself 85
19 Think Globally, Act Locally 89
20 A User at the Court of KDE Developers 91
21 Why I Chose KDE, and Why KDE Is Family 95
22 Story of a Contributor 99
23 The Motivation behind Contributing to KDE 103
24 My Journey from Documentation to Continuous Inte-
gration 107
25 A Place to Stay Forever 109
26 A Learning Paradise 113
27 The Circle of Four Steps to Become a Good Developer 117
28 How We Make Plasma 121
29 Evolution of Windowing Systems 129
30 Twenty Years of Email 133
31 Krita Animation 141
32 The Transient Nature of Design 143
33 Say Yes 149
34 Future Journeys: Which Path to Take? 155
Contents xiii
35 Staying Relevant 157
36 Software, Freedom and Beyond 161
37 A New Generation 165
1 KDE Ceased to Be Software and Has
Became a Culture
Aracele Torres
Aracele Torres fell in love with KDE technologies in 2007 and in
2010 decided that she should start to contribute to the community.
Since then she has made contributions in many areas, such as trans-
lation, promotion, artwork, and community management. She trav-
els through Brazil, giving talks about KDE and organizing activities
to promote the community. Additionally she participates in the orga-
nization of KDE’s Latin-America Summit LaKademy since its first
edition. She is a doctoral student in the History of Science and Tech-
nology, conducting research on the history of digital technology, free
software, the internet and related things.
KDE as a software project was born in 1996 when German pro-
grammer Matthias Ettrich realized that Unix-based systems were
growing, but their interfaces were not user-friendly enough for the
end user. It was only three years after the first GNU/Linux distri-
butions had begun to appear and Matthias noticed the absence of a
graphical user interface that offered a complete environment for the
end user to perform their daily tasks. He thought that for the people
who began to consider GNU/Linux as an alternative to proprietary
systems, a beautiful and easy to use graphical environment would
help a lot. Thus was born the project “Kool Desktop Environment”
or simply “KDE”. The name was a pun on the proprietary graphi-
cal environment very popular at the time, CDE (Common Desktop
Environment) that also ran on Unix systems.
One year after Matthias Ettrich’s announcement inviting devel-
opers to join the project, the first beta of KDE was released. Nine
months later came the first stable release. The dream of Matthias
2 KDE Ceased to Be Software and Has Became a Culture
and his community of contributors was becoming reality and occu-
pying an important place in the history of free software. The pro-
ject was maturing and becoming more complex and more complete.
Thanks to the collaboration of people worldwide, KDE had grown
from version 1 to 2 in 2000, and then to 3 in 2002. In 2008, after
very important changes, the community launched the revolutionary
version 4. In 2014, the equally innovative version 5 came out that
showed in its visual design, framework, and applications that the
community is ready for the future.
During this time, a lot had changed in the KDE Community and its
technologies. First came the change of KDE’s name and its identity.
In 2008, the community began to refer to “KDE” as not just a soft-
ware project, but as a global community. This identity change was
made official in 2009 when the community announced this rebrand-
ing. The name “K Desktop Environment” was dropped because it
no longer represented what KDE had become. This long name had
become obsolete and ambiguous, since it represented a desktop that
the community has developed. KDE at that point had become more
than just a desktop, evolving into something greater: KDE was no
longer the software created by people, but the people who create soft-
ware.
Outside observers of the KDE Community may not have noticed,
but this rebranding was a turning point in the history of KDE.
Through it, the community makes clear its ability to perceive and
keep up with the state of the art of computing. The reign of desktops
was over and it made no sense to limit KDE to traditional platforms.
Therefore, the decision to use only the name “KDE” intended to com-
municate to users that the community was attentive to the future.
“KDE” would not only be synonymous with a limited set of software
components, but be synonymous with the international community
that produces free technologies for the end user, whether for desktop
or mobile devices or other technologies that are yet to come.
In 2012, this rebranding effort was summarized in a manifesto. The
“KDE Manifesto” listed core values advocated by the community and
it served as an open call: New projects are now welcome under the
Aracele Torres 3
KDE umbrella brand. This led to the creation of the KDE Incubator
in 2014. The KDE Incubator serves as an integration point for new
free software projects that join the community to have the same
benefits as the existing KDE projects. This incubator has become
home to a variety of projects, from a wiki dedicated to educational
topics to a full-fledged Linux distribution.
KDE continues the same trend it has followed the past 20 years,
which is inclusive growth. Its founding principle was based on pro-
viding users a better desktop experience. It has expanded that view
to also offer the best experience on mobile devices. The future is ripe
with possibilities for a new generation of devices: cars, smart TVs,
refrigerators, stoves, etc. Can you imagine a smart home or even an
entire city using the technologies of the KDE Community?
For almost 10 years I have used the technologies that the KDE
Community produces. I remember starting with KDE 3.5 when I
still did not even know about the social importance of free software.
As a user, as a contributor, and as a historian, when I look back
at these 20 years of history, the feeling is the same. The KDE pro-
ject was born from the interest of a group of people who wanted to
make computing, especially free and open computing, accessible to
all. The 1990s was a time when the GNU/Linux systems became
popular and the internet and the web was becoming more present in
people’s lives. KDE emerged as an important tool in the populariza-
tion of free software. Born with the intent to be an interface between
a person and the computer, today KDE is an interface between peo-
ple. KDE unites and connects people through free computing. KDE
has become a community that encourages the growth of people and
projects, that seeks innovation, and defends the free sharing of in-
formation. KDE has move beyond simply being computer software
and has evolved to become a culture.
2 Serving the End User – a Brief Reflection
on KDE’s History
Matthias Ettrich
Matthias Ettrich is a computer scientist living in Berlin and the ini-
tiator of KDE. Since then he has been running different software
development teams at Trolltech and Nokia. He co-invented Qt Cre-
ator and QML, and co-developed several smart phone platforms which
were all terminated by either Nokia or Microsoft shortly before or af-
ter launch – Nokia X being the latest one. He currently works as
distinguished architect at HERE. Matthias is married with children
and recently took up playing jazz trumpet again.
Like any other complex project, KDE was created twice. At first as
an idea, and secondly as an implementation of the idea in the real
world. Looking back, it was astounding how quickly the idea gained
legs – and hands – and started to develop its own life. It obviously
showed that the timing was right and that many of us thought alike
20 years ago. My Usenet posting would serve as a catalyst which
allowed a growing group of people to connect and get started. Yet,
this doesn’t explain it all. There is still something magic behind
what happened in 1996.
Let me explain what I mean.
First, the concept of a complete and friendly user interface for
GNU/Linux, where complete means including almost all relevant ap-
plications, was crazily bold. If you had suggested building something
like this in a commercial company, you would hardly have made the
second preparation gate in the product process. Someone would have
given you the look and the obvious question: “Are you nuts? Do you
have any idea how much effort that is? How many developers you
would need, and how much time?”
6 Serving the End User – a Brief Reflection on KDE’s History
I wasn’t totally naı̈ve back then. Thanks to LyX I knew that my es-
timation skills for software complexity and required time were overly
optimistic. Therefore, I consciously tried to downplay the effort and
in hindsight probably the one major thing I got right, provided a
thought-out, detailed roadmap proposal leading to a minimum vi-
able product. When eating an elephant, take one bite at a time. My
plan looked reasonable enough to make success appear plausible if
enough developers joined. And so you did and created KDE.
They say that if you want to make people build ships, don’t teach
them building ships but teach them longing for the sea. That I didn’t
have to do. Many of us already had a promotional side and truly
wanted to make GNU/Linux accessible to the non-geeky rest. Why?
Simply because GNU/Linux was objectively the better system, and
there was a strong belief that it should be possible to convert the
technical advantages of a UNIX system into real added value for
users. “End-users” as we called them back then, to differentiate
them from those in the know.
So initially, KDE was about better software for non-technical
users, with GNU/Linux at its heart. Therefore, KDE software was
not supposed to run on Microsoft Windows, not even as a tactical
step. I didn’t want any compromises in software quality, but use the
alleged power of UNIX to the maximum advantage possible. The
idea was not to catch up with Windows, but eventually surpass it.
The plan wasn’t crazy, only early. In the end, two commercial
companies succeeded with the very same plan in ways which nobody
could have imagined 20 years ago: Apple with the Darwin-based
Mac OS X, which draws from many open source projects also in
higher layers of their software stack. And of course Google, which
today dominates the smartphone and tablet space with its Android
operation system.
Looking back, KDE has achieved great things also on the technical
level. I am sure everyone has their own personal list, but here are
my top-three technical achievements: (1) XDND, (2) DCOP/D-Bus,
and (3) KHTML/Webkit.
Matthias Ettrich 7
1. XDND is a drag and drop protocol conceived in 1998 by John
Lindal, with help from Trolltech, GTK+, and Red Hat. While
it wasn’t strictly speaking a technical achievement of KDE, the
combined critical mass of KDE and GNOME was instrumental
in establishing a de-facto standard on the X Window System.
It seems unbelievable today, but before KDE there was not
even an agreed way to implement such basic visual operations
on GNU/Linux. To be honest, before KDE there was such a
lack of visual applications that there hardly was any need to
drag and drop documents either.
2. DCOP, which later turned into D-Bus, highlighted the impor-
tance of IPC for building a complex modern system. The
GNOME project saw the same need, but was initially stuck
in following a Microsoft-style COM approach using CORBA
techniques. Android later went further by adding IPC to the
kernel, called Binder, and using higher level constructs in Java
for transparent IPC (the intents and content providers).
3. KHTML, which later became Webkit, is probably the most in-
fluential code base that came out of the KDE project. It played
an important role in the rise of Mac OS X and the iPhone.
Where would Safari have been without a competitive HTML
engine? And where would Mac OS X and the iPhone have been
without the competitive web browser Safari had become?
The one chapter in KDE’s history which I do not like to remember
is the one about the infamous Trolls vs. Gnomes fights. What can
we learn from this? First the obvious standard lesson: the more
similarities two communities have, the more intense they fight. I do
remember discussions with fellow Trolls where we spoke about the
odd sequence of events which brought us here, and how we could
have easily ended up on the other side, hacking our fingers off in an
attempt to make GTK and GNOME more attractive. In hindsight
all of that struggle was completely pointless and didn’t serve the free
software revolution well.
8 Serving the End User – a Brief Reflection on KDE’s History
Talking about revolutions, let’s quickly remind us how the French
revolution killed the king, and after a period of terror it crowned
an emperor. Is this a pattern? The free software revolution broke
Microsoft’s dominant position in operating system software, fought
rigorously against each other, and in the end crowned Apple and
Google, who both were very smart in using free and open source
software to their own advantages. In all fairness, the analogy is flawed
like any other analogy: Microsoft certainly wasn’t decapitated, but
today is no longer seen as potential threat to software freedom, but
simply as one highly successful software company among others –
one that actively contributes to free software.
Where are we now on the client side? Users have access to an in-
credible amount of high quality software today, mostly free of charge,
and a lot still available in source code. The horror years of DOS
and Windows 3.1 or Windows 95/98 are definitely over. Today ev-
ery kid or grandmother does things with their smartphones which
only hackers could do 20 years ago: email, chat, listening to music,
browsing the web; and all with multitasking, and without rebooting
the machine several times per day. They also participate in virtual
communities, something open source projects pioneered due to the
technical skills required to do so. In addition, voice over IP, taking
and sharing high quality pictures, and detailed searchable maps of
the entire globe are standard use cases today. A standard 9 year old
today does more geeky things than a hacker when we started – and
doesn’t even notice. Try to picture in your head what actually hap-
pens when you tell your phone that you would want to walk to the
next bakery, and the phone guides you there. Such a simple use case
will utilize voice recognition, satellite positioning, a massive graph
of places trained by zillions of search requests, and a location graph
knowing exactly how to get you there, and of course mobile connec-
tivity as most of the interesting computations are not done on the
actual device but inside services operated in big data centers. Isn’t
that mind boggling? Isn’t it amazing how much technical complexity
can be hidden behind user interfaces every child can operate at ease?
Matthias Ettrich 9
But also the developers are in a very different position today.
There is a plethora of great development tools available from com-
pilers to middleware to IDEs and a significant portion of these run
cross platform on Windows, Mac OS, and GNU/Linux.
GNU/Linux is an established platform today, not only in data
centers, but also on developers’ desktops. And KDE continues to
play a big role in enabling this. It plays an even bigger role in
demonstrating that the allegedly naı̈ve dream of an entirely free and
purely community-driven, open stack is indeed possible. And best
of all: No animals were harmed and no investor money was burned
in achieving this. That’s no small thing to be proud of.
Congratulations KDE, on your first 20 years. I will still be around
and curious to learn about the next 20 years.
3 The Values Within
Antonio Larrosa
Antonio Larrosa is a mathematician from Málaga (Spain) who has
always worked as a software developer. He joined KDE in 1997. He
is the author of the first versions of kmid, kpager and others, main-
tained parts of kdelibs and fixed bugs in nearly all applications when
KDE still used CVS. He organized Akademy 2005 and Akademy-es
2014 in the University of Málaga and gave nearly a hundred talks
about KDE for users and developers all around Spain from 1998 to
2005. Currently he works in the SLE Desktop Team at SUSE. He
was recently elected president of KDE España.
When someone looks at KDE there are many things that can be seen
depending on the point of view and the experience of the observer.
One can look at KDE and see an intuitive desktop environment and
many applications tightly integrated that allow anyone to use the full
power of his/her computer in an easy way. In that sense, someone
can use KDE for years and only see - and benefit from - the software
developed by its developers. From another point of view, if a devel-
oper looks at KDE, he or she might see not only the applications
but the framework that KDE provides. With KDE Frameworks a
developer can quickly write applications that use the full potential
of the desktop and integrate with other applications by maintaining
a homogeneous look and feel across the desktop.
But KDE is much more than that. It’s a community of people
doing Free Software for real users. Let’s analyze what that sentence
means.
12 The Values Within
A community...
It’s a community because there is a link that bonds us together.
There is a purpose in what we do: to create software that liberates
people when using computers1 . There is a strong feeling of commu-
nity in KDE. There are artists, designers, programmers, translators,
users, writers and other contributors from all around the world. Lit-
erally, from all continents (OK, maybe except Antarctica). Thou-
sands of people organized to create free software in a common direc-
tion.
Now I should point out that if you plan to contribute to KDE,
my words might be misunderstood so I want to make clear that
you shouldn’t let that strong feeling of community discourage you.
New contributors are welcomed and indeed will feel welcomed and
part of the community quite quickly. Contributing to KDE is not
only good for KDE, it can help you get in touch with many really
good developers, artists, translators, etc. and by getting you real life
experience, it will help you build a better resume.
... of people ...
I guess there is no need to state that, even if sometimes it looks like
there are, there are no robots and no aliens collaborating at KDE.
They are just people like you and me who at some point in their life
decided to invest part of their time (sometimes work time, sometimes
free time) in making the world a bit better through Free Software.
During these 20 years of KDE’s existence, I’ve met computer sci-
entists who collaborated with KDE, but also all kind of engineers,
designers, linguists, musicians, mathematicians, physicians, teachers,
retired persons and even high school students working at KDE. I re-
member an anecdote with respect to that from many years ago at an
Akademy meeting with a developer still in high school who needed
to use vectors in a game he was developing but he hadn’t studied
1 Although there are projects to expand this to tablets and mobile phones too.
Antonio Larrosa 13
them in class yet. As a mathematician I offered to teach him what
he needed for his game and he learned some math quite ahead of
other people his age.
Since KDE contributors come from very different countries with
different cultural backgrounds and customs, there is a Code of Con-
duct that offers guidance to ensure KDE participants can cooperate
effectively in a positive and inspiring atmosphere.
... doing Free Software ...
Everything developed in KDE is Free Software. It’s stated as such
in the KDE manifesto so it’s clear that freedom is in the core of
our technology. This has many benefits over non-free software. For
example, it’s the only way KDE can assure that the software will be
available for everyone, for all time.
Freedom is a very valuable right that is usually not perceived as
worthy of our attention, until it is lost. And there is a real possibility
to lose it. It is currently at risk when we use computer systems that
can not be analyzed like some televisions which have a microphone
always listening in on your own living room conversations and no one
can check exactly what it does with everything it “hears”. It is at risk
too when someone uses computer software whose license (enforced
via legal or technical methods) does not allow the owner to share
the software with some friend or family member to use in their own
computer. And it is also at risk when you have some software that
does something close to what you need but you can not modify it
(or get someone to modify it) to do exactly what you need.
Those are only three examples, but to solve those problems, among
others, Free Software guarantees 4 types of freedom:
• The freedom to run the program for any purpose.
• The freedom to study how the program works, and change it
to make it do what you wish.
14 The Values Within
• The freedom to redistribute and make copies so you can help
your neighbor.
• The freedom to improve the program, and release your im-
provements (and modified versions in general) to the public, so
that the whole community benefits.
... for real users.
Users are the most important part of KDE. During these years I
have seen people of all types use KDE’s software, from infants to
nearly 90-year-old elders, from users who were using a computer for
the first time to users with many years of experience using all sorts
of computers, from 10,000 PCs in elementary schools in Taiwan to
15,000 PCs in the Munich City Council. All of them use KDE’s
software with usually very positive outcomes.
But sometimes there are problems too. Usually those problems
are not much different to problems that would appear in other desk-
tops/operating systems, but with one main difference. If someone
finds a problem within KDE’s software, the very developers can be
reached at bugs.kde.org where any user can file a bug report with
the problem he or she found or the improvement he or she thought
it would be nice to have in future versions. That way users can par-
ticipate in the improvement of KDE’s software not only for them,
but for everyone else. And yes, developers are not offended when
someone reports a bug in a nice, educated and useful way. On the
contrary, they encourage users to report bugs since they sometimes
only appear under some specific circumstances that developers can’t
always predict or reproduce.
Conclusion
KDE has evolved a lot in 20 years. As you see, the work KDE cur-
rently does is important in many different ways: technically (provid-
ing an innovative state-of-the art desktop, applications and frame-
Antonio Larrosa 15
works), economically (providing free of cost software for everyone to
use, thus giving access to developing countries to the same technology
the rest of the world uses) and philosophically (providing software
that help us maintain our freedom and rights). If you also think this
work is important, don’t hesitate to join us and help us make the
world a bit better, at kde.org.
4 Continuity through Change
Richard J. Moore
Richard Moore joined KDE around 1997, first contributing a little
widget that displayed an LED. Over time that expanded to cover areas
such as scripting engines, task bars, and networking. He is currently
the maintainer of the Qt Network module and CTO at Westpoint
Ltd, an internet security company.
When I first started working on KDE it consisted of a window man-
ager (kwm), a file manager (kfm) and a panel to launch things
(kpanel) - it has grown a little since then! It was very easy at the time
to make a big contribution to the project simply because there was
so much that needed doing. My first application was KPaint, quickly
followed by KSnapshot which I wrote mainly so I could make screen-
shots of KPaint. If you had said to me at the time that KSnapshot
would continue to be developed and released for 18 years I wouldn’t
have believed you.
One of the most surprising things about KDE is how much con-
tinuity there has been in the code, and the impact of some early
decisions. One major feature was Torben Weis’ decision to make
the network download facilities of kfm available as a library to other
applications. This meant that from the start KDE applications had
built-in support for editing files on the internet. This might seem ob-
vious now, when ’The Cloud’ is such a big buzz-word and everyone
has 24/7 internet access but it was pretty revolutionary at the time.
Unlike today, most people weren’t on the internet at all (and had
often never heard of it). Many of the KDE developers had (by the
standards of the time) fast internet access when at university, but at
home we had modem access at best. It is only in the last few years
with the rise of tools such as One Drive, DropBox and OwnCloud
that this kind of facility has become available more widely.
18 Continuity through Change
An area where KDE has had a global impact is in the browser mar-
ket. The original KHTMLW widget was replaced by Lars Knoll with
the new standards driven KHTML library. This was later picked up
by Apple as the basis of WebKit and now forms the basis of the vast
majority of web browsers. I think one of the reasons why KHTML
was such a success was due to the way KDE is developed. The use
of the LGPL license was obviously a factor, but other rendering en-
gines existed with open licenses. Unlike many other projects, KDE
has always had a highly distributed developer base which meant
that it was always seen as important to keep APIs clean and un-
derstandable, and to make it easy for people to work on the code.
The emphasis on clean APIs and clear implementations meant that
KHTML was a lot easier to work with than its competitors.
The distributed nature of KDE’s development had other bene-
fits too. The first KDE conference organised by Kalle Dalheimer in
September 1997 brought together people from all over Europe - it
was a very exciting and productive weekend. As well as being a fan-
tastic opportunity to build a community, the amount of code that
got written (and rewritten) during the conference was astounding.
The KDE internationalisation framework was completed during the
meeting, and by the end of the weekend we had the whole desktop
working in German ready for the press conference! The meeting also
had other highlights such as the first demo of KOffice (written of
course by Torben) including the ability to embed different types of
document - this would eventually become KParts.
If you look at the modern KDE desktop, there is no doubting
that it has evolved from those early days. The level of quality now
is unbelievable compared to the early releases. This applies both to
the code itself via massive improvements in the testing infrastructure,
and much more visibly to the design of the interface itself. A modern
KDE desktop is a thing of beauty - the older KDE releases were
functional but sadly as engineers we had a big blind spot for graphic
design.
KDE as a project has evolved too - most notably it has grown in
both numbers and become even more diverse. The growth of a strong
Richard J. Moore 19
KDE community in India to the point where it is now hosting its own
KDE conferences is particularly noteworthy. KDE has started tak-
ing a more active role in the wider Free Software and Free Culture
community for example as an associate organisation of FSFE and
through collaboration with groups such as Wikimedia. The contin-
ued evolution of the project and community has helped ensure KDE
remains relevant despite the ever changing environment it inhabits.
One thing has been constant though throughout my time working
with KDE and that has been the people. While the individuals
working on the project change over time, the attitude remains the
same. The people are intelligent, curious and eager to experiment. I
look forward to seeing what they come up with - I’m sure it will be
awesome.
5 Did You Know?
David Faure
David Faure joined KDE in 1998, initially for a dialog box for a
‘talk‘ daemon, then contributing to many different parts of the soft-
ware: file manager, web browser, office suite, email client, core tech-
nologies, Qt, and anything else where a bug prevents him from being
productive. He works as a software engineer, consultant and trainer
at KDAB.
As one of the members of the community who has been active for the
longest time, I sometimes see it as my role to transmit the memories
and knowledge of the early days to the more recent generation of
KDE contributors.
Did you know, that “KDE” initially stood for “Kool Desktop En-
vironment”, but the K quickly lost its meaning, because Kool wasn’t
so cool after all? One of the very early contributors, Kalle Dalheimer,
sometimes joked that it meant the “Kalle Dalheimer Environment”,
of course :-)
Did you know, that choosing Qt as the base technology was just
to get started, with the idea that it was really just the GUI bits,
and that it would always be an option to switch to another toolkit
at some point? Yeah right :)
Did you know, that the very beginning was a window manager
(kwm), a panel (kpanel), and the first library classes where KConfig
(whose format was inspired by win.ini) and KApplication, as a place
where to instantiate the KConfig class? It took us 16 years to get rid
of KApplication again (to give KDE Frameworks 5 a more modular
design).
Then comes in my hero: Torben Weis. His creativity was amazing.
He was not afraid to start huge projects, with excellent architecture
22 Did You Know?
and design skills. He started with the file manager kfm, which be-
came Konqueror and also gave birth to KIO. Then he thought “how
about I start an office suite?”. This is where I came in, to take over
maintainership of kfm while he would go and start KOffice (known
today as Calligra). He was also a very fast coder, so people assumed
he had clones of himself helping him. An old joke in the community is
“Torben broke the cloning machine”, which explains why we weren’t
able to benefit from the same trick ourselves. He unfortunately left
the project long ago (my interpretation is that he was more into ini-
tial designs than long-term maintenance), but his influence on what
KDE is today is still very important, and not just because ‘kioclient5‘
shows file:/home/weis/data/test.html in an example :-)
What did we use before git? Subversion. And before that? CVS.
And before that? Just an FTP server where people would upload
their sources! When I joined CVS was already being used. Oh the
memories of that archaic version control system...
• Even ‘cvs diff file.cpp‘ requires a connection to the server, not
convenient in an era of 56k modems (I couldn’t be connected
all day at home, only at university).
• You want to rename a file? You need to ask Coolo (which is
Stephan Kulow’s nickname).
• On the other hand you could check out a single file from a
branch, we lost that feature. OK, I wouldn’t say I miss it :)
• Talking about branches, how do you call your feature branch
where you rework e.g. KIO’s architecture? “make it cool” was
a very often used branch name. There was definitely something
about the word “cool” in those days...
You might have heard that we used CORBA at some point in the
past (for component embedding using inter-process communication).
Did you know that there were no stable releases with it, only KDE
2.0 alphas and betas? One of them was even codenamed Krash.
This experiment (with a CORBA implementation called Mico) didn’t
David Faure 23
prove successful (the worst part that I remember was that we ended
up duplicating all of the menu and toolbar APIs as remote procedure
calls) so we had to find a replacement, see below.
Did you know, that we had developer meetings before they were
called Akademy? I recently saw a discussion where someone said
“DCOP was invented at Akademy long ago”. This is not exactly
right. Before Akademy (which is not just a name, it also means a
conference with presentations the first days) we had developer meet-
ings (nowadays known as sprints). And indeed DCOP was invented
at one of these. The story is that Matthias Ettrich and Preston
Brown got drunk and declared that they would write a CORBA
replacement in one night. The result is DCOP (later on replaced
with D-Bus, for interoperability with other freedesktop projects, but
I’m pretty sure that D-Bus took inspiration from DCOP, so it’s an
evolution).
Did you know that Trysil was a ski station in Norway? More
interestingly it was the location for two KDE developer meetings,
the first one just after the switch from CORBA to DCOP. The daily
cycle at that event was interesting... Summer in northern Norway
means that the sun never really goes down. At 4am the sun becomes
slightly less visible for half an hour, and when it comes back up again
we would then realize, OK, it’s time to go to bed. We’d sleep until
noon, have a copious breakfast (well, brunch), hack until dinner, then
hack again until 4:30am. Unusual but effective - we got lots done.
The hungry mosquitoes are another story though...
Torben joked that he was a bit ashamed of the bad design deci-
sion to go with CORBA (and out-of-process component embedding
in general), so his next project, with in-process components (which
became KParts) was initially called Canossa. Did you know that
Canossa is a village in Italy? OK but what’s the relation? In Jan-
uary 1077 the Holy Roman emperor Henry IV did penance at the
castle in Canossa to obtain a pardon from his excommunication by
Pope Gregory VII. We quickly switched to the KParts name though
:)
24 Did You Know?
The second Trysil meeting, much later (in 2006, before KDE 4.0),
is also a source of very good memories. The contributors coming
from America had a bit of a jet lag, so George Staikos was sleeping,
sitting on his chair, while his code was compiling, then waking up
again to keep hacking/testing. And while Celeste was sleeping on
the sofa, other people put a “do not disturb” sign on a sticky note
on her head. Meanwhile Coolo was drawing German flags on the
forehead and cheeks of anyone who wouldn’t run fast enough, due to
the Euro Football Championship happening at that time.
All of this, and much more, constitutes the history and culture
of our community, and I’m happy to have this opportunity to keep
passing it along to more recent contributors. The creativity and
enthusiasm of the early contributors is still something we can draw
inspiration from today.
6 KDE e.V. - the Backbone of the KDE
Community
Mirko Boehm
Mirko Boehm became a KDE contributor in 1997, where he worked
on libraries and applications. He was elected a board member of
KDE e.V. in 1999, and served in all board capacities from treasurer
to president until 2006. He is the author of ThreadWeaver, the con-
currency scheduler framework in KDE Frameworks 5. Until 2016,
he contributed to KDE as a coder, an auditor and member of the
financial working group. Mirko Boehm is a director at the Open In-
vention Network and the CEO of Endocode. He teaches open source
economics at the Technical University of Berlin. Mirko lives with his
wife and two kids in Berlin.
In 1996, I was a university student who learned programming in
C++ using an incredibly expensive Unix work station. GNU/Linux
was the obvious path to program on a similar system after school.
However, it was the time of FVWM - a graphical user environment
that mainly consisted of a rudimentary window manager with little
visual charm and no usability. Using GNU/Linux felt like flying a
jet plane, it was very powerful to the initiated, as long as a the user
knew what all the knobs and buttons did and all the secret tricks to
keep it going. When I learned about KDE, a free software project to
build a user-friendly and powerful graphical desktop, I was hooked. I
started coding on KDE, learned to love C++ and Qt and grew to be
a part of the community. My motivation was mainly to contribute
code. There where about two dozen KDE developers at the time,
and the community grew quickly. In 1998 I went to LinuxTag in
Kaiserslautern. I met many of the other contributors for the first
time there. We camped in Kaiserslautern university lecture halls,
26 KDE e.V. - the Backbone of the KDE Community
in sleeping bags on the floor. We talked about visual features and
interaction paradigms, performance, communication protocols and
software freedom. When I was asked if I wanted to be a member
of KDE e.V., I was a bit surprised. Why would a free software
community need a registered organization to represent itself?
KDE e.V. is a charitable organization that represents KDE in legal
and financial matters. As a legal entity, it is able to accept donations
on behalf on the community, and to own the trademarks on the KDE
name and logo. I was convinced and I joined. The “e.V.” in KDE
e.V. stands for “eingetragener Verein”, or registered association, in
German. This concept exists in Germany in this form since the year
1900. Essentially, it is modeled after a shareholder company where
each member (shareholder) holds the exact same amount of shares.
Choosing this legal structure implies an important trait of the KDE
Community - it is driven by individual contributors, and those con-
tributors are considered equals among peers. If the organization owns
assets like a trademark, this asset is effectively jointly owned by the
members of the organization. The concept of “eingetragener Verein”
implements the ideals of volunteer driven free software communities
very well, even though it was contrived long before software was a
thing.
In 1999 I was elected to the KDE e.V. board of directors. There
where two main tasks - to attain charitable status for KDE e.V., and
to rewrite the bylaws so that they are supportive of the large free
software community KDE evolved into.
Charitable status for KDE e.V. was not yet granted. Being a
charitable organization in Germany is not the same as being a not-
for-profit. The organization has to pursue a charitable goal. To a
casual observer, it seems obvious that facilitating the development of
free software contributes to the common good. Not so for the German
financial authorities, who fail to find this aim in the finite list of
potentially charitable activities, which does include the advancement
of marriage and family or of religion. KDE e.V. finally managed to
be granted charitable status, if only through twisting its purpose
to fit into the predefined schemes. Once that was achieved, KDE
Mirko Boehm 27
e.V.’s formal structure – a charitable organization with the goal to
advance free software and that considered all its members as equals
– fits the ideals of a volunteer-based free software community like a
glove. It seems like the German legislators would be well-advised to
add the advancement of free software to the list of blessed charitable
activities.
Re-writing the bylaws proved to be a challenge, because it meant to
lay the foundations of governance of the KDE Community as it con-
tinued to grow and began to show signs of needing formal structure.
To represent the community that understands itself as made up of
individual volunteers to the product KDE, the rule that only natural
persons could be “active” members (members with a vote) in the or-
ganization was kept. To protect the self-determined administration
of the community, a rule was adopted that to become a member, a
contributor had to be invited by an existing member and endorsed
by two more. Considering that every member became a co-owner of
all KDE-related assets, such protection was necessary. Directed at
preventing hostile takeovers of the organization (the community was
still not very big in numbers), this invite-only rule later contributed
to the image of KDE e.V. as an exclusive club. Organizations could
become “supporting members” if it was in their interest to advance
KDE, however this form of membership did not grant them a vote.
Companies that became a part of the community gained a say
indirectly by having employees that worked on KDE invited to be
members. This was an intended effect that preserved the focus on
the individual contributor while still involving organizations. Under-
lying that was an implicit understanding that the KDE Community
should be innovative and directed by the interests and motivation of
the contributors, as opposed to commercial interests regarding, for
example, the stability and maintenance of existing products. On one
hand, this enabled the KDE Community to drastically innovate over
multiple generations of its desktop. On the other hand, the rule shut
out commercial contributions into the stability and maintenance of
existing product versions. As a result, KDE became a beautifully
designed and technologically very advanced desktop that sometimes
28 KDE e.V. - the Backbone of the KDE Community
crashed. The focus on individual contributions is based on the idea
that self-identification, choosing what to work on based on individual
skills and motivations, is the best approach for a software commu-
nity to stay ahead of the curve. It has served KDE well and became
the yardstick for community management when free software finally
became mainstream in about 2010.
Similarly important to what an organization is supposed to do is
what it is not supposed to do. KDE e.V. is not supposed to steer
or influence the technical direction of the development of KDE. Its
purpose is to be a support organization for the community. In a
community that primarily produces software, it is however hard for
anyone who participates not to influence technical direction. In the
case of KDE e.V., it organizes the annual KDE conference, and fi-
nances sprints and other activities. The choice of which development
sprints to sponsor or where to be present at a conference does put
the spotlight on specific technologies and may influence technical
direction.
An important goal of the new bylaws was to account for the regu-
lar fluctuation of contributors and to retain the experience of those
who for personal or other reasons stopped contributing. The new by-
laws introduced the concept of “extraordinary members”, individuals
that are still members of the organization, but waived their voting
rights. It is a way of appreciating their past contributions and offer-
ing the opportunity to be part of debates and conversations, while
concentrating voting rights in the hands of those that are actively
participating.
These “design principles” served KDE e.V. well. It grew to 150
members and more, and was able to regularly collect enough do-
nations to open a permanent office and hire an administrator. It
regularly hosts the annual Akademy conferences and runs the hard-
ware and software of the KDE Community. It holds trademarks and
represented the community in legal matters. It has become an ex-
ample for how a free software community can handle its affairs in a
self-determined way. Today, KDE e.V. is a large organization with
multiple working groups and stable, established processes.
Mirko Boehm 29
Minor modifications aside, the current setup of KDE e.V. is more
or less unchanged since 2003. Over time, some areas have surfaced
where reform may be necessary, or is already underway. Many of the
discussions between the members have been conducted on the KDE
e.V. membership mailing list, which is not open to the public or all
contributors. Having such a private list was deemed necessary, but
it excluded some contributors from taking part in these discussions.
After heated debates at Akademy 2012, a public community mailing
list has been created. The norm is now that all debates should be
held there unless they require discretion. By preferring lazy consen-
sus and prolonged debate, controversial decisions are hard to make,
leading to a practice of bike-shedding. Even though an online voting
mechanism has been implemented, it was rarely ever used to ensure
that debates could be concluded eventually, and with a productive
outcome. This gave vocal minorities or even individuals a de-facto
veto and inhibited the implementation of majority opinions. A de-
cision making culture based on consensus works wonderfully well for
small groups, but stifles large organizations. Since KDE e.V. does
not provide technical leadership to the community, the board and
the organization are limited in what they can achieve or in provid-
ing direction. A balance needs to be found between maintaining the
freedom of the community to innovate, and the ability to coordinate
activities within a large group. And finally, there is a lag between
changes in the composition of the overall community and the time
those are reflected in the membership structure. This provides some
stability, but also disconnects the KDE e.V. membership from the
larger KDE Community. It is paramount for KDE e.V. to perform
well that its membership overlaps as much as possible with the active
core contributors of the community.
Most important of all, KDE has changed from being a project that
is all about software to a community that is all about people. The
KDE Community now invites other projects to come under its um-
brella. This marks an important cultural and technological shift, and
raises new questions. Should the new sub-projects be represented in
KDE e.V., and how? Since the community still consists mainly of
30 KDE e.V. - the Backbone of the KDE Community
volunteers, the design principles of the KDE e.V. bylaws still ap-
ply. The basic principles are sound. However, KDE e.V. needs to
evolve its processes and rules at the same pace as the community
changes and re-invents itself. It will also need to review if the ideals
embedded into the current organizational setup still represent why
contributors participate in the community.
I am glad that I was offered to opportunity to join KDE e.V. in
1998 and later had the opportunity to serve on the board. After 20
years, KDE e.V. is the backbone of the KDE Community, it provides
structure process and continuity. With a bit of maintenance, careful
adjustments and by putting the community and its ideals at the
center, I am sure the next 20 years can be just as successful.
7 KDE and Qt
Frederik Gladhorn
Frederik Gladhorn started his KDE journey with a small fix to KVoc-
Train (which he renamed to Parley shortly after) while in Spain in
2005. When he finds some KDE time nowadays, he improves acces-
sibility in Plasma and other KDE software since he values diversity
and inclusiveness. Since 2010 he lives in Oslo, Norway to work on
Qt for The Qt Company. Recently he worked on the continuous in-
tegration infrastructure for Qt. right now his focus is on improving
input handling in Qt Quick. That is when he is not marveling at
contemporary art, board gaming or outside, surfing, skiing, climbing
or doing acrobatics.
Qt is a framework that makes it easy to create applications, especially
graphical user interfaces. It is used as the basis for most of the KDE
applications and Plasma desktop. Qt provides a wealth of libraries
and makes programmers’ lives easier. Over time new technologies in
Qt were first adapted by KDE and KDE pushed many parts of Qt
forward. KDE and Qt always had a strong connection and influenced
each other over the years. In this essay I’d like to look back at a bit
of shared history.
In 1997 Trolltech started receiving weird bug reports from a certain
Matthias Ettrich in Germany. The first Trolltech employee, Arnt,
started to get exasperated and said something along the lines of:
“These bugs would only matter if you were writing your own window
manager”. Trolltech at that time consisted of four people, sitting
in an otherwise empty building, listening to loud techno and metal
music. When they realized, what he was trying to do, there was a
hint of doubt, since many projects had recently started with similarly
ambitious goals, usually leading nowhere but a small website looking
32 KDE and Qt
for people to implement the project. Luckily KDE started with a
more “show me the code” approach and became a real product not
so long after. And it would not take very much longer, before all of
Trolltech was running KDE as their desktop of choice.
Trolltech as a company had to keep a strong hold on Qt; it was
their product and business after all. But over time KDE influenced
the history of Qt in many ways. By the time KDE got started – this
was approximately the stone age of free software – Qt was available,
under the Qt public license. The QPL was considered not to be
compatible with the GPL, but thanks to primarily KDE’s interest
and dependency on Qt, the license was eventually changed to GPL.
All of this enabled great projects and great cooperation. Did you
know that KDE and Trolltech hackers got together in 1998, after
Netscape Navigator (yes, that’s the browser your parents used which
turned into Firefox) got open sourced? They ported the browser to
use Qt for the UI, with seven people in an amazing sprint of five
days, creating “QtScape” as a proof of concept.
On the people front, over time many a KDE developer started to
work on Qt. Yours truly is an example of that, but also Lars Knoll
who now holds the CTO position of The Qt Company, but also is the
chief maintainer of the Qt Project. Wait, what is a chief maintainer?
And the Qt Project, what’s that? Let’s take a step back; reciting a
bit of history is due here.
In June 2008 Nokia acquired Trolltech, leading to a series of
changes. All of this time, things could have gone terribly wrong
for KDE – after all there is no certainty for anything when big busi-
nesses are involved after all. Or is there? Long before the acquisition,
a plan was devised to make sure, Qt would be available to KDE, no
matter what the future holds. The KDE Free Qt Foundation was
conceived as a “poison pill”, should any company, current rights
owner or future, try to take the freedoms away from Qt. In case of
no free and open source release for twelve months, KDE would get
the rights to the source code under a permissive license. Long coop-
eration between individuals inside the commercial Qt business and
the KDE Community and the foundation lead to trust and respect
Frederik Gladhorn 33
from both sides. Over time KDE (represented by the non profit
organization KDE e.V.) and the Qt rights holders have worked to
refine and improve the terms regulating the foundation together.
Nokia changed things, aiming for as wide distribution of Qt as pos-
sible, on desktop and for their phones. The license was changed from
GPL to the more permissive LGPL. For the free software world, Qt
became a better project in many ways: a proper public bug tracker
became finally available. For the first time a system to allow ex-
ternal contributions was put in place: with the help of Gitorious
(now defunct) changes to improve Qt could be accepted. For me this
is the time of big adventure, moving from Germany to Norway to
find out why it wasn’t very smooth getting changes accepted into
Qt. From the outside it looked deceivingly simple: push the desired
change to Gitorious, wait for someone to click the magic button and
all was good. The process had some minor and a few major flaws.
At first each contribution was checked by a rather large legal depart-
ment. Assuming it got a green flag, eventually there was no button
to click, but a lot of work to do. Running a few scripts, reviewing
the change, testing it and then taking full responsibility for it was
roughly the process. The amount of work to get anything contributed
was often not worth the trouble, which is of course not a sustainable
process. The fix for this brings us to another historical development
under the reign of Nokia – the Open Governance project for Qt. One
thing which was pretty clear was that having two work flows, one for
“internal” people and one for contributors on the “outside” was not
going to cut it. The open source Qt Project was born to be steered
by the community. Making changes to Qt is the same for everyone,
reviewing changes is also shared by the entire community. Lead by
Thiago Macieira, the development process of Qt was re-shaped and
strongly inspired by KDE’s. For example the very flat hierarchy of
letting any contributor access all repositories works well. The pro-
cess is merit based, and just like in KDE, where people with more
experience often have greater influence and respect get to weigh in
on decisions, at the same time sound technical arguments will be
listened to, no matter who voices them. Qt started to have a lay-
34 KDE and Qt
ered system, where it’s easy for anyone to contribute changes. Those
more involved in the project eventually become approvers, having
the right to accept other’s changes. Here Qt diverges a little from
KDE: each change has to be reviewed. I’m happy to see that in KDE
reviews have become the norm in many areas as well. For each area
in both KDE and Qt, there are designated maintainers. Many parts
of Qt have their maintainer inside The Qt Company, but also quite
some are maintained by KDE contributors, holding these important
positions, influencing the direction of Qt strongly. To get back to the
earlier thread, you guessed, it, at the top of the maintainers for Qt is
Lars Knoll, another old time KDE contributor and now maintainer
responsible for all of Qt.
Another great story is the Android port of Qt, which was started
by BogDan Vatra. Nokia did not want to host the work for Android,
but KDE stepped up and hosted the port. Now that Qt is indepen-
dent again, the port found its proper home inside of Qt itself and
KDE applications are being ported to Android.
Eventually in 2012 Digia acquired Qt and the focus shifted from
Nokia phones to all of Qt’s users. This year, The Qt Company was
spun out of Digia and we are independent, shaping the future of
Qt with all of you. While The Qt Company takes a big role in
making sure the testing and releasing infrastructure is in place, a lot
of development of Qt comes from other parties, a significant chunk
from many KDE contributors, for that, we’d like to say thank you
KDE! There are also events such as Akademy which has been co-
located with the Qt Contributors’ summit for two times by now. I
cannot wait to attend this year’s QtCon, bringing together even more
and greater communities, among them KDE and Qt contributors.
For me personally, KDE and Qt mean a big group of friends, people
I see at work, but also when traveling. People I look forward to
meeting all around the globe. KDE has lead me to travel to Nigeria
and India, certainly the most memorable and impressive trips in my
life. I really wouldn’t want to miss that, ever. Special thanks to to
all the friendly people that hosted me, taught me, shared flats and
Frederik Gladhorn 35
went on crazy trips with me. I hope I’ll continue to have the chance
to learn from you all.
Twenty years have passed, but some things never change: we still
get weird bug reports from KDE. And all we can say is: “Keep them
coming!” Congratulations to being twenty years young, KDE!
8 German Association Law as Secret
Superpower
Cornelius Schumacher
Cornelius Schumacher became a contributor to KDE in 1999. He
maintained KOrganizer, co-founded Kontact, wrote KConfig XT and
a lot of other code. In addition to coding, Cornelius served on KDE
e.V.’s board for nine years, five years of them as its president. Cor-
nelius works as an engineering manager at SUSE Linux. He holds a
degree in physics from the university of Heidelberg.
When KDE was founded in 1996 it was off to a quick start. It only
took days to find a group of core developers, a few weeks to release the
first code, and it quickly gained popularity a couple of months after
its inception. In 1997 the founders decided to create a non-profit
organization incorporated according to German association law in
order to support and represent KDE. This decision turned out to be
of remarkable foresight.
When people ask if they should found an organization to support
their free software project, the usual advice is: “Don’t do it”. It
comes with a lot of work, with headaches of an unusual kind, and
requires quite a bit of stamina to follow through. It’s worth it, but
it’s a heavy investment, which only bears fruits if you can sustain
it. Nowadays there are a number of organizations which can act as
umbrella for free software projects, and many projects actually have
gone through the process of creating their own organization. This
was different in 1997. KDE was a pioneer.
The Linux-Kongress took place in Würzburg, Germany, in the
spring of 1997. It was one of the primary Linux and free software
related events at that time. KDE presented its desktop there for one
of the first times. This was an overwhelming success. Two members
38 German Association Law as Secret Superpower
of another desktop project canceled their presentation and left the
event after they had seen Matthias Ettrich and Martin Konold show
what KDE could already do. Haavard Nord, one of the founders
of Trolltech, presented Qt, the toolkit KDE based its software on.
He had conversations with the KDE people, which should shape the
future of the project. On the way back home to Tübingen the foun-
dation for creating KDE e.V. was laid and Martin then wrote the first
version of the articles of association of what would become KDE e.V.
The founding meeting was scheduled for October 1997 in the stu-
dent apartment of Matthias Ettrich. German law requires seven
people to physically be present as initial members to found an as-
sociation. As KDE already was a distributed international project
back then, they had to recruit Matthias’ room mates to meet the
required number. The initial members voted about the articles and
the association was born. Matthias became its first president, and
Kalle Dalheimer and Martin its vice presidents. That out of the
way, it’s said that the group then quickly turned to technical mat-
ters again and established a packet radio connection to the neighbor’s
apartment.
One of the primary reasons for creating KDE e.V. was the need
to handle money for developer meetings. The first KDE meeting in
Arnsberg in September 1997 already had a budget of a few thousand
Euros, and handling this in a private way was getting impractical.
With KDE e.V. there was the right mechanism in place to handle
that more professionally, and it turned out to be one of the most
powerful catalysts for the community. Hundreds of developer meet-
ings followed and dozens of conferences all over the world. Without
KDE e.V. as secret superpower behind it this wouldn’t have been
possible.
The first critical test for KDE e.V. came in 1998. There was a
debate about the license of Qt. Some people held the opinion that
it wasn’t free enough. Trolltech, the owner of Qt, decided to do
something about it and entered into an agreement with KDE that
would guarantee the availability of Qt under a free license. The KDE
Free Qt Foundation was born, founded by Trolltech and KDE e.V.
Cornelius Schumacher 39
Matthias and Kalle flew to Oslo to sign the contracts and established
a cornerstone of Trolltech’s commitment to free software and KDE.
The agreement of the KDE Free Qt Foundation is a defensive
agreement, which comes into effect in the case that Qt wouldn’t be
released under a free software license anymore. While it hopefully
never needs to be exercised it gives KDE a seat at the table when Qt
licensing is discussed. In 2008 this suddenly became very important
when Nokia announced to buy Trolltech including Qt.
Nokia acted as an exemplary free software citizen. They reached
out to the KDE e.V. board as one of the first things after the ac-
quisition. Nokia managers came to Frankfurt, where KDE e.V. had
established its first office together with Wikimedia Germany, for a
remarkable meeting, and KDE e.V.’s board returned the favor by go-
ing to Nokia’s headquarter in Helsinki to discuss collaboration and
strategy. It was a fruitful time with lots of investment in Qt and
KDE as well. It turned out that KDE’s strategy outlived Nokia’s in
the end, though.
The meetings, conferences, and the agreement about Qt are only
a few examples of how KDE e.V. backed the community in a way
which wouldn’t have been possible without an organization such as
this. KDE always has been a playful bunch of people, who focused on
technology. There are countless examples of brilliant technological
innovation in KDE’s history. But to operate a community on the
scale of KDE did require more than that. There were three domains,
which were of special significance here: Representation, support, and
providing governance.
When a group of volunteers comes together to work on free soft-
ware, the means of how technical collaboration happens fall into
place quite easily. Tools such as git, mailing lists, or IRC provide
the distributed infrastructure to develop and discuss code. The phi-
losophy of free software and its development processes provide a solid
base for decision making and coordinating work. Two cornerstones
of KDE’s philosophy always were the common ownership of code,
and the mantra that those who do the work decide.
40 German Association Law as Secret Superpower
Sometimes it needs more than that. Entering formal agreements
needs an entity which can act on behalf of the community. The KDE
Free Qt Foundation is an example from the early days of KDE which
is still highly relevant. There are more examples, such as holding
the registration of the KDE trademark, owning the kde.org domain,
being partner in EU research projects, receiving money on behalf of
the community, maintaining copyright through the fiduciary license
agreement created by the Free Software Foundation Europe, dealing
with legal obligations such as taxes, or simply having a central point
of contact for people who need an entry point to the community.
This is where KDE e.V. represents the community.
Millions of Euros have gone into the community through KDE e.V.
over the years. Lots of individuals support KDE by donations. Com-
panies give back by providing financial support. KDE participates in
programs where some money goes to the organization for work and
support it provides. KDE has been a partner in Google’s Summer of
Code in all the twelve years of its existence, and KDE e.V. handles
the money which goes into supporting the KDE mentors in the pro-
gram. This money goes back to the community, helping people to
attend conferences or developer meetings, providing technical infras-
tructure, paying for necessary administrative efforts. This is where
KDE e.V. supports the community.
Finally KDE e.V. provides governance to the community. This
actually comes with a twist, because KDE e.V. does not control or
steer the technical development of KDE software. This was one of
the conscious decisions when setting up the organization. The open
source development process provides culture and practices to take
decisions and run development based on the motivation and respon-
sibility of the individual contributors. This is a powerful concept,
which doesn’t require a central authority to plan and control ac-
tions. It can even be harmful to try to exercise central control in
that context. So KDE e.V. decided to stay out of this domain.
KDE e.V. does not stay out of the question who ultimately owns
KDE, and who manages its assets. The German association law
provides a strong and solid base here. It is used by hundreds of
Cornelius Schumacher 41
thousands of associations in Germany, and it provides a democratic
and transparent base of how to run an organization for the public
benefit. This makes sure that KDE can’t be bought or hijacked. It
always will be in the hand of its constituency, the people who put
in their time and effort as contributors. So KDE e.V. is the body
who is set up to give legitimacy to efforts within the community and
to people who act on behalf of it. This is where KDE e.V. provides
governance to the community.
Today KDE e.V. is a well oiled machine, which represents, sup-
ports, and provides governance to the community. There is an annual
general assembly where its members meet to report about work be-
ing done, elect the board and other representatives of KDE e.V., and
vote about the main decisions taken by the organization. There are
regular reports and discussions about ongoing topics, and there is a
team taking care of the daily business. This wasn’t always a given,
though. There was a critical phase in KDE e.V.’s development, where
the sustainability of the organization was threatened.
In the early years of the millennium after the tech bubble im-
ploded, there was less money available for technology. Many people
changed projects, some people who were paid to work full-time on
free software moved on to other endeavors. This also affected KDE.
While the development was in full swing driven by enthusiastic vol-
unteers, the organizational side starved. KDE e.V. was in limbo,
because too many active members had gone missing.
In 2002 Mirko Boehm, treasurer of KDE e.V at that time, orga-
nized a memorable meeting. He invited the members of KDE e.V.
and most of the active core contributors of KDE to a general as-
sembly. The goal was reviving the organization, putting an active
board in place, and revising the articles of association to deal with
members becoming non-active and setting up the foundation for be-
ing officially accepted as tax-exempt non-profit organization for the
public benefit.
The meeting took place in Hamburg, hosted by the university of
the German armed forces. There were meeting rooms, a computer
lab, which was quickly hacked to provide the means to compile KDE
42 German Association Law as Secret Superpower
software, and dormitories for the short times when people needed to
keep up with sleep. Rumors say that they were torn down directly
after the meeting.
It took two more years to implement all the decisions but with
the changes of the articles of association it defined the modern KDE
e.V. in the way it still is in place today. A new board was elected
bringing in Eva Brucherseifer who would run the organization for the
coming five years. The meeting also facilitated a discussion about
KDE’s values triggered by a document a young ambitious developer
from Canada, Aaron Seigo, had written. Aaron couldn’t be present
at the meeting in Hamburg, but he had a role in the future of KDE
e.V., serving as its president from 2007 to 2009.
KDE e.V. went on a growing trajectory over the subsequent years
after the meeting. It was able to provide support to the community
again, opened an office, employed Claudia Rauch as a business man-
ager in 2008, and dealt with a lot of the work behind the scenes to
run the community, to organize its events, such as the memorable
Desktop Summits in Gran Canaria and Berlin in 2009 and 2011,
hundreds of developer meetings, and many more.
In 2010 it even signed a Hollywood contract. The production
of Robert Rodriguez’ Machete wanted to include pictures of KDE
software in the movie. So KDE e.V. as owner of the trademark and
representative of the community jumped in to sign the agreement
and allow Robert de Niro and Lindsay Lohan to communicate via
KDE’s instant messenger.
It might seem surprising, but the solid base of the German asso-
ciation law, the foresight of the founders to create an organization
based on this law, and the relentless work of countless people to run
this organization did create a secret superpower for the KDE Com-
munity. May the community continue to use it wisely. There is a lot
of good to be done.
9 Who Does the Work Decides
Vishesh Handa
Vishesh Handa started his KDE contributing days in early 2010 when
he tried to understand the semantics behind the Nepomuk project. He
eventually started maintaining it, then killed it, and started main-
taining most of KDE’s search and metadata infrastructure. When
he worked on KDE professionally, he also hacked on KDE Frame-
works, KRunner, Plasma and various applications.
Open Source products targeting users are a rare thing. Even rarer
are the ones not dominated by a business or specific purpose. KDE is
one of those projects that satisfies both those criteria and is therefore
quite a unique place.
Most user-facing products have a company behind them. This
company often controls the entire product, and works on all parts
of it - marketing, distribution, evolution, and development. I have
purposely put development at the end, because normally the other
parts are what drives the development.
In KDE, we have an organization that helps with certain adminis-
trative and legal matters - the KDE e.V. However, they intentionally
do not steer the development in any significant way. This results in
an inversion of the classical model. We call this mode a “meritoc-
racy” and it is one of the core principles of the KDE Community:
“The person who does the work decides”
This meritocracy results in many interesting consequences. It has
resulted in a community where developers have far greater power be-
cause they are ultimately the ones who bring the ideas into light. For
a developer, this is great. It has built a strong community centered
44 Who Does the Work Decides
around technical excellence, and we developers have a lot of auton-
omy. This coupled with the amount senior members try to mentor
the newcomers has created a delightful place to learn and improve as
a developer. Also because the developers call the shots - they have
to take an active role in all other areas and this makes them grow.
It is a kind of Elysium that developers love and still get to work on
user facing software.
However, this does not lead to a cohesive product that has a di-
rection and really makes an impact. The product development side
where we try to understand the needs of a user and rapidly iterate
based on the business requirements and the market are lost. It is even
incredibly difficult to figure out how we should market our products
as developers and other contributors may have conflicting ideas. Our
product quite often develops at minimum because of personal itches
to scratch or otherwise with the hope that certain developers will
lead the product development. Though it is not guaranteed that the
others will follow.
It also results in other non appealing jobs often stagnating, espe-
cially proper quality assurance and documentation. We cannot just
hire people for these fields.
This way of working is not unique to KDE; however, being a
user facing product does compound the challenge significantly. Most
other significant open source projects are built around solving tech-
nical problems. Here the developers are often keenly aware of the
problems faced by the other developers, and decisions can often be
made solely on technical merit. In KDE we often do not expect our
users to be technically qualified.
Even with this developer controlled model, our community has
managed to accomplish a lot. Our most recent desktop shell, Plasma
5, has been the result of a lot of collaboration between designers and
developers. The existence of the Visual Design Group shows the
developers’ willingness to work with others. We have contributors
spending time in creating promotional material for KDE and others
organizing conferences to mentor newcomers.
Vishesh Handa 45
For me, however, this is one half of the story. The other half is
one which is well known - the evolution of KDE’s identity and its
interesting consequences.
In KDE we started off as a desktop environment and grew because
of our role as a Desktop Environment, and now KDE means the
community. However for many, including me, it is a mixture of the
desktop environment, certain applications and libraries. But this is
also now changing with the inclusion of projects such as Wiki2Learn.
It is hard to say who KDE is targeting and figuring this out is a
difficult process.
If we adopt a stricter approach we risk alienating existing projects
and members while loosening the criteria also results in KDE being
no different than “Free and Open Source software”, but with a bit
more user focus.
These two factors - the developer controlled products, and the
gradual decline of a core and actionable identity are for me some
of the biggest challenges faced by KDE. It is also what makes it an
exciting place.
The obvious conclusion to this is - where do we go beyond these
initial 20 years?
The libraries and developer tools will most certainly survive. They
suit this model where developers control the direction, specially since
they directly target the developers. The desktop shell still fulfills a
niche. It probably will continue, though it would be hard to say in
what form, and with the world moving towards trendier technological
stacks, the shell is certainly losing momentum.
The world of applications is quite different to what it was when
we started. Content is what seems to matter. The applications that
can help the user work with the content across multiple devices and
platforms are the ones that gain more traction. KDE applications
are starting to move towards other platforms and compete with the
rest of the world, but it is a difficult task, and being “open” does not
seem to be an important selling point. They will really need to step
up and focus on non-development roles.
46 Who Does the Work Decides
Overall, it has been a fun ride over the last 20 years. Many people
have come and gone, and KDE’s popularity has peaked and fallen. I
certainly hope the next generation of developers takes KDE further
in this completely different world.
10 Meet the Gearheads
Kévin Ottens
Kévin Ottens has more than 12 years of experience working with Qt.
He is also a long term contributor of the KDE Community where
he focused for a long time on libraries API design and architecture.
Graduating in 2007, he has a PhD in artificial intelligence. In 2012,
he participated in the creation of the KDE Manifesto. Nowadays he
spends time rethinking his job via a strong interest in Software Crafts-
manship. Kévin’s job at KDAB leads him to contribute to Qt 3D but
also includes giving trainings and the responsibility of community li-
aison with KDE. He lives in Toulouse where he serves as a part time
teacher in his former university.
As I am writing these lines, I am 36 years old. I have been a user of
KDE products since 1997. It has been 19 years, almost half of my
life, almost as long as the community exists. I finally decided to get
involved with KDE as a contributor in 2003, almost a third of my
life. Also, I intend to stay involved somehow. If everything goes well
(for the community and also for me), at one point my life without
KDE will be anecdotal compared to my life with it.
Why am I telling you all this you may ask? Well, I just want you,
dear readers, to realize that it has been an awfully long time! And
now you might just wonder “Why? Oh Why? Why would someone
in his right mind do something like this? Why spend your youth
working on something which won’t make you rich or famous? Why
even contemplate doing that while being older? Don’t you have a
life?”
These are a lot of valid questions and I will try to answer them
simply with this: you can’t and shouldn’t get rid of your family. That
might still sound mysterious, so let’s expand on this idea.
48 Meet the Gearheads
How It All Started
For as long as I can remember, I wanted to do something related
to computers and later decided that I’d at least try myself at artifi-
cial intelligence topics because of William Gibson’s Neuromancer. In
1996, I bumped into my first Linux distribution (a Slackware spin)
and got hooked on the Free Software culture as a result. It was only
a matter of time before I ended up contributing to something.
I had this hunch that I would likely contribute to something I use
and so I tried to use mostly Free Software with source code I felt
comfortable with. Yes, it means I chose by looking at the code of
the software I evaluated, not by its looks or by how many features
it stacked (those criteria came only distant second). Needless to
say, that quite a lot of the software at the time wasn’t really to my
liking. In the end, the source code coming from KDE impressed me
the most, so I started to use more and more of it, waiting for an
opportunity.
Finally, I found a missing feature for my workflow in the desktop
of the time and decided to make a plugin for it. Instead of keeping
it for me, I decided to contribute it to the world and was greeted
by a crazy Canadian who maintained Kicker at the time. My plugin
ended up being a part of the next official release.
That was obviously a very encouraging start. Still, the story thus
far has been mostly about technical facts and some distant political
vision. Nothing which could explain being engaged for long with the
same community.
“Happy Families” Meets the Lunatics
I started for technical reasons, but really, I have stayed because of
the people. When I first got into KDE, it sometimes acted like a
large, funny and chaotic family. It was also quite dysfunctional at
Kévin Ottens 49
times... like most large families. I think it still is like that. This
is probably important for bonding with people. Obviously, you see
some stereotypes in such families. I think I witnessed quite a few.
Indeed, while getting into the community I met plenty of charac-
ters...
The clever emo-goth cousin wearing only leather and weird boots.
You don’t always feel comfortable with him since you’re not sure how
he is going to react when you might point out something flawed he
did. He also tends to express weird and offensive opinions in public
just for the sake of it.
The aunt you admire hoping to be one day a bit like her. The
clearly inspiring person that takes you under her wing with great
pleasure. If you pay attention you will likely get insights from her
wisdom. You might not understand it at the time to only realize its
significance later.
The uncle you like to tag along with because you know the time
spent will be fun and crazy. He gets you to places you would never
go to (karaoke bars anyone?) and do crazy things, like talking to
drunken strangers in a foreign town.
The grandpa who is a great story teller. You always love spending
time with him late during family reunions. When the great noisy
time is over, he is still around gently telling real (or made up) stories.
The grandma who has lived several lives. Clearly you can gain wis-
dom from her experiences. That said, you also get the feeling that
sometimes she is getting overly conservative and over-protective.
As a long timer, I also ended up in the oldies group, which gives
you a whole new perspective...
Two sisters you appreciated, who had stopped talking to each
other because of some feud. There might have been some valid reason
years ago. Unfortunately, years after instead of being put to rest, one
50 Meet the Gearheads
is estranged and some relationships in the family are still tainted by
it.
The little cousin with attention deficit disorder who brings plenty
of new activity ideas for the whole family, but rarely delivers com-
pletely and someone else picks up to complete his vision.
The little brother still trying to find his place in the family. He is
still feeling insecure, but in time he’ll grab the torch and move the
family forward together with his whole generation. It is a privilege
to see him grow.
Of course, there are many more such characters in our community
and that is what makes it interesting and unfortunately I can’t list
them all here. My hope is that by pointing a few out bluntly it’ll
help members to reflect on their peers and try to improve how the
family works so that it is rarely dysfunctional.
Conclusion
Yes, I do have a life and it involves all of the KDE family characters
in some twisted way. This is not the kind of thing you really think
about as a child. You don’t envision something quite like it. But it
happens. Most of us start because of some itch to scratch or techni-
cal curiosity, this is hardly a rational choice in the first place.
Similarly, I’ll slightly change Desmond Tutu’s words: “You don’t
choose your family. They are [the Universe’s] gift to you, as you are
to them.”
Clearly, KDE has been a gift to me, a second family. This is why,
just like for my first family, I try to be available for fellow gearheads
and be a gift to them.
11 Deals with the Devil
Boudhayan Gupta
Some would say his childhood was misspent, but when you a put a
computer, a CD with a Linux distribution, and the permission to do
anything one pleases with the two in front of a 13-year old boy, there’s
only one way it can end. After acquiring ninja Linux skills, picking
up a couple of programming languages, and enrolling for an under-
graduate course in Computer Science and Engineering, Boudhayan
Gupta broke into the KDE Community in early 2015, eager to help in
the ongoing effort to port software to KDE Frameworks 5. Today, he
maintains KDE’s screenshot utility, is a system administrator, and
a member of KDE e.V.. In the very rare few moments when he’s not
studying or devoting time to KDE, he can be seen trying to learn as
many languages and read as many books as he possibly can.
It is the middle of autumn, almost exactly nineteen years to the day
KDE was born. An e-mail has just been posted to the community
mailing list. The e-mail is barely 20 lines long, and contains a very
simple suggestion. Over the course of two months, this thread will
grow to over two hundred e-mails, split itself into multiple threads
across three mailing lists, with nearly a hundred people participating,
putting on clear public display the passion the people have for not
just what KDE builds, but what the community stands for. This
debate and the resulting action will lay down precedent for services
the community will offer to its members in the future. This is the
story of what happened, and how it changed our community for the
better.
52 Deals with the Devil
Free Software Isn’t Just About Freedom
Free software is about freedom; that is what the free stands for. Free
software isn’t gratis software, it’s libre software. But free software
isn’t as much about freedom as it is about control, and making sure
that that control remains with the widest possible populace. Free
software abhors any action whose possible consequences include loss
of control over the software by any member who currently has it.
In the context of free software, we can define freedom in terms of
the control the users of the software has over how they use it, with
whom they share it, and how they change it. The KDE Commu-
nity recognizes that simply making sure users have control over how
the software is used, modified and shared isn’t enough to guarantee
a healthy ecosystem fostering the development and use of free soft-
ware. Like the users, contributors must also be guaranteed certain
freedoms, defined in terms of control over how they contribute to the
project. The contributors dictate how they want to develop the soft-
ware; the kind of tooling they want to use, the kind of workflows they
want to maintain, and the ways in which they communicate, among
others. To guarantee these freedoms to the developers, the commu-
nity must do everything in their power to ensure control over our
infrastructure ultimately remains in the hands of the contributors.
The KDE System Administrators
The KDE System Administrators (whom we really should call Infras-
tructure Engineers, since that describes their role more accurately)
are responsible for maintaining the infrastructure that supports the
activities of the community. This extends to beyond supporting the
development of software. A considerable chunk of the infrastruc-
ture exists to provide spaces for people to collaborate on tasks of
any sort, be it administrative, financial, or related to development.
The KDE System Administrators exist to meet the technical needs
of the community. To ensure that it does always meet the needs of
Boudhayan Gupta 53
the community, the system administrators need to ensure that they
never find themselves in a position where they are unable to provide
what the community requires, because services provided by other
providers which the community relies on do not let us do things we
need to do. This is why we host our own source code management
servers instead of relying on one of the large proprietary hosted ser-
vices. We simply cannot let other service providers dictate what we
are allowed to do with our infrastructure. This example is pertinent
because of the subject matter of the aforementioned email thread.
The email thread was a request from an active developer asking for
the presence of KDE’s code repositories on GitHub.
KDE on GitHub
It was clear from the very beginning that hosting our repositories on
GitHub and having all our activity take place there would not be
tenable, because of the loss of control over our infrastructure that
would entail. Among other things, we wouldn’t be able to ensure:
1. The availability of code hosting and code review services, as
if GitHub decides to change their services, for technical or fi-
nancial reasons, and their services are no longer in line with
our technical or financial requirements, we would find ourselves
without a place to publicly host our code, and coordinate our
development activities.
2. The integrity of the code repositories, since a breach in their se-
curity would allow code in the repositories to be altered. While
our own infrastructure is also susceptible to such a problem, if
such an incident happens on our own infrastructure, the ac-
countability is shared by the community and getting recourse
is infinitely easier. Our response to such an incident would be
tailored to our needs, which cannot be guaranteed for a hosted
service.
54 Deals with the Devil
At the same time, the code being present on GitHub has distinct
practical advantages. Some of the more important ones include:
1. Code visibility. A vast number of people who are just be-
ginning their journeys in the world of open source software
are simply not aware that open source code exists outside of
GitHub, thanks to the brilliant publicity and ubiquity GitHub
has achieved. Having code available on GitHub would ensure
the code will be discoverable by such people.
2. Developers’ credibility. A lot of employers simply look at a
person’s GitHub profile to find a prospective employee’s pub-
licly available code, and evaluate their suitability for the job.
Having KDE’s code on GitHub, with the commits made by a
developer showing up in their profile would make a vast amount
of code available for these prospective employers to peruse, as
well as display the developer’s ability to cooperate with other
developers and contribute to a shared codebase.
3. An offsite hot spare. If KDE’s infrastructure were ever to go
down, having our code on GitHub would ensure that the code
would continue to remain accessible while we work to bring our
services back online. Also, since it is possible to clone a reposi-
tory from GitHub and push new commits to our infrastructure,
this would lessen some of the load on our systems.
Eventually, a solution was found. GitHub has a feature wherein
organizations are able to host mirrors of their own self-hosted Git
repositories on GitHub, which we would make use of. These mirrors
can be made read-only, and all extra features of GitHub (such as the
wiki, the bug tracker, etc) can be disabled for these repositories. All
the KDE System Administrators would need to do is to push new
commits from our master Git server to GitHub, in addition to our
own read-only mirror network. It took us a month since the first
e-mail1 was sent to decide to have the mirror set up, but the actual
1 https://mail.kde.org/pipermail/kde-community/2015q3/001507.html
Boudhayan Gupta 55
work was conducted over a 36 hour period between September 16 to
September 18, 2015. First, we realized that the URL github.com/kde
was already in use by a user who had no activity, and therefore our
first task was to liaise with GitHub and get the organization assigned
to us2 . Then I got to work cooking up the scripts that would push
the repositories we wanted to our new shiny GitHub organization.
On September 17th, I finished up that work and handed the scripts
over to the Git infrastructure maintainer. As I went to sleep in India,
he woke up in New Zealand, reviewed the scripts and added them to
those we already ran when new commits were pushed to our master
server. On the 18th, we were able to announce to the world that KDE
was now present on GitHub3 . The discussions on the mailing lists
continued, and we reached a few ideological conclusions regarding
how we would engage with proprietary hosted services outside our
control. We concluded that for practical reasons we could never shut
them out, but that we should never rely on these services to fulfill
our core requirements. Additionally, we concluded that we should
always work towards bringing people on these hosted services to our
own infrastructure.
KDE on Telegram
The KDE Community has always relied on IRC (Internet Relay
Chat) to provide online chat rooms where people can get together
and discuss development. IRC has developed a subculture, and peo-
ple hang out in IRC channels to meet new people, socialize online
and discuss as much off-topic content as on-topic content. IRC has
a special place in the hearts of seasoned people in the open source
world. It is interesting to note that with all the care that we take to
retain control over every bit of our infrastructure, we don’t actually
host our IRC services ourselves, instead delegating it to Freenode,
a community run by people with strong ideological ties to the free
2 https://mail.kde.org/pipermail/kde-community/2015q3/001704.html
3 https://mail.kde.org/pipermail/kde-community/2015q3/001717.html
56 Deals with the Devil
software culture, many of whom are also associated with the KDE
Community. It is one of the very few cases where we can trust an
external provider to host services for us. During the preparations
for our annual mentoring program in 2016, we realized that there
was an entirely disjoint set of people who were active participants in
the KDE Community, but had never ever used our IRC services, and
were therefore invisible to the people who regularly used IRC to keep
in touch with their friends in the community. Part of a generation
of people never exposed to the wonders of IRC, instead, these peo-
ple used Telegram, a service that provides encrypted one-on-one and
group messaging services. Telegram has apps on mobile phones, all
major desktop operating systems (including GNU/Linux), and a very
functional website to fall back to if all else fails. Unlike IRC, which
uses its own ports (which may be blocked at workplaces and uni-
versities) and requires dedicated clients, Telegram simply works over
encrypted HTTP, over standard HTTP ports, and simply requires a
web browser to function. Telegram allows the transfer of images and
files, has native support for emoticons and “stickers”, and works on
the go with their lightweight mobile apps. There is only one problem
with Telegram: it is run by a for-profit entity whose interests may
not always be in line with KDE’s. While we could never officially
endorse the use of Telegram, with the precedent set by having our
repositories hosted on GitHub, we could extend our support to peo-
ple using the service. Telegram users also being active participants
in the KDE Community, we owe it to them to make it feasible for
them to participate in discussions happening on the IRC channels.
We also owe it to our IRC users to be able to join discussions hap-
pening on Telegram. The solution to this was simple. We used one
of our servers to run a bot. This bot would read messages from an
IRC channel and post the same messages on the Telegram group. It
would also read messages from the Telegram group and post them on
the IRC channel. This way, Telegram users keep themselves abreast
of the conversation happening on IRC, and IRC people get to partic-
ipate in the discussion happening on Telegram. Everyone is happy.
Boudhayan Gupta 57
A Happy Ending
In some countries, KDE is still not old enough to be of legal drink-
ing age. Over its 20 years of existence, the community has learned
lessons, and incorporated these lessons into their way of conducting
their activities. There were important lessons learned from these
two experiences. Firstly, with a community this large, there is al-
ways going to be a difference of opinion, and some of these opinions
may be incompatible with each other. Pleasing everyone is impos-
sible, but there is always a compromise to be found for people who
are willing to find it. Secondly, shutting users of proprietary systems
and services out is never an option. Trying to find a solution that
would enable such users to use our services and participate in our
community is the only responsible thing to do. Finally, KDE is as
much a sociopolitical movement as it is a group of technical geniuses
building great software, and it shows. KDE is what it is because of
the people; people who have poured their heart and soul into the
community and the software, and who voluntarily take ownership
of the community’s positions and actions, products and activities.
The political and social stands the community takes on issues is its
identity, and forms the basis for commanding the respect it deserves.
KDE is now 20 years old, and the community is primed to make
itself grow for 20 more years, and then 20 more after that. If there
is anything we can be sure of, it is that experiences like this will
continue to happen, and such stories will continue to be written.
12 Defining a Vision and Mission for KDE
Thomas Pfeiffer
Thomas Pfeiffer is mainly responsible for usability matters within
KDE’s Visual Design Group, where he works to keep developers, de-
signers 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.
In spring 2015, Lydia Pintscher started the initiative “Evolving
KDE” with the goal of “helping KDE and KDE e.V. get a bet-
ter 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 com-
munity 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
60 Defining a Vision and Mission for KDE
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
A world in which everyone has control over their digital
life and enjoys freedom and privacy.
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
Thomas Pfeiffer 61
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
62 Defining a Vision and Mission for KDE
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 Soft-
ware is generally more trusted to respect its users’ privacy than pro-
prietary 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 or-
der 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 some-
one 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
Thomas Pfeiffer 63
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 ques-
tions. Even though the road to the Vision was rocky, this shows that
the result was worth the effort!
13 On Subtle Contributions
Sandro Andrade
Sandro Andrade has been using Qt and KDE technologies since 2000,
when he found a new tool to create amazing C++ visual applications
– KDevelop. Sandro is one of the leading contributors to activities
which have been fostering KDE in Brazil and South America, such
as the creation of the Latin-America KDE Summit (LaKademy) in
2010. He was a member of the KDE e.V. Marketing Working Group,
is the creator and maintainer of Minuet (the KDE-edu software for
music education) and is currently a member of the KDE e.V. Board
of Directors. Sandro holds a PhD in Computer Science and works as
a professor in the Computer Science Department at IFBA, Brazil.
All of us want to see our beloved free software project succeed. In-
deed, we do a lot of consciously planned work to achieve such a
freedom nirvana. We strive to come up with a nice idea, decide
about promising technologies to adopt, and code hopelessly to have
an initial release to show off and maybe herd some new users and
contributors around the world. If you deliver your software as part of
a well-established and large community such as KDE, a brave army
of translators, designers, testers, sysadmins, packagers, and promo
people is promptly put in place to provide you all the needed support.
From the end-user perspective, only a small portion of such a huge
effort becomes effectively apparent, in the form of graphical inter-
faces, user documentation, helpful features, and so on. As you get
more involved in the community and start delighting the full FLOSS
experience, all those multifaceted contributions from different peo-
ple start to become apparent and you are immediately snatched up
with an irrevocable desire of saying a huge “Thank you” to all those
contributors. That said, I would like to talk herein about a different
sort of contribution though: the subtle contribution.
66 On Subtle Contributions
I started pushing KDE forward in Brazil in 2008 along with Tomaz
Canabrava, when we presented a Qt short-course in one of the biggest
Brazilian FLOSS conferences. At that time, only three Brazilian
contributors were doing some nice but somehow stand-offish work
related to development, translation, and packaging. In 2010 – as
a result of many activities we did in 2009 at some universities and
local FLOSS events – we witnessed the dawn of Akademy-BR, the
first Brazilian KDE sprint ever and expanded it to the Latin-America
KDE Summit (LaKademy) two years later, in 2012.
Nowadays, the Latin-American KDE contributor base is formed by
22 volunteers from Argentina, Brazil, Colombia, and Peru; working
on activities related to development, translation, promotion, sysad-
min, and artwork. After nearly nine years promoting KDE, doing
some development and artwork contributions, and lately working
on the overall community management, I now wonder what is that
essential element that bonds people together, cultivates a thriving
atmosphere, and makes such an odyssey last for 20 years.
People bond with each other by affinity. In FLOSS communities,
more often than not, they bond by technological affinity, common in-
terests in some application domain, or reciprocal wish to share knowl-
edge. Whilst such coalescence factors are certainly quite important
to build solid and healthy communities, I’d like to emphasize the
importance of contributions that go readily unnoticed and, in spite
of such contributor’s unawareness, play a definite role when forging
FLOSS communities. Failing to recognize such ’subtle contributions’
not only hampers the catalysis of community growing but also lets
’subtle contributors’ in the unknown about their own importance for
the whole FLOSS ecosystem.
The first kind of subtle contribution I want to describe is ’people
as extrinsic motivation’. Although I had been using Qt and KDE
technologies for seven years already, it was only in 2008 when I and
Tomaz had a conversation which ended with a “do you want to do
that?”, “if you want to do that, I also want to do it”, “cool, let’s
do it”. For some people, making things alone may be extremely
troublesome. Having someone just to say “you can!” or even walk the
Sandro Andrade 67
path alongside you is one of the most beautiful subtle contributions
I have ever seen.
Another subtle contribution is made by people able to proactively
identify the small things that engender a welcoming and relaxed at-
mosphere. And that includes everything someone involved with cod-
ing, testing, translation, infrastructure, and packaging usually isn’t
able to identify, let alone execute. I am writing this book chapter
in a hotel room in Porto Alegre (south Brazil), on the very last day
of the 17th International Free Software Forum (FISL), where KDE
took up an amazing booth, presented a whole day of nice talks, and
celebrated its 20th anniversary. What a nice demonstration of subtle
contributions!
Do you know that invigorating thrill and fond memories when a
FLOSS meeting or sprint comes to its end? New features, bug fixes,
and translations are awesome but I’d risk to say such a nirvana is
primarily caused by a different stimulus. Subtle contributors turn
us into a family. They care about how to decorate our booth, they
come up with a big commemorative cake, they talk about life or they
do not even need to talk to let us know they are quite comfortable
and happy in being part of KDE.
I regret not being sensitive enough to realize KDE is a stronghold
of subtle contributors earlier. I would have said more ’Thank you’s.
14 The Importance of Face-To-Face
Meetings
Dani Gutiérrez Porset
Dani Gutiérrez Porset is a Free Software activist. He does consulting
around Free Software and teaches at the Public University of the
Basque Country. He was a project manager at the Office for Free
Software at the Basque Government. He organized Akademy-es in
2010 and 2013 as well as Akademy and the Qt Contributors’ Summit
in 2013.
When speaking about personal fulfillments, some of the best achieve-
ments reached by individuals and groups happen in environments
where motivation is not tied to economic incomes but contribution
to community, be it a big or a small one. Think about situations
related to friendship, family or love. Or, beyond feelings, about an
important discovery for human health.
In the subset of free software world that is formed by communi-
ties like KDE, what moves people to contribute with personal time
(coding, designing, teaching, evangelizing and more) is not so much
a possible chance of making business, but other factors like building
a high quality product/service on your own or maybe with other col-
leagues, and of course sharing part of your “brain” around the world,
like when you know that your program is being used in more than
50 countries.
Twenty years ago it was very hard to believe that a KDE code
would be used in a place like a particle accelerator at CERN, or that
a free software kernel would conquer the market of mobile devices.
And these kinds of successes have been achieved not just by the
contribution of hundreds, thousands of people, but also by means of
a political point of view based on generosity and freedom to learn,
70 The Importance of Face-To-Face Meetings
modify and improve what past generations have been building for
future generations, trying to create a better world.
Does this all mean that making money from free software is bad?
Not at all. Today more and more companies are making good busi-
ness thanks to open source components. Think about the many
companies earning money thanks to Apache, Qt or Ruby on Rails.
Free software companies have some interesting sides: it is expected
that they make good products because of their “professionality”, and
they spread a fresh and competitive option among the traditional pri-
vate market. But there is a but: in general it will be more difficult
for companies to be open and share its software completely, because
their spirit and deep motivation is mainly business-focused. And,
again, it is not a bad thing (but a necessary one) that people do
work for a living, or even to become rich.
Joining all of this with the field of politics, it would be great if
there were a kind of basic income, publicly assured, for those people
that during some part of their life dedicate themselves to produce
and spread free software, in order to recognize its contribution to the
world.
Among distinct useful tasks related to free software communities,
typically we hear some like coding, designing, documenting and per-
haps lawyering. But “free software communities” is three words and
the last one means people cooperating together.
As we belong to the IT field, the interconnnection between our peo-
ple is usually done remotely, with email, messaging, social networks,
or video conferences on PCs, laptops, tablets or mobile phones. But
no technology comes near the direct face-to-face encounter and its
results. It is really great to meet us for the first time or even more
when we have met before. It’s interesting because we know each
other not only from the techie side, but also regarding other impor-
tant parts of our lives. And when we see and hear each other, and
share a drink and laugh, and we realize our common target across
the free software world, we come back home more motivated to go
on working hard.
Dani Gutiérrez Porset 71
So, to create spaces where programmers, managers, designers,...
meet face-to-face is key for a better continuation of the community.
And a big opportunity to reach this “community empowerment” are
the international meetings like Akademy or FOSDEM. For this rea-
son, for the KDE Community it is a must to organize good Akademy
encounters, mainly the technical part but also the casual and friendly
one. Let’s remain a community where we take care of all people who
belong to it.
15 Remote Places Make Magic Possible
Mario Fux
Mario Fux is the father of two sons, husband, teacher, webmaster and
a reader of almost anything. He is using Free Software for nearly 20
years and joined KDE around 2007. He is the main organizer of the
annual Randa meetings - KDE’s week-long tech summit - and helps
where help is needed.
KDE was born twenty years ago, in the last millennium. Back then,
I didn’t know about it and its great and welcoming community. Back
then I made my first experiences with GNU, Linux and distributions
and thus Free Software in general. I think it was my first distribution,
SuSE 5.3, that introduced me to KDE. KDE 0.9 or 1.X, I can’t
remember because I didn’t stick to Linux at first but went back to
Windows or maybe dual-booted. But something made me stick to
the Free Software world and when people asked me about why I
spent so much time on something I didn’t earn any money from, and
would spend hours or even days siting in front of a PC, I told them:
“It’s because everybody told me that you don’t even get kicked for
free these days, but here I found something where people are working
on something in their spare time, because they love it with passion
and this something even challenges multi-billion IT-businesses en
passant.”
So the Free Software movement became a big hobby of mine or bet-
ter say, a big part of my life. I visited several Linuxtage in Germany,
other Linux events abroad and then in 2007 Anne-Marie Mahfouf in-
vited me to Akademy in Glasgow, Scotland. She is of course famous
for her work in KDE Edu but we knew each other from a monthly col-
umn I wrote about Free Software in education: TUX&GNU@school.
Around this time I was really active in the area of Free Software
74 Remote Places Make Magic Possible
in education as I was a trained primary school teacher. I gave a
presentation about my local school that I migrated to GNU/Linux
and KDE software including old Windows education software un-
der Wine. It was a very interesting week and although I was (and
probably still am) quite shy I made some new contacts.
Back in Switzerland where I grew up and still live, my first Akademy
experience began to affect me. I began to use more and more KDE
software, and started to study computer sciences as my minor. I
realized that I love to write code but it is not my biggest strength or
talent. So how could I give back something to this community that
offered me software I use daily for free and with pleasure? In the Free
Software media I read about KDE sprints that happened frequently
and there it was: the idea to host such a sprint. It was around
the time that Aaron Seigo, one of the central people in KDE at the
time, was in Zurich for a presentation. I studied there and thus could
visit his presentation and used the opportunity to tell him about my
idea and that I would invite him and the other Plasma hackers to
come to Randa where I would offer them a place to sleep, electric-
ity, some internet connectivity and a beautiful and distraction-free
surroundings, and inspiring nature.
In August 2009 it really happened: more than 15 women and men
hackers from around the world arrived in a village with a population
of less than 400 people in the middle of nowhere. They all arrived
safely at my parent’s Chalet (local holiday house) and although I
didn’t know them the Plasma team felt like family immediately. For
a week they hacked, discussed, hiked and wrote software that I and
millions of other people use and even better: can and will use in the
future.
It was an amazing week for everybody and it just couldn’t stop
there. We needed to find a bigger house for more people. And there
is a bigger house in town; actually the biggest house in Randa that
we rent since 2010 for one week a year. That’s the story of how the
Randa Meetings were born.
(Almost) every year since 2009 several dozen Free Software enthu-
siasts come to Randa and spend a week eating, sleeping, discussing,
Mario Fux 75
hacking, deciding and contributing under one roof. This wouldn’t be
possible without the help and support of a lot of other people: my
wife, children, parents, brother and even my aunts and uncles are
helping. And there are a lot of Free Software people not part of my
family that help as well. It’s a lot of work, a lot of joy and always
great to see what can be achieved in one week with focus.
Over the years we saw important decisions made in Randa like
at the Platform 11 discussion which led to the successful KDE
Frameworks 5 releases. The KDE Multimedia team prepared some
great Amarok releases in Randa and discussed with Qt the future of
Phonon. Kdenlive, one of the best video editors in the world, not
just in Free software, had some important meetings in the middle
of the Swiss Alps and decided to formally become part of the KDE
community. The KDE Education group worked tirelessly in Randa
days and long nights and now includes GCompris, which has been
ported from Gtk to Qt, and has become part of the KDE commu-
nity. And in recent years we worked hard to bring KDE software to
new devices and even proprietary platforms as I strongly believe that
even users of proprietary operating systems should be able to use our
great software and thus know about us and be able to support us.
Although I strongly believe in the values of a Free operating system
and will most probably always use one of them on my main systems I
think that we should bring our values and software to other systems
as well. And we should not be afraid of asking for money, either. The
most important software distribution channels now are the Google
Play Store and the Apple Store and I’m convinced that KDE should
be there. Actually we are already there - some of ours apps are
included and downloadable for millions of users. But let’s ask them
for a Franken, Dollar or Euro or two and we’ll get the money and
can use it to support development.
Back to the farther future of KDE. I’m sure we will still be active
and healthy in five, ten and then twenty years and I hope that the
Randa Meetings will be there too. It would be great if at least one of
my kids would still be involved in these great meet-ups in the middle
of Europe. And if I had a wish for KDE I’d say KDE should become
76 Remote Places Make Magic Possible
more self-confident; we have such great software and values. More
people should know and use our software, and embrace our values.
If we stay such a welcoming community and continue to open up
in areas like promotion, artwork, design and communication, we’ll
become even more successful. As we become even more international,
more people on this planet will know about our great projects and
use our software and thus become part of this great community.
About the first train that drove through the Matter Valley, where
Randa is located,125 years ago, it was said: “Great people create
great things, but good people create the perpetual.” KDE people
are good people, creating for the future.
16 KDE in Taiwan
Franklin Weng
Franklin Weng is open source developer, translator and promoter
from Taiwan. He is the coordinator of KDE’s zh TW translation
team since 2006 and the president of the Software Liberty Association
Taiwan.
I’m a maverick. I’ve always been one. Well, okay, to some extent.
When I completed graduate school in 1999, my classmates rushed to
the Hsinchu Science Park to find a high-pay job at TSMC or UMC. I
didn’t. I went to a small company outside the Hsinchu Science Park.
That company was developing their own search engine at that time,
and I was their 19th employee.
While my colleagues were using Windows 98 and NT 3.0, I was
using Red Hat 7.2 with Chinese Linux Extension, and KDE/GNOME
as my desktop system. At that time, I wasn’t bound to a specific
desktop system. I started with KDE, then jumped to GNOME due
to the beauty of Gaelon. No matter what desktop system I used, I
kept looking for a useful mail client.
The first mail client I was satisfied with and started translating was
Sylpheed, which was developed by a Japanese developer and based
on GTK. Sylpheed was good, but at that time it couldn’t dock into
my system tray in GNOME. I used GNOME and Sylpheed for some
years, but eventually tried KDE again for KMail because it could
dock in the system tray in KDE. It was that simple, and since then
I have been bound to KDE.
My first impression was that KDE was beautiful. KDE had abun-
dant software for all kinds of jobs to use. KDE had many cool effects.
I loved it, and I started to translate for it, starting with KMail, and
then contributing to many other applications. I was proud to be the
78 KDE in Taiwan
only one in my company who fully used Linux and KDE as my daily
work environment. I was also proud to contribute to the traditional
Chinese translations of KDE, even though I was the only one to do
this.
Then KDE 4 was released. I had not yet changed my desktop to
4.0, but I had introduced FOSS and KDE 4.0 in some talk I gave
around that time. KDE 4 was buggy, but it still gave me a lot of
fun. When KDE 4.1 was released, I fell in love with KDE all over
again and changed my daily work environment to KDE 4.1 almost
immediately. I still remember the moment I understood the concept
of Plasma. It was when I successfully put the application menu on
the desktop, instead of the panel. It is a bit silly, but I was quite
excited when I realized this.
In 2012 I successfully changed the default desktop environment in
EzGo to Plasma 4. EzGo is a derived Linux distribution used to
promote FOSS in Taiwan’s school. The main reason to change to
Plasma was because it still had an application menu while the other
desktop environments had removed theirs. We had some (well, a
lot of) arguments about this change, but we finally decided to use
Plasma 4. Then, in 2013 we successfully “defeated” Microsoft and
managed to install Linux and Plasma 4 on the 10,000 computers
New Taipei City purchased that year. I also created some Debian
packages so that we could easily change Kubuntu into EzGo.
KDE is no longer a mere desktop system but a community of
people dedicated to creating a free and user-friendly computing ex-
perience, offering an advanced graphical desktop, a wide variety of
applications for communication, work, education and entertainment
and a platform to easily build new applications upon. However,
I have no idea how many people are aware of the change from a
desktop-centric system to a set of people dedicated to creating beau-
tiful experiences in the world of FOSS. Maybe most people seem to
still treat KDE as a desktop system only. Maybe.
KDE is facing a crisis of identity. After the iPad was born, the
computing world was flipped on its head. The famous vision for
“a computer on every desk” is almost realized. Facing such a huge
Franklin Weng 79
change, what is in the future for KDE? I see that many old commu-
nities like GNOME or Mozilla are facing these same challenges. We
all need to change, no doubt. IMHO, KDE must keep its identity
while adapting into the current new digital world. KDE should use
its advantages of being based on Qt and aim for being ported to
Android and iOS. KDE has many good applications that could be
used on Android or iOS with some user interface changes. At the
same time, it should not be too difficult to keep maintaining software
on the older platforms like PC and laptops. Even so, the marketing
part of KDE can and should aim to be more compact and effective.
I’m always proud to be a member of KDE. Let’s make it better.
17 Building KDE’s Community in India
Pradeepto Bhattacharya
Pradeepto Bhattacharya started contributing to KDE in 2005. He
started with KDE promotion in India and then contributed to KDE
PIM for a few years. He founded the KDE India community and
has served on KDE e.V.’s Board of Directors. He lives in Pune,
India with his wife. He works for Red Hat in the Developer Tools
Engineering Group.
In March 2016, the KDE India community organized its 5th edition
of conf.kde.in, the annual Qt/KDE conference in India, in Jaipur.
Jaipur is a small laid-back city in the North West part of India. It
took 10 years for KDE India to reach Jaipur. This essay tries to
tell you that story briefly, the 10 years of KDE’s journey in India,
a sub-set of its own 20 years journey. A story in which many new
friends were made who came together at different points of time to
make this journey a very happy memory.
It started with a Birds of Feather session at FOSS.IN, at that
point India’s and perhaps Asia’s largest Open Source conference, on
December 2nd 2005. Two KDE developers, Till Adam and Sirtaj
Singh Kang (Taj), were participating in the conference. I had flown
down to Bangalore from Mumbai to attend my first ever Open Source
conference. I used to write Qt code for a company in Mumbai and ea-
gerly wanted to know what all this Open Source is about. The result
of the BoF session was the founding of an informal group called KDE
India. Very simple beginnings - a mailing list for the Indian commu-
nity and a sub-domain in.kde.org because somebody owned kde.in
already. Some time later, when that domain was available, KDE
e.V took it under its wings. Aaron Seigo was supposed to attend
the conference as well but he couldn’t because of another clashing
conference. He made it up by coming to India for FOSS.IN/2006.
82 Building KDE’s Community in India
After the conference in 2005, the community basically grew very
slowly. I didn’t let go of any speaking opportunity between 2006
and 2009. I went to any college or university or anyone organizing
a FOSS event and would let me speak about KDE at their event.
Thanks to Google Summer of Code and Season of KDE, we got a
few KDE contributors from India over the next few years. Earliest
contributors that I can remember were Sharan Rao, Piyush Verma,
Akarsh Simha etc. I am fortunate to be still in touch with all of
them. In 2007, the FOSS.IN organizers came up with a brilliant
master stroke - “project days” for various Open Source projects.
These were modeled around LCA mini-confs or FOSDEM rooms.
We had to submit proposals even for “project days”. KDE got a slot
for a KDE Project Day. Long-time KDE contributors Kévin Ottens,
Till Adam and Volker Krause all were present for the KDE Project
Day and the main conference.
For any success story, there is always an inflection point. KDE
India’s story has one as well. It was in 2008. I contacted an ac-
quaintance of mine, Madhusudhan CS, who was still an engineering
student in Bangalore to help me with a certain idea for the KDE
Project Day at FOSS.IN. I requested him to keep it a secret be-
cause I wasn’t sure about the idea myself and how I would execute
it. Anyway, Madhu seemed to be sold on the idea but he couldn’t
help himself from keeping the secret from his best friend and class-
mate Santosh Vattam. Both started helping with the idea the next
day. As it turned out, Madhu and Santosh were excellent in selling
the idea to their classmates and soon, I had a whole “secret” team
- Krishna, Aditya - working on the idea. The idea was to create 1
or 2 KDE fliers and hand them out at the KDE Project Day. As it
turned out, with the help of an excellent team, your idea can multiply
manifold. The output wasn’t just a couple of fliers but a complete
booklet. The first KDE handbook was born. Soon we realized that
we needed money to print the booklet and lots of it if we wanted to
make it co lour and do it right. Taj came to rescue, he convinced
his company to sponsor the complete costs - a princely sum of Rs.
Pradeepto Bhattacharya 83
40,000 - to get the book printed. Those booklets traveled to Jamaica,
Nigeria, Europe, Malaysia, Taiwan and many other places.
The booklet wasn’t the inflection point and Madhusudhan didn’t
just help me find volunteers for the project day. He also played the
crucial role of introducing me to a junior student from his college -
Shantanu Jha. That changed everything for KDE India and me. I
finally found the guy who was crazier and better than I could ever
dream of. It was the beginning of a great partnership for many years.
I probably haven’t trusted anyone as much in my life as Shantanu.
Knowing that I could delegate work to him and it would get done
was such a relief. With his help we kept organizing KDE Project
Days and other co-opted events at various conferences across India.
During this period, many contributors kept coming and going.
Shantanu followed the tradition of his mentors. He got more
friends to contribute to KDE - Sinny (whom Shantanu married later),
Sudhendhu. In March 2011, we organized the first conf.kde.in in Ban-
galore. A lot of sacrifices went into it by everyone. I don’t think it
would have been possible if anyone would have been missing in the
team. A lot of new faces met for the first time - Vishesh, Rohan,
Kunal, Smit etc. Since 2013, conf.kde.in has become an annual trav-
eling event. The event has traveled from Bangalore to Gandhinagar
to Kollam to Jaipur. After Bangalore in 2011, every year the event
has been organized in a smaller city or town and it has always been
organized in some university, a tradition that the Indian community
has learned from Akademy.
In this past decade many people have played a crucial role in
keeping the KDE Community up and running in India. Atul Chit-
nis, Kishore Bhargava, Tarique Sani, Swati Sani, Prashanth Udupa,
Atul Jha, Sujith, Abhishek Patil, Supreeth Vattam, Kamal, Anurag,
Aanjhan, Runa, Sankarshan, Kushal, Harish, Yash, Devaja, Akshay,
Ashish, Shivam, Sagar. The list is long but not complete. Over the
period of a decade, many KDE members from the US and Europe
have visited India during the events and graced us with their knowl-
edge and love. Adriaan de Groot, Sebastian Kügler, Lydia Pintscher,
84 Building KDE’s Community in India
Simon Hausmann, Frederik Gladhorn, Kenny Duffus, Jos Poortvliet
and others - you all are a part of the KDE India family.
A community always needs fresh and young blood to keep going
strong. Slowly but surely we see new members join the KDE India
community. The community is small but it keeps going on. Bhushan,
Boudhayan and others contribute to KDE and are role models for the
future generations of KDE contributors in India. The KDE family
is growing and I really hope it keeps going.
I have seen this community or should I say this family and its
journey first hand through my eyes and I have been a part of it. I
am extremely proud of it and I feel humbled that I have had the op-
portunity to meet such a great set of people from across my country
and the whole world. I feel I am really fortunate that I am a part of
this journey and this family.
18 A Revolution in Itself
Yash Shah
Yash Shah is an active contributor to KDE since 2011. He started
his journey with contributing to the speech recognition program Si-
mon through Google Summer of Code and then along with the KDE
India team, he organized two of the largest KDE conferences in In-
dia - KDE Meetup 2013 and conf.kde.in 2014. He loves evangelizing
KDE and motivating students to contribute to open source in differ-
ent colleges in India.
One of the largest international open source conferences was or-
ganized in India: The KDE Meetup 2013 and conf.kde.in 2014
at Dhirubhai Ambani Institute of Information and Communication
Technology (DA-IICT) in Gandhinagar, Gujarat. It was a platform
for the exchange of ideas and thoughts with speakers coming from
different cultures, leading to an advancement in the essence of open
source development and reliving the joys of contributing in KDE.
Both the events were a huge phenomenon in itself with the partici-
pation of over 350 students from the far ends of the country such as
Delhi, Durgapur, Mumbai and many more.
It was always my dream to host something at a scale like this in
Gujarat. People in our state were not aware of FOSS. With over
150 engineering colleges, there was a huge opportunity to introduce
them to the world of contributing to FOSS. When my colleagues
and I first started planning the event, we never imagined that we
would receive so much support from across India and from around the
world. We never thought in our wildest dreams that we might attract
an amazing group of developers and open source enthusiasts from
more than 9 states in India. Both conferences served for a perfect
environment for getting people to know about KDE and open source
86 A Revolution in Itself
software development in general. The expert KDE contributors flew
in from different parts of India, Europe and USA to talk about KDE
applications, introducing the audience to KDE and open source tools
and technologies and answer their questions.
One thing that we experienced is that international conferences
such as these serve as the perfect arena for students to get involved
with open source and to get themselves acquainted with the way
communities such as KDE function. These events are the perfect
opportunity to interact with these mentors and members who can
guide them along and also help them to participate in various coding
mentoring programs such as Google Summer of Code and Season of
KDE. Students get to collaborate with them and also build upon
their own ideas and create new projects of their own as a part of
KDE.
One of the major highlights of the event - the Bardoli incident - is
an inspiration and an indication of the dedication of the members of
the KDE Community to spread knowledge among all and to ensure
that everyone is a part of the community and that no one feels left
out. Many enthusiastic students from Bardoli sacrificed their week-
end time off and came from far away places and were prepared to
make the most of the event. Despite the long journey accompanied
by fatigue, they did their best to work along with the speakers but
somehow it did not work out for them and they decided to leave the
event. Pradeepto saw them leaving and he sat with all of them and
talked personally to each one of them. He convinced them to stay.
The next day, special sessions were organized just for them and all of
them showed up with renewed interest. They covered all that they
had missed in a short span of time and were eager to learn more.
Let me share an insight to the positive things people consumed
from the conference and how the talks changed their way of thinking.
This was a text from a delegates of conf.kde.in who traveled 700km
to attend it:
Nobody cares about the people, only wants gathering and
all. No one knows what were participants doing. But as
Yash Shah 87
we cared a lot by you and your team is really appreciated.
Thanks for my side behalf of all participant.
#kdemeetup One thing to learn.. Don’t be scared of
coding.1
At the end of the event there was a newfound inspiration in all
the participants who had the desire to contribute and to be a part
of the largest and friendliest community in the world. This was
a change, a different sort of exposure which the students received
which relieved them from the usual drudgery and boredom of college
education which does not expose them to real-world programming.
The event lived up to its aim - helping people know about KDE and
to provide them with the basic skills and techniques so that they can
contribute to open source. The community speakers were as warm
and amiable as they could be and the students were encouraged to
approach them and ask as many doubts as they could. This event
left the students asking for more. All that they had in their minds
was to learn and explore and innovate - create something which could
be the next revolution. It gives us motivation to hold such kind of
conferences at other places so that young students can benefit more
than ever and the culture of FOSS keeps thriving in this world.
1 https://mail.kde.org/pipermail/kde-india/2014-April/001236.html
19 Think Globally, Act Locally
Aleix Pol i Gonzàlez
Aleix Pol i Gonzàlez has been contributing to KDE since 2007. He
started working in software development in the KDE Education area
and on KDevelop. He was the president of KDE España from 2012
to 2016 as well as a founding member of the organization. Aleix
joined the KDE e.V. board of directors in 2014. In his day-job, he
is employed by BlueSystems where he has worked with other parts of
the community including Plasma and Qt.
In KDE we are very proud of being a diverse community. We strive
to make sure it is - it’s not easy. Albeit being an international com-
munity it wouldn’t take an anthropologist to look at the KDE Com-
munity and realize that although we are diverse we are not spread out
evenly across the globe. Instead, we have some defined demographics
around age, sex, studies and probably income as well. What I want to
discuss today is one of my longstanding focuses since I joined KDE:
local communities, or how to offer to my people what we create.
From a creator’s perspective, it is useful to turn around and look
at who we are dealing with. When it comes to a specific project,
one thinks of rather stereotypical people who might be interested in
IDEs or spreadsheets, but when we think about what we want to
offer as a whole, I can’t help but think of society in a whole different
way. The further away you push it, the clearer it is that it is not
about adding specific features, but about listening to what users need
and explaining how we can solve the problems they see; to be there
when they need assistance and to help them be secure rather than
adventurous.
We created KDE España to be able to sustain Akademy-es (the
KDE conference in Spain) initially, but over time it has evolved into
90 Think Globally, Act Locally
a platform with a much broader communication spectrum including
Akademy-es, a magnificent blog, podcasts, training materials and
conferences. This is also important because as soon as you start
communicating, people come to you when they feel unsure about
how to help. Furthermore, it helps us stay organized and alive.
Interestingly, one of the initiatives we have started from within
KDE España has been achieved by narrowing the geographical scope
even further. We created a group called Barcelona Free Software,
where we offer content from local free software experts and enthu-
siasts including but not limited to us. This allows people with dif-
ferent interests to those who would attend Akademy or Akademy-es,
to come and talk to us. The feedback we get at such gatherings is
interesting as it shows the kind of problems that our people ache
from and how they ask for solutions.
In the end, what this experience has reminded me of is that I am
here to make sure society can make the best use of the available
technology. Furthermore, in a society increasingly based on infor-
mation, we need to let it empower the user, the people. We need
to remember what the advantages of offering free software solutions
are beyond technologies, by remembering that the end goal is that
people have the tools they need to create better content in every
aspect of their lives, and that includes the possibility to adapt the
tools they use.
I think one of the most important motivational factors is to see
people being able to adopt the solutions you come up with, and
another even more motivational factor is when they use them to
create new things. For many of us, it is beyond the comfort zone or
even the ideal plan for a weekend but it is worth it to talk to people,
it is worth going to that local convention to talk about why and how
important it is to grow our society on free software and then gather
reasons why that is not the case yet. The response never ceases to
amaze me.
20 A User at the Court of KDE Developers
Baltasar Ortega
Teacher by profession, Baltasar Ortega is a user who knows nothing
about programming and who loves Free Software and the KDE Com-
munity. When he is not teaching in his school, he writes a popular
blog about the KDE Community and its work (kdeblog.com). He is
the secretary of and responsible for communication in KDE España.
This is the personal story of how a simple user has become a member
of the KDE Community and the daily struggle for the success of a
project you are passionate about.
This story is written to commemorate the 20 years of the KDE
project which I consider extremely important for the development of
software worldwide and in which I feel completely integrated. Some-
times I do not completely understand the language of the developers
with whom I communicate almost on a daily basis, which sometimes
makes me feel like an astronaut at the court of King Arthur.
It all started when, after many unsuccessful attempts and thanks
to the help of the free software communities forums, I managed to
configure a USB router to work with my newly installed GNU/Linux
distribution. I think it was an openSUSE 10 and came with the KDE
desktop. I simply gave my PC software that I thought is better. It
started from selfishness.
At that time I did not completely grasp the workings of the ecosys-
tem and its applications but I quickly realized that the KDE project
gave me what I wanted: a nice configurable desktop, free from mal-
ware, 100% translated into my language and with convenient appli-
cations like Konqueror, Kontact, Kate, Amarok, Digikam, etc.
However KDE Software was just something that was “created out
of nothing” and I used it without paying much attention to its origin.
92 A User at the Court of KDE Developers
Gradually I started to fall in love with KDE and eventually I
realized that everyone should enjoy their computer as much as I was
enjoying mine. Thus I was determined to help spreading the word
about GNU/Linux and the KDE project but did not know how. I did
not know how to code, I could not draw, I did not like to translate
and did not know how to package software.
I, as a teacher, knew only how to explain things... so I created a
blog about KDE: kdeblog.com, where I would try to help others get
started in this wonderful world of ours.
Thanks to the blog I started learning a lot about the world of Free
Software; making many mistakes along the way but always learning.
This is how discovered that events were held regularly and discovered
that there was a regional group for KDE: KDE España... then I
applied to become a member... then I was accepted, surprisingly to
me... then I decided to attend the annual meeting: Akademy-es 2010
in Bilbao. That meant traveling 600 km from where I live to an event
where I knew no one except for a few email exchanges. It was the
experience that definitely changed my view of Free Software.
They welcomed me as one of them and I discovered what KDE
really is about. There I discovered that behind each application,
each translation, each design on my computer there is a person who
made it possible. There I discovered that these people have great
ethical and moral values and there I discovered I wanted to be a part
of this gear.
Suddenly it was no longer only KDE Software; KDE was a project
of people making software for other people, respecting their freedoms
and privacy. That was a great discovery for me, I wanted to be an
active part of the KDE Community and help spread it.
I understood that the KDE Community consists of all kinds of
people, not just coders as one could have assumed, and that myself
as a user without any coding skills, could play an important role in
the development of Free Software.
The rest, as they say, is history.
In that year I became “a user at the court of KDE Developers”
working every day to promote Free Software from my particular
Baltasar Ortega 93
point of view, either on the blog, in social networks, by giving talks,
putting stickers on my computer, telling my students about the free
alternatives, collaborating with projects such as Wikipedia or Open-
StreetMaps, installing GNU/Linux on my friends’ computers, orga-
nizing local events such as the 15th anniversary of KDE party or
the Jornadas Libres de Vilareal - all without knowing how to write
a single line of code.
A thank you comment, being able to travel, learning languages,
learning new working methods and understanding that I am part of
a community that works for the good of humanity, all this has given
me great pleasure. But above all it has given me the opportunity to
meet extraordinary people who devote so much time to creating a
better world.
Finally, I want to thank all the people who have contributed, con-
tribute and will contribute with all their work and their effort to
keep the KDE Community active and thriving. It will always give
you back more than you contribute.
21 Why I Chose KDE, and Why KDE Is
Family
Valorie Zimmerman
Valorie Zimmerman has been using KDE software since the KDE 3
days. After meeting some KDE women in Linuxchix, she became ac-
tive in Amarok documentation, then the Community Working Group,
and also on the distribution level, the Kubuntu community. Valo-
rie also helped build the Student Programs team, participating in the
first Google Code-in for pre-college students, administering Season
of KDE and Google Summer of Code. Building community is what
it’s all about.
Around 2001, my son showed me two desktops, and asked me to
choose which one I wanted on my new install of Mandrake. I chose
blue, the pretty one, and so began my KDE journey. Back then, I
understood very little besides that I found KDE software to be not
just more beautiful, but also usable and configurable.
Before contributing to KDE, life was busy with kids and work.
Fortunately a friend introduced me to Linuxchix, so a friendly group
who helped out newcomers welcomed me in. I met people who con-
tributed all up and down the stack, including Windows users like me
who were considering a move to Linux. So Linuxchix was my way in
to KDE and Kubuntu.
Back in those KDE 3 days, KDE was still a bit controversial in
free software circles. Qt licensing concerned some people and the
KDE vs. GNOME rivalry seemed real and even upsetting to some
advocates of free, libre software.
If any group wants to grow, it must have ways in. For KDE,
I found IRC and mailing lists first. Many women on the internet
find the hostility and bad behavior discouraging enough to never
96 Why I Chose KDE, and Why KDE Is Family
find their way in. Fortunately I had the Linuxchix at my back,
and found KDE mostly welcoming. When I spoke up to volunteer,
people enthusiastically replied, and gave me good suggestions about
how to start. I found that every project needs better documentation!
Growing groups will do everything they can to help you get started.
I began in Amarok, which was such fun. After looking through
old docs, and considering the options, we decided to do the Amarok
Handbook on Userbase, KDE’s user wiki. Not realizing that this was
somewhat pioneering, we just plowed ahead, and used the old docs
to make new pages in Userbase. It was great to work with Amarok
developers, KDE documentation folks, along with the wonderful web
team that has been keeping the wikis so useful to us.
A word on volunteering. Early in my “KDE career” I volunteered
for the Community Working Group. Little did I know what I was
getting into! That said, tackling the difficult issues between develop-
ers has been rewarding, because peace is usually the result. At the
very worst, we know we tried our best to create a good situation out
of a bad one. So blithely heading towards the cliff-edge like The Fool
on the Tarot card, has been a good move. Getting to know people
deeply is wonderful. Being a part of the Community Working Group
has continually reminded me why KDE is family. Learning how to
listen better, how to “fight fair”, how to recognize issues as they are
forming, and then helping them go in good directions, have made
all of us involved better humans. I salute all the past, present and
future members of the team, and peace-makers all around the world.
When the first Google Code-In was announced, those of us on
the Amarok Handbook project immediately thought about all those
unwritten pages, and began creating tasks for students; one task
equaling one page. What a fantastic experience! It was wonderful to
interact with those kids (ages 12-18) and help them help us. Once
involved in Google Code-in, which was intense, exciting and produc-
tive, I was hooked on student programs in KDE. Looking back at
the students who have worked with us over the years, one can see
that student programs create the future of KDE. Our students begin
working with mentors and teams, and our goal is always to welcome
Valorie Zimmerman 97
them into the family of KDE. Many of our most successful initia-
tives are now being run by former students, and many of our most
effective mentors were once students themselves. Working with the
Student Programs team has been so satisfying.
One of the things I love best about KDE is that while we do the
inward-looking work, such as improving our processes, governance,
and social relationships, we are generally outward looking. We don’t
simply make software that pleases us, but follow our ideals when
working. I see developers write tests for their software even while
complaining about how boring it is, simply because they value qual-
ity. I see people step up to write stories for KDE’s official news site,
release announcements and blog posts even when they dislike writing,
because they want to share our work with the world. People comb
the code for spelling errors and other small issues, and quietly fix
them. Document writers do the same thing with the documentation
– fix errors, test the texts to be sure they are up-to-date, contribute
new screenshots – all quietly and often un-acknowledged. Our Vi-
sual Design Group created itself out of nothing, and quietly steps
in to help application teams, Plasma developers, and web-workers.
The Sysadmin team is tireless! They keep our infrastructure up,
humming along happily, and most important: securely. They create
new structures to help out the developers, and improve old ones. We
have folks working upstream in Qt, making, for instance, accessibility
Just Work for everyone. Our distributions are richer and healthier
with KDE involvement, along with many other FOSS projects in the
ecosystem that surrounds and supports us in turn.
All of this work affects all of us in KDE every day, but we may
not notice it unless there is a problem. The focus on freedom and
quality is now even moving onto platforms beyond Linux and BSD
in a major way. Even folks who don’t use Android, Mac or Windows
have generously contributed to support developers making our ap-
plications usable to an even wider population. This generous spirit
and welcoming attitude is what has kept me, a grandma, involved in
creating KDE as long as I am able.
22 Story of a Contributor
Bhushan Shah
Bhushan Shah is an active contributor from India, previously a stu-
dent of Information Technology, who started contributing to KDE
two years ago. He maintains the flashable images for Plasma Mobile
and is one of the administrators for KDE’s mentoring programs.
I am celebrating the two year anniversary of getting my developer
account. I started to contribute to KDE by sending minor patches
and eventually in 2013 I participated in Season of KDE, the outreach
program organized by KDE. Sebastian Kügler from the Plasma team
mentored me. This was a great experience. After that I enrolled
into Google Summer of Code twice as a student - this year I am
helping to administrate Google Summer of Code and other mentoring
programs for KDE. On the development side I currently work on
Plasma Mobile, the free software eco-system for mobile devices.
Mentoring programs
The KDE Community runs and participates in various mentoring
programs, for example Google Summer of Code, Google Code-in,
Season of KDE and the FOSS Outreach Program for Woman. As
I got into the KDE Community through one of this programs I am
currently passing the torch and mentoring other students and help-
ing to administrate these programs. One of the reason I feel good
about this is that it gives me a feeling of “giving back”. KDE as
community welcomed me and made me one of them when I was
eager to learn and contribute to the KDE Community. Now I am
helping others experience the same. New contributors help to create
100 Story of a Contributor
a more diverse community and keeps the fun in the community in-
tact. In my two years of experience with the KDE Community I’ve
come across various new contributors from various professional and
cultural backgrounds. This also helps the naive contributors to build
their skills with help from existing contributors of KDE.
When I started contributing to KDE I didn’t really have a lot
of skills. All I knew was I wanted to contribute to KDE. At that
time the Plasma team helped me to learn important aspects of pro-
gramming and the KDE codebase. The first patch that I submitted
had more then 20 issues to resolve. At that point I also learned
an important skill: dealing with feedback effectively. Eventually I
learned more skills and started to contribute to more advanced parts
of the KDE Plasma Workspaces. For this I thank my mentors, Se-
bastian Kügler, Shantanu Tushar, Sinny Kumari, Marco Martin and
the KDE Community as whole.
Plasma Mobile
The Plasma Mobile project’s first prototype was revealed at Akademy
2015 by Sebastian Kügler and Boudewijn Rempt on behalf of the
Plasma team. The Plasma Mobile project has the following vision:
Plasma Mobile aims to become a complete software sys-
tem for mobile devices. It is designed to give privacy-
aware users back the full-control over their information
and communication. Plasma Mobile takes a pragmatic
approach and is inclusive to 3rd party software, allow-
ing the user to choose which applications and services to
use. It provides a seamless experience across multiple de-
vices. Plasma Mobile implements open standards and it
is developed in a transparent process that is open for the
community to participate in.
Which in my opinion plays really well with the vision of KDE:
Bhushan Shah 101
A world in which everyone has control over their digital
life and enjoys freedom and privacy.
From the start I was very excited about this project. Despite being
a new project, the KDE Community already has experience work-
ing with non-desktop devices through the Plasma Active project.
Currently I am working on building flashable images with Plasma
Mobile. I believe Plasma Mobile is an important contribution to
the Free Software movement, and I am glad to be a part of it.
I want to thank the whole KDE Community, every user, developer,
artist, translator, ... You are the ones who makes it possible to dream
of Konqi ruling the world. ;-)
23 The Motivation behind Contributing to
KDE
Sanjiban Bairagya
Sanjiban Bairagya studied Information Technology at the National
Institute of Technology, Durgapur, India. He currently works as a
Software Engineer at Magicpin. He made his first contribution to
KDE in 2013 and did a Google Summer of Code project with KDE’s
Marble team in 2014.
About 20 years ago, Matthias Ettrich proposed the creation of an
easy-to-use desktop environment in which users could expect things
to look, feel, and work consistently, something which was lacking in
the Unix desktop at the time. This was the initial motivation that
led to the birth of the KDE project, after a lot of people started
showing interest in the idea. Initially the K in KDE was supposed
to be termed as “Kool”, but very soon it was decided that K should
not stand for anything in particular, just call it “K Desktop En-
vironment”. I was introduced to KDE during my second year of
college by some of my seniors around 4 years ago in 2012. That’s
when I installed Fedora with KDE, as my first Linux-based setup.
At the time I looked at it as just a cool desktop having so many
fun applications and widgets to use and play around with. In the
beginning, I never gave a thought that I could be a part of building
these applications. It was only towards the beginning of the follow-
ing year that I thought of starting to contribute to its applications
by coding. I used to use Marble, a virtual globe software, more than
the others, so I started with that. At the time Marble had a pretty
basic UI, with some new features just introduced that year, like the
stars showing realistic colors and constellations, and draggable pan-
els replacing the tab-based controls. The git reviewboard was the
104 The Motivation behind Contributing to KDE
place to upload your patches at the time. And overall KDE was
focused almost entirely on creating desktop applications. But more
than the applications, its the welcoming community that encouraged
me to keep continuing. The first time I had pinged Dennis, one of
the main Marble developers, about contributing to Marble, in the
#marble channel was in Jan 2013. If the conversation wouldn’t have
proceeded in such a welcoming way in which it did, I don’t think I
would have been encouraged to go any further. But that was just
the beginning. And KDE has really evolved a lot since then.
KDE has gradually evolved itself from being a desktop environ-
ment, to now being part of almost every aspect of life that can be
touched in terms of technology. The KDE Community has apps on
Android now as well - KDE Connect and Marble Maps to name a
few. KDE via Plasma Mobile even offers a free platform for mobile
devices today, with a prototype already available. KDE Frameworks
has come a long way, with its recent KF5 release. We even have a
new place to upload our patches for review now, Phabricator, making
it much easier to track their progress. Not only in terms of technol-
ogy, the community has also become more diverse and vibrant now
with more people contributing and participating in sprints and con-
ferences from all across the globe. Not to mention, we have united
our vision as well: “A world in which everyone has control over their
digital life and enjoys freedom and privacy”. And that is true indeed.
It has been 4 years already that I have been using KDE software.
Mostly because it undoubtedly does produce the best and most user-
friendly products that free software has to offer. In fact, I grew so
fond of it when I was in college, that we had even organized an event
titled “Contributing to KDE” in the seminar room there, which was
a grand success as well. And it did not stop there. Even now in the
office, I installed Kubuntu on my laptop and after seeing me, some
of my colleagues have switched to using Plasma and other KDE soft-
ware as well. As a user and developer of KDE software, I feel it is
my duty to spread the information as much as possible, and I have
been doing just that. KDE gave me wings. The wings to know the
world so much more, and be able to spend time in working with the
Sanjiban Bairagya 105
most humble, knowledgeable, and welcoming people that can exist
on planet Earth.
Now, looking at what the future of the KDE Community might
turn out to be in a few more years from now, I think we should
already acknowledge the fact that it is already the second largest Free
Software community in the world right now (behind the Linux kernel
community), and its numbers speaks for itself about the amount of
freedom and friendliness that exists in the community. The rate at
which KDE has progressed that I have seen in the last 3 years, there
is no doubt but to know that there is no downhill from here. Having
a conversation with the folks at KDE, you feel more closer to home
than anywhere else, no matter which part of the world you come
from. KDE has been among the leaders in desktop, and soon, with
more people spending time on their phones than their desktops, it
has entered the mobile platform as well. With the release of Plasma
Mobile in full, people should be able to see a new world of KDE in the
future as it keeps on developing. It’s been 20 years since KDE was
born, and if I imagine how it might be 20 years ahead from now, I
can only see unparalleled progress. What could come next? Artificial
Intelligence? Virtual Reality? Well, with its current rate of progress,
along with its drive to fulfill its vision of everyone having control
over their digital life, who knows, maybe it is evident that KDE
will definitely keep spreading to the newest and latest technologies
that will become a part of life for everyone in the future. As for us
developers, what drives us to keep contributing is the very realization
that our code touches so many lives and makes a difference. Coming
back from a tiring day at the office, I think that contributing to
free software you love to use is a very productive way to spend your
free time. It can be any free software, I choose KDE because of its
community of people with its free and open culture.
24 My Journey from Documentation to
Continuous Integration
Scarlett Clark
Scarlett Clark has been an open source user since 1999 (Stacks of
floppies!). Her first contributions began three years ago in KDE
PIM documentation. She is now working on container packaging
solutions, KDE continuous integration and a dash of Debian based
packaging as time permits.
My journey started over three years ago with an email to the KDE
documentation list asking a simple question, “How can I help?”. Lit-
tle did I know the adventures that would transpire from that email! I
was quickly pointed to the KDE PIM team to assist them with some
documentation. My first task was a massive rewrite of the KMail
documentation, as it was very dated and in the worst shape. This
progressed for some time, until I had to step down to resolve some
health issues. Upon my return, I had briefly discussed with Valorie
Zimmerman and Jonathan Riddell about helping out Kubuntu with
some documentation as well. Thus begins a new adventure.
The next leg of my journey was Kubuntu. I was working on a bit
of Wiki documentation, when Jonathan asked in IRC if anyone was
interested in learning packaging. Me being the curious sort that I am,
raised my virtual hand. This began a rather long journey into soft-
ware packaging. It is an exciting facet of software, because you need
to make everything work together and it is not always as straight
forward as one would think. After some time of my packaging ad-
venture, I was invited to my first Akademy! This was an amazing
experience for someone rather new to Open Source contributions. It
not only fueled me to further myself into contributing more, it got
me closer to the people I have been working with online. It put faces
108 My Journey from Documentation to Continuous Integration
to the IRC nicks! This I feel made a big difference in future online
communications, as now personalities are known. Text does not re-
ally do justice to personalities and can be quite misunderstood. So
now armed with a pile of new friends, I begin my next adventure
into Season of KDE.
I had no knowledge of Season of KDE until Valorie had asked
me if I would be interested in DevOps type work. She then linked
the Season of KDE project to me, my thirst for knowledge trig-
gered, thus beginning the next leg of my adventure. After getting
approved for the project by Ben Cooksley (KDE’s main sysadmin),
I started on the revamp of build.kde.org. It began as quite a large
learning curve, but as the pieces came together, it got easier. I suc-
cessfully completed my Season of KDE project and launched my new
build.kde.org automating job creation with groovy DSL. Seeing your
creation go live for public consumption is an amazing feeling! With
my packaging work and Season of KDE project, I was once again
invited to Akademy. This Akademy was very special as I won an
Akademy award1 ! The jury award to be exact, it was truly exciting
to be recognized for all of the work I had put into the CI. The CI
system is still a continuing work in progress. We have since moved to
using docker containers for our builds. I have recently recruited some
help to push forward the other platforms (Windows, Android, and
OS X). With new knowledge and experience under my belt, I have
rewritten the DSL once again to be much cleaner and extendable.
So look forward to much more in the land of build.kde.org!
1 award given out annually at Akademy to KDE contributors
25 A Place to Stay Forever
Sinny Kumari
Sinny Kumari joined the KDE family during late 2010. She worked
mainly on Plasma Media Center and parts of Plasma. She loves
talking about the KDE Community and its software. Other than
that, she works toward motivating others to work on Open Source
projects. In the daytime, she is a Software Engineer at Red Hat
where she helps in maintaining Fedora and RHEL for PowerPC and
s390x architectures.
It was late 2010 when I slowly started getting familiar with a new
operating system called Linux which had the KDE Desktop envi-
ronment with it. First, I started as a user and then slowly pushed
myself to fix bugs. The first time I interacted with the community
was by sending a patch for the File Watcher widget. As a beginner
working on fixing the patch was not very easy. It required me to
first download the source code and build Plasma and all required de-
pendencies. Later, I had to find the right place where the fix should
go and then re-compile the affected application and see whether the
changes I made are working. Even though the changes I made were
really small the experience I gained was not. It was an amazing
feeling and experience to work with such a large community who de-
velops loads of amazing software. I realized how different and fun it
is to work on software which is used by millions of people compared
to the way I was studying in college. This lead me to stick around
the KDE Community even further.
My journey in KDE continued further as a volunteer for conf.kde.in
2011 in Bangalore, India. It was the first KDE conference happening
in India and also the first KDE conference I attended. Thanks to
Shantanu and Pradeepto who gave me a chance to be part of organiz-
ing it. It was fun to spread the news among colleges and explain to
110 A Place to Stay Forever
them why they should attend this conference. Lots of people came
to attend it including college professors, working professionals but
mainly students. I believe this conference opened the gates for a lot
of students from India to contribute to KDE. For me, it was the first
time I met people in-person from around the world and felt how awe-
some this community is. It increased my bond to KDE even further
and felt like I am part of the KDE family.
With great enthusiasm, I planned to stay even longer here and
contribute to KDE. As a result, I started getting into different KDE
projects which interest me. I figured out that projects around Plasma
(KDE’s workspace) interest me more. Meanwhile, the Google Sum-
mer of Code period was also about to start, hence I applied to Plasma
Media Center - the project that has always stayed close to my heart.
Plasma Media center is a KDE application which aims to provide
an easy media experience (music, pictures, videos) to people on a
device running KDE Plasma. It supports browsing and viewing me-
dia local to your system as well as available from online services like
YouTube, Flickr etc. Many thanks to Marco Martin who mentored
me to get this project in good shape. While writing this, I recall how
different family members from KDE participated to shape this pro-
ject even better and helped it to mature - in terms of code, design,
spreading the news, packaging, motivating and so on. I remember
writing blog posts and articles for KDE’s official news site about
Plasma Media Center releases and how happy people were to see it
growing from desktop to tablets and extending to TV. KDE love is
always about spreading it to more people. Later on in KDE India
conferences and meetups, we used to talk about and give demos of
Plasma Media Center to attendees. We explained how to create an
awesome UI application like Plasma Media Center using Qt/KDE.
Attendees used to love this application and liked to contribute to
it. As a result, we were able to pull in even more people to work
and continue evolving Plasma Media Center further along to a long
journey. With continuous effort of loads of people, Plasma Media
Center’s codebase matured from Playground (the place where new
KDE software starts its life) to Extragear (where mature software
Sinny Kumari 111
lives that is not part of the main release cycle), and then to the main
release cycle. The journey of this project’s success was not easy but
not impossible either. It reached this maturity level only because of
love from different people in the KDE Community. Sadly, these days
due to job and other responsibilities I don’t have time to work on it.
But I am positive that it will keep getting love in the future from my
other KDE family members.
Life keeps moving on further and so does love towards the KDE
Community and its software. In order to maintain, improve and
have new software in KDE, it is important that together we keep
on expanding our family while keeping everyone involved. This
friendly and loving nature of community members will always keep
new/existing contributors feel welcomed and homely while working
on KDE projects.
26 A Learning Paradise
David Narváez
David Narváez is a PhD student in Computer Science at RIT in
Rochester, NY, USA. Originally from Panama, he is the current
maintainer of Kig, an application for interactive geometry that is
part of the KDE Education Project.
I joined the KDE Community back in 2009 to fix a couple of bugs
and never left. I was one to scratch my own itch in any application
I would use frequently: from Kig, which was my main interest, to
KDevelop which I used to work on Kig, to Plasma because I was
using it to manage my desktop environment. KDE was certainly
not the only FOSS community I contributed code to, but no other
community was as enticing as KDE. At the beginning, I could not
really point the finger at what the reason for this was.
At the same time I was learning the trade as a professional software
engineer (which, in my culture is nothing but a name for a glorified
computer programmer) back in Panama, my home country. At the
peak of my contributions to KDE, I had a full time job as a software
engineer, coding several hours a day, only to come home and code
several more hours working on KDE-related stuff. Many would say
I spent my entire day coding, but for me these were two completely
different activities.
I eventually realized that the differentiating factor was learning.
KDE was much more than a developer community for me: it was a
learning environment. My daytime job, on the other hand, did not
foster innovation and learning. This was not a problem particular
to my employer at the time, but a more general issue about the
culture among software developers in my home country. While I
understand not everybody is as excited about learning as I am, I can
114 A Learning Paradise
objectively argue that KDE, as a learning community, prepared me
better for a global market and gave me a better chance at several
other opportunities that came by later in life. Here I describe some
of the core values I found in KDE that I could not have found inside
the software developer market in my home country:
• In KDE we have a horizontal structure promoting code review,
open design discussions, collaborative coding, etc. In contrast,
my daytime job at the time had a vertical structure where
fixing bugs in somebody else’s code was considered an offense,
and trying new technologies was never an option during design
discussions.
• Proposing the adoption of new ideas and paradigms in my
workplace would almost always meet the mantra of “we have
always done it this way”. In contrast, I joined the KDE Com-
munity as a developer just a couple of years after KDE adopted
a whole new approach to desktop environments through KDE
4.
• KDE is, by definition, a global community. As such, you will
always deal with not only different time zones, but also different
cultures. I vividly remember waking up at five in the morning
to read code reviews from people at 7 time zones away, and
improve my code based on their feedback before leaving for my
paid work. Right around those years, the software development
market in my home country was starting to globalize, and as
a consequence, people started thinking about different time
zones. When it was my turn to deal with these issues, it felt
like home because of my KDE experience.
• From the merely technical point of view, the various software
architectures used across KDE projects made it possible for me
to explore paradigms and designs that were not popular inside
the market in Panama. My exposure to these ideas turned some
of the more challenging tasks of my day job into straightforward
David Narváez 115
adaptations of problems that had already been solved inside the
KDE Community.
I am convinced it is because of all these values we have forged as a
community inside KDE that I was able to pursue many opportunities
that would have been way out of my reach had I been equipped only
with the knowledge I could acquire in the local market. But Panama
is not the only country in the world where the digital divide is keeping
developers with great potential from acquiring all the knowledge they
need to be competitive in the global market. In fact, most of the
skills and experience that are highly valued in the IT market (think
of fluent English, or early exposure to computers) are native to a
small fraction of the planet which we usually refer to as the first
world. In the age of information, communities like KDE play the
role of forges of global talent that will enable important changes in
our digital lives. And although my personal journey in KDE has
improved my IT skills, the global talent we attract as a community
does not necessarily need to be programmers: some of our most active
contributors work on designs, translations, technical writing and even
marketing; all of which are areas with their own global markets and
needs. What is in it for all of us, is that our participation in the
community also brings along experiences that are stepping stones in
our paths to achieve personal goals.
Today, I have moved away from the industry and into research,
doing doctoral studies. This move has meant leaving my home coun-
try, adapting to new places and having less time to contribute code
to Free Software in general. Yet, KDE is still an important part of
what I do and, as such, I care about its future. Since I consider the
KDE Community an enabler of opportunities, I see our products as
means to a greater goal that is helping the world through innovation.
This point of view is what drives me every time I contribute to KDE,
because it is as exciting to think about where I can take KDE as it
is to think about where KDE can take us. Thus, it is my first and
foremost priority, looking into the future, to preserve this nature of
our community. I believe this, and not the technology we produce,
116 A Learning Paradise
is the key to staying relevant for the next 20 years. In this context,
outreach and mentoring naturally translates to more opportunities
as more people get involved, and I cannot think of a better excuse
to strive for world domination :)
27 The Circle of Four Steps to Become a
Good Developer
Sune Vuorela
Sune Vuorela is a software developer who has been around KDE and
other open source projects for more than a decade. Sune works as a
software consultant doing Qt and C++ and whatever else is needed,
mostly in areas of logistics or medical technologies. When not in
front of a computer, Sune enjoys cooking, reading books, and being
outdoors. Either alone, or with the scouts.
KDE recently formulated a vision:
A world in which everyone has control over their digital
life and enjoys freedom and privacy.
Free software is a important step for that vision, and that has been
how KDE has done its things since forever. But for free software to
matter, people also need to be able to take advantage of the freedom
they are given. Having more and better developers is needed for
that. Partially to be able to understand code, partially to be able
to write readable code. Both plays into being a good developer, and
especially for newcomers asking how to become a good developer is
a frequent question.
When I have the time and am in a joyful mood, my answer has
been “Just follow Sune’s four steps”, partly serious, partly tongue in
cheek, because they aren’t actually formally described anywhere.
This is an attempt to write it up and how they are applied within
various KDE projects as a part of KDE producing many new skilled
developers.
The four circular steps to become a good developer are:
118 The Circle of Four Steps to Become a Good Developer
• Read some theory
• Write some code
• Read other people’s code
• Have other people read your code
These steps can be applied in any order, but to become a good
developer it is important to visit all steps frequently.
Read some theory
Extending your base of knowledge is an important thing to always
be doing. Depending on your area of expertise and interests, it can
be anything from reading about what a for-loop is, to the newest
upcoming meta programming features in the upcoming standard of
C++, the theory behind the Java Virtual Machine or how to do
basic OpenGL for games. A simple, but important theory document
originating from KDE is the document about binary compatibility
in C++ libraries1 .
The theory can just be an introduction to new design patterns or
a starter guide in a new programming language. But read. Learn.
Try. Which leads me straight to the next point about writing code.
Write some code
No one ever becomes a good developer without practical coding expe-
rience, or as they says it at the scouts, “Learning by Doing”. Not all
code should be production quality or actually meet the public eye,
but do publish as much as possible. It helps you and others with
many of the other steps. Write code for fun. For experimentation.
And for actual real life use cases. Have experimentation projects
1 https://community.kde.org/Policies/Binary_Compatibility_Issues_
With_C++
Sune Vuorela 119
both in your primary programming languages as well as other pro-
gramming languages. Maybe the other programming languages have
features you like that are coming soon to your primary programming
languages. This points nicely back to reading some theory.
KDE offers a quite fast “code to production” path with a large
userbase that helps keep up the motivation for actually writing code.
In order to be able to write better code, getting experience with other
people’s code and improving other people’s code is a really good way
to become a better developer. And this points again forward to the
next point about reading code.
Read other people’s code
A part of being able to know what good code is is to see good code,
as well as bad code. Especially in various open source projects, it is
very easy to get a hold of other people’s code.
Reading other people’s code leads directly to writing better code,
as well as pointing to interesting areas for studying more theory.
The code reading can both be in private behind closed doors, or as
part of public/formal code reviews, where you can discuss the code
and suggest improvements.
By reading other people’s code, one learns a lot by example about
what to do and what not to do, and usually it ends up supporting the
theory one has read. A simple thing like the importance of proper
variable and function naming becomes much more clear once one has
tried reading both code where the original author(s) had cared for
that kind of details, and reading code where all variable names are
single letter ones. Once you have tried reading both, you know how
it actually helps.
KDE has only open source code, so it is easily available for any-
one to learn from, and several KDE projects also have optional or
mandatory code reviews for all new code, where everyone can jump
in and participate in the code review to let both the reviewer and
the author learn from each other.
120 The Circle of Four Steps to Become a Good Developer
Have other people read your code
You need to know when you have done well and where you have
room for improvements. When contributing to existing projects, the
current developers usually review your code and help you raise the
quality if needed.
KDE is full of people who do what they do for fun, and put a lot
of work into ensuring that whatever code they have is maintainable.
Reviewing incoming code is important for this. This also gives a
unique opportunity to discuss your possible code changes with the
original authors of whatever piece of code you are contributing to.
KDE has several systems in place for that. New projects have
to go through an initial review to ensure that the basics are sane,
and many subprojects either have optional or mandatory code review
where experienced developers have to sign off on new code for existing
projects.
End notes
These four steps are crucial to continuously educate both new and
existing developers. Most people want to get better at what they
like doing, and this approach really helps. There is no requirement
to spend an equal amount of time and energy on all steps, but all
steps should be revisited. Also, make sure to occasionally get out of
your comfort zone to learn something new.
Interacting with others around your code is important, and work-
ing with an existing code base is often better to learn from, in both
good and bad ways, than starting all projects from scratch. KDE
with its 20 years of history has an amazing code base and an amaz-
ing set of experienced and new people always helping each other in
making everyone better.
28 How We Make Plasma
Sebastian Kügler
Sebastian Kügler is a core developer at KDE and Free Software ac-
tivist. Being involved in the creation of the Plasma desktop from
the beginning, Sebastian lead the development of its recent version,
Plasma 5 as part of his job as Chief of Operations at Blue Systems.
Sebastian has been release manager throughout the KDE 4 series and
initiated KDE’s Marketing Working Group. He was part of the KDE
e.V.’s Board of Directors from 2006 to 2013. On the technical side,
sebas’ develops and maintains several of KDE Plasma’s key compo-
nents.
The KDE project originated from the wish to create a consistent
workspace environment that made Linux devices accessible to normal
users by offering a graphical interface. Since its inception, 20 years
ago, the KDE Desktop, nowadays called “Plasma” surpassed this
initial goal and today offers one of the most popular workspace user
interfaces. In many aspects, it represents the state of the art of
computing.
In this article, we are going to have a closer look at various aspects
of Plasma, its evolution, how it is used and developed, and why it
exists in the first place.
The User Story
A desktop is the primary user interface of a computer, it allows to
start apps, switch between windows and offers access to configure
system-level functions, such as hardware support and the general
behavior of the desktop and software. 20 years ago, KDE was the
first of its kind, X11 was still pretty young, and consistency a concept
122 How We Make Plasma
almost unheard of on Linux systems. Developers looked at competi-
tors like SUN Microsystem’s CDE, and wanted to offer a modern
replacement as Freedom software.
KDE 1 released relatively quickly, given the gargantuan task, and
laid the base for many further development. Looking through the
code-base, we still often encounter code written 20 years back. To-
day, millions of users around the world rely on Plasma on a daily
basis. It is the tool that makes their computer useful. While many
users do not particularly care (and that’s a good thing: Plasma
should be a tool that helps you to get the job done), there is also
a large number of people who deeply care, who follow every change
developers make and who install new versions with excitement and
anticipation.
To many users, Plasma enables them to do what they want, how
they want. Plasma’s flexibility and configurability is unparalleled,
even in proprietary software. Users demand to be met with respect,
and do not want to be limited, but rather enabled by the software
they use.
Plasma has become a professional tool, today it is used in large
enterprises, schools, governmental organizations at different levels.
Not long ago, it was even spotted in the control room of the Large
Hadron Collider, the biggest and most complex machine in the world.
Development model
Plasma is developed at a rapid pace. 4 yearly feature releases are
followed up by a number of stabilization and translation updates.
Plasma is developed in a collaborative fashion, based on consensus.
There is no single person that decides about features and priorities,
but rather a team of maintainers that take decision based on user
feedback, consensus and the available resources. Mailing lists, IRC
chats and weekly video conferences keep communication channels
tight and make sure that problems can be addressed in a timely
manner.
Sebastian Kügler 123
This quick succession of releases and cycles is made possible by
a huge amount of technology in the background. Every change a
developer commits leads to automated builds in different configu-
rations and unit-testing. Feedback about mistakes in the code is
automated to ensure a higher quality and less interruption in opera-
tion and development. Users who want to follow development closely
and help testing can nowadays even get their fix daily in the form
of daily updated packages directly from Plasma’s git master. Con-
tinuous building and integration makes rapid development possible.
Modern tools like git and Phabricator foster developer collaboration,
and there is a strong culture of code reviews in the Plasma team.
Quality has become a central part of the goal of Plasma’s develop-
ment model. A code-base as complex as Plasma and its underlying
stack is hard to “get right”. Quality problems usually stem from a
relatively complex task to solve: users will run Plasma on random
hardware, drivers vary in quality. Plasma sits on top of a modular,
but complex software stack that is also moving rapidly. It is not
always easy to catch up with changes in underlying systems, such as
Qt, D-Bus, the graphics stack, the Linux kernel and its close rela-
tives.
Methods and Tools
The Plasma team has adopted several modern software engineering
practices. Back in the days, the user interface of the KDE Desktop
was often designed by the same people who wrote the software. It
often simply reflected what the code could do. Nowadays, a team of
designers has a say in almost every user-visible change, and larger
changes are carefully planned in advance keeping in mind how it
solves the user’s problem and how it fits into the whole of the soft-
ware environment. On the software development side, test-driven
development is making inroads into KDE’s and Plasma’s develop-
ment processes. While it is not possible to automatically test every
single function call and behavioral expectation, more and more code
is covered by a battery of tests that are run regularly. This avoids
124 How We Make Plasma
unintended breakage and speeds up the development by reducing the
need for tedious, time-consuming manual testing.
Both, product and project decisions are being taken by the core
team of developers, in consensus with a group of designers, other de-
velopers and based on user needs. Product-level decisions are more
and more influenced by product-level thinking, although this is a
process which is only being adopted within the past years. Devel-
opment happens openly, the central discussion forum is the plasma-
devel mailing list. A new project management tool has been adopted
in 2015, the Plasma team now uses Phabricator, a web-based collab-
oration platform to structure tasks, review code and discuss changes
in general. Phabricator’s git integration presents a clear and logi-
cal workflow to get changes developed, reviewed and merged. Issue
tracking is done in KDE’s Bugzilla instance. Most developers have
a love and hate relationship to Bugzilla, as it can feel a bit like han-
dling a monster. Practically, however, Bugzilla’s usefulness is pretty
much unparalleled. It is a proven tool for software quality assur-
ance that has lead to many users receiving fixes for their problem.
bugs.kde.org provides a powerful and well-used feedback mechanism,
and forms an essential part of the development process.
In the past, KDE software was built by engineers, for engineers
and user interface design was not always a strong point. Now, user
experience experts and interaction designers have become important
contributors all over Plasma. Instead of a top-down approach on
design and functionality, the user experience experts are embedded
in the development process at a deeper level. The development of
Plasma 5 has seen an increased focus also on visual quality, it has re-
fined and redefined its design language, without sacrificing flexibility,
functionality or negatively impacting technical architecture.
Nowadays, technical quality, visual coherence and smooth interac-
tion design have become equally important. Plasma does not baby,
but empower the user to get the work done.
Sebastian Kügler 125
The Technology Story
Frameworks, QtQuick and Plasma 5
In its first three iterations, kdelibs, a monolithic library on top of Qt
which shared functionality and code across KDE applications and
the desktop. In its first iterations, KDE was technically a more or
less monolithic thing. While it was very powerful from the get-go,
it grew organically and eventually became a big and interdependent
platform on top of Qt. Your editor remembers discussions about the
scalability limits with this approach already back in 2005. KDE 4
took the first step into a more modular world by coarsely splitting
kdelibs into topical libraries. Internally, there were rather big sec-
tions of entangled functionality, however. These were finely split up
in the development cycle of the fifth iteration of “kdelibs”, and first
released separately as a consistent set of modules offering more than
50 individual frameworks with a clearly defined dependency struc-
ture and backwards compatible future releases in quick cycles with
tight quality control. Frameworks 5 has worked out very well from
a technology point of view and covers a very wide range of needs.
Thanks to its modular structure it allows the creation of leaner apps
that are smaller in footprint, easier to deploy and load faster.
Devices
In the Plasma 4 cycle, we have seen the first user interface built for
non-desktop devices. An experimental phone UI built with Plasma
technology successfully held a phone call as early as 2010. Plasma
5 has been designed for deployment on different devices. Plasma
today will on most machines load a desktop UI module and compo-
nents suitable for use with a mouse, touchpad and keyboard. Indeed,
the highest priority for Plasma’s fifth iteration was to build up the
desktop that is functionally equivalent with previous releases, us-
ing Frameworks 5. In the same release, the move to QtQuick for
the user interface components of the workspace has been completed.
126 How We Make Plasma
This architecture allows sharing components across devices at multi-
ple levels, and a high degree of code-reuse. It allows to improve the
user experience across devices, and in combination a consistent-to-
use cross-device experience. The Plasma Phone project, for example,
shares roughly 90% of the code with the desktop, without sacrificing
usability. Reversely, Plasma technology allows to develop applica-
tions that work not just on one device, but across a range of devices,
adapting its user interface to the hardware used.
Graphics and Wayland
Looking down the graphics stack, we have finally reached a point
where we usually render the entire user interface using hardware ac-
celeration on the graphics card. Smoother graphical effects, better
energy efficiency and more CPU resources being available to the ap-
plications all make for rather user-visible improvements. Not all is
rosy in the graphics world however, and driver problems hurt many
users. At the same time, KDE’s user base enjoys an incredible variety
in hardware and setups. Some run it on a small laptops, others on
powerful multi-core machines connected to a video wall – all expect
Plasma to handle the job gracefully. Aside from the workspace, a
component that has seen serious modernization over the past years is
Kwin, Plasma’s window manager and compositor. Pluggable hard-
ware and rendering backends, exchangeable user interface elements
such as task switchers make Kwin a very versatile window manager.
Over the past years, Kwin has gained support for running as a Way-
land compositor. It now provides both modes, running on top of
an X11 server or starting its own Wayland compositor that provides
the graphics rendering and input for applications. A Wayland ses-
sion uses a much leaner graphics stack, protocols which guarantee
pixel perfection by using more modern and more clearly defined se-
mantics. Kwin’s Wayland mode is in fact already used in Plasma
Mobile’s phone user interface, and is being readied for desktop end
users this year.
Sebastian Kügler 127
Developing and maintaining a codebase such as Plasma’s is not
an easy job, but having the architectural work on modularization
behind us, these areas will improve over time as we get more and
more fixes into our codebase, upstream and downstream.
Roadmap Story
For the next years, there are no major architectural changes planned
for Plasma – other than making Plasma available on Wayland. This
means that the focus shifts more to user-visible changes, bugfixing,
polishing and performance improvements. Additional features can
be added without affecting the core thanks to Plasma’s modular
structure.
Developers want to make Plasma a serious contender for profes-
sional use-cases. This means that stability and quality shifts into
focus. Indeed, the primary focus of the current development cycle is
bugfixing and quality improvements.
In devices-land, Plasma has yet to make inroads. Developers con-
tinue to improve the mobile shell and related technology. In the long-
run, Plasma could stick to the desktop, which is becoming more and
more of a niche market, so it will lead to less relevance overall. The
strategy to make Plasma as a technology and as a workspace avail-
able also on non-desktop devices will at some point prove essential
to the survival of Plasma. Already today, the mobile efforts supple-
ment the desktop by improving performance, footprint and give the
codebase much wider testing.
Your editor once said himself: “I want Plasma to help me get my
work done so I can go diving”: Plasma is not a purpose in itself, but
a tool that allows using other tools (your computer, applications)
efficiently. It should get out of the way as much as possible, but
when needed it should be there and have the right tools available at
your fingertips. It should do all this gracefully and elegantly, and
give a feel of quality and that I am really using the best tool for
this job. Users come for the features and the look, and they stay for
128 How We Make Plasma
the freedom and privacy aspects. Plasma shows excellence in both
areas.
29 Evolution of Windowing Systems
Martin Gräßlin
Martin Gräßlin is a KDE developer since 2008 with the primary
focus on KWin, the window manager and compositor of the KDE
Plasma workspaces. He is employed by BlueSystems GmbH to work
on KWin and Plasma.
When Matthias Ettrich announced the Kool Desktop Environment it
was intended for Linux/Unix and by that also for the X11 Windowing
System. At that time it was the only available windowing system
for Unix-like systems. Matthias didn’t want to write a dedicated
window manager for this system. He thought that “at the beginning,
the KDE panel will work as an Fvwm-Module”.
Nowadays KWin, the window manager started by Matthias for
KDE 2 in 1999, is one of the oldest components in the KDE Plasma
workspaces and the largest single code base of Plasma. It is one of
the pillars of Plasma and an extremely important part of the user
experience of Plasma. KWin, unlike many other components from
KDE 2, survived several technology transitions. The biggest threat
to the existence of KWin was the time before KDE 4 was released. A
disruption on the desktop happened: Compiz! Finally there was the
chance to unify the desktop world and have just one major window
manager.
Compiz was a huge change. It made use of “compositing” di-
rectly in the window manager. Compositing is a kind of hack added
to the X windowing system to make it possible to have translucent
windows. The extensions allow interested applications to get noti-
fied when a window changes its content (damage extension) and to
redirect the windows from rendering directly to the X-Server to a
pixmap (composite extension). A compositor can now take all the
130 Evolution of Windowing Systems
windows pixmaps and render them as the final image, making use of
translucency, arranging them in different ways and applying smooth
transitions. One of the core parts of the XServer got replaced by two
extensions and an additional application. It was a sign of defeat in
retrospection. The X developers decided to hand over responsibility
to other applications because the XServer was not able to deliver the
required features.
In the beginning there was only xcompmgr and various forks (in-
cluding one by KDE) - an additional process adding translucency,
drop shadows and simple animations, not integrated in any way with
the window manager. Compiz changed that significantly. A win-
dow manager built around the idea of compositing, making use of
OpenGL for all rendering. It demonstrated functionality which just
was not possible on other systems. Of course KDE wanted to inte-
grate that technology and Compiz was a true competitor to KWin.
Yours truly, a user back at that time, questioned the sanity of the
KDE developers to implement compositing in KWin instead of just
using Compiz. The problem for Compiz back then at the end of the
first decade of this century was the hard dependency on compositing
and on OpenGL. Both are things which could not be guaranteed.
Basing your environment on this technology was not an option (yet)
and having two window manager with different sets of functionality
was not a good idea. So the better option was to extend the excel-
lent window manager KWin with the functionality of a compositor:
KWin 4 was born.
But over the years we learned how much compositing was more
of a hack than a proper solution. Why is it not possible to have
thumbnails for minimized windows? Yes one can hack around this as
well, but then legacy applications might think they are not minimized
and continue to play the video instead of pausing it and more. Why
does it have to stutter when unminimizing a window? Why is it
not possible to transform the pointer input events in a way that it
matches the transformed window positions? Why do we get invalid
screen content when a window first opens (especially when using
Martin Gräßlin 131
OpenGL)? Why is it not possible to resize windows in truly smooth
ways?
And then there is the problem of security. X11 being designed
in the 1980s completely lacks the idea of malicious processes. It is
trivial to write a key logger, it is super easy to get to the content of
the windows and their positions. This allows all kinds of wonderful
attacks. Your malicious application wants to get the user’s password:
just replace the lock screen. Your malicious application wants to get
the root password: just install a key logger when a window asking
for the password is added. You want to take over the browser and
send it to fakebank.com instead of bank.com: just send the right key
events and put a window on top of the browser to simulate that you
are on bank.com.
This all shows that X11 is not suited for today’s world - neither for
desktop nor for mobile. Something new was needed, something like
an X12. Many contenders existed to replace the aging X window-
ing system, but none gained traction. Except for Wayland. A new
windowing system, designed from ground up with the aim of “every
frame perfect”. Designed by X11 developers applying the lessons
learned from X and taking the good things to the new world.
This development again means a disruption for Plasma and espe-
cially KWin. A system based around X11, developed for X11. How
should that ever go to Wayland. Maybe it is easier to write a new
system from scratch? Something which gets rid of the legacy and
does it right from the start? But what if Wayland fails just like
all the other X-replacement-systems? The community decided to go
the long walk: bring the system to the new world without having to
rewrite everything. Especially for KWin this meant a huge effort.
The code base needed to become windowing system independent,
needed to support both X11 and Wayland windows.
Now this effort is slowly reaching an end. This article is written in
a Plasma session on Wayland in a KWrite using Wayland instead of
X11. But of course it will still be a long way till we finally get rid of
X11. There are many X11 specific functionalities which are essential
to users’ workflows, but which are built around the insecure parts of
132 Evolution of Windowing Systems
X11. It will take time to identify the workflows and add sufficient
(and secure) replacements.
30 Twenty Years of Email
Volker Krause
Volker Krause joined KDE in 2002, and primarily contributed to
KDE’s email and personal information management infrastructure
and applications. He works as a software engineer, consultant and
trainer at KDAB.
On October 14, 1996 Matthias Ettrich started KDE, with an RFC822
message, the same message format still in use today two decades
later, with just minor fixes and extensions for supporting non-ASCII
text. We all know this as email.
Shortly after, still in 1996, KDE’s own email client, KMail, was
started. While it mutated heavily several times in its almost twenty
years of history, you can still find traces of its founders in the code
today.
Email has always been an essential component of KDE, although
a lot has changed, and will continue to change. It is interesting to
look at the developments and challenges in this way, as these are also
reflected in many other areas of KDE, and beyond.
Enabling Access
Back when KMail was started, the prevalent way of using email was
downloading and storing it locally on a single personal computer,
with ISPs or universities providing POP3 accounts that buffered in-
coming emails until the user had a chance to fetch them. With email
becoming popular and important on a larger scale, various compa-
nies tried to push their proprietary variants, such as Lotus Notes and
Microsoft Exchange.
134 Twenty Years of Email
Therefore the first challenge was to provide free access to email,
both free of cost and with the freedoms guaranteed by Free Software.
This might seem odd from a present point of view, where we are used
to finding Free Software applications for pretty much any use case.
In the first years of KDE, Free Software as such was not yet univer-
sally accepted. On the contrary, it had to face massive opposition, in
particular from Microsoft. It took years to prove that Free Software
was a development model that could provide high quality and inno-
vative applications, something that is hardly questioned anymore by
now. Even Microsoft is contributing actively to Free Software today.
KMail, together with many many other Free Software applica-
tions, proved the opponents of the GPL wrong, having become a
competitive product, with some of its innovations such as the miss-
ing attachment warning having found their way into many other
email clients. And it has found a balance between purism regard-
ing open standards and pragmatism when it comes to compatibility
with proprietary applications, still an ongoing discussion in the Free
Software world.
In order to enable free access to your data, free applications are
essential. As the world changes however, this is challenged over and
over again, and free applications are not the only piece in the puzzle
any more.
Clouds
As computing equipment, and email with it, became more and more
ubiquitous, a new challenge arose at the beginning of the century.
With the availability of laptops, and later smartphones, email needed
to be available on multiple devices simultaneously; the old download
model did not work anymore.
With the widespread availability of permanent internet connectiv-
ity in the wake of the dot-com boom, the solution turned out to be
server-side storage and online access, an approach that years later
became associated with the term “cloud”.
Volker Krause 135
IMAP, the protocol for server-side email storage and access was
standardized, and KMail received support for it. While solving the
problem in theory, the limited availability of email providers offering
affordable IMAP hosting at the time did not really help though.
Instead, advertisement-based webmail providers started to appear
and became popular, offering cost-free email hosting with access from
a browser, and a few megabytes of storage space. That entire market
got swept away with the appearance of Gmail in 2004 though, which
offered an (at the time) audacious one gigabyte of storage space, and
a stream of innovations in the user interface. Gmail has since become
the de-facto standard for consumer email.
The implications of this were not immediately recognized by every-
one, and the inside perspective tends to be skewed. We understand
the risks and implications of the cloud approach (“there is no cloud,
just other people’s computers”), and we have access to alternatives,
but that is not what the average user sees when looking at Gmail. It
is a solution to a very real and pressing problem, and even seemingly
free of cost.
KMail, of course, has dedicated support for Gmail and its various
non-standard extensions nowadays. But regarding having control
over your own data, is that really the way we envision our commu-
nication infrastructure?
How and where data is stored and how it is accessed have become
just as important as having a free application to access it, and this is
more than providing a Free Software server implementation. We also
need to offer solutions for secure and reliable hosting and deployment.
“Just run your own email infrastructure” is not a viable solution for
most users. Finding convincing and practical answers to this will
be an important challenge for the Free Software community in the
coming years, KDE included.
136 Twenty Years of Email
Small Screens
In 2007 the iPhone started the age of the smartphone. A year later,
Android followed. By 2012 a billion devices had been sold, making a
small touch screen with barely more than a ten centimeter diagonal
the world’s primary communication interface.
First attempts to give KMail a smartphone-compatible interface
happened in 2010, with limited success. The way we organize and
use email is inherently tree-based. Folders, message threads and in-
line conversations can all get deeply nested. Tree-based interfaces
however only work poorly on small screens, either being very cum-
bersome to use or imposing severe restrictions on the nesting depth.
Not only KMail was affected by this challenge though. This sit-
uation contributed to the rise of a new style of communication ap-
proach: messenger apps. By linearizing conversations, they avoid
the user interface challenges email poses on small screens, quickly
gaining hundreds of millions of users.
Unlike email however, the messengers, no matter if using propri-
etary or open source clients, are not using standardized and inter-
operable protocols, turning them into communication islands relying
on vendor-hosted server infrastructure.
Gmail and proprietary messengers are challenging conventional
email clients, in particular in the consumer space. Even heavy-
weights like Thunderbird struggle with this. Solutions that allow
you to regain control over your communication data, without losing
the convenience and functionality proprietary solutions provide right
now, have yet to be found.
Silos
The smartphone platforms also made application bundles a widely-
used technology, to support their application stores and increase
security on the devices. Application bundles since then have also
become relevant on all other major platforms.
Volker Krause 137
Isolation from broken or malicious applications and straightfor-
ward deployment and cleanup make application bundles a very at-
tractive choice.
On the other hand, application bundles lead to the creation of
silos. Data and functionality is only available to a single application,
and the rest of the workspace cannot benefit from it.
Because the KDE community acts as both application vendor and
a platform vendor in this model, the KMail team is faced with a
dilemma. In order to be easy to deploy on the most widely-used
platforms (Windows, Android) an application architecture that al-
lows the creation of an application bundle would be needed. On
the Plasma workspace however, deep integration would be desirable,
providing access to email communication for the entire platform.
KMail has chosen to go “all in” on the platform integration side,
with a multi-process architecture enabling data sharing and non-
exclusive data access. This is a prerequisite to offering a free and
privacy-honoring answer to the personal digital assistants for exam-
ple.
Other KDE applications are focusing on application bundle com-
patibility instead. There is no right or wrong here, but finding a way
to serve both scenarios will be a major technical challenge for many
KDE libraries and applications going forward.
Privacy and Freedom
Providing secure communication can be traced back to the early days
of KMail. Support for PGP encryption was added in November 1997,
and support for transport encryption followed soon after. Growing
interest in security, also in the form of public funding, resulted in the
joint Gpg4Win project together with the GnuPG community, with
KDE providing the Kleopatra certificate manager.
In May 2013 Edward Snowden gave the world a glimpse of the ex-
tent of global mass surveillance. What were once considered paranoid
138 Twenty Years of Email
speculations suddenly looked naive, and unless you took measures to
protect your privacy, privacy itself turned out to be only an illusion.
Not only is all your communication intercepted and recorded, it is
also automatically analyzed by machine learning algorithms that de-
cide what is “normal” and what is suspicious. You lose your freedom
to be different, and uncontrollable machines decide the consequences
of that. It has become very apparent that privacy is an essential
prerequisite for freedom.
Free Software is well positioned to ensure privacy when it comes
to your digital footprints. Free Software is probably the only way
to ensure that. And without conflicting commercial interest in KDE
getting in the way, our users are not our product, and we can truly
follow the “privacy by default” maxim.
As news about the extent of the mass surveillance spread, demand
for Gpg4Win tripled, with monthly downloads crossing the 100,000
mark. KMail also saw a renewed interest in improving encryption
features, in particular by making them easier to use. “Privacy by
default” also means the software needs to do everything it can to
ensure privacy if the user does not understand the intricate details
of public key encryption and certificate trust chains.
Today KDE technology is helping millions of users to protect the
integrity and privacy of their email content. There is still more to do
though. Content encryption is only addressing part of the issue, and
protecting metadata of email communication is an equally important
and still unsolved problem.
Conclusion
Matthias got what he had asked for, and so much more. What KDE
in particular and Free Software in general achieved in the last two
decades is beyond what would have been imaginable in 1996.
People have questioned the relevance of the desktop, the relevance
of email or that of KMail in today’s world. All this of course might
or might not change in the future. That is not the most important
Volker Krause 139
question going forward though. It is who will have control over your
data. And that is not just affecting email. What is the point of
Calligra if your documents are locked in a proprietary Google or
Microsoft cloud? What is the point of our scientific and educational
software if you cannot afford the corresponding textbooks? What is
the point of our communication software if the world uses proprietary
messengers?
Obviously free applications will stay a key element for this, but we
also need to look at the bigger picture and continuously reevaluate
if we still provide a valid solution to whatever the original problem
has evolved into by now. With ubiquitous connectivity and software
so deeply embedded into every aspect of our lives, we cannot look
at applications on their own anymore. We need to look for solutions
for today and tomorrow’s use cases that allow you to retain and
regain control of your data, striving for a world in which everyone
has control over their digital life and enjoys freedom and privacy.
31 Krita Animation
Timothée Giet
Timothée Giet is a graphic artist from France, using exclusively free
software since 2010. He works mainly on free software or freely li-
censed projects, doing all kinds of graphical work from illustration to
icon design, and also teaching and creating training materials. He is
a regular contributor to Krita and GCompris.
Let me tell you the story about Krita and animation. For me, it
started in 2010 when I discovered Krita. I was impressed by the
quality of its drawing tools, and since I was looking for a free software
alternative that would allow me to draw comics and animations, I
secretly wished you could draw animations with it.
Imagine how excited I was when, just the next year, a new myste-
rious contributor actually started working on an external plugin to
add some animation tools. It was not easy to use nor very stable,
but it was a good sign that other people wanted this.
Around the same time, thanks to KDE e.V., I could attend the
Libre Graphics Meeting where I met for the first time Boudewijn,
the maintainer of Krita. During our conversation, I told him how
great it would be if we could add some internal animation tools. It
sounded a bit crazy at the time, and we both agreed that lot of work
was needed first to get a solid drawing software, but the idea was
there.
This first animation plugin experiments did not progress very
much, and the main author left them unfinished. Later in 2013, a
more serious project started with a Google Summer of Code student
trying to add some internal animation tools. Sadly, even after two
years, the plugin still was not production-ready and did not progress
much. The contributions were still in a separate branch and not yet
integrated in the main binary.
142 Krita Animation
It was finally in 2015 that another Google Summer of Code student
managed to really integrate the animation tools, learning from the
mistakes in previous attempts. Now we have Krita 3.0, officially
released and including basic animation tools. Animators from all
over the world quickly started adopting it and sent some positive
feedback.
But this is only the beginning. We are still working on adding more
tools and features, and I have no doubt that Krita will soon become a
famous software tool in the animation world, if it hasn’t already. It is
a big step forward for people creating multimedia content exclusively
with free software (for the operating system as for the tools). We
now have a quite complete ecosystem of tools available in which
Krita provides a missing piece for traditional animators. Let’s see
what people will create with it.
32 The Transient Nature of Design
Nuno Pinheiro
Nuno Pinheiro is a Portuguese graphic designer and illustrator. He
specializes in iconography, themes and user interface design. Nuno’s
works include general illustrations, UI design, web design, corporate
design as well as other works in creative areas. Known for his work
in the Oxygen Project where he is the current coordinator of a design
platform with 2000+ icons, wallpapers, sound effects and window
styles. His computer art is used on KDE computer platforms world-
wide. Over the last years he engaged in coding with QML creating
fine tuned experiences for users and became interested in the Devel-
oper/Designer Interface. He works as a UX/UI designer, consultant
and trainer at KDAB.
The Tempos of Oxygen
Design in open source is special. At least to me it is, and has always
been, and the reason for that is simple: the relative ephemerality
of it, so unlike other open source projects where the beginning is
well defined but the end is something to be avoided. In design and
especially in this post-modern ever-recursive design landscape the
end is as present as its beginning, and so it must be fully embraced.
So... What is the point of it? I mean if it is done to have an end
what does it achieve? This creates a problem that I’m sure every
design related open source project has debated with itself.
For Oxygen and me personally it was solved with the assumption
of three time periods: a future, present and past. That looking back
has now been reverted.
144 The Transient Nature of Design
Its Past was its Future
So what drove me to design and open source? I guess this is where,
for me, design shares more with common “traditional open source
projects”: an itch to scratch, or more specifically a couple of emoti-
cons in an instant messaging app I used in my favorite desktop at the
time (KDE 3.X). So I made a couple of icons (really low quality) but
was encouraged by the wonderful community to keep working on it
and so I did. And as a result of my continued engagement with the
community, I was invited to be a part of this new project – Oxygen.
In its infancy it was a Future, it was everything, and anything, the
solution to all problems. It was also a repository of all my uncer-
tainties and doubts (all founded, I might add), but it was a fantastic
time, a time to get to know what you are and how you express it,
a time to realize that working within a group of people is far more
challenging but also far more rewarding than all by yourself. A time
to make mistakes, a time to correct those mistakes and a time to
realize the extension of your errors would mean, you would need to
start all over. In the end what comes out is Oxygen, a child of its
time, a son of Everaldo Coelho, Crystal Icon set of Nuvola by dear
friend and Oxygen colleague David Vignoni. It was an icon set and
it was amazing. The future offspring of some superb parents - and
trust me we stood on the shoulders of giants - for its time Oxygen’s
parents were, in many ways, ground breaking feats of computer de-
sign not just in open source but in computer design, rivaling with
the best of the best in the industry.
This realization made me become fully certain of Oxygen’s own
future and goals: Oxygen should strive to be as successful as its
parents, and most importantly, prepare the way for future offspring.
So in my mind Oxygen was something for the KDE 4.X series.
Beyond that something new would have to take its place.
Nuno Pinheiro 145
Its Present, where Past and Future face each-other
So you have this group of people, that are making an icon set, and in
the constant struggle between past and future, you keep on creating
new futures in order to move on, so you get more people involved
in the project and you add new futures, new projects, new ideas,
and the icon theme becomes so much more. This is the explosion
phase. An icon theme becomes a Qt theme, a sound theme, a design
platform – 1000 different things! Personally, this is the time that
made me a designer. Never underestimate the power of trial and er-
ror. A lot of practice does not make perfect but it sure helps you to
get better. The icon set suffered many mutations as it defined itself
thought time, the Qt theme, Plasma themes, Oxygen and Air, the
cursor theme, the sound theme, the multiple websites, the countless
posters, banners, mugs, pins, meetings, talks, etc, etc,... amounted
to gargantuan amounts of work. Make no mistake it was an absurd
and gigantic effort, it was incredibly fun and in a way it set, what
I personally consider, Oxygen biggest achievement. Before Oxygen,
design projects in the open source world tended to vary from unco-
ordinated projects that lived in the same space, to vaguely related
projects where different groups would coordinate design visions so
that desktops would have some sort of coherent visual language, for
example: the good efforts from our friends at the GNOME Desktop,
and the multitude of projects it created but that shared an obvious
vision and language. Still Oxygen was different now. It was so much
more than just an icon theme. It was anything you would see in
your desktop and more. We went to the extreme of making GTK
themes so that the KDE experience would be even more consistent
for the users. Hat tip to a great Oxygen guy, Hugo Pereira for his
outstanding work in this area. Oxygen might not have been the best
icon set of all times (it was good enough in my opinion but not as
ground breaking as its parents were) but the scope of design efforts
was unprecedented in the open source world. So to me, Oxygen’s
development period, “present”, was a success - maybe not from the
pure creativity design language point of view (I’m not even sure if
146 The Transient Nature of Design
I’m unbiased to say anything truly fair about its merits in that re-
gard), but from what it set as the goal post of what a design project
in open source should be. I believe it did reach its goal by setting a
new high bar in what to expect from open source design projects.
Its Future or the starting of a new Past
Some years ago Qt released Qt 5.0 and, as anyone that knows some-
thing about KDE knows, that means big changes are coming. Add
to that the mobile explosion, the touch explosion, the QML language
and Qt Quick revolutionizing things and the relative importance of
design in computer user interfaces. This meant that visual languages
and user expectations were changing. Also my expiration date on
Oxygen was reaching its due date with series 5.X’s on the horizon.
A perspective of making themes, even coordinated ones were not
enough to create meaningful competitive user experiences. Oxygen
failed to be that. As a result of the way it evolved and what it con-
sisted of in its inception it was hard to be anything else than what
it was. This new method of doing things in some ways would defeat
the propose of consistent theming, just like architecture and urban-
ism rules are different things, so are consistent theming and perfectly
tailored user experiences different and not fully compatible concepts.
So at the end of the Oxygen period, user experience and user inter-
face design was reaching an inflection point. Gone were the days were
graphical designers challenged their own illustration skills in a per-
petual “I can draw my candy more naturalisticly silly than yours”.
We had reached the saturation point of the silliness in graphic repre-
sentations of every day objects as user interface elements. Now back
then people needed to find a culprit for it all, a quintessential word
that in itself represented all evil. Cue in “skeuomorphism”, a word
used in traditional design to imply a faux representation of a mate-
rial. In this word we collectively found the “wrong” to be corrected.
We had our culprit. Well all of this to me, back then, sounded a bit
like a personal attack. I mean, gradients and shadows was all I did,
Nuno Pinheiro 147
and just because some were abusing it I had to pay for it? Yeap I
did!
Plus Oxygen was starting to look old, in my eyes, and I knew it
was time for something new, something fresh. The true testament
to Oxygen’s relevance was about to be put to a test. Would it be
replaced, would some breeze of freshness be able to correct all wrongs
in Oxygen? To be absolutely honest, I was worried. For some time
it seemed no-one would pick up the work, and from a personal point
of view I felt I needed to take some timeout to reinvent myself, so I
should not be leading a post-Oxygen design language.
But the magic of open source did offer us, collectively, a new set
of fresh people in the form of the KDE Visual Design Group, and
with that Breeze, a new past of something new that was its future.
Oxygen will still live on the 5.X’s series of Plasma/KDE desktops
and I will keep on maintaining it, but now there is a new being that
Oxygen failed to be. And it is great. This was achieved by far more
than just me, it was/is a wonderful group of people - some of them
I mention above, and trying to mention them all is impossible; but
being incredibly unfair to all of the ones I will not mention, a word to
Riccardo, Marco, Sho, Bettio, Ken, and all of the users: an enormous
Thank You.
Conclusion
So when starting this article the point I wanted to make was the
transient nature of design in open source projects. Its announced
death at inception time is not something to be taken as a bad thing.
It is a natural event that should be embraced from the beginning,
the fact that it will have three tempos and that they will cross within
themselves is a natural thing, on its way to reach conclusion, that
its mortality is nothing but a step into a new birth. I wanted to
say that I knew this from the beginning and that it made me happy
that everything went as planned. It did and it is true that I am sin-
cerely happy about the little apparent loop of creation, the cheating
148 The Transient Nature of Design
of death by continuity, a glimpse of immortality, via the ever chaotic
butterfly effect. And this would make a nice enough conclusion ad-
vising you, the designers, to embrace open source projects with that
in mind.
But... Thinking a bit more about it, I have to be more honest, I
have to look into what drove me, what motivated me. I mean having
a plan and executing it when you previously define that very plan
according to a pattern that you see as the only possible best outcome
may feel a bit mechanical, and it was nothing like that.
... and then I remember, people used to ask me all the time “how
come you do it?” and I would answer “because it’s fun”, this simple
answer was my real truth, maybe this is all it boils down to, that
terrible cliché. It’s not the destination it’s the journey, the journey is
what makes life and at the end of the day life is only true if you do,
see, feel, create, quit, restart, win, lose, and love, yes love. Love what
you do! I Loved doing Oxygen. I love doing open source design.
33 Say Yes
Jens Reuterberg
Jens Reuterberg is an illustrator and designer (but always illustrator
first) living in Sweden with husband, cat and laptop. Since 2012
he has used Open Source for work exclusively, and since 2014 as
his work exclusively since he started KDE’s Visual Design Group.
Sources have it he even talks in his sleep.
There are things in life that shape you. The little things that make
your life take a sharp turn and wheer off in an entirely different
direction. They happen constantly, it’s how you met your partner,
it’s how you got the new job, it’s how you got started playing the
banjo. Often they are tiny little incidents of no remarkable relevance
in and of themselves. A man slips on the concrete, you laugh and
someone else laughs - you start to talk while in the background he
brushes himself off and walk away and five nights later you wake up
next to them and wonder how you could have even considered life
“living” before.
We take them for granted, the little strange happenings that you
can’t foresee. Like they where a natural effect to you being you.
How could you NOT have started playing the banjo, you might ask
yourself. If it wasn’t for that time you by mistake ordered one online
you would probably have picked one up at some point, wouldn’t
you? It is amazing that, with the billions of us living here on a huge
mass of land, the small chance that any one of us would meet any
specific one of everyone else of us, is never really remarked upon with
greater fascination than it currently is. Like it “just happened”. Or
how from an impossibly large selection of options you just chose the
right one, at the right time, while being in the right frame of mind.
It just happened.
150 Say Yes
In my opinion - the method with which to gain the greatest amount
of “just happenings” is to allow for the little off-chance things to
happen, to the greatest extent of its capacity. Let go. Say yes. Go
“oh just this once” once more. Accept that you will look like an arse
no matter what you do, so you might do it anyway and in a way you
yourself could foresee and somewhat control than by just the act of
being you every day.
That is why I am in KDE now. My willingness to look like a
complete and utter arse. My readiness to say “yes” to things I am
not totally sure about.
Obviously this is not the only reason. Other people’s capacity to
accept me even though I look like an arse are just as relevant as my
own ability to be one, of course. Others’ willingness to ask, is as
important as my ability to say “yes”. But that is, simplistically, the
reason why I am in KDE at any rate. Saying “yes”. Looking like an
arse. But mostly saying “yes”.
I was asked by Sebastian Kûgler to show up at the Plasma Sprint
in Barcelona. He in turn had had me suggested to him by Aaron
Seigo and those two, my “yes” and ability and acceptance of risking
to look like arse was why I was standing outside of Barcelona airport
alone.
Now I am a fairly awkward person. I know this. I can be either
painfully silent and withdrawn or overly jovial and with the voice
and body language of an opera singer for the hard of hearing having
a stroke. Standing outside an airport, about to go to an office filled
with strange programmers, a profession I don’t grasp at all, about
to do “design-stuff” for a week in an area I had never worked in
before in my life, Open Source - I was in “silent-mode”. At that
point, grabbing a smoke between flight and bus ride, I regretted it
greatly. I wanted nothing more than to go back home. To be fair I
had spent the entire flight from Sweden regretting it. The bus ride
from my home to the airport outside of Gothenburg had been a clear
and constant battle to tell the bus driver to stop because I’d gotten
on the wrong bus and had to walk back home through the woods.
The act of going out the door was the emotional equivalence of a
Jens Reuterberg 151
nuclear bomb strike of regret - regretting I had ever said “yes” when
Sebastian asked me.
But it is those slapdash and shot-from-the-hip yeses that do it and
that understanding was what had made me say it in the first place.
Saying a skeptical “no” makes things easier but it’s the yeses that
deliver the potential for “just happens”.
Not that I cared then for the bravery of my past. It’s so easy to
be brave before the battle. So simple to be self-confident before the
test. To say “yes” then when you now want to scream “no”.
I spent the bus ride from the airport into town in abject terror and
was dumped at Plaça d’Espanya with suitcase, hand-drawn map and
confusing self-doubt about the whole thing. What was I meant to
do there? I had this vision of me, sitting alone in a corner checking
Facebook and pretending to laugh at C++ jokes while work went
on around me. Of questions with answers I could hardly spell - let
alone deliver - and a group of programmers lying about having to all
go to the loo in another area of town at the same time just so they
could have beers and ask each other “why this Swedish mustaschioed
dickhead is here”. If optimism and hope for the future is a blue bird
swooping through the sky, I was a bright orange elephant trying to
maneuver a burning 747.
Now had I, at that time been able to see just a few days into
the future - had I been able to, from that chance online encounter,
question and temporarily insane “yes” on my part, extrapolate what
would come, I would have been happy as nothing to be there. You
see, KDE is a mess of people. Tons of us and all going in [Number of
KDE people]+1 different directions at the same time. We stretch a
rather broad gamut of humans, from the loud to the quiet, the kind to
the apathetic, the professionals and the hobbyists, the productive to
the lazy. “Anyone can join this club” could have been an insult,
but for KDE it is more like a battle cry of clear intent. Had I
known then, that the week that followed was not just productive
and thought provoking but fun, I wouldn’t have been nervous at
all. Had I known I would meet people who I now consider close
friends, who have that rather adorable quality of being incredibly
152 Say Yes
intelligent, but seemingly not able to grasp how much more intelligent
they actually are, treating some random Swedish arse as an equal
instead as a befuddled moron - well I would be cartwheeling all the
way through Barcelona to get to the sprint. In the days to come I
talked technically complex issues with people who can do what is best
summarized as “magic” as far as I’m concerned, people who didn’t
talk down to me, who didn’t ignore me but instead explained every
issue in a way that I could take part. Who listened to my ideas and
more importantly explained why some of them would not work and
some might. I talked about design with people who listened to me,
asked questions and suggested ideas with the casual ease of a giraffe
eating a trimmed hedge. People who inspired, not just amazing work
in me but amazing work with them. Had I known, at that time, on
that street, that I would go home later that week, fall asleep next
to my husband and dream about interaction design, UX and visual
elements and wake up the next morning pouring all energy into this
“Open Source” thing - I would probably not have believed myself
anyway, but if I had I wouldn’t have been the least bit worried or
scared of having said that initial “yes”.
But I hadn’t so I was, as I stumbled along that street through
Barcelona with my map, backpack and social anxieties in tow.
I had drawn the front door of the Blue Systems office by hand on
a piece of paper from Google Streetview simply because at the time
that had felt more calming than taking a screenshot and the little
drawing I kept holding up to compare different doors to was getting
damp and soggy from my sweaty hands. When I found the door,
that was also the moment I met my first KDE developer: Ivan.
I don’t know what clued me off to him being one of the developers.
It could have been the bags since he had also come from the airport
or maybe it’s the nerds innate ability to recognize a sibling but I
asked “You here for the Plasma Sprint?” He looked at me as if he
had yet to deduce if I was there to murder him, or just rob the office.
As if some kind of debate on whether to pretend not to speak English
and walk away or reply was raging inside him.
Jens Reuterberg 153
After a rather too long second or five he seemed to make up his
mind, take his chances and go “yeeees...?”, pressed the intercom to
the front door, opened it and let me in.
34 Future Journeys: Which Path to Take?
Ben Cooksley
Ben Cooksley has been a user of free software since 2005, when he
stumbled across a Knoppix CD. Since then he has gone on to wear
many hats in the KDE project including user support, development,
and more recently infrastructure administrator. When not working
on KDE he can be found in places he previously hasn’t visited or on
nature trails.
As being a well established and successful community, KDE has ac-
complished a great deal by producing software for a wide variety of
roles while having a good deal of fun along the way (although some
hair may have been lost, depending on who you ask). We have pro-
duced countless different desktops and applications that users love,
something proven by the wide variety of user customization and other
content that exists for them. But we are not finished yet. The next
evolution in technology, and along with it users’ devices, awaits us.
Being ready for this evolution is crucial. Countless examples of
titans not being ready for change exist: IBM underestimating Mi-
crosoft and Intel in the PC revolution; both Microsoft and Nokia
failing to ride the smartphone revolution, all despite their former suc-
cesses. With the rise of smartphones and their attached app stores,
our traditional base of both users and new contributors is changing
as well and will continue to do so as the next evolution arrives. We
must change with it, bringing our software to new places and creating
better software others haven’t yet thought of.
If you think back to how you got involved in free software, chances
are it started with you using the software in some form. Whether it
was a bug that bit you, a feature you missed, documentation that
lacked answers to your questions or something else, the road to in-
volvement in free software communities such as KDE starts with
156 Future Journeys: Which Path to Take?
becoming a user of the software it produces. It certainly did for me.
Without a presence on these platforms, people cannot become even
aware of our software, let alone try it and become a devoted user.
With today’s users being tomorrow’s contributors, we cannot afford
to miss new platforms as contributors are the lifeblood of not only
our, but many other, free software communities.
The creation of better software sounds like a daunting task, like
climbing a mountain with no prior experience of doing so. The truth
is, the best software is the software that meets the needs of our
particular use case the best and presents it in the most accessible
form possible. This requires knowing the needs of the particular
group of users, what issues they hit, the features they miss, and the
things which get in their way. From there, we can set about solving
these problems, climbing the mountain as it were, and creating a
community of enthusiastic users for whom our software is best in
class. In the long term, these very same users will not only spread
our software but some will also become contributors, joining the
communities that produced the software.
While the path forward may not be entirely known yet, the next
20 years hold many things in store for KDE. Our future software will
run on devices we have yet to conceive of and will do things for our
users that have yet to even be dreamed of. Yet one thing will remain
the same – the creation of software people love – that will inspire the
next group of contributors to our community.
35 Staying Relevant
Albert Vaca
Albert Vaca is a software developer from sunny Barcelona, with ex-
perience in Android and C++. He maintains the KDE Connect app
for Android and PC.
When I was first asked to talk about KDE’s history, I thought that
I am much too new a member of the community to have something
interesting to say. My first contact with KDE (as in “the KDE desk-
top”) was in 2006, and I didn’t touch any code until 2010. However,
maybe with some luck, my experience as a relative newcomer might
bring a different point of view to the whole picture.
The first thing I want to note is that I first approached Linux and
the free software world in a time when it was booming. The mar-
ket share of the Linux desktop was not huge, but free software was
trendy: schools and public administrations were adopting it (even if
only to save costs), it was in the news, a lot of innovation in browsers,
in security and in other areas came from open source projects. For
all of these reasons, it was a time when a lot of people, who like me
were interested in geeky-computery-stuff, got into the free software
world.
Many have said that one of the reasons for this boom was the
failure of Windows Vista. And yes, Vista was not a success, but in
hindsight it was probably the least of the problems Microsoft would
have to face. The major game changer, in my opinion, came a bit
later: the popularization of the smartphone. And there, the Linux
desktop was hit in the same way Microsoft Windows was.
The reality is that, after the smartphone revolution, personal com-
puters are not that relevant anymore. Therefore, in my opinion, the
less relevant the desktop is, the less relevant we are as a community:
158 Staying Relevant
most people get into the KDE Community through our desktop en-
vironment and desktop apps.
This means, to start with, that we will not see that many geeky
teenagers like me coming to us. This is perfectly normal: people
today are more interested in context-aware, notification-enabled An-
droid and iPhone apps, than in big bulky desktop suites that you
manually launch to perform a task. Sadly, there is not much free
software available on these new platforms.
Our current situation is that most people in KDE are people who
work on and know about desktop software. Of course, most of these
people are not going to stop developing for the desktop just because
it is not trendy anymore. Instead, what I would like to see happen is
engagement with a new generation of developers who have the ability
to grow within KDE a new family of products relevant for them and
the way they use the technology. That is, a generation of developers
who understand what needs to be done in order to reach the users
of the emerging platforms, and who want to do it from within free
software.
Only by achieving this will we manage to reach a whole new genera-
tion of people and get them interested in using (and maybe eventually
developing) free software, and to continue to grow our community.
We are faced with non-free software, but in the same way we did it
in the Windows monopoly era, I am sure we will put our focus again
on providing software which fits the users’ needs better. On these
new platforms, there are plenty of new areas where free software can
excel above non-free. Probably the most important one: the privacy
of users.
At the same time, of course, we still need to maintain our po-
sition as one of the best desktop free software communities in the
world. Here, though, we can learn a lot from the emerging plat-
forms and adopt what they did well. Just to name a few things:
sandboxed apps with discrete permissions, great focus on the user
experience, standardized distribution mechanisms from developers
to users, context-aware apps, and more. Non-free desktop platforms
are also trying to do the same (an example of this are the dramatic
Albert Vaca 159
UI changes we have seen in each version of Windows from 7 to 10),
so we have the opportunity to have a big impact by being, one more
time, faster than them.
In conclusion, even though the personal computer is not going to
die anytime soon, things are changing fast and we need to keep up
with the good work we have been doing until now. At the same time,
though, I think we need to find a way to reach all the people who
don’t use traditional desktop software, but who we believe would
benefit from using free software.
We need to understand what we use technology for and how we
can make sure that it serves our society now and in the future. We
all agree that free software is the way to achieve this goal, so we
have to make sure it is present on every front where technology is
involved. It is then when we will be the platform that makes possible
the society we believe in.
36 Software, Freedom and Beyond
Riccardo Iaconelli
Riccardo Iaconelli is a KDE developer since a very young age. He
made his first steps in the open source world within FSFE and never
stopped. He counts in his portfolio important collaborations with en-
tities such as CERN or INFN. His latest project is WikiToLearn, a
web platform dedicated to the creation and exploitation of free scien-
tific knowledge.
I have been a KDE developer for more than half of my life now. KDE
is turning 20 this year, making it one of the longest living (and most
successful) open source communities in the world. I have performed
almost any kind of tasks in all those years: I have been coding, trans-
lating, doing graphical work, promotion, even event organization or
paperwork, when it was needed. I am so grateful to the community
for the experiences I have made, that I am writing this essay with
slightly wet eyes. KDE has been a central part of my education,
one I could not do without. KDE is, today, about to face many new
challenges. To be able to tackle them effectively, we need to know
what made us strong, during all this time. I don’t presume to have
the answer, but I will share my story, in the hope that it will be
useful.
So, how did I get interested in Free Software, in the first place?
Well, I had the luxury of learning how to code at a very young age:
I was 9 and I wanted to build my own website about skating. So I
started to learn what I needed: HTML and JavaScript. And then, of
course, some PHP. But I got so intrigued by the programming world
that I decided I was going to be a hacker, when I grew up. After much
googling, I figured that the only way I could be a hacker, though, was
to install Linux. I downloaded my first Linux distribution, a SuSE,
162 Software, Freedom and Beyond
and I installed it like I would with any other Windows application:
I just kept pressing “Next” without caring to read what was going
on. A minute later, I was there, without a bit of all of my data,
applications and music, with an operating system I did not know,
with no internet connection, but a strong will to “become a hacker”
and learn. I installed and used just about every application I had
on the SuSE DVD (I even went as far as installing and using an
application to print out barcodes for hours). But it was not just
technical work. I educated myself about the four freedoms of the
GPL and why they mattered. And I found the community I wanted
to be a part of: KDE.
I was, however, too shy to contribute to KDE through coding,
even if I already knew some C++, so I started with the simplest job
I could take on: translating. And I had lots of fun! So I continued,
I became a core developer of Plasma, writing the first plasmoids, a
core developer and a designer of Oxygen (working on the theme, win-
dow decoration, cursor theme, icons, wallpapers...) and many more
things (from kdelibs to games to PIM). Probably the single piece of
work (outside these big projects) I am most proud of is the complete
redesign (and implementation) of Amarok’s user interface in QML.
It was sexy, but unfortunately it was never released. By getting my
hands dirty I learned a lot from everyone in the community, trying
to build new skills and expertise, to be used later. It was simply
amazing.
There was not a single role model, but I had the luck of finding
many great mentors within the community. In general, I tried to
simply be attentive to other people, trying to find out what I like
in what they do, and what I can learn from them. Once I see it,
I start to apply those elements in my life, whether it’s a personal
lifestyle choice, a technical decision or a way to relate to others.
This “growing together” is, in my opinion, the true spirit of free
software.
It is partly due to this belief that I launched WikiToLearn, a KDE
project which works with the greatest research centers, universities
and experts, to share under free licenses the great amount of knowl-
Riccardo Iaconelli 163
edge produced there, at Akademy in 2015 in La Coruña. We want to
create free and collaborative textbooks, accessible to the world and
always remixable, to teach the values of openness and collaboration
to the next generation. I think that teaching why openness is im-
portant is crucial, if we want to keep the open movement as strong
as it is now.
To motivate myself I always remind myself why I am doing what
I am doing. I believe in a free world; I believe in the power of
decentralization. I believe that the sum of our collective minds and
efforts is greater than what any of us alone can achieve. And I want
to have fun while doing what I am doing.
I feel that one of the challenges we are facing right now is evolution.
How do we grow past a world which was entirely desktop-centric, and
which now gives the desktop an important but no longer essential
role? I think the answer lies in the community. We have to go
back to our origins, to the universities where many of us started
contributing. We have to see what is now interesting, explain the
fun we can have developing in the open world and the importance of
keeping a thriving open ecosystem.
We need to explain our strengths and bring them our experience.
Here is what I usually suggest people to do: learn by doing, and
always get great mentors to review your work. Get your hands dirty
and teach yourself to code. Try, fail, try harder and iterate. And
don’t stop until you become perfect. Aim for elegance. Learn every-
thing you can from the world and your peers, and never stop doing
that. The challenge is with yourself, not with anyone else. How
much better can you be?
This way, many years later, I found I have been growing with the
community, learning many skills along the way. I watched subpro-
jects flourishing and dying, and in this process shaping the meaning
and essence of KDE. In all this period serving as core developer I
have seen KDE grow and evolve beyond what we thought was our
first goal, to face new and unimagined challenges, and expand to-
wards directions we didn’t even believe possible.
164 Software, Freedom and Beyond
I have been a KDE developer for half of my life. KDE turns
20 this year, and I am 25. I want to continue to see this amazing
community to flourish, and I want to play my part in the first project
that I maintain, by adding yet another global success to our portfolio.
And I think that with WikiToLearn we have all the right cards in
our hands to achieve that. The KDE Community has been almost a
family to me, and I just want to thank every member of it for making
all this a reality.
37 A New Generation
Andreas Cord-Landwehr
Andreas Cord-Landwehr joined KDE in 2011 and primarily con-
tributes to KDE’s educational software applications. After his PhD
at Paderborn University in the field of algorithmic game theory in
spring 2016, he joined CLAAS E-Systems as a software developer.
When my aunt tells me about her youth, about using horses and
carriages to harvest the hay at my grandparent’s farm, it sounds like
a story of long ago. When I tell some high school student about
twenty years ago, about going to the library to borrow programming
books, since we did not have access to the internet at home at that
time, it must sound like a story as similarly ancient as my aunt’s
one. As hard as it is for me to imagine a world where we still use
horses for our daily work, it might be similarly hard for someone of
the “digital native” generation to understand the life in the world
just twenty years ago – albeit it is just one generation.
Twenty years ago was the time of the struggle out of the Microsoft
vendor lock-in. At that time everyone I knew used a Windows PC,
even me. Actually, my KDE and Linux memories only start some
years later. It must have been about fifteen years ago, when I got
my first Linux Boot CD and got excited by a boot screen that really
showed me what happens on the system instead of a Windows screen
that liked to magically freeze during boot. Still, I can remember my
first log-in into the KDE desktop, my first bug report, my first system
configurations. It has been an exciting time. Updating the KDE
desktop always brought tons of new features, new applications that
I was missing from the Windows world, and I really felt the freedom
and adventures this new world gave me. For me, as someone who
joined the ranks of the KDE developers several years later, I can
166 A New Generation
only guess how exciting the times must have been in particularly as
a developer back then.
Today, the world is a different one. Linux is an important ecosys-
tem and deeply rooted in the economy. The KDE desktop together
with the Linux ecosystem provides applications for all needs and it
is a rare event when one encounters a missing application from the
Windows world; actually, sometimes at work I have it the other way
around. However, the trend of the desktop as the predominant com-
puting system is changing. In the economy, the desktop will surely
remain and will still be an important tool for many decades to come.
But for our daily lives it is already different. The desktop computer
is slowly becoming an office tool, like a typewriter in old times, a
thing that you do not place in your living room but rather in an
office. Already today, the desktop computer is not the first device in
your hand if you want to look up some information. Some years ago
it was very different.
The question is, what does this mean for us as the KDE Commu-
nity, a community that started around the goal of making a great
desktop for end users. I believe that this new trend is both a chal-
lenge and an opportunity at once. We have our main products, which
target the desktop, a solid platform which will still be used for a long
time. But there are the new fields, the smart phones, the tablets, the
watches, and the countless devices that try to make your life easier.
Compared to our starting grounds the signs for these new fields are
not bad. Actually free software found its way into many parts of
these devices. Now we have to identify what the challenges are that
we want to address in the future. With the KDE Vision in place we
are in a good position for doing this.
One major challenger will be to find a good balance of what to
preserve and what to start anew. We have a long tradition as an
open source project but should not become a dinosaur waiting for a
comet. We are active in hot topics, but should not become a flock
of lemmings running mindlessly in one direction. In a community
we are people of various backgrounds, educations and ages, and with
twenty years completed, we finished what one can call a generation.
Andreas Cord-Landwehr 167
I wonder, how does someone perceive this world who is young enough
that they cannot even remember KDE 4.0, a world that always had
the internet, where the first access to a computer was swiping a hand.
With each generation the perception of the world and of the way we
deal with it is changing. This even changes the fights we see as worth
fighting. As drastic as the change from horses to harvesters was, I
see the change from the open source world twenty years ago, with the
KDE desktop still being an infant, to today. But since not only the
tools and techniques are changing, we as a community must evolve
to the next level, to update the purpose that drives us. Twenty years
are one human generation, I am curious what will be after another
one.
Closing Words
When I joined the KDE Community 10 years ago I could never have
imagined how much of an impact it would have on my life. I am
where I am today because of the people in KDE and everything I
learned from them. I am surely not the only one and I am grateful
for it. In a world of rising tension between cultures, countries and
people, communities like KDE transcend artificial barriers and make
us understand that we are better together than we are apart, that
we achieve more when we are united than when we are divided, that
our shared interests are bigger than our differences.
This book can only give you a glimpse into the past 20 years of
KDE. I hope we still gave you a good overview and explained why
our heart is in this community.
To my fellow contributors: May you always stay innovative, smart,
open-minded, inclusive, dedicated and awesome. Thank you for be-
ing a part of the journey. A lot of amazing things are still ahead of
us.
To our users: The past 20 years have shown that there is a lot
of technical excellence, pragmatism and will to fight for our users in
this community. We will continue on this way - for you.
— Lydia Pintscher, President of KDE e.V.
Berlin, Germany; 24th of July 2016