In my previous post I played with the team size and activity metrics on several communities and see what would come out of it. Interestingly, to me this wasn’t necessarily the most interesting of what I posted (it’s rather basic in what it presents) but somehow it’s the one which triggered the most comments, especially in the KDE community. Looks like I struck a nerve. :-)
Anyway, it got quite a lot of good comments, so I thought it deserved a follow-up post with a different tone. For the record, I generally try to avoid putting too much of my own personal opinion in posts where I present metrics. I think it’s sane to try to shield facts on the data from my biased position. It’s obviously super hard, if not impossible. Indeed, at a minimum I’m forced to mention potential events in the time frame considered (if I know them)… it’s risky, but still I do it because otherwise things would be just very dry and super annoying to read! And I think that’s why the previous post struck a nerve, but more on that below.
In the rest of this post, I’ll pick extract of the comments I got, in no particular order, followed by my own opinion. So contrary to my usual “data posts”, the cursor between factual presentation and opinion piece will very much point toward “opinion piece”. Be warned! ;-)
I got a very nice comment from Florian Gilcher, I won’t address it all, but I’ll add my reactions to some of the extracts.
This doesn’t mean that we have an explanation for everything. But I can certainly say that the slowdown in 2015 is a couple of people going on holidays and taking some time off for once. There was a lot of exhaustion and also tension in the community at that time.
Thanks a lot for the confirmation! When looking at the history of the project from the outside it seemed the most logical conclusion, glad to see I wasn’t far off for once. ;-)
While I agree that we will probably not hold this growth forever, we are doing a lot of intentional work to make that happen. One of them is constantly reorganising the project and actively pulling people in.
That’s what I got from attending a couple of RustFest. I was very much impressed by the efforts going on into growing the community. It’s very proactive and welcoming while KDE has a more passive stance even though it’s a very welcoming community as well.
We take a very clear stance that we want to recognise all work that people have done for the project and invest time in that, for example with projects like https://thanks.rust-lang.org/.
Wow, didn’t know about that page! It’s a great idea. I wonder if KDE has something similar, it’s probably worth producing. Each application has an about box with some people, but there’s nothing structured for the frameworks, also I like the breakdown per version used by Rust. Probably something I could script, I’ll look into it I think.
We try to keep all processes as lean as possible and especially don’t try to impose a huge process on first-time or small contributors. Contribution effort should scale with the size of it.
This is an interesting concern. Instead of going for a one size fit all contribution model. To be kept in mind for sure.
Also, I don’t want to say that we do everything right - the contrary. But we have gotten our project used to reflection and change.
Right, I think it’s important to maintain a culture which allows both to pass the wisdom of older contributors while also being open to change.
From Florian Gilcher still, we got a point about tooling:
Talking a little about your readings here: In contrast to other comments, I don’t find it unreasonable to attribute the bump in KDE to the change of tooling. […] Free contribution also means that leaving is easy. And some people don’t want to pay the mental tax of learning new tooling.
Of course I agree with that, and I think that’s why KDE lost some of the old guard and quite a bit of the drive by contributions (Git was really painful at the time). Also, on top of the mental tax of learning the new tooling there’s Conway’s law to take into account, a switch means organizational changes which in turns mean quite some communication generated by it, updating our wiki pages for on boarding, team building and so on.
And we got a similar stance from Anton Latukha as well:
I strongly agree on “documented process of 100 steps or to follow” for contribution versus “documented process of 5 steps”. It is so much, that I wanted, but really never bothered to contribute. It is just too much rules and info to fit-in myself for me to make drive-by commits.
I strongly agree with that point of course! It’s not related to the “was the dip caused by the switch to git” debate, since most of the reasons why it’s hard to contribute to KDE predates that switch anyway. But it’s a very important thing to keep in mind if we want to improve. We don’t get as many drive-by contributions as we could and it’s unfortunate. People expectations are that it should be much easier than it is. That’s why at last year Akademy we gave the talk Looking at the Application Developer Story with David Faure.
Of course there’s also another position on that debate which consider the tooling as irrelevant in the contribution history of KDE.
First from Luke Parry:
In short, the excitement has gone. KDE has just become a utility that works pretty well for a DE. Yet, It is not pushing any boundaries of how we interact and work with a desktop.
It’s indeed another factor to take into account and I agree with that. For some parts, KDE is just a commodity people are glad it’s around and since it’s not exciting enough anymore they don’t feel compelled to contribute. Note this is worrying though because it means the community (not the software) has fallen in a kind of Tragedy of the Commons trap. That’s why I think it’s important to hear the comments from Florian above, they show a path forward: the KDE Community should be consciously groomed like a proper common (aka we’re doing great on the software side, not so much on the people side).
Then we got comments from Martin Flöser who are very much on the “switch to git is irrelevant” side:
Personally I don’t believe in the git theory for the kde community. It just doesn’t fit. KDE is a highly technical community, our code has partially a superb quality. Why should the community metrics change just because the introduction of git?
I would say: just see Florian’s and Anton’s comments above. There’s a cognitive cost to such changes, especially when git was really a pain to use.
Instead I would rephrase the question: what resulted in the 2010 peak? For this I see two main events in the KDE community: KDE 4 and Nokia buying Qt.
I agree about KDE 4 resulting in more activity, but not all the way to 2010. As for Nokia, well… I really don’t think it brought much more to KDE than extra sponsorship. One particular project saw extra contributions due to Nokia, but it wouldn’t account for a big increase in activity by a long shot.
After the release of KDE 4 new developers were brought in.
That’s the thing, we always had a strong contributor influx. Except during KDE 4 preparation (it was very hard for people to join because everything moved all the time as the increased activity indicates) and after 2010… which is where we’re debating the reasons still. :-)
If I remember correctly you still were a student at that time (or did you already do your phd?)
I already had my PhD at that time. Besides, I don’t know if it goes like this for all PhDs everywhere, but it was really a full time job in my case. I was definitely not working like a student anymore through my PhD. Anyway, very specific and not very relevant so I won’t dwell on this more. ;-)
So what did happen around 2010 that we did not get the new students in? My answer to that is Bologna and Android. From talking with Bachelor students around that time I got the impression that they don’t have the time anymore to do things as open source development next to their studies. The second thing I mention is Android. I think for students we were no longer the interesting and attractive community to join. Why hack on the old thing if you could do Android apps?
I think that’s where we touch the crux of the issue in this debate. I very much agree with the KDE 4 impact and the commodification of the KDE products. Now, I tend to ignore them because we can’t act on them, and that’s why I talk much more about the tooling: I know we can act on that part!
And that’s where you disagree, you think that the tooling change had no impact on the existing community. Well, I’m pretty sure at least part of the “previous developers” were driven away both because of the personal reasons and the change of tooling. The two collided, learning new half done annoying to use tooling while having less spare time? No way they’d do that. Remember git back then it’s was really very difficult to learn with all its quirks.
Second reason why the tooling matters: the students changed. It’s not only about the time available and making Android apps being more hip. Post-PhD you might remember I was involved in an University program setting up student projects. They had the time, they had cool things to pick from, so only stuff they were motivated to work on. Still, over the years I could see it was less and less natural for them to contribute to KDE. There has been a strong cultural shift I witnessed over the course of a few years.
It became much easier for them to use git, but the paradox for me is that it became much harder for them to use the rest of our tools. Somehow as various generations of students became more skilled in Git, they also became more influenced (or brainwashed, pick your position) by the GitHub contribution model. And nowadays it’s for them the only true way of contributing. Our current processes for contributing are thus looking very alien and preposterous to your average student. I don’t like that, but that’s what I witnessed.
Also Dominik points out git is a standard:
But git is the de-facto standard, it’s not to blame for the decrease - well, at least not in the last 5 years.
Yes definitely. I was thinking of “git back then”, which is in part why we lost a fair share of the old guard as mentioned above. Nowadays git is fine, but as I mentioned above the other tools seem to get in the way for new contributors.
We got a couple of interesting points from Boudewijn as well revolving around comparing projects:
I think you should superimpose the rust graph on KDE’s graph — put the current 2018 location on KDE’s 2010 location. Everything has a hype curve, skyrockets, drops then settles.
Yes, I definitely agree there and I mentioned that at the end of my previous post: the Rust curves currently look similar to KDE early days. That being said even if we do what you propose with the curves, there’s still a difference between KDE and Rust in my opinion. Their team size and their commit count variations are much more strongly correlated than for KDE. The only time KDE had it in a similar fashion is roughly for its first five years as far as I can tell after quickly checking. They kept that almost twice as long now. This is interesting in itself I think.
It would also be interesting, but controversial, to make this graph for larger kde projects – libs/frameworks, plasma, krita/calligra (that doesn’t matter much, krita was always the larger part of koffice/calligra development), kdenlive, digikam, pim.
I don’t think this would be controversial. And that’s actually one of the gazillion things I’d like to do… so many angles to look at those things, I can keep myself busy for the next ten or twenty years I think. I kind of touched it a bit for PIM in my previous posts by the way.
Sho opened the debate on the commit count metric itself:
I think our commit count going down has a lot to do with how we do code review - which we didn’t do before.
This could be a factor for the 2010 drop, I somehow doubt it is a strong one because I seem to recall we were already doing reviews in 2009. Now I agree that we likely increased the amount of reviews at some point, but it didn’t take 6 years to do that. That’d account for some of the decreasing trend but not all.
This makes it difficult to assess activity by comment count alone without looking at diff sizes too.
Yes, this is something I’d like to explore better. Currently I use commit count for the activity, but I know it’s a poor proxy for it: not all commits are born equal and also reviews is work and collaboration. The reviews I can likely get a partial history through the Phabricator API, but that will never go back many years. For the “value” of a commit, I still didn’t find an approach I liked from what I drafted… still looking for one.
Finally, I got an unexpected comment from Anton Latukha regarding Phabricator:
Phabricator community/development is already virtually dead: https://www.openhub.net/p/phabricator
Obviously a very important point… It’s really a shame because I personally like Phabricator quite a bit despite the fact it looks foreign to a fair share of our contributor base. Of course it makes things concerning since it became a very central piece of KDE’s infrastructure.
Really it pains me (did I say I like Phabricator?) but between Phabricator’s declining contributor base and what I’ve seen with students who consider it confusing, I wonder if we should reconsider it. I hate gratuitous tooling changes (see my points on their price above) but it looks like the price of staying with that particular choice might sooner or later increase by a lot… and it’s already high (see my points above about it looking alien to nowadays students). :-/