git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Junio C Hamano <gitster@pobox.com>,
	shejialuo <shejialuo@gmail.com>,
	git@vger.kernel.org
Subject: Re: the latter half of october, the maintainer goes offline
Date: Mon, 7 Oct 2024 10:56:06 -0400	[thread overview]
Message-ID: <ZwP2hlVN7Cd+U3O7@nand.local> (raw)
In-Reply-To: <ZwN10b28Aaj3roz2@pks.im>

On Mon, Oct 07, 2024 at 07:47:07AM +0200, Patrick Steinhardt wrote:
> > Sure, though I would add that my personal feeling is that it is a
> > possibility, not a requirement, that the maintainer's funding come from
> > either an independent entity (like the Linux Foundation) or from a pool
> > funded by industry leaders.
> >
> > I say that only to point out that while Junio is employed by Google, I
> > don't think any of us would doubt his impartiality with regard to the
> > project.
>
> Oh, yes, and I've explicitly mentioned that Junio is doing an awesome
> job of that indeed. But I see the employment by Google as kind of an
> outlier here, because Google itself is not really competing in the Git
> ecosystem. They do not sell a Git-based product directly to customers as
> both GitHub and GitLab do, to the best of my knowledge.

I think your argument looses some subtlety here. Indeed, Google does not
sell a SaaS product based on Git like GitHub and GitLab do. But they
most certainly use Git extensively within Google. And I imagine that the
engineering team working on Git at Google has certain things that they
would like the project to do that would benefit Google's use of Git.

But what I don't see is Google benefiting unfairly by employing the
maintainer. So as long as Junio continues to maintain that impartiality,
I don't see any problem with him being employed by Google.

The other aspect of this is that it is Junio's personal choice where
they would like to work. Is it possible to organize some kind of shared
funding model? Perhaps (though I am personally not convinced). But I
think that imposing that model on Junio is not fair to him. Junio may
wish to work at Google for other reasons (e.g., perhaps he likes the
benefits, his work environment, benefits from his tenure there, etc.).

As long as Junio remains impartial, I do not see why the project should
dictate his choice of employer. Or IOW, if Junio woke up tomorrow with a
job offer from GitLab or GitHub (or any other company), I do not think
the project should dictate that he turn it down, or mandate that he be
replaced as maintainer for exercising his personal choice.

IOW, I think that the maintainer's impartiality is the most important
aspect of this. So long as the maintainer is impartial, I don't see why
they can't work at any company they choose.

> > I think as long as the maintainer's employer does not unfairly influence
> > the maintainer's decisions on their behalf, then it is OK.
>
> So yes, I would probably be okay with a maintainer that is employed by a
> company which I don't see as competing in this space. But I would
> strongly disagree with this statement if the intent were to ever have a
> GitHub or GitLab employee become the single maintainer.
>
> Impartiality is only one part of the picture here. The other part is
> that Git would start to feel like a project owned by that company. There
> simply is too much political tension for this to work out in the long
> term, in my opinion.

Again, I don't really see how this is the case. Git does not feel like a
Google project to me, even though Junio is employed by Google. I think
as long as the maintainer is impartial with respect to their employer,
then their individual choice of employer should not matter.

> So if we do not have an individual at the ready that is independent,
> then I would strongly favor a model where the maintainer role is shared
> across a group of people.

Like I mentioned earlier in this thread, I don't really see how this
model would work.

Thanks,
Taylor

  reply	other threads:[~2024-10-07 14:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-03 17:26 the latter half of october, the maintainer goes offline Junio C Hamano
2024-10-03 17:53 ` Taylor Blau
2024-10-04 15:22   ` Patrick Steinhardt
2024-10-04 16:31     ` shejialuo
2024-10-04 16:38       ` shejialuo
2024-10-04 16:58       ` Junio C Hamano
2024-10-04 22:35         ` Taylor Blau
2024-10-07  5:47           ` Patrick Steinhardt
2024-10-07 14:56             ` Taylor Blau [this message]
2024-10-07 15:28               ` Patrick Steinhardt
2024-10-04 22:47     ` Taylor Blau
2024-10-08 16:56       ` Junio C Hamano
2024-10-09  5:51         ` Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZwP2hlVN7Cd+U3O7@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ps@pks.im \
    --cc=shejialuo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).