For instance, we've seen projects selling ongoing support/maintenance.
Like a lot of those, myself included, you could also do both of these at the same time i.r.t. cloud and self-hosting (i.e. have a community and enterprise self-hosted edition).
You could also try to sell support and consulting contracts to enterprises (this is hardest route, imo).
If you're selling it then it's not free as in beer, and if it's not open source then it's not free as in freedom. The little loophole you describe doesn't make it FOSS.
Free as in beer (gratis): Given away at no cost to the recipient. For instance, a closed source program with a highly restrictive license that isn't allowed to be taken apart, repaired, moved to another machine, etc, but is given away for free.
Free as in freedom/speech (libre): The recipient can do with it what they please. They can repair, alter, port, etc. For instance, an open source program with a copyleft license that the user may or may not have money paid for.
While it can be libre and also be sold, available source code is a prerequisite for libre status. And the 'four essential freedoms' include the right to redistribute, which would necessarily cause that source code that you only make available to buyers to eventually become open source to the broader community. You cannot restrict the distribution of source code without impinging on the software's libre status.
https://en.wikipedia.org/wiki/The_Free_Software_Definition#T...
Less dependency management than JS but they don’t run in docker.
In terms of sustaining a living, the second best option is IMHO dual-licensing GPL/AGPL and a commercial license. However, note that this isn't really writing FOSS for a living. This is mostly a job of making sales calls, reviewing contract changes, and chasing invoices.
Trying to make money from ”the project itself” creates misaligned incentives, as the maintainers are trying to extract value/funnel users to pay. Whereas the community is attracted towards FOSS in order to not pay…
Adding support and maintenance fees also creates this misalignment of incentives. The community wants easier and simpler configuration, debugging etc… but the maintainers get support work if the project is difficult to configure, so naturally it’s not in their interest make the project easy to fix/configure…
The FOSS project itself needs a different commercial product to support its development. The best projects with aligned incentives are FOSS frameworks and libraries that a company needs in their commercial product…
Community comes together to co-create value for everybody, which in itself is some sort of tangible currency.
But a very high number of FOSS libraries/packages DO NOT have a community. How do you believe such projects must be sustained?
In this case the community is volunteering time/resources to the project. In my experience it takes a lot of management to pull this off, with PR reviews, discussions, design road maps… etc
> ”But a very high number of FOSS libraries/packages DO NOT have a community. How do you believe such projects must be sustained?”
Without a community to volunteer effort, the creators need to donate.
Either they have a commercial product that funds the FOSS project. Or more commonly, a highly paid software engineer gives back to the community as philanthropy
In my experience, if the community really wants something, they'll build it and open a pull request. The company behind the project isn't required to make things easier to e.g. self-host. Not accepting PRs that do make things easier for the community but may hurt upsell incentives otoh would be very bad, I agree with that.
Let someone use it at home, then be forced to pay a license at "work".
(I regret being such a socialist in my 20s)
Also there's the comedy option of selling zero days you yourself inserted.
(I tend to just use them, since CERT was rude.)
This is basically the entire business model of RedHat, I believe. They don't sell their software as much as they sell support for it.