Hacker News Reader

Comment by dpweb | Hacker News Reader

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.

View on HN

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.

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.

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-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.

Cloud services will destroy Indian IT services viz TCS/Infosys/Wipro/TCS/HCL

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.

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

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.

> 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?

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.

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.

> 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.

> 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.

OK, so what, though? If it makes the software better for the users, I don't understand the problem. If the problem is "but it's work for me," see above: you knew the job was dangerous when you took it. Volunteerism should be a labor of love. If it isn't, find a replacement for yourself.

> OK, so what, though? If it makes the software better for the users, I don't understand the problem.

there isn't a problem! your pull request might take me 6 months to respond to. That's the point. Contributors shouldn't have a problem with that, either.

Reply on news.ycombinator.com