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

From: Theodore Ts'o <tytso@mit.edu>
Date: Jan 2, 2023, 03:37 UTC
Message-ID: <Y7JRh6WZ1YZ2AkKJ@mit.edu>
In-Reply-To: <Y7H2sN1fEZ8pi6xY@tapette.crustytoothpaste.net>

On Sun, Jan 01, 2023 at 09:10:08PM +0000, brian m. carlson wrote:

Show 7 quoted lines

> 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