Yep right hello again,
let's talk about i'm sure most of you have seen this picture at some point we're
going to talk about laser pointers broken but you know who i'm talking about
that guy what does he do who is he Why is he doing it?
So we're talking about maintainers. What is a maintainer anyway?
Chances are the maintainer of a certain project is the original author of the project.
It's often the case, doesn't have to be the case, but let's assume it is.
Then they are also likely the lead developer of the project.
And also what in a corporate world one would call a software architect.
Then when the project has some form of UI, chances are they are also the designer
or the UI designer, the UX designer of that project.
Whether that's a good idea or not is up for debate, but more often than not, that's the case.
They are also likely the one who takes care of CI and CD infrastructure and
are a sysadmin for the website of the project or any auxiliary build and promotion infrastructure.
Then chances are they're going to take care of packaging for various app stores
or package managers, distributions and so on.
One, already mentioned, system administrator for various things.
They're also the one who set out the guidelines for what's happening with the
project and the product. So in a way, they are a product manager.
And some people like to say the most important thing a maintainer can say is
no to contributions that don't fit the vision of the project.
They're also likely the one doing bug triage and bug fixing primarily,
dealing with user support, questions, complaints, and everything.
And once you have a certain community around you, of which about a third is
reserved for sleep and most or a lot of maintainers don't only do that in their
free time, which is very limited.
And so things can get rather slow.
There's also risk of bus factor, because if there's one guy or one person taking
care of everything, if that person, something happens to them,
doesn't have to be a bus, then that project is in trouble.
And then there's the saying, jack of all trades, master of none.
And when you have to take care of all of these things, then you are very quickly
a jack of all trades, but not necessarily a master of anything.
And with all of that, it's very, very likely that the person is at risk of burnout.
And once you're at the point where you kind of burned out of the project and
people keep coming to you with things to do and suggestions and complaints,
you develop a sort of siege mentality where you block off any attempt at challenging
the status quo and just refuse to do anything differently, even if it's a reasonable request.
So a single maintainer project can quite quickly devolve to a dictatorship over that project.
So, how do we do things in KDE? Most KDE projects don't have a formal maintainer.
For frameworks, we even explicitly remove that information from the metadata
files because quite often it was wrong anyway.
And quite often we have something that Nates likes to describe as a council
of elders, which is a couple of senior developers that do a lot of the things
that the maintainer is supposed to do and make decisions about the project.
Then we have a sysadmin team that takes care of CI infrastructure,
website infrastructure, build infrastructure, email, a ton of things.
We also have people looking after websites. We have a bug squad that takes care of bug triage.
We have a visual design group. We have a promo team.
We have KDEV taking care of a lot of legal and financial matters that nobody wants to deal with.
We have people dedicated to doing user support.
We have translators because no single maintainer can translate for all languages.
We have distributions that take care of packaging and some form of user support.
And generally, we have a community. And I think that's what makes KDE not unique, but special.
Is this all fine and dandy and perfect? No, there's some unique risks and challenges to that.
One of them is fragmentation of the community. If you have individual groups
or people taking care of things, then things can get quite fragmented.
And if those groups don't talk to each other, there will be conflict.
Then there's overhead to it. If Plasma needs to wait for SysAdmin or SysAdmin
needs to wait for Plasma or anyone waiting on anything introduces a lot of communication
overhead and delays and generally not pleasant experiences.
And when you are able to focus on only one thing, you may or may not become
master of that thing, but you only become master of one thing and don't even
get close to being a jack-of-all-trades.
Then not only does the community fragment, the knowledge in the community fragments
because very few people outside of Ben know how to run our infrastructure which
is causing bus factor issues,
and there can also be a lack of ownership
about some parts of the code that a community so if somebody writes something
then disappears and then nobody feels like they should be careful care for something
that thing can rot and if then somebody comes and wants to do something about
it but no one's around to review and merge patches for it,
that can cause a lot of frustration and issues for new-time people.
Let's think about all of those. And with that, I'm done.
Thank you.