3 ms·

It is a tough thing. I want to focus on the negatives from two perspectives, as you wrote some positive: * This can make it harder to recruit further contribut

It is a tough thing. I want to focus on the negatives from two perspectives, as you wrote some positive: * This can make it harder to recruit further contributors as there is a two-clays system of contributors. Paid and unpaid. "Why should I fix a bug for free, while others earn the money?" * Accepting money make sit a business transaction, if I accept somebody's money they have demands towards me. Then I got to work on it. But of course the volunteer free model has sustainability issues ...

robmensching 1y ago
> This can make it harder to recruit further contributors as there is a two-clays system of contributors. We'll see. I haven't seen any reduction in contributions (not that the project gets lots of contributions because we're the same as every other Open Source project, most consumers just consume). Also, note that the fee is just for maintenance. I've seen near 0% contribution rate for all Open Source projects to "maintenance chores". Those just don't fall into the "scratch your own itch" class of problems. > Accepting money make sit a business transaction, if I accept somebody's money they have demands towards me. Then I got to work on it. True, but I've been committed to my project for over 25 years and I want to continue to improve the project. The fee has really helped keep that motivation up (aka: sustainable). The reaction has been mostly positive which is also a plus. :) > But of course the volunteer free model has sustainability issues ... Agreed. I think the OSMF is a good way to tackle exactly that issue.
- kvemkon 1y ago
  Free software community participants, contributors, can feel discouraged with the diving the whole community in strictly 2 class of only Maintainers vs. Consumers and then demand something like an Open Source Contributors Fee. All those investigative and reporting work about software behavior issues, hard to reproduce issues, bugs only in specific environment or specific circumstances, sharing experience, helping each other and so on, let alone fixing some issues on their owns and posting PRs.
  - robmensching 1y ago
    There aren't 2 classes of participants. The OSMF only talks about two but there are plenty of spaces for contributors to participate. And it's possible people will choose to participate less, but I haven't seen that happening yet. Contributors that like working on a project just work on a project. I've not seen any complaints about maintainers getting the paid because the contributors just drop in and drop out when they feel like it. They don't work on all the "chores" in the project to keep it running. If a contributor does do "chores" then they are probably more like a maintainer and probably should be part of the maintenance fee. But... this hasn't been a problem.
snickell 1y ago
I think many open source projects already experience two buckets of contributors which maps nicely to the two class distinction inherent in this model: 1) a bunch of people who contributed one or two PRs, but it took the maintainers more time to review/merge the PR than the dev time contributed 2) a much smaller set of people who come back and do more and more PRs, eventually contributing more time than it takes to review their work A major existing reason to review PRs from class 1 "once or twice" contributors (perhaps the main reason?) is that all class 2 "maintainer-level" contributors start as class 1. I agree there's an awkward middle ground here, now you have to define where the boundary is between class 1 and class 2, but I think if you were able to graph contribution level you'd find there's already something of a bimodal distribution naturally in many projects anyway.

robmensching 1y ago

> This can make it harder to recruit further contributors as there is a two-clays system of contributors. We'll see. I haven't seen any reduction in contributions (not that the project gets lots of contributions because we're the same as every other Open Source project, most consumers just consume). Also, note that the fee is just for maintenance. I've seen near 0% contribution rate for all Open Source projects to "maintenance chores". Those just don't fall into the "scratch your own itch" class of problems. > Accepting money make sit a business transaction, if I accept somebody's money they have demands towards me. Then I got to work on it. True, but I've been committed to my project for over 25 years and I want to continue to improve the project. The fee has really helped keep that motivation up (aka: sustainable). The reaction has been mostly positive which is also a plus. :) > But of course the volunteer free model has sustainability issues ... Agreed. I think the OSMF is a good way to tackle exactly that issue.

kvemkon 1y ago
Free software community participants, contributors, can feel discouraged with the diving the whole community in strictly 2 class of only Maintainers vs. Consumers and then demand something like an Open Source Contributors Fee. All those investigative and reporting work about software behavior issues, hard to reproduce issues, bugs only in specific environment or specific circumstances, sharing experience, helping each other and so on, let alone fixing some issues on their owns and posting PRs.
- robmensching 1y ago
  There aren't 2 classes of participants. The OSMF only talks about two but there are plenty of spaces for contributors to participate. And it's possible people will choose to participate less, but I haven't seen that happening yet. Contributors that like working on a project just work on a project. I've not seen any complaints about maintainers getting the paid because the contributors just drop in and drop out when they feel like it. They don't work on all the "chores" in the project to keep it running. If a contributor does do "chores" then they are probably more like a maintainer and probably should be part of the maintenance fee. But... this hasn't been a problem.

snickell 1y ago

I think many open source projects already experience two buckets of contributors which maps nicely to the two class distinction inherent in this model: 1) a bunch of people who contributed one or two PRs, but it took the maintainers more time to review/merge the PR than the dev time contributed 2) a much smaller set of people who come back and do more and more PRs, eventually contributing more time than it takes to review their work A major existing reason to review PRs from class 1 "once or twice" contributors (perhaps the main reason?) is that all class 2 "maintainer-level" contributors start as class 1. I agree there's an awkward middle ground here, now you have to define where the boundary is between class 1 and class 2, but I think if you were able to graph contribution level you'd find there's already something of a bimodal distribution naturally in many projects anyway.