notes from /dev/null - musings

Thoughts on Funding Free Software Development

2025-11-13T17:20:00-08:00

“I have always depended on the kindness of strangers.” — Blanche Dubois from “A Streetcar Named Desire”, Tennessee Williams.

DISCLAIMER: None of this post should be considered as financial or career advice of any kind. All views and opinions expressed here belong solely to Charles Y. Choi.

Not getting paid for making free software has long been recognized as a conundrum in the early 21st century, where much of its discourse is trenchantly summarized by the xkcd drawing “Dependency” [1] shown below.

For some time I’ve been gathering my thoughts on this matter, with stances that I’ll share in this post today.

Fundamentals on Bringing a Product to Market

Before talking about software, let’s review the basic steps needed to bring a physical product to market.

Design & Development

In this step, the intellectual construction of the product is defined.
Manufacture

In this step the product is mass produced. This step must occur after step 1.
Distribution

In this step the manufactured product is delivered. This step must occur after step 2.
Marketing

In this step, awareness of the product to its target market is raised to induce demand for it. Ideally this step is taken when there is high confidence in delivering the product to the market.
Support

In this step, the producers provide support for the product after it has shipped. This step must occur after step 3.

For a physical product, each step has a monetary cost associated with it. If the producer wishes to make a profit by selling the product, the price of the product must be greater than the cost to produce it. This leads to the incentive to manufacture and distribute as many copies as possible to maximize profit. At scale, the dominant costs are manufacturing and distribution for a physical product.

Software is Different

If the product is software using internet distribution, then its costs for manufacture and distribution become effectively zero. For a software provider, the dominant costs to bring a product to market are design & development, marketing, and support. Such costs are largely fixed with respect to demand. Since software has no intrinsic manufacturing nor distribution cost, for-profit software must resort to creating artificial scarcity to justify (and protect) profit that scales with meeting demand. Tactics to create scarcity include:

Constraining code to be closed-source.
Distributing only executables, typically code-signed to a model of computer.
Compilation-enforced licensing, typically tied to a subscription model.

What about Free Software?

With that background in place, let’s talk about free (both in speech and beer) software. In this post, I make no distinction between free (libre) and open source licensed software [2] as their differences fixate on the user’s ability to modify and redistribute received software. In contrast, this post views free software through the lens of the costs required to deliver said software to the market as described above.

Free software requires that its distribution be zero-cost to users. In contrast with for-profit software, free software evades the creation of artificial scarcity. In light of this, what options are available for developers who want to get paid for making free software? Here are three:

Ask users to voluntarily give money after the software has been produced.
Attach the developed software to a service or hardware-based business model.
Get money upfront from users (or organizations) who have an interest in realizing some specific software, before its design and development are completed.

The first option offers providers no financial incentive to make free software, nor offers a reliable path to cover the cost to make it.

The second option relies on indirect compensation where the service or hardware revenue is expected to cover the cost of software development. Scarcity is imposed by restricting access to the service or hardware based on payment. This option is often taken by startups funded with venture capital.

The third option offers direct financial incentive for the developer to create free software, as money is taken by the developer with the expectation that said software is delivered at a future date. With this option, the design & development step is what is considered scarce. Upfront funding can come in a variety of forms, but largely fall into the following patterns:

Institutional funding, where an organization puts up the funding.
Angel funding, where a small group (< 5) of people contribute the funding.
Crowdfunding, where a pool of small contributions from individuals (> 1,000) is gathered, typically with a target funding goal.

Which approach is taken can vary widely depending on the functionality of the software and the relationship (or lack thereof) between the developer and their benefactors. Note that getting money upfront to develop software precludes gaining profit from it based on demand after it is made, as free software insists its distribution be zero-cost to users. The only avenue for developer profit in this case is to demand funding that exceeds the baseline cost of producing the software.

Getting money upfront implies negotiation, which gives the developer agency to choose whether to commit to building the desired software. It also significantly raises risk to all involved parties if the software fails to be built.

Upfront funding aligns the incentives for producers and consumers of software by having agreement on a future deliverable:

Consumers pay to get the future software deliverable.
Producers work to build the future software deliverable.

While the exact number is unknown, I think a safe presumption is that single developers have built the vast majority of free software packages as evidenced by the Linux, Emacs, Python, and Node ecosystems. Most all of them resort to appeals to user gratuity, which is not enough to actually cover the market cost of designing & developing that software.

Given the above options for upfront funding, I’ll further make the assumption that most single developers do not have access to institutional nor angel funding. So, let's talk about crowdfunding.

Crowdfunding

The dominant cost to producing software is labor. A common project scope is a three month schedule with a single developer. Estimating a market rate salary of $10K/month, this results in a budget of $30K to deliver software at cost.

Crowdfunding has proven to be successful in raising that level of funding, by mitigating risk to all participants by defining a funding goal. Typically a funding goal is set within a window of time. If the goal is not met, then patrons who already put money down will have their money returned and the producer is not committed to work on the software. With high demand, the goal can be met with potentially low financial risk to an individual patron. For example, if 30,000 people gave $1, the above budget could be met.

Reaching those 30,000 people is another thing altogether, as crowdfunding is an exercise in marketing.

To have a successful crowdfunding campaign, the producer must deliver a message about a future software product that is compelling enough to create demand for it. Common tasks undertaken to make a crowdfunding campaign include producing:

A video describing the envisioned product.
Marketing copy for said envisioned product published on web, possibly print.
Brand merchandise for patrons.
- Order taking
- Fulfillment
Press campaign.
Social media campaign.

Note that the success of the crowdfunding campaign will depend on how effective its message is to the target audience. Each audience is bespoke, meaning that not all things successful for one crowdfunding campaign can be applied to another. Invariably, the software producer must know their audience.

Single developers producing free software might look at the above and say “nope.” Most certainly it is a lot of work, much of which is perhaps outside the comfort level of persons whose focus has only been on coding. It is also not a common practice to use crowdfunding to support free (libre) or open source development. Regardless, if a developer wishes to be paid to work on free software, they will need to get comfortable with pitching their work beforehand to get the funding to do it. Wider-scale use of crowdfunding could bring better agency to the developer and enable the development of larger scope free software projects that would be untenable with volunteer time.

Observations and Closing Thoughts

This post has been a distillation of my thinking about free software and how it can be sustainably funded. From this exercise are some of my personal observations:

If you have a software idea that you want to distribute for free, determine as soon as possible if you want to get paid to make it.

If you don’t care about getting paid, ever, for that work, then GO MAKE IT! Be thankful for whatever gratuity you get from it.

If you do care about getting paid to make the idea, then explore what funding model fits best for the idea. At this point, DO NOT MAKE THE IDEA AND PUBLISH IT.

If you get funding, GO MAKE THE THING. MAKE PEOPLE HAPPY.

If you don’t get funding, let it rest. Move on to the next idea.

If you already produced free software that was built without funding, accept that you will never recover your development cost.

To reiterate, free software requires that its distribution be zero-cost to users. This is excellent for user freedom but comes at the expense of agency for developers: Users can not be compelled to pay developers for their already published work. Developers can however make new features and fixes contingent on funding. I think this position is fair and defensible for the obvious reason that software developers must pay for the costs of living in a material world.

If you’ve made to here, thanks for reading! Feel free to share your thoughts about this post on Mastodon or Reddit.

References

[1]

R. Munroe, “Dependency,” Aug. 17, 2020. Available: https://xkcd.com/2347/

[2]

R. Stallman, “Why open source misses the point of free software - gnu project - free software foundation,” 2024. Available: https://www.gnu.org/philosophy/open-source-misses-the-point.en.html

Surprise and Emacs Defaults

2023-07-05T09:54:00-07:00

Throughout the history of building computers (both hardware and software), there have been different schools of thought on how to build them. There’s really no one “right” way, however different schools have formed with different levels of success. The thinking of such schools gets further compounded by the many levels of abstraction in computer design. More often than not, a school with a successful pattern at one level of abstraction tries to apply that to other (or worse yet, all) levels. An observation in building computers is that invariably you must ship something that embodies both policy and mechanism. Systems that coherently separate the two end up being more flexible to change.

When I think of the default settings in Emacs (base and external packages alike) and its design overall, I can’t help but think of its culture’s emphasis on providing mechanism and deferring policy to user choice. Perhaps this thinking was influenced by the design of X11 protocols (“Provide mechanism rather than policy. In particular, place user interface policy in the clients’ hands.”). Regardless, this school of thinking values building systems with generalized behavior that can be sculpted into many specific use cases. With such thinking there is a strong tendency to not fixate on the default policy, as it can always be defined by the end user.

Another school of thought, particularly coming from 80’s microcomputer user interface research has been to emphasize consistency to improve usability. Such thinking, evangelized by folks such as Bruce Tognazzini and Don Norman, has had a profound influence in thinking about computer user experience (UX). Key to gaining such consistency was to be very opinionated about policy. Informed by human computer interface (HCI) research and scaled by microcomputer adoption, the UX of such opinionated software became the expected convention by contemporary users.

Suffice to say, the conflict between such schools of thought play out repeatedly in many different places; the most recent one that comes to mind is the Fediverse (Mastodon, ActivityPub, etc.) versus Scott Jenson.

It also plays out in thinking about the default settings (aka the policy choices) in Emacs in 2023.

New users are often surprised by the policy choices in Emacs because these choices often diverge from conventional app UX. When surprised, the reaction can be quite adverse. Such was the reaction from @summeremacs which prompted me to write this post. I’ve had similar reaction multiple times as well over my several decades of using Emacs.

I don’t have any power to make Emacs maintainers change their defaults, but I will call out that the default settings they ship are a policy choice. If one considers usability with minimal training (and consequently minimal surprise) to be valuable, as I do, then positive first impressions are important! I think it would be a better thing for Emacs defaults to be less surprising to contemporary users.

That said, here are some opinionated Emacs settings that I think makes Emacs less surprising.

Variables

bookmark-save-flag

By default, bookmarks are saved only when you exit Emacs cleanly. This is problematic if you keep Emacs running for a long time, particularly if you use Emacs server and are not aware of this default behavior. I got burned badly by this several years back when first adding a number of bookmarks during a long-running Emacs server session. The session ended up being in a bad state, crashing Emacs, and I had lost all those bookmarks. Persisting bookmark changes to disk as it happens it is the saner default. I leave it as an open question as to why bookmark-save behavior is so complicated.

Default	My Setting
t	1

Interestingly enough, in the recent post Emacs: mark and register basics, Stavrou remarks that he discovered bookmark-save-flag after implementing his own logic to persist bookmarks, which reinforces my opinion that the default behavior of persisting bookmarks is surprising.

sentence-end-double-space

The one that triggered @summeremacs. Yes, sentences are single-spaced in 2023.

Default	My Setting
t	nil

delete-selection-mode

If you select text and then type over it, it should delete that text. Surprisingly, you do not get this behavior out of the box with default Emacs. You have to explicitly enable it.

Default	My Setting
nil	t

dired-auto-revert-buffer

By default, Dired buffers will not update themselves unless you explicitly tell them to. Setting this variable to t will auto-update the Dired buffer when you revisit it.

Default	My Setting
nil	t

global-auto-revert-mode, global-auto-revert-non-file-buffers

Whenever the disk state changes, Emacs should update as well. While supported, this is not turned on by default. Changing these two variables to t fixes this.

Default	My Setting
nil	t

dired-dwim-target

If you like Dired to emulate Midnite Commander with having two Dired buffers side-by-side and moving files between then both, then use this setting.

Default	My Setting
nil	dired-dwim-target-next

eshell-scroll-to-bottom-on-input

Pretty much every terminal program will scroll to the bottom on input. Eshell won’t though until you configure it to.

Default	My Setting
nil	this

magit-save-repository-buffers

IMHO Magit is too cautious by defaulting to prompting the user to save every modified file in a repo before taking action. This gets annoying quite fast. Setting it to dontask will save you from a lot of prompts.

Default	My Setting
t	dontask

Ediff

Having the visual diff tool, Ediff, packaged into Emacs is really convenient. I’ll be blunt though: Ediff default behavior out of the box is awkward. First, the Ediff control panel is put into a separate frame (GUI window) when running in GUI mode, making GUI window management an issue. Second is the default behavior to show the diffs on top of each other rather than side-by-side. Third, when you quit Ediff, your previous window¹ layout is messed up.

Here is what I do to address the above three points:

Variable	Default	My Setting	Notes
ediff-split-window-function	split-window-vertically	split-window-horizontally	Show diffs side-by-side
ediff-window-setup-function	ediff-setup-windows-default	ediff-setup-windows-plain	Puts the control panel in the same frame as the diff windows¹

Updated 2023-07-10 - Please disregard this Ediff checkpoint and restore logic. A much better configuration is offered in the post Using Ediff in 2023.

~~Checkpoint and restore window~~¹ ~~configuration for Ediff session~~ (code from helm - Restoring windows and layout after an Ediff session - Emacs Stack Exchange):

(defvar my-ediff-last-windows nil)

(defun my-store-pre-ediff-winconfig ()
"Store `current-window-configuration' in variable `my-ediff-last-windows'."
(setq my-ediff-last-windows (current-window-configuration)))

(defun my-restore-pre-ediff-winconfig ()
"Restore window configuration to stored value in `my-ediff-last-windows'."
(set-window-configuration my-ediff-last-windows))

(add-hook 'ediff-before-setup-hook #'my-store-pre-ediff-winconfig)
(add-hook 'ediff-quit-hook #'my-restore-pre-ediff-winconfig)

Man-notify-method

When raising a man page in Emacs, the default behavior is to open it in a new buffer but keep the focus on your current buffer. Typically I want to read the man page and quickly exit it. Changing this variable to aggressive will change the focus to the new man buffer so you can immediately (q)uit it.

Default	My Setting
friendly	aggressive

Summary

Reviewing the above defaults, I’m struck by seeing that many of them deal with synchronizing state (typically persisting to disk) and choose to make the user responsible for managing it. This stands in stark contrast to conventional UX in both desktop and mobile apps to automatically synchronize state on behalf of the user. My preferences definitely are in-line with the latter camp.

If you’ve gotten to here I hope this post has been helpful, especially if you’re new to Emacs. Let me qualify that I very much like using Emacs and that I am deeply grateful to its many contributors who help make it an essential tool for me. That said, I do think first impressions are important in software, and the less surprises it gives the user, the better. Ciao folks!

Footnotes

¹ Emacs window definition, which is a whole another story on the different semantics Emacs uses to describe UI elements.