231–240 of 251 posts
2. I wonder if web developers are more stingy than other developers...
3. "I obviously wanted to make a paid version of the app because the donations weren't exactly working out for me" <- Not obvious. The app should serve the public interest, as FOSS.
Earlier quoted context omitted.
>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.
The page I linked was the FAQ, which addresses this exact point: > 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…
Fine. But if my code is useful, and it ends up convincing more users to become Patrons, will I get any financial gratification from the Fody maintainers? Or are any profits from this contribution going solely to the maintainers?
In your average open source project, backing it is separate from using it and contributing code to it. My contribution would therefore benefit all people, including those who cannot pay. But the Fody maintainers consider them to be freeloaders and unwelcome people, so I have reservations about contributing and what the benefit from my contribution would be to others. I'm not working for free for a for-profit entity.
Earlier quoted context omitted.
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 th…
I'm not saying that Fody's model is superior to selling retail software, if what you are in the business of doing is selling retail software. I'm saying that it's superior to giving up on open source monetization if what you're in the business of doing is open source.
How is that a more ethical, straightforward, or profitable business model than just GPLing the project and offering proprietary licensing?
Releasing code under a permissive license, then calling people dishonest when they use it according to the license but not the authors’ desires, seems silly and inefficient.
Earlier quoted context omitted.
> You realize that my dependency stack contains about 2500 dependencies 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,…
I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks? Modern devs don't care. They just install whatever, let it pull in 1000s of other packages, and continue on their merry way. Meanwhile, a package you use today, can root your stuff tomorrow. That is, next update and bam! Package was sold to Evil Entity, or just the dev decides to rm your drive based upon ge…
Have an unobvious copyright condition, get your code in thousands of projects, then spider the internet looking for companies that use your code, and charge them a $1000 “licensing fee”.
Or change the copyright in v1.1.2.2 and wait until everyone updates, and do the same thing.
> Modern devs don't care
I think the “modern” is superfluous and vaguely insulting: security isn’t/wasn’t cared about by most old-skool developers either!
Earlier quoted context omitted.
>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.
> 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…
Nonsense. You think signing yourself up to maintain a patched version of someone else's code for eternity is better than using someone else's code? You have to sign up for upstream CVEs, keep updating the upstream base and rebasing your patches on top.
>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?
False dichotomy. A library is measured in various dimensions - how well-maintained it is, what features it has, OS / hardware dependencies, performance, etc. Something that is better in one dimension might be worse in another dimension, so that there's no single objectively better library.
>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!
I have my own work to do, not maintain forks of other people's code.
Earlier quoted context omitted.
> 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 star…
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 invest…
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.
Earlier quoted context omitted.
>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.
The page I linked was the FAQ, which addresses this exact point: > 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…
No, I really don't.
https://github.com/keepassxreboot/keepassxc/pull/8500 - I was randomly reading keepassxc's manpage and spotted a curious option, spent some time spelunking through the code and history to discover that it was an outdated option, sent a PR.
https://github.com/python/typeshed/pull/8617 - I converted one of the scripts I use in my DE from shell to Python, saw that VSCode has this new fancy typing support for Python, quickly found a basic bug in the type definitions for the os module, tested a fix locally, sent a PR.
https://gitlab.gnome.org/GNOME/gtk/-/issues/5250 - I found an issue with copy-paste on my phone, investigated it all the way through to the GTK stack, found the commits that introduced the issue, created a distro patch for it while discussing it with GTK upstream.
https://gitlab.alpinelinux.org/alpine/aports/-/merge_request... - I noticed that gnome-passwordsafe crashes some times, debugged it to discover that it was missing a dependency, sent a PR to the distro package to update the dependencies.
etc etc. I've made lots of fixes like these. I have no interest in paying for each and every one of them. The projects are all better off for fixes like mine and gatekeeping them on payment would've been nothing but their loss.
Also, to be clear, there is nothing special or unique about what I do. All large community projects where the users greatly outnumber the developers continue to work because of PRs like these from their users.
Btw if you wanna make money with opensource, check how FastAPI doing it.
I've been harping for years to anyone who would listen, Open Source is not a business model [0]. If your motivation for doing open source is money, you're doing it wrong. You'll be much better off just getting a job (and GitHub stars can help with that!). We all know "build it and they will come" and "follow your passion and the money will follow" don't really work in the real world. You have to make something people…
Are people really depending on Open Source for Economics? Open Source is not a business model, and that should be obvious. It's a distribution model, which has nothing to do with economics. Sure, it may affect a few variables but marketing and sales strategy are what matter more.
It's a source code license.