Dear Open Source: let’s do a better job of asking for money
reactflow.devI personally see the models completely different.
One is free redistribution, which is an open source project.
The other is a SaaS product, which is closed source. (Pro examples, priority queue, email support, etc)
You can build a SaaS around your OSS, but do not call it asking for money. You are more or less changing from a project to a product model. People happen to pay for perceived valued products more often than sponsoring projects.
Rather than releasing under the MIT license, I'm wondering if the authors had considered duel licensing their code under a strong copyleft license, like the GPL, and selling closed-source licenses? I'm considering doing this in addition to paid support and feature requests as mentioned in the blog.
This is something I thought about for a while. But isn't using MIT contributing to the project popularity? Also, my project is a desktop application, so I think people don't really care if it's MIT or GPL. Maybe it makes more sense if it's a library.
> But isn't using MIT contributing to the project popularity?
Yes, definitely.
Curious about this topic.
Would it be possible to submit an issue with a bounty attached? I find a bug, I don't know the code base well enough, I escrow $20 and attach it to my bug report.
Someone fixes the bug, they get 80%, and the project it's 20%.
This would directly contribute positive outcomes to contributors and projects.
Some services already exist, like Bounty source (https://app.bountysource.com/). But the volume of issues is very small despite it existing for years. Also, most tasks seem to require a lot of work, and who can you convince to work on a task requiring 5 days of work if it pays 100$? Sounds a bit like Fiverr.
I don't think it's a lack of tools, or lack of advertising, but rather a problem of culture. I personally tried to convince some companies using my open-source project to pay me to add a feature or fix a bug, but it rarely works. Usually it goes like this: they either expect me to fix it for free because it's open-source, or they fancy forking the project and hiring someone to do the work for them, but not me, of course. If it's free, they don't see why they should pay. Which also make sense from an accounting point of view. If I go and see my boss about paying for something free, they will probably laugh. A better solution could be dual licensing, but then it's not really open-source anymore (or GPL + custom license). And having an open-source project also greatly contribute to its popularity.
I feel like crowd sourcing the bounty might help, although I don't know if that's something offered already. The more people that the bug hinders, the more people can contribute
I'm all for developers getting paid, but the thing with monetizing an open source project is:
If someone pays for your project, does the money belong exclusively to you as the project creator?
If the answer is "yes", you're literally making money off the effort of others without compensating them[1]; if the answer is "no":
* How do you decide how much should go to everyone else?
* Do you pay some percentage of what you earn to your dependencies? Only direct dependencies? When do you stop considering something a dependency (e.g. if you use a Linux distribution, do you donate to their maintainers as well)?
* Do you pay maintainers of your project?
* If you're not working actively in the project, but some devs are maintaining it, do you still get paid as the author? Or does "your share" go entirely to the maintainers?
* If some dev contributes one time, but it turns out to be a real important feature that becomes "core" because of how useful it turns out to be, do you pay them? Only once, or some part of your earnings?
* If someone forks your project, and you merge code from that fork, do you pay the author of the fork?
I'm not arguing for or against either position. I do what keeps my conscience clean.
I'm just trying to raise some questions that always come to my mind when the author of an open source project tries to get donations, or when they complain about others profiting off their project without donating anything[2].
[1] [2]: Notice the similarity between these two situations.
You are assuming that the "creator" of the project has not contributed a significant part of the code base. If the commercialisation scares away developers that might be sad but that may not matter in the long run because core developers usually contribute the vast majority of the code. Drive by commits/pull requests could be still worth it, because it is the responsibility of the core team to carry the maintenance burden of your patch, so depending on how valuable you consider the time spent on your patch and how valuable you consider avoiding the burden of maintaining a fork, you may decide to simply donate your patch. If you wanted to be a significant contributor with no expectation of compensation, then this arrangement is suboptimal but if you insisted, nothing stops you from forking the project and taking it the direction you want.
A big problem with capitalism and economics is that all of it is seen through rose tinted glasses. In the mathematical models, everything you have said is perfectly accounted for, every single commit gets properly compensated down to the cent and even the companies pay exactly as much money as it costs the developers to maintain the software to the necessary standard.