5 ms·

>If you’re the leader of one of these projects, charge an annual fee for community membership. Open source, closed community. The message to users should be “do

>If you’re the leader of one of these projects, charge an annual fee for community membership. Open source, closed community. The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.” Lock non-paying users out of the forum and issue tracker, and ignore their emails. People who don’t pay should feel like they are missing out on the party. This could be the dumbest thing I have ever heard of it. I mean seriously, you want people to pay even for PRs they have already written? >Also charge contributors for the time it takes to merge nontrivial pull requests. If a particular submission will not immediately benefit you, charge full price for your time. Be disciplined and remember YAGNI. 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. Perhaps what projects worrying about work for commits should require rigorous testing (integration tests at the very least) on unknown PRs if they ever feel the need to do something like this. And limiting feature requests is understandable, but most projects already ignore overly specific feature requests. Charging for PRs though seems like the fastest way to have your project forked, and have you lose control of it, or for it to split the development talent and die completely.

TAForObvReasons 9y ago
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 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.
Clubber 9y ago
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.
skue 9y ago
> 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?
- normalocity 9y ago
  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.
jancsika 9y ago
> 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
- sverhagen 9y ago
  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.
  - sundvor 9y ago
    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.
    - xfer 9y ago
edem 9y ago
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.
hbt 9y ago
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.

TAForObvReasons 9y ago

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

Clubber 9y ago

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.

skue 9y ago

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

normalocity 9y ago
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.

jancsika 9y ago

> 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

sverhagen 9y ago
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.
- sundvor 9y ago
  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.
  - xfer 9y ago

edem 9y ago

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.

hbt 9y ago

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.