Blogs

OK, it’s been a while since I blogged about community data analytics… I thought I’d do more posts on the matter but somehow never managed to get back to it. Now it’s a bit more than 6 years since my last post on the topic!

Worry not though I didn’t loose touch. Indeed I still hone this skill professionally since it’s an excellent source of information to better target audits or to give better advice when consulting on software architecture. This is by the way exactly what my last post on the topic was about. But this is not what we’re here for today!

Indeed, in a few weeks, KDE will turn 30 years old. This is impressive in terms of longevity for such a community. We’ve fostered a very diverse group, people are coming and going of course… So where does KDE stand? Are we looking at 30 more years or is it on a darker path?

It took a quick look at how KDE has been growing and shrinking as part of a post about communities size and activity. It was a quick peek only (I needed to look at other communities too) and 8 years ago. Time to revisit it all and with more details! Time to brace yourselves, it shall be a somewhat long read, we have 30 years to explore, but more importantly we’ll look at several subcommunities separately.

Choices, improvements, and caveats

For this article I made a couple of choices. I decided to give the current article the same angle than the 2018 one about communities size and activity. So I won’t show some of the more advanced diagrams I can produce and will stick only to the easy to read “team size” diagram and the “activity” diagram (the beloved “colored blobs” diagram).

For the latter, I also decided to anonymize the contributors, so no need to zoom to try to find your name, you won’t. I generally leave them when I’m doing more focused work since we mostly know who is working in a given team, but here I’ll be casting a very wide net and I don’t feel some people to feel uncomfortable because their name appears. Hopefully this should limit ego trips.

Note however, that behind the curtain I did produce “contributor network” diagrams (more advanced, more expensive, harder to read) without anonymization. They won’t be included in the article, but if I happen to mention some people, it’ll likely come from prior knowledge that I validated through those diagrams.

The last choice I made which deviates from previous explorations is how I map identities. I usually went for names and used manually curated rules to normalize such names. Some people are not really consistent there with sometimes three or more variations (looking at you Aleix 😉) hence those rules. Now doing this for all of KDE over 30 years… let’s say I didn’t have the time to update my rules this time around. Also, we’re having more company sponsored development nowadays so I decided to use emails. That means for instance that I represent two different contributors depending if I’m using my kde.org or my enioka.com email address. It doesn’t seem to skew too much the data, probably less than not having normalized names. For finer grained explorations it also helps figure out if a given contributor was doing something on company time or his own time (not everyone has that discipline but so be it).

Now let’s talk about improvements compared to previous related articles. Roughly speaking I tended to look only at repositories with C++ in them: libraries and applications. This time, I changed how I built my corpus of repositories (the switch to GitLab made things easier too) and I’m covering as wide as I could. It’s important because we’re doing more packaging work nowadays and also we can get a glimpse to the sysadmin activity.

But that’s also where lay the caveats…

I didn’t include the kdelibs repository this time, to reduce chances of counting some of the commits happening during the KDE Frameworks transition twice. This means we’ll have the very early history missing and the one we have will be underestimated a bit. But from previous explorations this shouldn’t distort things too much or change the trends we’re going to see anyway. I double checked this by also running experiments with kdelibs included on the side so I’m not worried. It’s worth keeping in mind though as if you use a fine enough comb you might spot tiny discrepancies.

Another problem to keep in mind is that I had to exclude the KDE Neon repositories. This is quite unfortunate but the majority of them started as forks coming from Debian or Ubuntu and so they pulled many commits unrelated to our community activity. The volume of those commits was unfortunately high enough that it’d completely skew the data at important points in time to have a readable history. Sadly I couldn’t figure a way to reliably sort between the commits to keep and the ones to reject hence why I left it completely out. Still it is something to keep in mind as well: later years are slightly underestimated. Hopefully not by much but I have no way to check.

However the Snap packaging and KDE Neon Core efforts are included as those were easy to split from the rest.

OK… with all those disclaimers out of the way time to look at the result.

30 years of KDE history

First let’s take a look at the teamsize plot for the whole community. It is an updated version from my 2018 post. Back then it was the only one we looked at. Of course, keep in mind I did things slightly differently as explained in the previous section.


What can we see here? (I recommend looking at the full page version for all the plots) First striking thing is a similar profile to the plot I did in 2018 for the 1997 to 2018 period. Which is good news: what I wrote in 2018 isn’t invalidated by the adjusted and improved method I used for data collection.

Back then I noted that the active part of the community had been growing all the way to 2010 then started to shrink again. This is what we see, it peaks around 180 on average (and sometimes reaches towards around 200 people) then shrinks again hitting bottom around 110 persons on average in 2017.

We had no definite answer about why we’d seen this decline. The best shot we had is work done by Paul Adams and presented at Akademy 2014 pointing out that the community cohesion started to drop around the same time. This kind of pointed to the switch to git which could have demotivated some of the existing contributors. Also we didn’t have a really good forge on top, so it was harder to have a consolidated view of what was happening in all of the repositories IMHO.

Alright, but 2017 is almost ten years in the past… Since then, we had two major events happening. First, 2018 is the year where we had the first set of KDE Goals being picked by the community, one being “Streamlined onboarding of new contributors”. Second, we had the transition to GitLab which was fully delivered early in the second quarter of 2020.

Interestingly, we see the team size starts to pick up again towards the end of 2017. This is around the same time as the beginning of the KDE Goal process leading up to the first set of goals being selected in November 2017. It is also when we worked on the KDE Vision refresh. Around this period we don’t see the commit count pick up though (the entry count line), the new people probably joining at the time don’t quite compensate earlier losses.

Then later on, we see the team size growing again but this time the commit count is picking up too. It is between the end of 2019 all the way to mid-2020. Could it be helped by the GitLab switch? In any case, this is very good news, in my 2018 post I wonder if KDE would stabilize around the lower value of the time or pick up again… It definitely picked up again!

Now it seems like the team size if around 140 people on average, so closer to the all time high of 2010 but we didn’t fully close the gap yet. Interestingly though, the commit count is much closer to the one we had in 2010, with a bit less people. We even had an all time high commit count in 2023 which surpassed any other week since the creation of the project.

And to make things even brighter, the trends at the end of the plot point upwards. Looks like 2026 will be a very good year. Hopefully the growth will stay stable this time and then the community will be the biggest it’s ever been.

Now let’s take another point of view.


This is our activity plot for the whole history of all of KDE. This is our colored blobs, I won’t focus much on the colors this time, it just says we have some contributors who are constant outliers in their activity. It’s not news and I’m not going to point them out.

Much more interesting is the shape of those blobs. The “bottom envelope” forms a curve and if we look at the angle it has, it is becoming more and more vertical. It’s not always the case we see some inflexion points if we zoom in, but on the whole history it definitely becomes steeper. Including towards the end of 2025 and through 2026 we see it changing again reinforcing the same trend.

This means we’re seeing more and more new contributors. KDE is recruiting new contributors and does so faster and faster. But is it only drive by contributions or people staying for longer?

This is were what’s on the other side of the curve, the actual blobs get interesting. If it’s not very dense and we see “lots of gray” it means people contribute a bit then stop. If it’s dense it means they’re staying around much longer or “forever”. To me, it started to get denser around 2019. So not only KDE is recruiting faster, but it’s retaining contributors for longer. It’s of course not at dense as in the early days but it’s likely the best you can do with such an old, large, and diverse community.

So altogether, I would say that KDE is a community which struggled between 2010 and 2017. It shrunk in the process but has been recovering since then. It feels very strong right now and could surpass the all time high it had in the past if the conditions are right. There are first signs of this: more commits per contributor, recruiting more, and better retention.

Looking a bit closer

At least we established that the forest (the whole KDE) is likely healthy. It doesn’t tell us much about individual trees though. Even healthy forests have diseased trees and that’s OK. Still for our exploration I think it’s good that we reduce the scope a bit and look at sub-communities within KDE to see how they fare.

KDE Frameworks


Looking at KDE Frameworks the teamsize plot seems to tell a very different story than KDE as a whole. There are obvious similarities though. It’s mostly growth since the beginning and until 2010, the slope on that post is not as steep but remember the caveats. Since I didn’t include the kdelibs repository we miss some commits in the early history.

We find the same dip starting in 2010, but there’s a first big difference. It rebounds strongly and much earlier! Around 2012 it picks up already and reaches all times high in 2014. There I immediately know how to explain it because I was right in the middle of it.

We knew we were reaching the limits of the kdelibs model and in 2011 we had the Platform11 meeting. This is where we planned to turn kdelibs into KDE Frameworks. So for us a slow down in the kdelibs area was only natural we were busy making the necessary plans for the architectural transition. The transition itself began to be executed a bit later culminating in 2014 with the release of KDE Frameworks 5.0.

Hence the new dip we see just after. Everyone was tired and things were getting back to normal. By 2015/2016 the activity level was already back to the activity level of 2010.

This explains why I was kind of surprised by Paul’s talk in 2014… I was buried deep in KDE Frameworks and everything looked fine from there.

Which leave us now with the period of the GitLab transition. When it’s fully in effect (2020) KDE Frameworks also grows just like the whole KDE community. It’s oscillating a bit but it looks like it stabilized there.


On the side of the activity plot, we see an overall acceleration in recruiting since the very beginning but it has clear periods of slowing down. Towards the end we find the same profile than for the whole of KDE: it looks like it’s accelerating further in 2026.

That being said in terms of retention, KDE Frameworks isn’t as good as KDE as a whole. But maybe it’s fine, it’s the base of all the projects and by its nature it likely attracts more drive by contributions than anywhere else in the community. We want to mutualize and that’s what people seem to be doing.

This product is not very noisy and just happily churns along it seems.

KDE PIM


KDE PIM clearly has a more complicated history. It starts to mostly grow like the rest of KDE all the way to 2004 and then has a first clear dip in team size starting in 2004. It took three years to recover from it. I’m not sure what caused it… I wonder if it’s related to the great KMail maintainer war I hear about from time to time? It was before my time getting involved in KDE PIM.

Anyway, once the project recovered in 2007 things seem to be going along well with even a small spike in team size and larger spike in commits around 2009. If my memory serve this is when KDE PIM had seen some serious funding last. Then it dives like the whole of KDE around 2010.

It starts to pickup a bit again during the GitLab transition, but not as dramatically as the whole of KDE so something else must sustain that community wise increase. This is a common pattern for the whole of our applications by the way (I did plot it but didn’t include it here as this is already way too long).

One reason to rejoice is the increase of both team size and commits building up in 2026. With some of my colleagues, we might have something to do with this and I’m fairly happy about it. It’s likely not the only factor of course, as I mentioned earlier it looks like 2026 will be a particularly good year for KDE as a whole.


In term or recruiting and retention, KDE PIM is a bit at risk I’d say. Clearly there’s been a slow down in recruiting new contributors starting in 2015. It looks like it’s slowly getting better catching up to earlier times but it took ten years to get there and it’s too early to see if it’ll sustain it.

In term of retention… let’s face it, it’s never been great nor improving. There’s a few individuals who stay around but not many. There’s clearly something pushing new contributors away preventing them to stay for long. For the nature of the product it raises questions. I have theories but no definitive answer so I won’t share them here.

What’s sure is that KDE PIM needs more involvement going forward to be sustainable.

Plasma


Time to our flagship product: Plasma. The plots here include desktop, mobile, and big screen repositories. Note the very early history can’t be trusted, clearly it inherited commits from before Plasma was a thing.

Anyway, in terms of team size it’s been almost constantly growing. We find the 2010 dip but it’s much less dramatic than in all the other plots. It stabilized much quicker and managed to stay with an almost identical team size.

We also find the increase leading up to 2020. And clearly it’s one of the projects which benefitted the most of the GitLab transition. It’s average team size almost doubled during the transition!

Earlier I asked where the increase we could see on KDE as a whole but not on applications was coming from? Well, this is probably it.

Like the rest of KDE, 2026 will be a very good year for Plasma as well. I wonder… will it double in size again next year compared to 2020?


Unsurprisingly recruiting is going well in Plasma if we look at the activity plot. Now the retention has been somewhat spotty, but clearly it’s improving: the density increases as we go down. Keep up the good work I’d say!

KDE Linux


Time to look at the new kid on the block: KDE Linux. There’s been a lot of PR and expectations around this one but keep in mind it’s still young (history starts in 2023). We don’t have many data points yet so it’s a bit more difficult to draw conclusions.

Clearly so far it’s been growing in term of team size. This is good. That said, it is rather smaller than I’d expect from the exposure the project gets. This can be a good thing if it’s because we have a high impact team. But it can be a bad thing if it’s a sign of hyping things up before they’re truly ready to have a bigger team. Time will tell I guess.

What worries me a bit more is that the commit count doesn’t seem to pick up as fast as the team size. Again, we need more data and history to be sure there is a problem. But I’m wondering if we’re seeing early difficulties to synchronize within the team which is eating away at what could be produced. It might be a sign of some growing pains having a hard time to make newcomers truly productive.


The activity plot seems to go in the same direction as my questioning above. The project has been recruiting faster towards the end of 2025 and this year. At the same time its retention rather diminished it seems. It could be again a sign of newcomers not finding their place or simply only motivated by drive by contributions.

Community wise it looks like KDE Linux is off to a good start but needs to strengthen its path on how to get involved.

Conclusion

This article turned rather longer than I anticipated, sorry about that!

We had a quick tour through 30 years of commit data. I would have liked to also process merge requests but at this scale it’s very time consuming so maybe I’ll do it another time on something more focused.

In any case, I’m rather happy that KDE as a whole seems very healthy. The last time I did such an exploration we left things undecided wondering if the community would ever recover from “the big 2010 dip in activity”. I would argue it did and with a few more years like 2026 we could expect to even go above the 2010 levels. We’re seeing early signs of it I think.

As for the projects we explored, flagship products (KDE Frameworks and Plasma) are doing rather well, for the other ones… your mileage may vary, it depends where you look. KDE PIM clearly has long term challenges it needs to overcome while KDE Linux raises questions but nothing unsurmountable. For both there’s likely some community work to be done, something need to be done to have a better retention of contributors.

I’d loved to also zoom in on Krita, Kdenlive, Elisa, etc. There are so many products in KDE!

So it looks like in almost 30 years KDE built a great community and many awesome products. We’re really forming a large and diverse family. Like any large families it can get sometimes ugly or messy but keeping the ties matter. Kudos to all the people involved for the past 30 years! Even if you’re not involved anymore you helped contribute something beautiful and precious to the world. We’re the living proof that large commons can be created and made sustainable thanks to passionate people.