4 ms·

Couldn't you charge people to look at their pull requests? The contributor's fix may seem very important to them, but in actuality may or may not be of any val

by dpweb 12y ago

Couldn't you charge people to look at their pull requests? The contributor's fix may seem very important to them, but in actuality may or may not be of any value at all. They are using free software but asking the maintainers of it to spend their time to review their pull request. Some entitlement there. The justification, my fix is important. Well, we don't know that, and to determine it costs time. I would think a fee system where people pay to have their pull requests prioritized. I know it goes against this misguided idea that everything free is a virtue, but there is a good reason why some things have an associated cost involved.

zzzeek 12y ago
this is very true because a pull request that solves a problem that the software's maintainer is also interested in solving is one that will be merged quickly. it's the frilly things that nobody else really needs, are difficult to review and merge, don't include tests, aren't particularly well written, and/or will only make the codebase worse just to appease someone's half-baked use case of dubious validity that typically sit in the queue for weeks or months.
nmb 12y ago
Interesting idea, but it would incentivize people against writing small, modular commits.
- dpweb 12y ago
  It prioritizes them overall. People wouldn't have to pay, but paid ones take priority. Maybe even crowdfund each request, would put the priority in the hands of the community, while the owners retain final say.
otterley 12y ago
> Couldn't you charge people to look at their pull requests? I'm puzzled - your response to a complaint that there's a tax on new open-source contributors is to tax them more?
- zo1 12y ago
  You misunderstood the sentence. In the sentence you quoted, "you" is referring to the project maintainer and "people" is referring to the contributors. So in essence, the suggestion is for the maintainer to charge the contributors for looking at their pull requests.
  - otterley 12y ago
    I didn't misunderstand. I think the confusion may stem from the question of whom the taxation is bad for - the maintainer or the contributors. I don't believe prospective co-committers should ever be taxed for their contributions. If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation. Open-source project maintainers should understand that by posting their code on GitHub, they're inviting contributions -- that's why GitHub is called "social coding." Its purpose is to make code better through a marketplace of contributions. If you put your code there, you voluntarily accept the burden of dealing with PRs. If that's the tax people are concerned with, there's an easy way to escape it: don't use GitHub, or disable the "issues" feature in the repository. I'm not sure if you can disable PRs; but you can certainly say that you won't accept patches via GitHub in your CONTRIBUTING and/or README document.
    - zzzeek 12y ago
      > If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation. that's really not how it works in reality. The vast majority of pull requests do contain something that is ultimately a positive addition, so a simple "rejection" is not appropriate. Instead, in order to get a pull request to be presented in the way that the maintainer needs it to be, the request have to be slowly nursed over days/weeks/months, in a series of often dozens of back and forth emails, code samples, coachings, tutorings, attempting to get the PR submitter to please write correct tests, please get it to look a certain way, etc. The contributors will frequently themselves not reply for weeks or months when these suggestions are made - pull requests that ultimately have something useful will languish just as much if the maintainer attempts to compel the contributor to finish the work of preparing the PR for a merge, as if the maintainer just took a long time to finish the PR themself. It is much less effort and usually much more expedient for the maintainer to simply take the PR in its incomplete state and just fix it directly. Very often the problem is involved enough that the maintainer needs to be involved in restructuring in any case, even with a very well written PR. The reality of the pull request is that it is in the vast majority of cases a more verbose form of bug report or feature request. They are quite often just as much work, if not more, than a plain bug report, for the maintainer of a well-written project.
joeblau 12y ago
Ive noticed this on my project. People make suggestions that seem great, but they only help a small, extremely advanced portion of the community. It would be interesting to see something like this in place, although serendipitously good contributions would probably also fall with this in place.
Thrymr 12y ago
I seriously doubt that a financial incentive would change most maintainers' attitude towards pull requests. What is an appropriate piece rate for a PR review? There are plenty of highly paid developers who are doing a side project for free, for whom an hourly consulting rate <$100 would be well below their market rate. Well paid professionals doing a labor of love are not likely to be motivated by $5-10 here and there. Not all package maintainers are in this category, of course, but most are volunteers who don't expect financial compensation for it. Offering me $5 (or whatever nominal amount) to review a pull request is more likely to insult me than motivate me. This is my problem with Gittip/Gratipay as well, the amounts are not enough to make a self-sustaining project, and even if it becomes a standard expectation, when someone else is willing to do it for free it would breed resentment. Open source should not be a service economy dependent on the gratuities of others. Note that I'm not arguing that developers should work for free, just that small sums aren't likely to change their behavior. Sustainable business models for open source projects are difficult, and I suspect that tips are not often going to provide one.
- dpweb 12y ago
  I wouldn't be too US centric in your assumptions. India will soon overtake the US in software devs and the average Indian dev makes approx. $5400/yr. http://www.glassdoor.com/Salaries/india-software-developer-salary-SRCH_IL.0,5_IN115_KO6,24.htm http://www.glassdoor.com/Salaries/india-software-developer-s... Now, even on the high end if the Indian dev makes $7k a year or $3.50/hr. And I'm a relatively high paid US developer who depends on their project and I offer $50, that's 14 hrs. of work. Not insignificant.
  - known 12y ago
    Cloud services will destroy Indian IT services viz TCS/Infosys/Wipro/TCS/HCL

by dpweb 12y ago

zzzeek 12y ago

this is very true because a pull request that solves a problem that the software's maintainer is also interested in solving is one that will be merged quickly. it's the frilly things that nobody else really needs, are difficult to review and merge, don't include tests, aren't particularly well written, and/or will only make the codebase worse just to appease someone's half-baked use case of dubious validity that typically sit in the queue for weeks or months.

nmb 12y ago

Interesting idea, but it would incentivize people against writing small, modular commits.

dpweb 12y ago
It prioritizes them overall. People wouldn't have to pay, but paid ones take priority. Maybe even crowdfund each request, would put the priority in the hands of the community, while the owners retain final say.

otterley 12y ago

> Couldn't you charge people to look at their pull requests? I'm puzzled - your response to a complaint that there's a tax on new open-source contributors is to tax them more?

zo1 12y ago
You misunderstood the sentence. In the sentence you quoted, "you" is referring to the project maintainer and "people" is referring to the contributors. So in essence, the suggestion is for the maintainer to charge the contributors for looking at their pull requests.
- otterley 12y ago
  I didn't misunderstand. I think the confusion may stem from the question of whom the taxation is bad for - the maintainer or the contributors. I don't believe prospective co-committers should ever be taxed for their contributions. If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation. Open-source project maintainers should understand that by posting their code on GitHub, they're inviting contributions -- that's why GitHub is called "social coding." Its purpose is to make code better through a marketplace of contributions. If you put your code there, you voluntarily accept the burden of dealing with PRs. If that's the tax people are concerned with, there's an easy way to escape it: don't use GitHub, or disable the "issues" feature in the repository. I'm not sure if you can disable PRs; but you can certainly say that you won't accept patches via GitHub in your CONTRIBUTING and/or README document.
  - zzzeek 12y ago
    > If their contributions aren't helpful/don't live up to their standards, you can reject the request with a polite explanation. that's really not how it works in reality. The vast majority of pull requests do contain something that is ultimately a positive addition, so a simple "rejection" is not appropriate. Instead, in order to get a pull request to be presented in the way that the maintainer needs it to be, the request have to be slowly nursed over days/weeks/months, in a series of often dozens of back and forth emails, code samples, coachings, tutorings, attempting to get the PR submitter to please write correct tests, please get it to look a certain way, etc. The contributors will frequently themselves not reply for weeks or months when these suggestions are made - pull requests that ultimately have something useful will languish just as much if the maintainer attempts to compel the contributor to finish the work of preparing the PR for a merge, as if the maintainer just took a long time to finish the PR themself. It is much less effort and usually much more expedient for the maintainer to simply take the PR in its incomplete state and just fix it directly. Very often the problem is involved enough that the maintainer needs to be involved in restructuring in any case, even with a very well written PR. The reality of the pull request is that it is in the vast majority of cases a more verbose form of bug report or feature request. They are quite often just as much work, if not more, than a plain bug report, for the maintainer of a well-written project.

joeblau 12y ago

Ive noticed this on my project. People make suggestions that seem great, but they only help a small, extremely advanced portion of the community. It would be interesting to see something like this in place, although serendipitously good contributions would probably also fall with this in place.

Thrymr 12y ago

I seriously doubt that a financial incentive would change most maintainers' attitude towards pull requests. What is an appropriate piece rate for a PR review? There are plenty of highly paid developers who are doing a side project for free, for whom an hourly consulting rate <$100 would be well below their market rate. Well paid professionals doing a labor of love are not likely to be motivated by $5-10 here and there. Not all package maintainers are in this category, of course, but most are volunteers who don't expect financial compensation for it. Offering me $5 (or whatever nominal amount) to review a pull request is more likely to insult me than motivate me. This is my problem with Gittip/Gratipay as well, the amounts are not enough to make a self-sustaining project, and even if it becomes a standard expectation, when someone else is willing to do it for free it would breed resentment. Open source should not be a service economy dependent on the gratuities of others. Note that I'm not arguing that developers should work for free, just that small sums aren't likely to change their behavior. Sustainable business models for open source projects are difficult, and I suspect that tips are not often going to provide one.

dpweb 12y ago
I wouldn't be too US centric in your assumptions. India will soon overtake the US in software devs and the average Indian dev makes approx. $5400/yr. http://www.glassdoor.com/Salaries/india-software-developer-salary-SRCH_IL.0,5_IN115_KO6,24.htm http://www.glassdoor.com/Salaries/india-software-developer-s... Now, even on the high end if the Indian dev makes $7k a year or $3.50/hr. And I'm a relatively high paid US developer who depends on their project and I offer $50, that's 14 hrs. of work. Not insignificant.
- known 12y ago
  Cloud services will destroy Indian IT services viz TCS/Infosys/Wipro/TCS/HCL