One of the biggest problems of working in such a large project as Gentoo, is that there’s always a lot of work to be done. Once you get engaged deeply enough, no matter how hard you’re going to try, the backlog will just keep growing. There are just so many things that need to be done, and someone has to do them.
Sooner or later, you are going to start facing some dilemmas, such as:
- This befell me, because nobody else was willing to do that. Should I continue overburdening myself with this, or should I leave it and let it rot?
- I have more time than other people on the team. Should I continue doing the bulk of the work, or leave more of it to them?
- What is the right balance between reviewing contributions, and doing the work myself?
In this post, I’d like to discuss these problems from my perspective as a long-time Gentoo developer.
Doing what needs to be done
There are things I’ve taken up in Gentoo simply because I’ve found them interesting or enjoyable. However, there are also some things that I’ve taken up, because they needed to be done and nobody was doing them. And then there are things that fall somewhere in the middle — like in Python, where I enjoy lots of stuff, but this also implies I’m ending up with a lot of thankless work. And I don’t believe it’s fair to just do the nice part, and ignore the hard part.
The immediate reasons for taking up these jobs vary. Sometimes a particular problem affected me directly, so I stepped up to resolve it — this is basically how people end up joining the Gentoo Infrastructure team. Sometimes I’ve noticed something early that would be a major hassle for users later on, and I’ve taken it up. Sometimes I’ve noticed that many users are already complaining about something, and that something needs to be done.
But then, what next? Let’s say I’ve ended up doing something that’s not really a good fit for me. I keep sending calls for help, but receive no offers. Now I’m facing said dilemma: Should I continue overburdening myself with this, or should I leave it and let it rot?
The truth is, sometimes abandoning stuff is the right thing to do. It has major drawbacks: it affects people, and makes the work pile up. However, it also makes people more aware of the problem. Sometimes it’s the only way to have another person pick it up. At other times, it makes more users aware of the problem and they can offer to help.
However, it’s never an easy choice to make, and should you make it, you are never sure if it will actually work. It may turn out that you will eventually have to pick it up yourself, and have to deal with all the resulting backlog.
Doing work yourself, or letting others do it
There’s a proverb: if you want something done right, you have to do it yourself. Perhaps it’s not the nicest way of putting stuff. Let’s frame the problem differently. You are person in the best position to do something. You are flexible, you can do things the same day, while others need two or three days.
So, there are advantages and disadvantages to doing things yourself. On one hand, it means things get done sooner (so users benefit), and people who are more busy with their lives aren’t distracted by stuff that you can do. On the other hand, it means that if you are already overburdened with work, you spend time on things that others can do for you, instead of on things that only you can do. Others have less opportunity to practice doing stuff, and in the end may even get discouraged from actively contributing.
The last part is actually the biggest problem, it’s a bit of chicken-or-the-egg problem. If you’re more experienced, you’re better equipped to deal with problems. However, this means that others don’t get an opportunity to gain the experience and become better. And this in turn means that the actual bus factor is not as high as it could be — you have people interested in doing stuff, but they don’t have the training.
This is where the dilemma comes in: Should I continue doing the bulk of the work, or leave more of it to them? Sometimes it’s not that big of a deal — in Python team, the version bumps are mostly a sliding window kind of work. I do the bulk of bumps every morning, and others join in at different times. But sometimes this isn’t this easy.
And in the end, you never really know whether things will work as expected: if you start doing things rarer, giving more time to others, will they actually find time to do them? Or will it just mean you’re going to end up doing more the next time, and at the same lose your perfect track record of response time?
The balance between doing and reviewing
As any Free Software project, Gentoo has a thriving community. A part of being developer is accepting contributions from this community. Unfortunately, reviewing them is not always easy.
Sometimes it is, for example, when a pull request is addressing a very specific problem, and you just have to look at the diff, and perhaps test it. At other times, reviewing actually takes more work than doing things yourself. And then you have to strive for balance.
For example, let’s consider an average version bump. How you do it yourself is, roughly: run a script to copy the ebuild, check the diff between the sources, update the ebuild, test. Sometimes it’s trivial, sometimes it’s not — but it’s all pretty streamlined. Now, if you’re reviewing a version bump done by someone, you need to merge their commits, diff the packages, diff the ebuilds, test. Most of the time, it means you’re actually doing more work than if you were doing it yourself — but this is fine so far.
The problem is, sometimes the user doesn’t do some extra maintenance tasks you’d do (not blaming them, but it’s something you want done anyway). Sometimes there are mistakes to be fixed. All these things multiply the work involved, and delay the actual bump (effectively affecting users negatively). You need to leave review comments, wait for the user to update and try again. Rinse and repeat.
The worst part is that you’re never sure if it’s worth it. Sometimes you don’t even know if the user is really interested in working on this, or just wanted to get it bumped. You spend your time pointing out issues, the user spends their fixing them, and in the end you both would have preferred if you’d have done it all yourself.
The flip side is that there are actually promising contributors, and if you go through the whole effort, you’ll end up having people who you can actually trust to do things right, and it pays back in the end. Perhaps people who are going to become Gentoo developers. But you have to put a lot effort and take a lot of risk for this. And this isn’t easy when you are already overburdened.
If you get the balance wrong on one side, you get things done, but you get no new help and the project eventually dies. If you get it wrong on the other side, you waste your time, get no benefit and don’t get other things done.
And then LLMs come and promise a new hell for you: people who could be (unintentionally) making pull requests with plagiarized, bad quality code. They submit stuff with the minimum of effort, you spend a lot of effort reviewing them, only to discover that the submitters have no clue what they’ve sent in the first place. That’s one of the reasons Gentoo has banned LLM contributions — and added an explicit checkbox to the pull request template. But will this suffice?
Summary
In this post, I’ve summarized some of the biggest dilemmas I’m facing as a Gentoo developer. In fact, we’re all facing them. We’re all forced to make decisions, and see their outcome. Sometimes we see that what we did was right, and it pays off. Sometimes, it turns out that things end up on fire, and again we have to make a choice — should we give up and run with the fire extinguisher, and go back to square one? Or should we just let it burn? Perhaps somebody else will extinguish it then, or perhaps it’s actually better if it burns to the ground… Maybe it will turn out to be a phoenix?
Protect yourself. Step down. Do what you need in your private space, and don’t push it to the upstream (here, Gentoo), or keep it minimal, like only indicating the outline. In the long run, it will be your best. You have already done a lot, and we (I) really appreciate and respect you, Michał.
This is repeated. Many experience this sooner or later. It’s true that every FLOSS is understaffed, and Gentoo does not excel in this part, but usually (or, it always has been?) younger folks save the situation.
This time it may not be the case. Then we may have to give up Gentoo. Anyway we have to accept the situation, and nothing more than that.
You must already know and be aware of all what I said, but this is what I can do for you.
Let me repeat again I’m really grateful for what you have done.
My take on this:
* if you feel overwhelmed, pause a bit, but not forever
* reduce the trivial things, focus on core problems, like automation
* prepare tools & path for younger to take part in project easier
* document the above