Blogs

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!