171–180 of 251 posts
Earlier quoted context omitted.
well , most of the project use tens if not hundreds other project's open source code and also do not donate to them
What about those self-contained ones like mine?
GitHub stars are a useless metric. It’s basically a bookmark count. If there was any correlation between them and donations, my combined projects of 35k+ stars should make me at least a couple of bucks each month. Instead, lifetime total of ~7 years is ~300 EUR, which includes donations to a NGO I forwarded, which account for most of it. Most people will not pay voluntarily for something they can get for free. That’s…
Sadly, it's now got to the point where people will downvote you for charging anything more than 0 and, if possible, they will write 1 star reviews in caps DON'T DOWNLOAD, IT'S NOT FREE!!
The main idea of free culture is building on each other, not maximum extractive consumption. I believe the idea to be further ahead than our economic systems and accompanying incentives though.
Earlier quoted context omitted.
What about those self-contained ones like mine?
Unless it's rigidly self-hosted compiler for your own language, I have a feeling it still depends on other projects a lot.
I put up a donation link (before GitHub sponsors was introduced) on a repo that had 5k+ stars. Got just one recurring donation (about $1 a month). This wasn't a s/w tool though (tutorials for CLI text processing). Later, I switched to creating books out of such tutorials. I gave them away for free during launch weeks (but readers could still pay if they wish) and this model worked so well that selling programming ebo…
Today you can use sponsored repos to still use GH as your distribution angle but also paywall certain content you create. Perhaps best of both worlds.
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 suppor…
>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.
Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version. Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
Pull requests take work to review and test. You shouldn't take that for granted and assume everything will be merged for free.
If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
Earlier quoted context omitted.
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. H…
> 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.
That is amazing: when I was younger, sharing code was a goal, but absolutely nothing could prepare me for your world. Previously I have had the luck to be able to rewrite a lot from scratch, removing most runtime dependencies, although definitely not replacing build dependencies.
I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks?