Re: Promoting Git developers

[Junio C Hamano <gitster@pobox.com>]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> I guess we have at least 3 kinds of people here:
>
> A) Paid to do Git development, at least as part of their job.
> B) Freelancers who don't get paid directly for "doing git" but hope to
> profit from their git efforts directly or indirectly.
> C) Doing it in their freetime (or as minor, inofficial part of their
> non-programming job).
>
> I'm in camp C and honestly wasn't aware of camp B until now.
>
> I consider camp A to be beneficial for all of us, and I don't think
> specific employer interests have pushed the project in specific
> directions, or specific features (OK, maybe one, but not as a rule).
>
> I do see that remuneration is an issue for camp B.

As one of the four things you are not supposed to talk about in a
polite society, it is indeed hard to talk about money.

Let me digress a bit before coming back to your 3 classes, because
money is hard not only for those who want to receive, but is also
hard for those who want to pay. I remember having a brief discussion
during one of the GitTogether meetings with this person who managed
Git users at his company. I think it was one of the chip makers
whose association with Git was through its involvement with Android,
but don't hold me to this, as I do not exactly remember. The
conversation started with "How do you get changes to Git?" and what
he ultimately wanted to learn was how a company can enhance Git to
make the life of his engineers easier by hiring some Git experts and
have them work on missing features.

As you can guess, the conversation did not get to a satisfactory and
clear "here is how you would go about it". Sure, a company can pay a
developer to do a feature, but it is impossible to predict if the
end result will be used by us. For a usual work for hire, the hiring
company can set the evaluation criteria itself, which would be that
the end result works with the given version of the base software and
produces desired result for the specific workflow the company
needs. But the evaluation criteria for a "contribution" to us is not
under the control of the paying company and the bar the person who
does the work for hire has to cross is different. It of course needs
to fill the needs of the sponsoring company, but also it needs to be
cleanly done, maintainable, and it must not harm workflows other
people employ, which the sponsoring company may not care about at
all. That makes it hard for companies to pay a developer to work on
Git to benefit themselves. It is the same deal for an enterprising
soul who would start a crowdfunding campaign "I'll add this feature
to Git---if you guys raise this much money".

This also makes the involvement of employers in category (A) a
nuanced one. Because money is not an effective currency to buy
"inclusion", "Paid to do Git development" does not equate
"Companies pay developers to develop Git in a way to benefit the
sponsoring companies". When it comes to working on Git, I, Shawn
or Jonathan do not get orders from Google management to add funky
features nobody outside Google would use to help Android [*1*],
and I doubt that Peff and Michael's job description are to push
GitHub specific enhancement into our codebase, either [*2*].

There are different schools of thought on how to support open source
development [*3*]. I heard some people dream of "free software tax"
and have public support our endeavor, just like public purse supports
academia. We do not live in such world. Some projects pay for bugs
with bounty program; I think that would be the closest thing to
support your category (B), and that form of support does not have to
be limited to bugs. Projects could buy features in addition to bugs.

But we are not structured that way, at least so far. If we start to
buy features, that would make it even more difficult than the "My
company wants to fund somebody to add features to Git---how do we go
about it?" case. How do we decide an effort was successful? Would
that decision be affected by the fact that we paid for it in the
first place (i.e. declaring a failure would mean we admit that we
made a mistake when approving to fund the effort)? When other
developers think that a feature we bought shouldn't have been bought
in the first place, what happens? How should conflicts in such
decisions be resolved? How would that payment affect people who are
in category (C), or category (A) for that matter? Faced with two
reasonable implementations by a bounty hunter and a hobbyist, does
it enter the equation that one costs and the other is free? Do we
pay everybody to sidestep that issue? Where does the money come
from? Do we want to become a project that employ some developers but
not others? Who makes hiring decision and how?

In short, I agree with you that we are not set up to support bounty
hunters very well. That might be something we want to change, but I
am not sure what the endgame would be, if I would like that endgame
when I see it, or what the first step to reach that endgame would
be. My gut feeling is that there can be many "reasonable" answers to
all the question marks in the previous paragraph, but I have a vague
apprehension that taken together the answers would lead to a community
that is rather uncomfortable to live in, for hobbists and aspiring
hackers who want to be a part of category (A) alike, but that is
merely a vague apprehension at this point.


[Footnote]

*1* We however do get inspirations by being in a company that uses
Git in a way that may be different from the outside world, noticing
pitfalls common to in-house users, their pain points, etc. But we
know enough to think about the issues to see if they are common with
the outside world before considering to tweak the public version of
Git.

*2* I started Git from its early days as a category (C) participant,
but in later years before I came to Google I was doing Git
effectively out of my pocket, as I was paid only for the non-Git
days and by that time Git maintainership has grown to consume about
half my time. I however do not think I would throw me during those
days in category (B) myself. To me, I was still (C) with reduced
income. As you would expect, eventually that arragement became
untenable. There was a company who benefited from having a healthy
open source ecosystem that are supported by Git in the wider world,
and appreciated that I was not driving the project into ground, and
it was fortunate that they wanted me to continue. That is how I came
to be in category (A).

*3* I personally feel that good open source developers should be
like court painters. They may paint their employer's children to
earn their keep even if they did not like doing so, but their output
eventually enriched the wider public. Their employers might have
been leeches who exploited serfs, just like evil corporations in the
modern day, and I understand those who oppose my simplistic world
view.