7 ms·

I continue to think that the best model is the one adopted by Fody.NET[0]. It's open-source, on GitHub, under the MIT license, developed in the open, and with a

I continue to think that the best model is the one adopted by Fody.NET[0]. It's open-source, on GitHub, under the MIT license, developed in the open, and with a voluntary OpenCollective. And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. The result is a system that is paid enough to be excellent, excellent enough for most users not to need support, and non-bogged enough for paying users to get excellent support. The best part is when corporations get involved. A company will absolutely get something for free if it can, but if it has to pay, it'll pay a lot more than the absolute minimum, for PR reasons. [0]: https://github.com/Fody/Home/blob/master/pages/licensing-patron-faq.md https://github.com/Fody/Home/blob/master/pages/licensing-pat...

nequo 4y ago
> if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. Maybe I’m misunderstanding but does this mean that you cannot submit a bug report unless you donate to them?
- 8K832d7tNmiQ 4y ago
  users who use their product are probably assumed to be working on enterprise market already, hence a weird B2B model in an open community.
- layer8 4y ago
  Yes. And this is answered in more detail on the linked page.
- _carbyau_ 4y ago
  My reading of it on their page was that they are free to ignore your bug report unless you donate to them. You didn't pay? Well, that's just, like, your bug report, man... Essentially it boils down to: you cared enough to submit a bug report? Then you should also care enough to donate.
  - slavik81 4y ago
    > they are free to ignore your bug report That is true of any open source project.
    - jmoss20 4y ago
      It's a UX thing. The "auto-close" behavior makes the policy obvious. And presumably the maintainers are not bound in any way to not re-open an especially good/important bug. It just makes makes non-patron support opt-in, instead of opt-out.
  - jcparkyn 4y ago
    That logic (your last paragraph) essentially assumes that people only care for selfish reasons. Plenty of people contribute for the sake of giving back to the project (by e.g. taking the time to write a high-quality bug report or PR).
    - _carbyau_ 4y ago
      True and in this case, if the team thought it was good they can still choose to run with it. But that would be unexpected. This is about managing expectations. And generally in the modern world, if you want someone to fix something for you, you pay them.
- pie_flavor 4y ago
  In practice, excepting for major issues. In principle you are supposed to donate in order to use it at all, and the issue tracker is simply where they check to make sure.
jcparkyn 4y ago
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...
carterschonwald 4y ago
Next time i wind up maintains a large oss effort im going to seriously consider this.
jongjong 4y ago
It doesn't work if the project hasn't had any new issues in a while. There is no incentive to be part of the OpenCollective if the project is completed and has no bugs. I've been struggling with this issue with my project. It's a completed project, no scope creep, no bugs, just occasional update once every 6 months or so. The docs are complete and detailed so nobody needs extra help; no one will pay for support At the same time, I know for a fact that if the project was buggy or had gaps in the documentation, nobody would use it; they would use an alternative solution from a big corporation. The level of competition is so intense that there is no room for profit, no room for missing documentation and no room for bugs on my end. Competing products are backed by a big name brand tech corporations; so they can have bugs and gaps in the documentation and users will forgive them. Branding is extremely powerful. Once people trust a brand name, they will ignore reality. If you don't have a brand name, you need to be 10x better to be perceived as the same quality.
- bruce511 4y ago
  Perhaps it would be helpful to articulate what you feel you are missing? (I'm presuming money, but I don't want to put words in your mouth.) It sounds to me like you have a solid project, and some number of users. With good docs. Which is great (we'll done.) I'm assuming you want to monetize it? That seems to be the logical next step. Alas I'm not going to be very comforting with the next bit. A) the time to think about monetization is when you start the project, not when it's done. Obviously a lot of projects get done for reasons other than money, and when you started you may have had other reasons. That's fine. But monetizing after-the-fact is a very difficult, dare I say "unsolved" problem. B) this is going to sting, but most successful money-earning products have nothing to do with the code, beyond that it exists. A "business" requires more than "product" - a lot more. Marketing, sales, revenue, administration and so on. All of this is expensive, hence the need to have a business plan (ie, how does this thing make money?) before you start. As developers we have a code-first mindset. But we try and compete with companies that have a business-first mindset. Companies are winning. The fact that your project is complete, that it is solid is fantastic. Well done for that. However turning it into a business may be impossible, or expensive. That's OK. Celebrate what is is, don't pine for what isn't. If nothing else you've learned the difference between a code project, and a business, and if you internalise that then you will have gained something of high value.
thejosh 4y ago
Mostly would be bug reports I would like to see instead stay open, but depending on volume that doesn't scale.
Arnavion 4y ago
>And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and you reject it because you want me to pay you first, I'm dropping your software without a second thought.
- deleted 4y ago
  [deleted]
- krasin 4y ago
  >Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library without a second thought. You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.
  - Arnavion 4y ago
    Yes, I'm sure it makes sense for them to have this perspective. And it also makes sense to me that if I'm not going to get the bugs I encounter fixed, even if I make the effort to fix them myself, then my effort is better spent on a project where that will happen. Their loss.
    - knicknic 4y ago
      I don’t pr unless it will be obviously taken without first opening an issue. This prevents me wasting time testing and writing code. If someone is going to just close these questions, then I will drop them as it’s not open source I want to be a part of. I am okay with paying for software. not okay with paying to find out my feature request will get denied
  - pharmakom 4y ago
    Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.
kriro 4y ago
Thanks for pointing this out, I've never heard about this model before. Sounds quite reasonable to me. The only problem I see is if they treat all requests equally. I'd be concerned if security related PR get cancelled because the submitter is not subscribed. From my understanding they do pre-screen submissions before cancelling so that shouldn't be the case (at the price of creating some overhead for them).
lifeisstillgood 4y ago
Isn't it Open Collective that was on the front page recently being used by casinos for money laundering or some other weird scam? re: https://news.ycombinator.com/item?id=33529742 https://news.ycombinator.com/item?id=33529742 (Had not heard of OpenCollective before yesterday so intrigued to see it come up twice)
ahepp 4y ago
I think the part of this that's weird to me, is that non-paying users are able to open issues or pull requests at all. Something about it feels very passive aggressive. Why not just have the public facing project be a fork of a private, access protected project where bug tracking and PRs are handled, that only patrons can access? For some reason, saying "only patrons can access our development repo" seems perfectly reasonable, but saying "we'll close your bug report if you don't pay us" feels a bit grumpy.
- ilyt 4y ago
  Yeah at that point just turn it off so people don't waste time (both them and yours) filling out bugs that will never get touched and just closed
  - iudqnolq 4y ago
    If you don't read the prominent documentation before filing issues you're wasting lots of maintainer's time.
safety1st 4y ago
While I'm always excited about new ways of monetizing open source, if I'm looking at the OpenCollective contribution page for Fody correctly, this model has made them under $10,000 in the past 2 years or so. From a business perspective that's basically a rounding error and nothing compared to what you can do with the conventional approach of selling consulting/support or, heaven forbid, your own proprietary solution. So in what sense is this the best model? Has anyone used it to generate $100,000 in annual revenue, let alone say $10M+? More profitable model = more hiring developers to improve the software...!
- pie_flavor 4y ago
  It is indeed terrible from a business perspective, because Fody isn't a business. It's an open-source project. If you want to start a business, you should start a business. The author of TFA wasn't under any illusions it would completely replace her day job, the problem was that it wasn't worth spending the time on after the day job. There's no substitute for selling retail copies / subscriptions, but within the realm of open source for all, Fody's model is the most efficient way of converting appreciation into a little extra cash.
  - twosdai 4y ago
    This is a deceptively insightful comment. At least it wasn't clear to me for a while. If you want to start a business it can definitely have an open-source element to it, but that's just it. The open-source part is just one piece to a business and you better be aware of all the other pieces that need to be done in order to make money which aren't always engineering/programming related. EG: marketing, sales, consulting, fundraising, accounting, etc... A common approach that people do now is create the open source offering then run it as a service where they can charge a premium for the support and leg work for hosting it. See: mongodb or elasticsearch or influxdb. I haven't found many pure open source solutions where all they do is make the software better all day and ignore all the elements of business growth needed. Maybe the Linux foundation is a good counter example but I don't think there is a clear path to be paid for just contributing solely to open-source while neglecting other business elements.
goodpoint 4y ago
> under the MIT license This is a poor choice for a donation-driven project because it allows easy proprietization. It also does not protect from patents, tivoization and so on. GPLv3 would be a better choice.
zelphirkalt 4y ago
> And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. I don't know enough about the resulting system, but this sounds quite silly and contra-productive. Issues often hint at important flaws. If the community is not open (Ha!) to outsiders notifying them of important flaws, then that is a recipe for bad software. Some people might go there and start asking for features, instead of describing issues (although even that can be valuable input), but in my experience people are more often reporting bugs or asking how to do something, because it is not well described in the docs, or the docs are not as visible as they should be, or probably many other good reasons. Closing ones door to these valuable inputs can only result in worse software.
- pie_flavor 4y ago
  Closing the door to people that are drive-by posters who cannot be bothered to fork over three dollars can only result in better inputs. The issue with open source tip jars isn't that they're expensive, it's the psychological barrier in front of giving anything at all. That's the subject of TFA and Fody's model is the only real way to circumvent it. Ninety percent of people who submit issues are people who are invested in continuing to use Fody and so should be patrons, and the remainder of the issues are unlikely to be high on the signal-to-noise ratio.
  - zelphirkalt 4y ago
    > Closing the door to people that are drive-by posters who cannot be bothered to fork over three dollars can only result in better inputs. We are not talking about the same kind of issues or people. Aside from the strawman: People creating an issue with all the detail are already investing time into reporting an aspect of your project. Immediately closing the issues is like giving them a middle finger, for investing their time, trying to help the project. Sometimes, when I have a problem with some tool being buggy, I consider opening an issue, but sometimes I don't do it, because I know it would be time-consuming. However, when I open an issue, I usually try to provide all required information and maybe even an example to reproduce the issue. I invest time to make it easy for the maintainers to see the actual issue. If they closed that issue immediately and wasted my time like that, I would be very careful to ever invest time again into anything those people create.

nequo 4y ago

> if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. Maybe I’m misunderstanding but does this mean that you cannot submit a bug report unless you donate to them?

8K832d7tNmiQ 4y ago
users who use their product are probably assumed to be working on enterprise market already, hence a weird B2B model in an open community.
layer8 4y ago
Yes. And this is answered in more detail on the linked page.
_carbyau_ 4y ago
My reading of it on their page was that they are free to ignore your bug report unless you donate to them. You didn't pay? Well, that's just, like, your bug report, man... Essentially it boils down to: you cared enough to submit a bug report? Then you should also care enough to donate.
- slavik81 4y ago
  > they are free to ignore your bug report That is true of any open source project.
  - jmoss20 4y ago
    It's a UX thing. The "auto-close" behavior makes the policy obvious. And presumably the maintainers are not bound in any way to not re-open an especially good/important bug. It just makes makes non-patron support opt-in, instead of opt-out.
- jcparkyn 4y ago
  That logic (your last paragraph) essentially assumes that people only care for selfish reasons. Plenty of people contribute for the sake of giving back to the project (by e.g. taking the time to write a high-quality bug report or PR).
  - _carbyau_ 4y ago
    True and in this case, if the team thought it was good they can still choose to run with it. But that would be unexpected. This is about managing expectations. And generally in the modern world, if you want someone to fix something for you, you pay them.
pie_flavor 4y ago
In practice, excepting for major issues. In principle you are supposed to donate in order to use it at all, and the issue tracker is simply where they check to make sure.

jcparkyn 4y ago

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

carterschonwald 4y ago

Next time i wind up maintains a large oss effort im going to seriously consider this.

jongjong 4y ago

It doesn't work if the project hasn't had any new issues in a while. There is no incentive to be part of the OpenCollective if the project is completed and has no bugs. I've been struggling with this issue with my project. It's a completed project, no scope creep, no bugs, just occasional update once every 6 months or so. The docs are complete and detailed so nobody needs extra help; no one will pay for support At the same time, I know for a fact that if the project was buggy or had gaps in the documentation, nobody would use it; they would use an alternative solution from a big corporation. The level of competition is so intense that there is no room for profit, no room for missing documentation and no room for bugs on my end. Competing products are backed by a big name brand tech corporations; so they can have bugs and gaps in the documentation and users will forgive them. Branding is extremely powerful. Once people trust a brand name, they will ignore reality. If you don't have a brand name, you need to be 10x better to be perceived as the same quality.

bruce511 4y ago
Perhaps it would be helpful to articulate what you feel you are missing? (I'm presuming money, but I don't want to put words in your mouth.) It sounds to me like you have a solid project, and some number of users. With good docs. Which is great (we'll done.) I'm assuming you want to monetize it? That seems to be the logical next step. Alas I'm not going to be very comforting with the next bit. A) the time to think about monetization is when you start the project, not when it's done. Obviously a lot of projects get done for reasons other than money, and when you started you may have had other reasons. That's fine. But monetizing after-the-fact is a very difficult, dare I say "unsolved" problem. B) this is going to sting, but most successful money-earning products have nothing to do with the code, beyond that it exists. A "business" requires more than "product" - a lot more. Marketing, sales, revenue, administration and so on. All of this is expensive, hence the need to have a business plan (ie, how does this thing make money?) before you start. As developers we have a code-first mindset. But we try and compete with companies that have a business-first mindset. Companies are winning. The fact that your project is complete, that it is solid is fantastic. Well done for that. However turning it into a business may be impossible, or expensive. That's OK. Celebrate what is is, don't pine for what isn't. If nothing else you've learned the difference between a code project, and a business, and if you internalise that then you will have gained something of high value.

thejosh 4y ago

Mostly would be bug reports I would like to see instead stay open, but depending on volume that doesn't scale.

Arnavion 4y ago

>And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and you reject it because you want me to pay you first, I'm dropping your software without a second thought.

deleted 4y ago
[deleted]
krasin 4y ago
>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library without a second thought. You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.
- Arnavion 4y ago
  Yes, I'm sure it makes sense for them to have this perspective. And it also makes sense to me that if I'm not going to get the bugs I encounter fixed, even if I make the effort to fix them myself, then my effort is better spent on a project where that will happen. Their loss.
  - knicknic 4y ago
    I don’t pr unless it will be obviously taken without first opening an issue. This prevents me wasting time testing and writing code. If someone is going to just close these questions, then I will drop them as it’s not open source I want to be a part of. I am okay with paying for software. not okay with paying to find out my feature request will get denied
- pharmakom 4y ago
  Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.

kriro 4y ago

Thanks for pointing this out, I've never heard about this model before. Sounds quite reasonable to me. The only problem I see is if they treat all requests equally. I'd be concerned if security related PR get cancelled because the submitter is not subscribed. From my understanding they do pre-screen submissions before cancelling so that shouldn't be the case (at the price of creating some overhead for them).

lifeisstillgood 4y ago

Isn't it Open Collective that was on the front page recently being used by casinos for money laundering or some other weird scam? re: https://news.ycombinator.com/item?id=33529742 https://news.ycombinator.com/item?id=33529742 (Had not heard of OpenCollective before yesterday so intrigued to see it come up twice)

ahepp 4y ago

I think the part of this that's weird to me, is that non-paying users are able to open issues or pull requests at all. Something about it feels very passive aggressive. Why not just have the public facing project be a fork of a private, access protected project where bug tracking and PRs are handled, that only patrons can access? For some reason, saying "only patrons can access our development repo" seems perfectly reasonable, but saying "we'll close your bug report if you don't pay us" feels a bit grumpy.

ilyt 4y ago
Yeah at that point just turn it off so people don't waste time (both them and yours) filling out bugs that will never get touched and just closed
- iudqnolq 4y ago
  If you don't read the prominent documentation before filing issues you're wasting lots of maintainer's time.

safety1st 4y ago

While I'm always excited about new ways of monetizing open source, if I'm looking at the OpenCollective contribution page for Fody correctly, this model has made them under $10,000 in the past 2 years or so. From a business perspective that's basically a rounding error and nothing compared to what you can do with the conventional approach of selling consulting/support or, heaven forbid, your own proprietary solution. So in what sense is this the best model? Has anyone used it to generate $100,000 in annual revenue, let alone say $10M+? More profitable model = more hiring developers to improve the software...!

pie_flavor 4y ago
It is indeed terrible from a business perspective, because Fody isn't a business. It's an open-source project. If you want to start a business, you should start a business. The author of TFA wasn't under any illusions it would completely replace her day job, the problem was that it wasn't worth spending the time on after the day job. There's no substitute for selling retail copies / subscriptions, but within the realm of open source for all, Fody's model is the most efficient way of converting appreciation into a little extra cash.
- twosdai 4y ago
  This is a deceptively insightful comment. At least it wasn't clear to me for a while. If you want to start a business it can definitely have an open-source element to it, but that's just it. The open-source part is just one piece to a business and you better be aware of all the other pieces that need to be done in order to make money which aren't always engineering/programming related. EG: marketing, sales, consulting, fundraising, accounting, etc... A common approach that people do now is create the open source offering then run it as a service where they can charge a premium for the support and leg work for hosting it. See: mongodb or elasticsearch or influxdb. I haven't found many pure open source solutions where all they do is make the software better all day and ignore all the elements of business growth needed. Maybe the Linux foundation is a good counter example but I don't think there is a clear path to be paid for just contributing solely to open-source while neglecting other business elements.

goodpoint 4y ago

> under the MIT license This is a poor choice for a donation-driven project because it allows easy proprietization. It also does not protect from patents, tivoization and so on. GPLv3 would be a better choice.

zelphirkalt 4y ago

> And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. I don't know enough about the resulting system, but this sounds quite silly and contra-productive. Issues often hint at important flaws. If the community is not open (Ha!) to outsiders notifying them of important flaws, then that is a recipe for bad software. Some people might go there and start asking for features, instead of describing issues (although even that can be valuable input), but in my experience people are more often reporting bugs or asking how to do something, because it is not well described in the docs, or the docs are not as visible as they should be, or probably many other good reasons. Closing ones door to these valuable inputs can only result in worse software.

pie_flavor 4y ago
Closing the door to people that are drive-by posters who cannot be bothered to fork over three dollars can only result in better inputs. The issue with open source tip jars isn't that they're expensive, it's the psychological barrier in front of giving anything at all. That's the subject of TFA and Fody's model is the only real way to circumvent it. Ninety percent of people who submit issues are people who are invested in continuing to use Fody and so should be patrons, and the remainder of the issues are unlikely to be high on the signal-to-noise ratio.
- zelphirkalt 4y ago
  > Closing the door to people that are drive-by posters who cannot be bothered to fork over three dollars can only result in better inputs. We are not talking about the same kind of issues or people. Aside from the strawman: People creating an issue with all the detail are already investing time into reporting an aspect of your project. Immediately closing the issues is like giving them a middle finger, for investing their time, trying to help the project. Sometimes, when I have a problem with some tool being buggy, I consider opening an issue, but sometimes I don't do it, because I know it would be time-consuming. However, when I open an issue, I usually try to provide all required information and maybe even an example to reproduce the issue. I invest time to make it easy for the maintainers to see the actual issue. If they closed that issue immediately and wasted my time like that, I would be very careful to ever invest time again into anything those people create.