Suppose that all your expertise is in making software for use by other programmers, and you want to run a small business. How do you make money?
The weird thing about being a system engineer is that it's quite easy to make something that is valuable and widely used. But quite a lot harder to get paid for it. It's easy to wake up as this brick:
Part of this is because the competition is often completely free software produced by highly paid teams at some of the most profitable companies ever to exist. And part of this is because we've somehow ended up a with a community norm that it is mildly immoral to charge money for software.
But I think part of it is also that pricing models for systems software are tricky. If you're selling software to the person that is going to run it then you can charge by seat. But if you're selling a library that your customer is going to ship as part of larger service, how much do you charge them?
The niches where I see small businesses directly charging money for software are ones where the pricing model is tractable. Tools for individual developers can charge by seat (eg intellij, sublime, wallaby, gitkraken). Libraries that will be part of some software that costs money can charge per install (eg game engines, and many libraries in game engine app stores).
But webapps often don't really have a notion similar to seats or installs. And there is a much larger range of business models, leading to wildly different incomes per user depending on the webapp.
Wrapping libraries in a SaaS is kind of a pricing hack - allowing you to charge for usage. But running a service requires a whole new set of skills, and only works for certain kinds of software. And it requires doing a lot more than the original library itself. Eg duckdb is an incredibly popular library, but to make a SaaS from it the authors had to use it as a funnel into a separate cloud database, which I imagine was a substantial amount of extra engineering. And as a small or solo business, having on-call rotations is a big additional cost.
In theory for server-side software you can just charge for a license per server. I don't know of many small businesses succeeding this way, other than sidekiq's wild success. But maybe they're out there and I just don't see them.
Dual-licensing (eg qt) also seems rare. And I often see news stories about companies violating the gpl with seemingly no consequences (eg wix). It seems mechanically easier to sell extra proprietary features on top of an open-source core, rather than try to dual-license the whole thing.
Support and consulting are definitely viable (eg sqlite). There's a tradeoff between how much time you spend doing individual support vs making the software itself. I hear mixed accounts - some people have many support contracts that hardly ever get called in, and are effectively just sponsorships. Other people seem run off their feet. I've also seen some strategies for reducing the cost of support eg offering prioritized tickets rather than email support with an sla, offering access to shared weekly office hours rather than selling hours to each customer separately. Filippo's retainership is particularly interesting - it seems a large part of the value offered is reciprocal access, ensuring that the sponsors problems make it into the feedback loop to the maintainer.
Sponsorship seems less common. I know a few projects that are able to pay salaries entirely from sponsorship (eg zig) but also plenty of excellent projects that barely make anything. Presentation and fundraising effort seem to matter a lot. I've heard that it's difficult for businesses to justify sponsorships in an audit, but that presenting the exact same transaction as a purchase of support is much more palatable - shading into the lightweight support strategies above. One model I haven't seen yet (that mirrors the reciprocal access above) would be to give sponsors access to the repo and limit everyone else to tagged releases.
I suspect that at least part of the prevalance of SaaS is that VCs believe that non-SaaS companies don't make money. Or at least enough money to provide a VC-sized exit. This maybe became a self-fulfilling prophecy: there are less non-SaaS companies around, expertise in non-SaaS business models becomes less available, corporate spending rules evolve to favor SaaS etc.