Hacker News Reader

Merging PRs isn't as simple as clicking a button. I wrote this months ago in another comment: https://news.ycombinator.com/item?id=13231590

> most people are only willing to contribute to open source to the extent that it scratches their itch. They feel that their obligation ends as soon as the code is written, and the maintenance of their code falls on you.

> So from a maintainer perspective, you have to act like people's contributions are your contributions. You have to evaluate the code as if you have to maintain it later, you have to understand the circumstances surrounding it, etc. You have to be aware of everyone's concerns at the same time and make sure you don't end up messing up other people's use cases without good reason. And more often than not PRs reflect a "selfishness" of sorts wherein it solves their problem but breaks the general case.

> This sounds like a great way to lose all your real contributors. The article mentions "get paid for your time" over and over again, yet who is paying me for the time to write the code for the PR? You expect me to both dedicate my time to writing the code for a PR, and then pay you for the privilege.

It certainly sounds absurd on the face of it.

On the other hand, I can think of at least three cases where I'd do the work of submitting a PR if the project in question required me to pay.

In each case I can't currently gauge accurately enough whether these projects have a well-functioning development process. I could easily end up with a bitrotting PR with the project lead making a not unreasonable argument about why it's rotting (their time is limited, something else is taking priority, etc.). I imagine I'm not the only person who's ever been in such a "holding pattern."

On the other hand, if a reputable project says they'll take money in order to merge a branch I want, things become less amorphous very quickly. A project lead is not going to get away with blowing off a bitrotting merge request, at least not without their project's reputation (and future income from PR's) taking a hit.

edit: clarification

Reading this makes me wonder, though... These maintainers are often well-paid professionals. If their lifes outside of their day jobs put the pressure to limit the open source work, what is a little money going to do? If money was their main motivator to compromise their personal life, would they not already have gotten a second job (like a part-time consulting gig), maybe instead of the whole open source thing? Makes me feel as if this article misunderstands the motivations of maintainers.

Not every developer is a highly paid superstar in Silicon Valley. When needing to juggle family / life, I'm sure this proposed model would make it a lot easier to explain to the wife/husband/partner why they need to stay up a bit longer at night to work on their (previously) non-paying projects.

You need to show income to justify your hobby?

As a potential contributor I need to know whether there's a professional process or a guy "playing with trains" on the other end of the wire.

The problem is that the FLOSS ecosystem doesn't give you an easy way to tell. So if I misjudge and hit a wall of dysfunction, the general response would be, "Well, the maintainer just wants to play with trains. Leave them alone and fork the project if you want it to be some other way."

At least with paying to contribute, it would force the FLOSS ecosystem general response to be, "Those maintainers are just playing with trains, but they're taking money as if they are professional engineers. That's bad." Of course that's worst case scenario-- best case is that they really are engineers and I'm funding their development. Either way, it's potentially better than the status quo which is that you have no idea until you submit the patch.

I'm not saying that's what they are, but somehow I got the impression that maintainers of projects that are good enough to attract payments for pulls, would have marketable skills, and be ahead, regardless of the market they live in.

> You expect me to both dedicate my time to writing the code for a PR, and then pay you for the privilege.

No, better yet it would eliminate PRs from entitled users who think this way — who believe they contribute value by writing up issues and submitting minor pull requests that address their own needs, while remaining blind to the far greater value they receive from the project’s much larger code base; the mammoth time investment of the people who have designed, developed, and maintained that code base; and the thankless job those leaders have done nurturing a community often comprised of far more takers than givers.

Basically, the proposal eliminates the takers. Whether it would work or not is an open question. But if you find yourself feeling indignant at the very suggestion, then maybe take a hard look at which role you really fall in?

Eliminates the takers? The maintainer could just reject the PR to "eliminate takers" rather than setup a more complicated system of payments and different classes of users, some of whom pay to have a voice, and some who don't or can't.

I understand both your perspective and the perspective of the maintainers who do it for free. Spending all your time dealing with pull requests, code review thereof, etc is a huge hastle. On the other hand, no one is going to do free work, then pay to have it merged.

I would offer a compromise. Freely accept requested modifications. Project maintainer creates a list of features he/she will willingly merge. Any other contribution would be a pull fee.

Either way, I'm amazed that people working tirelessly for free to promote open source all these years hasn't hit this problem yet (burnout due to lack of proper monetary compensation).

I wish all maintainers luck.

Regarding PR and paying, people fork the code and make the changes they need. They send PRs to avoid merge conflicts in the future. i.e it is in your best interest to get your code merged.

You are not obligated to send PRs. You can fork and let it sit there.

Regarding community management, past a certain scale you should charge for it. People often feel entitled and will waste your time instead of reading doc. Majority of OSS projects rely on a handlful of individuals; often 1 or 2 people handling everything.

I completely understand the spirit of this.

OSS is not charity or altruism. Share your code out of self interest (e.g contributions, forks, bug detection etc.) If you get nothing out of it, unsubscribe from notifications.

You don't owe people your time, skills, energy.

My thoughts exactly. What a steaming pile of crap...no wonder that the OP has zero public repositories which have contributors...in fact all of the OP's repositories are forks.