This post is part of a series about the KDE Manifesto

In the previous posts of this series, we looked at the history of our community and the reasons which pushed us toward answering "What is a KDE Project?". We also discussed which process we followed which ultimately gave birth to more than a definition in the form of the KDE Manifesto.

I'm just done delivering the Akademy 2013 Community Keynote (and yes, the slides of my keynote are already online), and this last part of my KDE Manifesto series will follow a very similar message than my keynote (even if approaching it from a different angle and likely with more words).

The KDE Manifesto is almost one year old now... That prompts the obvious question of "Did it have any effect?" And good news, yes it did, so all that work wasn't for nothing! More seriously the most obvious effect is the fact that we got some new projects joining our community; projects that already existed outside of KDE. We're not talking about dozens of them, more likely three or four, which over a year is not too bad. It also had a less obvious effect toward projects which were already part of the community or perceived as such, it prompted them to get closer to the rest of the community. In both cases, it gives me great hopes. Indeed, those people joining or getting closer are the living proof that our community and its values are attractive.

Now of course, we risk becoming lazy and stopping here. Maybe just adjust the manifesto a bit here and there, roll out updates to it and done... I think that would be sad, and for the past year I've been taking a step back from the manifesto trying to connect the dots and see where past events could lead us. I think that now I've a theory worth sharing.

The obvious (in my opinion) conclusion of the events I related in my previous posts (the Akademy 2006 discussions, the KDE Rebranding and the KDE Manifesto) is that our software products are not what matter the most. The community is what truly matters. It might seem obvious to you as well oh my dear reader... but it was clearly not a given 10 years ago. Ultimately, we could completely stop producing a workspace (worry not though, we still plan to do so, it's a pure thought experiment) as long as the community survives and lives up to its values.

Then we must ask ourselves if the community has the necessary means for such a long term survival. Since the manifesto it has the seeds to create such means, but they still need to be created. And to figure out which tools to create, I think we need to realize which type of structure we're evolving into and keep pushing in that direction. And even though it can be a fuzzy concept, I think we're evolving to be a democracy. We have no land (apart from some presence on the internet) but even without physical borders it's what we strived to be and that's clear from the manifesto in my opinion: more than half of the values listed there are democratic traits. As a corollary it means that the manifesto would be our constitution (I don't know about you but I find that extremely exciting).

If we take the "KDE Democracy" for granted, it gives us a guide to know which tools we should build. Indeed, we need to complete our democracy to make sure its culture keeps striving. It will be tackled thanks to three main aspects. I'll examine those now (in no particular order).

First, we need to find out patterns and document our governance. That should be done at two levels I think. At the community level, we need to figure out how the overall direction emerges, where are the power structures and if we want to adjust some things (I'm thinking for instance at the links between KDE e.V. and the community, but there's more). Also at the projects level, we need to find which type of governances we use and where are the shared patterns. Overall, we're relying a lot on auto-organization (which is good in my opinion), but that works only within a regulation framework... remove the regulation and you'll get a chaotic system instead.

That's why we have to find and preserve our regulation framework. I often refer to the "Respect The Elders" unwritten rule. I might get to that in a separate post one day as I don't quite like the name (it could be mistaken for the seeds of a gerontocracy which is not the case) and it raised some controversy during the keynote (for the reason above)... After explanations, something like "Respect the Up to Date Experience" might be a more correct wording (although less catchy). In any case, it is likely our regulation framework has more unwritten rules. Obviously, that has to be tackled at both levels (community and projects) in parallel, it wouldn't be surprising that the governance at the macro level emerged from the regulation framework at the micro level.

Second, we need to internalize the fact that we are part of or in interaction with greater ecosystems: the Free Software community at large, the software producers, the software consumers, the hardware vendors, etc. Just like a country being in interaction with other countries, we're in interaction with other such entities. As such we should be constantly aware of our surroundings otherwise we rick to not realize that the world changed without us and our culture didn't evolve to cope up with that.

That's why we really need to properly tackle our alliance management for instance. Probably by creating some kind of "foreign office" were people interested in this matters or responsible of a particular alliance can meet and share. Otherwise we're at the mercy of ad hoc links, and when the person leaves we loose the alliance with it.

Third (and last), we need to make sure we pass the culture properly to projects which join the community. It's very important to protect the culture itself so that it evolves at a proper pace avoiding deadly disruptions. But, it's even more important for the joining team! Indeed, it's not easy and can be very intimidating to join a community like KDE. You could quickly become isolated and so you got no reason to stay any longer. In the end it would completely destroy our ability to provide both cohesion and diversity in our community.

That's why we need to create an incubator responsible for welcoming new projects joining the existing community. It will have to make sure that the joining team has everything it needs to be able to work and is properly introduced to the culture and the rest of the community (or at least the parts they have potential to share with). I think it's a very interesting topic on a human level and because through it I'll have to keep thinking about the overall culture of our community. I'm currently working toward setting up such a KDE Incubator with Paul Adams and Wade Olson. We're looking for input and feedback on that particular topic, so please feel free to join the corresponding BoF on Tuesday 4pm, room B2.

And that concludes this series about the manifesto genesis and its implications, I hope you liked the read as much as I enjoyed the writing. As you can see during the big evolutions of our community we go there and back again. This evolution seems to have cycles. Indeed we went on a journey to reach the creation of the KDE Manifesto, and now we're back home looking at what are the consequences of it on our community. We're also better prepared to create more tools to sustain the growth of our community, like the ones I mentioned above. Let's put our passion to the service of the community and let's work together toward those goals!

This post is part of a series about the KDE Manifesto

As mentionned in my previous post, I have been on a very needed hiatus from public communication. It also means that I delayed indefinitely my series about the KDE Manifesto. If you don't remember the first part, I advise you to read it again first. Now... Let's resume the story telling.

We've previously seen why we needed a tool to answer this question of "What is a KDE project?", in this part we'll see how we tackled the task which led to the KDE Manifesto.

Because of all the events and the questions without answers related in the previous part, some people finally noticed some actions were needed and that we couldn't ignore the symptoms any longer. At one point the discussion started in the KDE e.V. about trying to provide a definition of what is a "KDE project". Then in the KDE e.V. was created a small team which had the mandate to create that definition. I had the honor to be part of that team, and the other members were Cornelius Schumacher, Eike Hein, Ivan Čukić, and Sebastian Sauer. We should really be grateful to the work they put in that task (I know I am).

We started with the right first step in my opinion: collecting feedback from the community and from different projects to see how they perceive themselves and the community. But doing it this way had a downside, we ended up with way too much data, and got completely overwhelmed. That was clearly not easy, and everyone being busy as usual at some point the data got ignored, collecting dust in a dark corner of our hard drives. The team became completely dormant and no communication was going on anymore.

Until... one night... I don't really know why, I picked up everything and tried to map it on paper. I extracted criterias and definitions out of the pieces of text we received. After all, I used to do Knowledge Engineering, that couldn't be an impossible task! That's when I noticed why we felt overwhelmed and silently gave up on the task at hand. If you took all the criterias and considered them equals (which was our mindset all along), you could end up only with a tautological situation: "A KDE project is a project considering itself part of KDE or started by a known KDE contributor". Not a terribly useful outcome, but at least I then knew how to move forward.

I asked the membership of the KDE e.V. to change our mandate in order to move away from trying to define what a KDE Project is and instead determine which characteristics we want KDE Projects to share. It sounds similar but makes a huge difference, you're not working on a closed check list anymore. It made for a much more open space, and not all feedback could be treated equal anymore, there definitely was noise in there.

Once that change of scope got accepted, I summoned the original team again to set up a meeting at Akademy 2012 to work together on the data again. With the given mandate, it was likely not possible to nail it down in finite time remotely. Since not everyone could make it to Akademy, we had to reshuffle the team a bit to make the meeting happen.

And so the meeting finally happened at Akademy, after the KDE e.V. general assembly in presence of Alex Fiestas, Albert Astals Cid, Carl Symons, Cornelius Schumacher, Mirko Boehm, Pradeepto Bhattacharya and myself. We were looking at a very long and intense brainstorming session to go through all the notes which were collected the past months and try to make sense out of them... We all know how this kind of brainstorming sessions can quickly go out of control and be in the end fruitless. That's why I came with an experiment to propose.

Instead of debating the outcome, I proposed a very light process, in the form of a tuned "Prune the Product Tree" game. This game is part of a set named "Innovation Games" which are good for market studies, or emergence of answers to very broad questions like the one we were tackling.

The basic idea is that we went through all the feedback we got, and for each piece of information found, we tried to determine where on the tree it would fit:

  • On the floor if that was irrelevant, or mentionned as something we should avoid as a criterion in the future;
  • On the roots if that was something supporting the community, something the community couldn't function without;
  • On the trunk if that was something central to the community definition;
  • On the canope for anything less central, and derived from the rest, further away from the trunk as it was more refined by-product, in other words consequences from what was on the roots and the trunk.

And so, while playing that game (it's a serious game, but a game nonetheless so it has to be played!) we obtained the following tree:

tree-thumb

That's when it struck me... We're not really creating a definition, we're creating a manifesto. On the roots and the trunk it was clearly on the values level, while on the canope you could see practical consequences of those values. I suggested the rest of the team to work on a document which would follow this form: the real manifesto talking only about the high level values, and then extra parts for the practical consequences of those values. This proposition was accepted by the whole team.

Before parting, we also decided to sanity check our result and get an idea of its impact on existing projects. We took a few sample projects and examined them through the tree we produced. Obviously sample projects which were already KDE projects would have to fit, and for sample projects which were not KDE projects we would need to easily identify the blockers for them to join. Reassured by this last check, we parted ways and the editing work started.

I ended up carrying that editing work. I took inspiration in the Agile Manifesto and the Software Craftsmanship Manifesto which went through this kind of exercise before us ("stand on the shoulders of giants" they say). While creating the different drafts, I proposed them to more and more different people, collecting feedback and amending as I go. That led us to the release of the KDE Manifesto in its current form. It is definitely not a document set in stone, I keep collecting feedback and I plan to push updates to the manifesto in the future. I expect the main page to be rather stable, but we'll probably see the rest of it change with time. It seems I turned into the de facto curator for the KDE Manifesto, it's something I try to approach humbly as to not betray the spirit of KDE.

And that concludes this genesis of the KDE Manifesto... it is definitely not the end of the process I mentionned in my previous post. We're really on the doorstep, this document is more or less our late constitution, it's up to the community to choose the path from here. I'm pretty sure it will be full of adventures for the years to come... That's why, even though I generally avoid to do that, in the last part I will try a small exercise in forecasting and see which changes it might bring to the community.

This post is part of a series about the KDE Manifesto

So the cat is finally out of the bag... The KDE Manifesto has been officially announced. It probably came as a surprise to some of you, and since I got a unique perspective in its birth I thought it'd would be a good idea to blog about it to give some background information.

So why this unexpected party and the sudden release of this document? Well, like most unexpected events, it is the realization of an unnoticed process set in motion a long while ago. I think I would have a hard time to pin point exactly when the need to have such a document appeared in the subconscious of the community... My opinion is that it should probably have been done a few of years ago. I'm sure of one thing though, it became necessary because our community evolved in a way that its creators didn't expect.

Now, let's jump back to October 14th 1996, a student named Matthias Ettrich sent an email announcing a new project. If we examine this announcement today, what is immediately obvious? Let's see... It was an energic call to arms. It was very developer centric. It laid down some of the main technical choices. It was limited in scope by providing a list of the components a desktop needs. Also, at the same time it pointed out that more than what was listed might be needed, claiming it's a very open project.

After this announcement, people started to join and to happily work on KDE. They clearly delivered, release after release, KDE was getting bigger and better. Nobody really thought about the community which formed, it was all about the technical artifacts (which is totally fine, I'm not judging). This trend continued for years, pushing KDE (the desktop) toward its popular success, while the community making KDE was growing.

It's time to fast track to the year 2006! The community behind KDE is busier than ever (the first KDE 4.0 alpha will be released the following year), and all this activity shows how big and complex this community became. Teams formed, not every team progressed at the same speed or had the exact same vision of the whole. Clearly something happened in our community which changed it.

That same year we had Akademy in Dublin, probably one of my favorite Akademies. And remembering that particular edition two things struck me:

  • The first one is Aaron Seigo's keynote which was subtitled "The Quest for Project Identity and Definition"... Interesting, in retrospect, isn't it? But lots of people probably attended it, I won't spend more time on it, you probably got the idea from the title.

  • The second one got probably unnoticed to most. It is one of those tiny details which are really precious because the event passes quickly... and somehow I remember it vividly, it touched something in me and stayed in my memory. During that Akademy, Matthias Welwarsky was chairing the community track of the conference. During one of the introductions, and probably in reaction of the keynote mentionned above, he said that to him "KDE is not a project anymore, because a project has an end, it has become an on-going process".

And here it is... I think that in one sentence, Matthias Welwarsky has put the biggest change which happened to KDE in plain sight. The event which was unforseen by the creators of our community, at some point between 1996 and 2006, KDE became an "on-going process". And that's right, if you look at the original announcement of KDE, all of the goals set there were reached in 2006...

KDE was still operating, but in the unknown, what is this "on-going process" trying to solve? Nobody could provide an answer to that question anymore. Somehow we created something self-sustaining which was delivering more and more software.

It took a few more years before someone really tried to visit what was going on and to characterize what KDE meant... At that point it was clear it wasn't simply about KDE the desktop anymore, the community was doing much more than that. That's why in 2009, our marketing team took the lead and announced the repositioning of the KDE brand. KDE wasn't a product brand anymore, so not a single KDE the desktop anymore, but it was a vendor brand. It meant that from now on KDE the community was producing (among other things) a desktop. The new word on the street was "KDE released KDE Platform 4.5", "KDE released Kontact 4.7" and so on... Quite a change of perspective!

I know some people didn't really like the marketing team taking the lead on that... I don't have a strong opinion about the exact content of the repositioning, but it clearly was the tip of the iceberg of the mutation of KDE. It had the merit of making it explicit at last!

At the same time, despite such a brand repositioning being welcome, it was not enough to address the changes in our community. It emerged because we kept going after reaching the goals set in 1996. It emerged because we were creating more and more diverse products: development platforms, workspaces, desktop applications, mobile applications, even server applications (Kolab was born in our ranks, ownCloud would appear in 2010). But, it didn't allow to answer "what is a KDE project?".

And that's pretty much the situation we were at in early 2012. "KDE" is the name of the community, and this community makes products. So we're in a situation where "a project is a KDE project because it has been created by people in the KDE community". It's not exactly satisfying though... What if someone from the community creates a database system? is it a KDE project? (hint: the answer depends on who you ask) What if someone outside the community creates a mobile application? can it join the KDE community? under which conditions?

I'm not making this up. Those are real questions which arose over the years... and we never had a tool to help us devise a proper answer. We dealt with that in an ad hoc manner, and it was a growing pain. I'll go as far as saying it had potential to hurt the cohesion of the community.

That's what we're trying to fix, and we'll see how in the next post of this series. :-)