Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html