> but then you're not directly selling your software either
You can't usually sell FOSS because any of your downstream customers can undercut you. Since they may be doing less development than you (to the point of doing nothing), any business model around FOSS that relies on directly selling your software is risky. I suppose it can work, but it requires all of your downstream customers to be working in concert with you, which is very unlikely long term (and especially unlikely if you start making a lot of money).
You can try to offer SaaS services on top of your FOSS software, but that will also be undercut if you are reasonably successful.
This gives you a couple of options. First, you can try to eke a living out of selling software/SaaS but making little enough money that you don't attract attention from competition. This is not necessarily unreasonable if you are trying to make a living wage. People are unlikely to compete with you if the pool is only $100K a year.
But in reality, the only actual scarcity that you have to offer is your time. Very rarely do you see someone fork a project, do a huge amount of development work and offer up the result. People/organisations trying to cash in on your work will be trying to avoid doing development. Otherwise they will almost certainly prefer to look at your effort and rewrite it from scratch.
This means you have to charge for development work. There are only really 2 ways of doing this: find contract work for your project (up to and including sponsoring development entirely), or asking for willing support of development (aka "donations").
I think it's incorrect that donations aren't enough. It's fair enough to say that they generally haven't been enough, but I think part of the problem is the idea that a "donation" is optional. Especially for business software/services, one thing I've heard over and over again is: "We would pay for this, but there is no way to get an invoice". IMHO, this is actually the problem. It's not that there is a shortage of people willing to pay, it's more that there is a difficulty making the payment happen. Even non-corporate end users are willing to pay for software and support development (what percentage of people would hold up their hand and say they wouldn't pay for the tools they use every day). It's more that they don't pay (strangely, quite a few free software game developers have discovered that putting their game on Steam results in money appearing, simply because it is a convenient method for people to pay).
I think part of the problem with current FOSS business models is that they are predicated on the idea that people won't pay unless forced to rather than the idea that people will pay, but don't because there is too much friction in the payment area (psychological as well as actual).
Fix the payment issue and I think you will find that you have a viable business model which is robust because anyone wanting to challenge you has to produce better than you, rather than just ride your coat tails.
One small thing I would also advise: don't overlook trademarks! There is a very good reason why the GPL does not include a trademark license. Do not hand out your trademark to your downstream customers and allow them to piggyback on your success. Force them to build their own brand if they want to market software/services using your code.
This is exactly right. People can pretty easily make their own lunch, and yet every day there are millions of transactions involving people forking over, say, $8 for an overpriced and overspiced pasta dish.
Programmers need to stop looking at the most negative pathological potential that involves not getting paid and then extrapolating that it will be true for everyone in the pool of prospective customers. (That and also stop feeling burned when someone either takes a path that involves not paying or just doesn't bite at all). The sandwich shop doesn't have to capture 100% of the revenue that could be generated by the passing traffic. They just need to do well enough to keep the lights on.
And stop focusing on open source versus commercial software, or how to "run an open source project" and find funding for it. Start selling software that's incidentally open source.
In 2017, I decided that I would (a) start paying for more software, and (b) never again pay for any program that didn't come with source code. (I.e., not even necessarily free software—they just need to have published the source somewhere.) The consequence of that is that I've paid a total of $0 since then. Know how many times I've bought pizza in that time period?
That is absolutely hilarious. I did the exact same thing... I don't know... 20 years ago. Same result :-) To be fair, I have paid for some free software, but it can be a bit tricky. As soon as I can wrest my wife's credit card away from her (I don't have one myself :-( ), I intend to pay for https://sourcehut.org/ even though I don't use it at the moment. It's exactly what I want someone to build. I hope he does a good job! Not affiliated in any way, but I want it to be true that he can make a living doing that.
> This means you have to charge for development work. There are only really 2 ways of doing this
There is potentially a third way: crowdfunded bounties. There are some sites for these, but they don't seem to have attracted much activity. (I built one myself a few years ago, but dropped it when it didn't get any traction.)
I'd really love for this to be a thing.... I think the main problem I see is that the true cost of the bounty is dramatically higher than most people (even in the industry) can understand. For example, let's say I'm trying for $100k a year in sales (fairly conservative, I think). That gives me about 250 working days or a daily (sales!) rate of $400. 1 day of development is a pretty tiny feature, but would require that 20 people pledge $20 each. Personally, I'm not really comfortable paying more than about $20-$50 for a single piece of software in a year, so that means that my input is really tiny... Which it is of course. $100k in sales would require 5000 people paying $20 per year, so each person's vote is pretty small.
I think it's all about optics... 5000 people paying $20 is probably easy to manage in a "I'll do something awesome this year, trust me" model than 50-100 "Let's raise money for this tiny feature" pledge drives.
But... It would be really nice if it were a thing... Possibly there is a better way to represent it that makes it more appealing to payers.
> the true cost of the bounty is dramatically higher than most people (even in the industry) can understand.
Only in a few parts of the U.S. with sky-high cost of living and rents. Most FLOSS developers are not in such places. (OTOH, high costs are definitely the reason why there's little-to-no "pure" crowdfunding for things like AAA-class video games, or live-action feature movies. It turns out that the cost of these things is so high that, by and large, people aren't actually willing to fund them when the full cost is made transparent.)
You can't usually sell FOSS because any of your downstream customers can undercut you. Since they may be doing less development than you (to the point of doing nothing), any business model around FOSS that relies on directly selling your software is risky. I suppose it can work, but it requires all of your downstream customers to be working in concert with you, which is very unlikely long term (and especially unlikely if you start making a lot of money).
You can try to offer SaaS services on top of your FOSS software, but that will also be undercut if you are reasonably successful.
This gives you a couple of options. First, you can try to eke a living out of selling software/SaaS but making little enough money that you don't attract attention from competition. This is not necessarily unreasonable if you are trying to make a living wage. People are unlikely to compete with you if the pool is only $100K a year.
But in reality, the only actual scarcity that you have to offer is your time. Very rarely do you see someone fork a project, do a huge amount of development work and offer up the result. People/organisations trying to cash in on your work will be trying to avoid doing development. Otherwise they will almost certainly prefer to look at your effort and rewrite it from scratch.
This means you have to charge for development work. There are only really 2 ways of doing this: find contract work for your project (up to and including sponsoring development entirely), or asking for willing support of development (aka "donations").
I think it's incorrect that donations aren't enough. It's fair enough to say that they generally haven't been enough, but I think part of the problem is the idea that a "donation" is optional. Especially for business software/services, one thing I've heard over and over again is: "We would pay for this, but there is no way to get an invoice". IMHO, this is actually the problem. It's not that there is a shortage of people willing to pay, it's more that there is a difficulty making the payment happen. Even non-corporate end users are willing to pay for software and support development (what percentage of people would hold up their hand and say they wouldn't pay for the tools they use every day). It's more that they don't pay (strangely, quite a few free software game developers have discovered that putting their game on Steam results in money appearing, simply because it is a convenient method for people to pay).
I think part of the problem with current FOSS business models is that they are predicated on the idea that people won't pay unless forced to rather than the idea that people will pay, but don't because there is too much friction in the payment area (psychological as well as actual).
Fix the payment issue and I think you will find that you have a viable business model which is robust because anyone wanting to challenge you has to produce better than you, rather than just ride your coat tails.
One small thing I would also advise: don't overlook trademarks! There is a very good reason why the GPL does not include a trademark license. Do not hand out your trademark to your downstream customers and allow them to piggyback on your success. Force them to build their own brand if they want to market software/services using your code.