"Why isn't your software free?" Because I hope to make a profit.

To give an answer to this question beyond a glib one-liner, I feel I must first outline various sources of revenue, and expenditures, for a software developer. This list isn't exhaustive, but should be illustrative.

Possible Income Sources

1) License/registration fees
This is the traditional way of making money from software development. Would-be users pay once and receive the right to use the full version of the product paid for, into perpetuity. Sometimes these rights include upgrades and updates, other times only minor updates are available and major upgrades must be purchased anew. In the latter case, previous customers often get a discount by only having to pay an 'upgrade fee'.

2) Subscriptions.
The user periodically pays you for a temporary right to use the current version of the software for a length of time. Fees may be paid monthly, quarterly, or annually. When a user hasn't paid recently enough, they lose access.

3) Tech support.
Some developers allow users to pay extra to receive 'privileged' or 'expedited' support, whether in resolving problems, or in helping them to use the product.

4) Wages, salaries, subsidies, and grants.
You are employed, often by a company, to work on the software; they pay you an agreed-upon amount for this work.

5) Fundraising.
You solicit people or companies to give you money, with the understanding that you in turn will develop the software. This may be limited strictly to actual development or production costs, or it may include your 'time cost' or costs of living. In the latter case, it must be made clear up front how you intend to use the money; some developers or project leaders were not clear, and were then censured for using funds for personal expenses.

6) Investments.
Similar to the former, except that contributors actually own a percentage of your company and you have ongoing financial, not just moral, commitments to them.

7) Donations.
People or companies voluntarily give money to you for work you have already done. They may hope that you will do more, but you aren't morally or contractually obliged to.

8) Selling rights, and royalties.
If you agree to sell away the rights to your software to another person or company, depending on your contract, you will likely get a lump sum of money, and you may be able to get a percentage of some or all future sales. (This is distinguished from publishing agreements, where you retain the rights to your software, and can change publishers if you choose. It is also separate from selling copies of source code.)

9) Advertising and endorsements.
You give publicity to other companies or products, and are paid by them in return. This can include a set amount for agreeing to advertise at all, or 'per-click' rates for each time someone engages with the ad, or both.

10) Distribution.
You charge for physically getting the software to the user. Distribution costs are often limited to physical media. In theory you might charge users for downloading things from your server, but I'm not aware of anyone who has done this in the last 25 years.

11) Unrelated work, or allowances.
You receive pay or upkeep for things that have nothing to do with this software's development. Hobbyists and part-timers who work a day job, and youth supported by their parents, are examples of this.

Possible Expenditures

1) Costs of living.
This covers the majority of most people's costs, and can include groceries, electricity, water, clothing, housing, transportation, etc, for yourself as well as for dependents.

2) Third-party software fees.
If you use proprietary software from another developer in your development process, you may have to pay them for the right; this can include single-time payments, subscriptions, or any of the above mandatory means that you might use to get funding yourself.

3) Taxes.
If you're successful at all, this is going to come up.

4) Server costs.
You have to pay to maintain an online presence. This is especially expensive if your software is web-based; your server(s) need to be able to cope with the demands of dozens, hundreds, or thousands of users running your software.

5) Legal expenses.
Hopefully these aren't regular, or costly, but they can be a thing.

6) Contractors.
If you have gaps in your time, or skills, you may (have to) hire others to do certain tasks for you.

7) Hardware costs.
The requirements of development or testing may require purchasing special or more powerful hardware.

8) Publishing fees.
In some cases, you may have to give up a set amount of money, or a percentage of your sale revenue, to the company who publishes your software. Present-day examples of this would include money given to Apple when you sell on their app store.

Having outlined income and expenditures, it is now time to discuss the definition of 'free'. The primary definition virtually all English-speaking civilization uses means "available without monetary cost". The other one, popularized in the geek world by the Free Software Foundation (or "FSF"), means something more like "open-source; users have a right to use, modify, or adapt the code for their own purposes". I will now explain my position on both.

In the first sense, all of my works (as of Jan 9, '24) are presently free. There are different reasons for this. Sometimes it's because I don't feel a work is complete enough to make a profit yet. In other cases, I don't think it can be monetized in a way that meets my standards; my hope is that these will drive interest in my other works.

In the second sense, of users being unrestricted by intellectual property rights, things are more complicated. I provide terms by which readers can take advantage of some of my works, but the bulk of the main features is proprietary. While I can't predict the future, I expect most of it to remain so, because in my case, open-sourcing it seems mutually exclusive with making a profit from it.

While the FSF insists that 'free software can be sold', it is my conviction that this is not realistic, and that software that is 'intellectually free' will tend to be economically free.

Access to source code rules out registrations, subscriptions, and advertising as reliable ways of making money. Users often avoid those restrictions if they can. Given that, if you have any of these in an open-source product, there's an ongoing risk that a 15-year-old will come along, offer a version that doesn't have these restrictions, and destroy your profits.

The FSF used to push distribution as a revenue source, but this is largely dead because of modern technology and infrastructure. When it comes to online downloads, the same logic applies as in the former case: someone with extra server capacity will do a public service and offer a cost-free version. You might be able to sell physical flash drives, DVDs, or CDs, but not very many people need physical media now, and you're unlikely to make a profit much greater than your expenses.

Thus, we can see that there are three remaining general means of making a profit: tech support, being employed by somebody else to do this work, or charity. These all have corresponding issues, which I will discuss.

The problem with offering paid technical support is that the goals and type of someone who wants to develop good software, and the goals and type of someone who wants to offer paid tech support, are opposed.

In terms of values, programmers want to make software that does a job quickly, efficiently, and easily. If the software is so bad or so complicated that it requires professional help to get any value from it, they have failed. In terms of personal preferences, many coders are introverted and got into their field as a way of avoiding having to deal directly with other people for their job, especially unhappy, screaming people.

Tech support, on the other hand, requires two things: one, that users regularly need help using the software, and two, that the representative has the skills (social, but also others) and energy to interact with them. So the first requirement opposes the programmer's values, and the second is against their personality.

We understand that tech support is necessary and unavoidable, but it is perverse to make the least desirable aspect of computing-related work the most potentially profitable one.

Regarding employment, the most successful open-source projects have been helped by government and/or big businesses along the way, and if you're able to get this, I don't think there's anything wrong with it, either practically or morally.

The trouble here is merely that it seems antithetical to the fundamental goals of 'free software', as described by the FSF. They claim to be empowering individuals, but how can this be, if restrictions on your financial options require the same old major conglomerates to fund you? If it limits freedom to not be able to modify software as you please, it must be more limiting when it isn't possible for someone to make the software at all.

Lastly, we have charity. Let's begin by discussing donations. An understanding of human nature and observations of the world lead us to suspect this path is not sustainable. People may donate to save kittens' lives, but our common experience is that they won't pay for someone's upkeep if they aren't required to. Probably the only ones who have ever voluntarily done this for you are your parents, and even then, that's because they felt uniquely responsible for you, not because they liked you or what you did.

However, this is based on examples 'outside'; perhaps the software world is a special case. How has it gone, in practice, for developers who relied on voluntary donations? Have they been prosperous? Have they even been able to make a living wage?

The answer is no. Nobody who has experience with donationware or similar offerings believes that this is a strategy for success. Nobody who has done this for an extended period of time trusts in voluntary donations for their living.

There are ample modern examples. The DonationCoder community confess with their words and actions that you won't get significant donations from goodwill [1]; their means of giving out license keys is a compromise to try to make their system viable. Another donationware developer, Hillel Stoler of the late GetSocial, admitted in an interview [2] that he was "far from making a living" from his software, with a donation being received at a rate of '1 to every 182 downloads'.

I can also offer my personal observations of how this unfolded in the past. As someone who grew up using a Mac in the '90s. I was well-acquainted with the Macintosh shareware movement. Early on, shareware was functionally equivalent to donationware; the program (often, but not always, a game) would mention that it was unregistered, but would not restrict you in any way. But over time, 'shareware' began to mean something different. The next model nagged users to register, and gave other annoyances that wasted time but did little to reduce value. After that, we got trial periods, after which the functionality of the software would be reduced or eliminated. By the mid-00s, central registration servers were being used to reduce piracy, and the functional difference between the offerings from these surviving shareware companies and the commercial software they competed with was that their demos were better.

This isn't because these developers were greedy. They started out trusting their users and expecting to get a good return on their work. But each step testified to the reality that depending on others to freely support you is not a viable long-term career path.

So much for donations. What about fundraising? As I've defined the terms in this post, there are two differences between fundraising and donations. The first is that in this case, you are going above and beyond trying to persuade people to give you money, begging them, if you will. The second is that you are promising future results. Any money you get from this effort isn't necessarily for your past work; it's because they're expecting you'll do more of it. In other words, you make commitments that you would make if you were working for a salary, with no salary guaranteed in return, but rather the need to get 'hired' for each and every paycheck.

The FSF seemed to suggest [3], speaking about free developers generally, that they should begin by asking for donations, and that eventually, society would shift so that this money would come unsolicited. It would be nice if this had happened, but it has been decades since this prediction and things haven't turned out that way.

Instead, the trend on the modern internet is that people expect everything to be free, and so they don't pay, unless they are forced to, or else develop a strong emotional attachment to the recipient. Thus, instead of coming to a day where everyone recognized a moral obligation to support developers, society went in the opposite direction. We are further from the FSF's dream, in this area, than when we began. There seems no prospect of this changing.

As for me, if I must be a marketing man, I would market things I have accomplished and can guarantee, rather than spending most of my time pleading with people to support me in doing things that I only hope to complete, and that, given the wrong circumstances, may not come to pass.

I'd like for you to pay me for my products, not my promises.