5 ms·

I'm not sure how I feel about this one. Sure, the maintainers have no obligation to review and merge other people's PRs. But when this also applies to genuine h

I'm not sure how I feel about this one. Sure, the maintainers have no obligation to review and merge other people's PRs. But when this also applies to genuine high-quality community contributions, I feel like there must be some negative side effects. I'm sure this model works well for an established project like Fody that's already quite highly polished, but I'd be pretty sad if all (or even a significant subset) of open source adopted this model. I'd definitely be interested to hear any counter-arguments to this though. Are there any avenues for individuals to contribute for free, if they aren't using it for profit?

brightball 4y ago
I like it personally. Free to use, pay for support. The distribution of something already made is free. Supporting, understanding your issue, developing a fix and releasing it…all of that takes a real person’s time. As a contractor, you learn very quickly that people will ask for anything if it doesn’t cost them anything. There are a lot of people happy to take advantage of you if you let them. I like seeing a good model to get OSS devs paid.
- jcparkyn 4y ago
  I totally agree for things that would normally be described as support (e.g. feature requests or low quality bug reports), but a lot of things aren't that. Personally, if I submit a bug report or PR to an OSS project (which admittedly doesn't happen very often), it's almost always because I think the time I've spent investigating the bug/feature could benefit other users of the project. For my use cases, it's generally much faster and easier (at least in the short term) to just fork a project and make whatever change I need locally, than to wait for it to go through review/merge/release in the original project. Another commenter has pointed out that they make exceptions for certain types of contributions though, which I guess would help with this.
robocat 4y ago
From the link: But it is MIT, can't I use it for free? Yes all projects are under MIT so the community backing honesty system can be ignored and Fody used for free. Do I need to be a Patron to contribute a Pull Request? Yes. Users must be a Patron to be a user of Fody. Contributing Pull Requests does not cancel this out. It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging. Do I need to be a Patron to raise an issue? Yes. Users must be a Patron to be a user of Fody. As such when raising an issue (question, bug or feature request) and not a Patron, the issue may not be actively triaged, and eventually closed as stale. Issues from non-Patrons, that are bugs and are highly likely to affect the larger Fody user base, may justify the effort and be handled. Also, the minimum amount is $3/Month: which surely isn’t near enough to pay for their time! Many developers can afford $36 a year, and if not, a developer can still use it for free (BSD licence) and maintain their own branch. https://opencollective.com/fody/contribute/patron-3059/checkout?amount=3&interval=month https://opencollective.com/fody/contribute/patron-3059/check...
- Aeolun 4y ago
  > Many developers can afford $36 a year You realize that my dependency stack contains about 2500 dependencies right? If they all follow this model I’m looking at $90k/year just to contribute to a project.
  - jmoss20 4y ago
    ? What contribution are you imagining that involves a PR to all 2500 projects?
    - thomastjeffery 4y ago
      Applying this business model to every project they use.
      - 12907835202 4y ago
        Do you PR or raise an issue to every package you use? You can still use 2500 different packages for free. This seems like a good example how it would work well.
        thomastjeffery 4y ago
        My point is that you are taking their point too literally. Also, the business model is paying a subscription for the right to submit a pull request. Sure, you could wait until you are about to make the PR to buy the subscription, but that's a pain of its own. Their point here is that this isn't a scalable business model. That's the assertion that started this whole comment thread.
      - quickthrower2 4y ago
        Let’s imagine you can, for example fix an issue with NextJS API system without needing to touch, say React or Express or a whole load of other deps.
  - viraptor 4y ago
bruce511 4y ago
>> I'm not sure how I feel about this one. I think this may be a case where because you have a bunch of freedoms, you feel like you should have more. I say this to re-assure you, not critisize you. Open Source, and Free Software, are very clear on the 4 freedoms you enjoy. You can use, modify, distribute etc. But it's not a 2-way street. You have no rights about what goes back into the project, the author is under no obligation to receive code contributions, no obligation to add features, fix bugs, or anything like that. Of course lots of projects actively seek out contributions, but it's certainly not a requirement - nor (IMO) should it be. Coversely open source has struggled to find viable financial models. This sounds like a success story and we should look long and hard at any successful financial model. So, I don't think you should feel unsure. If you want to contribute then chip in some loot. If it means the project becomes sustainable you are the big winner. But most of all, I think, be careful of adding "more freedoms" to your understanding of OS and FS, when they don't exist.
- TAForObvReasons 4y ago
  The logical conclusion of everyone taking the model of "pay me to review patches or read your issues" is fragmentation. Instead of a vibrant ecosystem where people collaborate on patches and the project grows, the issues and solutions remain internalized in private forks. Is that a better outcome? From the time/money standpoint it's great, and it may make the project more sustainable since there are fewer issues and PRs to review, but it hurts the project long term.
  - deleted 4y ago
    [deleted]
  - bruce511 4y ago
    You have articulated well the trade-off between "project first" and "business first". From a user point of view, project first is the only thing that matters. There is an instinctive resistance to anything that gets in the way. On the other hand users generally don't care about the project authors getting paid or not. From the author side, getting paid is often a goal. If that means limiting the community to paying users, then so be it. From their perspective they are offering value, and they choose to spend their time focused on users who are paying. In other words they need your money, not your code suggestions. They can code, but code doesn't pay rent. As you say, others can choose to silo their changes, and not post them back, that is their right, and indeed likely happens anyway.
thayne 4y ago
There's an important qualification on that page: > This process will depend on the issue quality, and the impact on the larger user base. So, if I understand correctly, they won't automatically close issues if you aren't a subscriber, but the bar for the quality to keep it open is probably significantly higher. I don't think that's a bad model. Although, I don' think it would scale well to every open source project having it's own subscription stream. But maybe if there were companies that maintained collections of projects?
- jcparkyn 4y ago
  Yeah that qualification helps a lot.
- ilyt 4y ago
  Depends on where the bar is set but as long as "A PR that fixes actual bug with nicely written code" passes I think that model is entirely fine (especially in modern era when it can bet mangled thru test suite via CI and merging it is near-zero effort for maintainer). That's essentially someone helping your paid customers to have better product for free.

brightball 4y ago

I like it personally. Free to use, pay for support. The distribution of something already made is free. Supporting, understanding your issue, developing a fix and releasing it…all of that takes a real person’s time. As a contractor, you learn very quickly that people will ask for anything if it doesn’t cost them anything. There are a lot of people happy to take advantage of you if you let them. I like seeing a good model to get OSS devs paid.

jcparkyn 4y ago
I totally agree for things that would normally be described as support (e.g. feature requests or low quality bug reports), but a lot of things aren't that. Personally, if I submit a bug report or PR to an OSS project (which admittedly doesn't happen very often), it's almost always because I think the time I've spent investigating the bug/feature could benefit other users of the project. For my use cases, it's generally much faster and easier (at least in the short term) to just fork a project and make whatever change I need locally, than to wait for it to go through review/merge/release in the original project. Another commenter has pointed out that they make exceptions for certain types of contributions though, which I guess would help with this.

robocat 4y ago

From the link: But it is MIT, can't I use it for free? Yes all projects are under MIT so the community backing honesty system can be ignored and Fody used for free. Do I need to be a Patron to contribute a Pull Request? Yes. Users must be a Patron to be a user of Fody. Contributing Pull Requests does not cancel this out. It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging. Do I need to be a Patron to raise an issue? Yes. Users must be a Patron to be a user of Fody. As such when raising an issue (question, bug or feature request) and not a Patron, the issue may not be actively triaged, and eventually closed as stale. Issues from non-Patrons, that are bugs and are highly likely to affect the larger Fody user base, may justify the effort and be handled. Also, the minimum amount is $3/Month: which surely isn’t near enough to pay for their time! Many developers can afford $36 a year, and if not, a developer can still use it for free (BSD licence) and maintain their own branch. https://opencollective.com/fody/contribute/patron-3059/checkout?amount=3&interval=month https://opencollective.com/fody/contribute/patron-3059/check...

Aeolun 4y ago
> Many developers can afford $36 a year You realize that my dependency stack contains about 2500 dependencies right? If they all follow this model I’m looking at $90k/year just to contribute to a project.
- jmoss20 4y ago
  ? What contribution are you imagining that involves a PR to all 2500 projects?
  - thomastjeffery 4y ago
    Applying this business model to every project they use.
    - 12907835202 4y ago
      Do you PR or raise an issue to every package you use? You can still use 2500 different packages for free. This seems like a good example how it would work well.
      - thomastjeffery 4y ago
        My point is that you are taking their point too literally. Also, the business model is paying a subscription for the right to submit a pull request. Sure, you could wait until you are about to make the PR to buy the subscription, but that's a pain of its own. Their point here is that this isn't a scalable business model. That's the assertion that started this whole comment thread.
    - quickthrower2 4y ago
      Let’s imagine you can, for example fix an issue with NextJS API system without needing to touch, say React or Express or a whole load of other deps.
- viraptor 4y ago

bruce511 4y ago

>> I'm not sure how I feel about this one. I think this may be a case where because you have a bunch of freedoms, you feel like you should have more. I say this to re-assure you, not critisize you. Open Source, and Free Software, are very clear on the 4 freedoms you enjoy. You can use, modify, distribute etc. But it's not a 2-way street. You have no rights about what goes back into the project, the author is under no obligation to receive code contributions, no obligation to add features, fix bugs, or anything like that. Of course lots of projects actively seek out contributions, but it's certainly not a requirement - nor (IMO) should it be. Coversely open source has struggled to find viable financial models. This sounds like a success story and we should look long and hard at any successful financial model. So, I don't think you should feel unsure. If you want to contribute then chip in some loot. If it means the project becomes sustainable you are the big winner. But most of all, I think, be careful of adding "more freedoms" to your understanding of OS and FS, when they don't exist.

TAForObvReasons 4y ago
The logical conclusion of everyone taking the model of "pay me to review patches or read your issues" is fragmentation. Instead of a vibrant ecosystem where people collaborate on patches and the project grows, the issues and solutions remain internalized in private forks. Is that a better outcome? From the time/money standpoint it's great, and it may make the project more sustainable since there are fewer issues and PRs to review, but it hurts the project long term.
- deleted 4y ago
  [deleted]
- bruce511 4y ago
  You have articulated well the trade-off between "project first" and "business first". From a user point of view, project first is the only thing that matters. There is an instinctive resistance to anything that gets in the way. On the other hand users generally don't care about the project authors getting paid or not. From the author side, getting paid is often a goal. If that means limiting the community to paying users, then so be it. From their perspective they are offering value, and they choose to spend their time focused on users who are paying. In other words they need your money, not your code suggestions. They can code, but code doesn't pay rent. As you say, others can choose to silo their changes, and not post them back, that is their right, and indeed likely happens anyway.

thayne 4y ago

There's an important qualification on that page: > This process will depend on the issue quality, and the impact on the larger user base. So, if I understand correctly, they won't automatically close issues if you aren't a subscriber, but the bar for the quality to keep it open is probably significantly higher. I don't think that's a bad model. Although, I don' think it would scale well to every open source project having it's own subscription stream. But maybe if there were companies that maintained collections of projects?

jcparkyn 4y ago
Yeah that qualification helps a lot.
ilyt 4y ago
Depends on where the bar is set but as long as "A PR that fixes actual bug with nicely written code" passes I think that model is entirely fine (especially in modern era when it can bet mangled thru test suite via CI and merging it is near-zero effort for maintainer). That's essentially someone helping your paid customers to have better product for free.