Re: Request to remove Junio C Hamano as the Git Maintainer

["Theodore Ts'o" <tytso@mit.edu>]

On Sun, Jan 01, 2023 at 09:10:08PM +0000, brian m. carlson wrote:
> Instead, this is an open-source project, and it's my impression that
> Junio spends most of his time shepherding other people's patches and
> making sure that the project and contributions are in a good state.  He
> sends relatively few patches himself, and while he might make a
> suggestion on what he'd like to see out of a series or project, he
> doesn't really tell people what to do because people don't have to
> do what he says.

Another way of putting this is that git is perfectly usable for
intermediate to expert developers.  As a long-time Linux
developer/maintainer, my opinion is that git developer experience is
just *fine*.  I like how powerful it it is; I like how it improves my
productivity; and I don't have any problems using git.

One of the ways this can be seen is that we haven't see a huge amount
of contributions trying to make git more novice-firendly.  The fact
that we haven't seen those contributions is a strong indication that
it's not really a problem for git development community.  And given
that git developers are humans, there is very clearly a set of humans
who find their experience of git sufficiently convivial that it's not
worth their time to make it better.

So the claim that git has a poor developer experience is not accurate.
It may be that the experience for novice / beginner developers could
be improved, sure.  Unfortunately for novice / beginner developers,
they generally do not have the expertise to contribute those sorts of
patches to git.  They can send petulant messages to the git mailing
list, not understanding the difference between an open source
maintainer and a "product manager", but that's not going to be
effective.

And by the time that they do become experienced git developers, they
understand why things are the way things are, and very often, they
will find better things to do with their time.  For those that do
become experienced git contributors and who continue to be passionate
about making git easier for novice users, the challenge is how to make
git more friendly to novices while not compromising backwards
compatibilty or the power that expert users are happily using every
day.

And of course, if they are contributing to git on company time, their
company has to be willing invest their engineers' times on making git
easier for novices, which implies that most companies will want a
valid business case for making git more friendly more users for
developers like (presumably), Filip.  And if we aren't seeing those
contributions from corporately funded git developers, perhaps that is
a strong suggestion that the business case simply doesn't exist.

						- Ted