3 ms·

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

>> 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.
  - deleted 4y ago
    [deleted]
jcparkyn 4y ago
I'm not saying I think the maintainers have any obligation to do things for me (I tried to make that clear in the original comment). What I was really trying to say is that I don't think this model would apply well to most projects, as the GP was saying. To take an exaggerated example, if I tried to use this model with any of my small OSS side projects, the only result would be that no one would contribute. This model means that the development of the project is going to be almost entirely driven by: a) The original maintainers of the project (who will rightfully get bored of maintaining it at some point), and b) The handful of companies that have financial interest in a certain bug/feature. Again, that's probably fine for projects like Fody, but certainly not all of OSS.

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.
- deleted 4y ago
  [deleted]

jcparkyn 4y ago

I'm not saying I think the maintainers have any obligation to do things for me (I tried to make that clear in the original comment). What I was really trying to say is that I don't think this model would apply well to most projects, as the GP was saying. To take an exaggerated example, if I tried to use this model with any of my small OSS side projects, the only result would be that no one would contribute. This model means that the development of the project is going to be almost entirely driven by: a) The original maintainers of the project (who will rightfully get bored of maintaining it at some point), and b) The handful of companies that have financial interest in a certain bug/feature. Again, that's probably fine for projects like Fody, but certainly not all of OSS.