Kannan Goundan [off-list ref] writes:
Thanks for the explanation. I didn't realize some projects don't want to
initialize all their submodules, but the explicit opt-in idea you described
sounds nice.
I've seen cases where people will financially "sponsor" feature development
in open source projects. Is there any precedent for this in the Git
project? Is it ok to use this mailing list to ask about such things?
We are unfortunately not set up to handle money well. For a
background explanation, please go read [*1*], which I wrote my take
on "money" some time ago. Note that it is an explanation and not a
justification. It explains why we are not set up to handle money
well and what the issues around money that are troublesome for the
project are. It does not mean to say that it is a good thing that
it is hard to buy feature with money from our project [*2*].
I do not see (and back then in the discussion I do not think anybody
saw) how we can make "We, a sponsoring company, pay this money to
the project to fund effort Y." work well. But that of course does
not mean it is impossible to make it work--somebody with a fresh
perspective may come up a way to do so, and that would be a very
welcome development.
[Footnote/Reference]
*1* http://thread.gmane.org/gmane.comp.version-control.git/264993/focus=265215
*2* Just like my message that you are responding to was an
explanation of the reason why we do not recurse and and
initialize all submodules by default.
Junio C Hamano <gitster <at> pobox.com> writes:
We are unfortunately not set up to handle money well. For a
background explanation, please go read [*1*], which I wrote my take
on "money" some time ago. Note that it is an explanation and not a
justification. It explains why we are not set up to handle money
well and what the issues around money that are troublesome for the
project are. It does not mean to say that it is a good thing that
it is hard to buy feature with money from our project [*2*].
I think the way I described it ("sponsoring a feature") doesn't really
reflect how I was imagining it. In my head, it looked like this:
1. Figure out whether the Git community and maintainers seem ok with the
overall feature idea. If not, give up.
2. Come up with a plan for the UI/UX; see if the Git community and
maintainers seem ok with it. If not, iterate or give up.
3. Implement it, then go through the regular process of getting it merged
upstream. If it doesn't go well, might have to iterate or give up.
I could try doing that myself, but someone familiar with the Git
codebase/community/history would be better at it (and probably be easier for
you guys to work with :-)
I guess I'm just wondering if there are people who meet those qualifications
and are interested in going through those steps for pay. Or maybe there's a
company that does this, like the old Cygnus Solutions?
In particular, I don't expect anything to change about the project's
development process.
(This part is not relevant to the Git project, but I understand that it's
hard for anyone to guarantee a feature will make it into an open source
project. I imagine these kinds of contracts are set up so that you're
primarily paying for the effort, not the outcome. If it ends up not working
out, you don't get your money back.)
On Fri, Oct 23, 2015 at 5:46 AM, Kannan Goundan [off-list ref] wrote:
Junio C Hamano <gitster <at> pobox.com> writes:
quoted
We are unfortunately not set up to handle money well. For a
background explanation, please go read [*1*], which I wrote my take
on "money" some time ago. Note that it is an explanation and not a
justification. It explains why we are not set up to handle money
well and what the issues around money that are troublesome for the
project are. It does not mean to say that it is a good thing that
it is hard to buy feature with money from our project [*2*].
I think the way I described it ("sponsoring a feature") doesn't really
reflect how I was imagining it. In my head, it looked like this:
1. Figure out whether the Git community and maintainers seem ok with the
overall feature idea. If not, give up.
2. Come up with a plan for the UI/UX; see if the Git community and
maintainers seem ok with it. If not, iterate or give up.
3. Implement it, then go through the regular process of getting it merged
upstream. If it doesn't go well, might have to iterate or give up.
I could try doing that myself, but someone familiar with the Git
codebase/community/history would be better at it (and probably be easier for
you guys to work with :-)
I guess I'm just wondering if there are people who meet those qualifications
and are interested in going through those steps for pay. Or maybe there's a
company that does this, like the old Cygnus Solutions?
Well I am starting to do that for Booking.com. Not sure if it will
also be possible for me to work for you as I also work on IPFS
(http://ipfs.io) for the company that develops it, but we can discuss
it privately.
There was David Kastrup (dak at gnu.org) who previously said he could
be interested in such jobs. We wrote a very short article about it in
the first edition of Git Rev News last March:
http://git.github.io/rev_news/2015/03/25/edition-1/
We also wrote a very short article "Job Offer" article about
Booking.com looking for Git developers in Git Rev News in the third
edition last May:
http://git.github.io/rev_news/2015/05/13/edition-3/
so if you want we can write a similar "Job Offer" article in the next
Git Rev News edition.
You can even propose such an article yourself by editing the draft of
the next edition here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-9.md
and then creating a pull request.
In particular, I don't expect anything to change about the project's
development process.
(This part is not relevant to the Git project, but I understand that it's
hard for anyone to guarantee a feature will make it into an open source
project. I imagine these kinds of contracts are set up so that you're
primarily paying for the effort, not the outcome. If it ends up not working
out, you don't get your money back.)