There's a quite a few different business models to choose from. You can do open source with a turn-key cloud offering (like myself and others e.g. Sentry, Plausible, Cal.com, Airbyte, Bearer). You can do open core with premium/enterprise features (Sidekiq, OpenReplay, PostHog, Supertoken).
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).
This isn't quite what you asked, but selling free software is totally viable if you don't open source it. The only caveat is that you have to give the source code to anybody that purchased the binary if they ask for it. As for open source code, pretty much the only thing I can think of is consultancy services, but your project would have to be big to pull that off.
>selling free software is totally viable if you don't open source it
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.
You have it backwards. Open source software is free as in beer, while free software, by definition, is free as in freedom. The right to view or modify the source code is only guaranteed for people who actually own the code, and developers have a right to sell that. FWIW, Stallman actually used to run a business where he sold copies of GNU Emacs on floppy disks.
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.
Selling performance optimizations is another option. It's not relevant to startups and individual users, but can be relevant for enterprises, who spend millions on cloud.
This is a good suggestion. I assume you mean FOSS maintainers can create a variant (package?) that's optimized for performance. I'd thought of a similar variant, but for telemetry based on the recent Moq incident https://news.ycombinator.com/item?id=37066312
Mike from Sidekiq kind of does this with his Pro [0] version -- offering a "more reliable" job queue via Redis' RPOPLPUSH among other features. He still uses license keys and a private gem server to distribute the premium features, afaiaa [1].
Stump grinding services? A decent machine can be had for under $3000 can be towed by any vehicle and the planet just keeps making more stumps so there’s always one to grind.
Less dependency management than JS but they don’t run in docker.
There are many options. The appropriate mix would depend on the project, popularity, target audience and skills/interests of the maintainer.
Off the top of my head: Hardware, hosting services, support, trademark or patent rights, custom development, consulting, features (open core), bragging rights, social/insiders club membership, swag/merchandise, educational materials, certification, job placements/recruiting/headhunting, marketing/ads/product placement.
The easiest option is to get a full-time job at some place that needs the type of OSS code you write and negotiate your employment contract to specify exactly what will stay yours and/or open.
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.
It’s simple, FOSS projects are an act of charity to the community.
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…
> 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…
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.
> ”Community comes together to co-create value for everybody, which in itself is some sort of tangible currency.”
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
You sell value adds. This is often in the form of consulting (see JBoss and others) but can also be in the form of commercial plugins/extensions while your fully functional core. If you go the second route though, remember that people will notice and you'll lose users as soon as you start gatekeeping commits in order to keep your commercial plugin attractive. Instead, continue to add value to your plugins through services, hosting, new features. This is a variant of the Open Core model (https://en.wikipedia.org/wiki/Open-core_model), used by Kafka and others.
sell support to other businesses, they dont care about it being open source. only individuals do and even at that only a subsection of technically inclined ones do
Services. Often, a FOSS application may be too "wonky" for the average user, and so the creator of the FOSS application makes money by offering support services for their product.
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.
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).