On Wednesday, February 4, 2026 2:38:13 AM Mountain Standard Time Guillem Jover wrote: > It feels like problems with for example weak/team maintainership always > get obviated in this kind of commentary. Such as, it shifting > disagreement from maintainer vs user to internal team strife *and* > team vs user, it substantially increasing communication and consensus > overhead, both of which can very easily either cause "edit wars" or > "paralysis by lack of consensus", or feelings of rudeness or unease > when one internal faction plows ahead regardless of consensus. It > might make maintainers have to work closer than desired with people > they'd rather keep at a distance with, besides the minimum required, > say via bug reports or whatever else. It makes having a coherent vision > of how the package is being maintained harder to understand from outside, > both from upstream and within the project. It makes it harder to invest > in deep understanding of how the upstream code works. It makes it harder > to have a reliable and clear contact point of interest from outside and > within the project. It makes it harder to have a long-standing > relationship with upstream and knowing/understanding each other's quirks, > requirements, preferences or disagreements. It makes unmaintained packages > more difficult to track, it makes inactive teams more difficult to deal > with and detect. It makes trying and experimenting with different packaging > styles or techniques harder, because one has to justify diverting from > any team practices, for something that might well be a dead end. People > feel way less responsible for packages, as supposedly "someone else in > the team can take care of it". Etc. > > . . . > > A weak ownership team is not inherently a better way to maintain > packages, and I'd not like to see this reductionist maintainership view > keep being pushed across the project.
I agree with the above. There are pros and cons to both strong and weak maintainership models. Neither one guarantees that a packages will be well maintained, but there are good examples of packages being well maintained under both models. I prefer a strong maintainership model as long as the maintainer is doing a good job. Personally, I prefer to have at least one co-maintainer where we communicate well, are both on the same page as to how to handle the package, and both have a relationship with upstream. All of the complaints against a strong maintainership model have to do with the maintainer not doing a good job. Usually that is through inactivity, but occasionally it is through active participation in negative ways. -- Soren Stoutner [email protected]
signature.asc
Description: This is a digitally signed message part.
