@federico also proposed that idea to his 2024 board candidacy, see:
In general for such matters there is not a single person with the idea, itās a collaboration. I thought @ebassi would mention it.
As for the maintainer role, I think itās useful for a developer to feel to fully own some parts of the code, in order to arrange the code so that it has the style that the developer is comfortable with, so that that developer fully understands the codebase, and itās easier for that person to reason about the correctness of the code.
It means in practical terms: being comfortable doing lots and lots of small refactorings to an old codebase.
If nobody feels comfortable doing that because itās a āteam effortā, Iām afraid that legacy code will stay that way during a longer time.
Psychologically it could be harder for someone to do such huge efforts to modernize a lot an old codebase.
But I totally agree that there is a feeling of isolation with all the developers working on separate modules. (And indeed a risk for the mental health: stress, burnout, depression).
I donāt think I agree with this! Itās open source, people come and go, and one day someone else will be the maintainer. We should always be thinking in the back of our minds about making code comfortable, understandable, and easy to reason about for other contributors. And in the long term we should be thinking about succession planning.
For me personally, when I just read some piece of code (a class), I only understand the implementation superficially (except for trivial classes). To have an in-depth understanding of a class that I want to improve, I usually need to modify the code beforehand. To see how it works. And I better understand the code afterwards when it follows the style that Iām used to (it includes variable names, function names, how to split the work into functions, etc).
The maintainer role currently provides that freedom. Doing releases is a small amount of work for the maintainers, for me the main thing of being a maintainer is what I described. That is, having the liberty to modify the code freely. (Thatās more true for single-maintainer projects). And I encourage that practice. (For multi-maintainer projects, the developers involved can assign some code owners for certain classes or subsystems).