Would you pay for Free Software?

Would you pay for Free Software?

For most of us who used smartphones for any length of time before switching to Linux, learning how to download a lot of graphical applications on a Linux distro was quite a smooth process: just open the app icon that looks like an App Store, and what you see is an "App Store" where everything is free to download. Not only that, but none of the applications had advertisements or in-app purchases in them. It felt refreshing.

This has been the situation up to now.

However, things are seldom meant to stay the same. In fact, through these years, a topic that has been discussed more and more is the sustainability of most free software projects. It's easy to forget that maintaining FOSS projects has a cost: computing resources, time and energy are only a few of the resources consumed while maintaining a free software product. A lot of the open source applications you love are not developed as a job and they are not meant to make a profit; they are side projects that are mostly maintained by students and by developers who work a regular, corporate software development job as their 9-to-5, but also manage to find the time and energy to spend on the project in the limited amount of free time they have.

So, how do you maintain a FOSS project?

With traditional proprietary applications, a very common way people get motivated to build and maintain those projects is the profit motive - not only do they have fun building something they love, but they also turn it into a revenue stream. Many use the extra money derived by the sale of some software as a side hustle, many more dream of escaping the 9-to-5 schedule to gain more flexibility and work on projects they like better, and launching a successful application is often seen as the way to go. It's still the same dream born in the early 2010's as smartphones began spreading, and the mobile market was seen as a great opportunity to launch a successful product and make a lot of money.

On the other hand, looking at free software projects, things are not quite the same. People typically do not make much money from an open-source application, where donations are the main revenue stream. The motivation to maintain the project even through the most annoying chores and most stressful periods has to come from somewhere else than the profit motive. It is no surprise that most FOSS developers are very passionate about what they do - they do not merely tolerate or not mind the act of building software, they are passionate about something and they want to bring it to light. But passion only gets you so far, and it is often not enough to motivate people past an initial sprint where an initial working version of the project gets released... and then it gets abandoned.

Linus Torvalds showing off an iteration of his working desk, forever ago

It is very common for free software maintainers to reach a psychological condition called burnout. Burnout is what happens when you overload yourself - either by overworking or by having too much pressure put on yourself in general - to the point where you start losing efficiency and your mental and physical well-being quickly decreases: you start to feel more and more tired, then you start to dread your work, then you start to lose motivation to even pursue hobbies you like, then you begin struggling even to get your basic daily tasks done. When left unchecked for a long time, there is a very real possibility that it could lead to depression. Burnout is a sneaky beast that is sadly infamous in the software community.

Burnout is often the real death of open-source projects. How often have you used an application that had something like -ng or -next in its name? That would be a strong indicator that the application was not being maintained by the people who originally wrote it, but was picked up by someone else. Sadly, lots of smaller projects die this way: the lone maintainer who works on them gets tired and quits. This is made more and more aggravating as a piece of free software starts getting popular, so users begin complaining about bugs / missed features, and some companies who use the software freely without contributing anything back begin pushing for changes and fixes the same way they would for a commercial product they are paying. It's also not only small projects that get affected - people leave big projects due to burnout all the time. In fact, without delving too much into Linux kernel drama, during the past few months, a bunch of Linux kernel maintainers have left their positions, partially or mostly due to burnout.

So, how do you solve burnout?

There are several approaches one can take. However, the most effective remedy is to reduce the amount of time you work. This is why contributing to an open-source project is such a good idea and a fundamental practice: not only you will learn a lot - by working on technologies that your company doesn't use and that you would otherwise never even discover - but you are also helping out the maintainers. Any contribution you make is some load taken off of the maintainers' shoulders, and it will be appreciated.

However, code donations are not the end-all-be-all. Financial donations are also equally important. Money can be a good motivator to keep building the software, and it can even be put back into development in many ways. Maybe a maintainer owns an old, slow computer, and putting some donation money into something more powerful can do wonders to help the development progress. Maybe some bills need to be paid to host APIs somewhere, or - one of the most obvious options - money allows a maintainer to put more hours into their project: when you do have a second income source it's much simpler to reduce your job from a full-time to a part-time, get paid less for it, and use the remainder of the time to maintain your project.

The question is: do donations work? How do you even integrate money into free software?

Donations might not be enough

Donations are nice, for all the reasons we have just stated. They are a great help to a project, and they also allow anybody to make important contributions to a piece of software, even if coding skills, writing skills for documentation or even energy and time are not assets they can contribute. In a lot of cases, it might be easier to contribute to software you know and love, like KDE Plasma, by periodically donating the financial equivalent of one hour of your day job to the project.

The problem with donations is that few people make them. Altruistic folks do exist but, for one reason or another, most people never donate to a free software project.
Some projects have reacted to this in various ways, all of them mostly geared to finding a middle way between the donation-supported model and the proprietary sale-based support models.

So how do you even sell Free Software?

Which raises the question: selling an application? In my "Free Software" community? It's more likely than you think!

While it might seem contradictory, the FSF's official definition of free software explicitly allows selling a piece of FOSS for a price. Even Richard Stallman, founder of GNU, has repeated many times that copyleft software can absolutely be sold.

Several free software projects try to sell their applications in order to gather more donation money to aid development, and they don't have an easy job to do: it's a road full of roadblocks, and it's a hard balance to strike.

There are two approaches here that are being explored: either strongly encourage a donation through a free offer, or sell binaries.

"Pay what you want"

The former approach is taken by elementaryOS, a really pretty Linux distro that focuses on design and providing users with a highly refined UX. If you look at their landing page, at first glance, you will think that it is a paid-for operating system - but it is only when you look closer that you realize you can choose the amount you pay. If you want, you can go to the length of defining a "Custom" amount of €0.00, and still being able to obtain the OS without a payment. They call it the "Pay What You Can" model, and it has its pros. People who can pay for the software are strongly encouraged to do it, while people who might not have the money to spare are not obligated to donate much if anything at all.

Free code, paid binary!

Another very interesting approach is charging for convenience. Some projects decide to leave the code completely free, but charge for pre-built binaries. This means that, officially, while you are free to clone and compile the software for yourself - which is a longer and more tedious process for a regular user - you will be asked to pay a fee to download a regular binary that you can install and run on your computer. This is the approach taken by Ardour, a free and open-source Digital Audio Workstation software.

You will see it hinted on the initial download page, where you are asked if you want a ready-to-run program or the source code, explaining why the source code might be technically challenging.

From there, it only takes a couple more clicks to be taken to the purchase page. You will be asked to make a payment. You can choose between a subscription model, buying a single version, or also being eligible for updates, depending on the amount of money you pay.

But is this effective?
The answer is - well, it depends.
On Windows and Mac this model might work. On Linux, though, it doesn't. Just as a test, let's see what happens when we look for Ardour through the available distro packages on my machine:

As you might imagine, you will have no trouble finding a free download there. Clearly - this is allowed. It's still free and open-source software, so while the developers themselves might not want to give you a free binary, external maintainers are still allowed to repackage any kind of free software and make it available for free download.

This makes it, sadly, the no-brainer option for Linux users. Not only for the price but because there are several advantages to installing a piece of software from your distro's repositories - among which I am, of course, counting Flathub.

The first and most obvious one is ease of access. It's just a much faster process to install something through your package manager than to go on a website, download the binary, put it in your PATH, or figure out how to manually install the package, cross your fingers and hope it works on your exact setup. You will even get software updates more easily, and you will even get all the cool features of Flatpak, like sandboxing and the permission model!

So, it naturally follows: wouldn't it be cool if, as a developer, you could maintain your own Flatpak package on Flathub, and handle donations or payments through a centralized way, like App Stores, which would allow users to pay for your binary or quickly send you a donation with just a click and a quick scan on their fingerprint reader?

Payments on Flathub

Enter payments on Flathub.

While it is not possible to pay for applications on Flathub yet, the problem has had the idea to eventually implement support for something like this for a long time. However, things are finally beginning to take shape: the GNOME Foundation, in conjunction, with the KDE e.V, has posted a job offer looking for someone who would be qualified to lead the management of a program that would allow payments on Flathub, and finish off the already started work on the payment backend.

So far, one of the people who have replied to this thread is none other than Cassidy James himself, one of the core maintainers of the Elementary project. Paying for Linux applications is already a reality on the Elementary AppCenter, where developers who make Vala apps targeting elementaryOS specifically can decide to make them paid-to-download.

As you can see, the details are still yet to be decided, but things are moving, job positions for this project are opening up, and some of the most competent people in this area of expertise across the Linux community are beginning to show interest.

If it all goes well, what this means is that Flathub will support paid applications as well, like a regular App Store, providing a solid financing option for projects that decide to rely on it.

It is yet to be seen what would happen to third-party packages that are available for free, should the developers take over. But there is little room for speculation when the figure that is being hired is supposed to take care of all these bits and details.

It will be an interesting change of paradigm for sure, where paying for the convenience of having a Flathub package for some of the FOSS you use will be a reality. Whether this will finally help projects ease some financial pressure, or whether this not help, is yet to be seen. We also do not know yet how this will be used: on top of paid apps, direct payments through the store could also serve the goal of making donations easier. Reducing the barrier to donations is often a great way to obtain more, so that would be great progress. Going back to elementary again, their AppCenter has supported donations for a very long time already!

AppCenter donations

This is also a similar concept to what the success of Steam is built on. While this is talking about piracy, which is a completely different can of worms, the words of Gabe Newell on how comfortable accessibility of a paid-for service helps with its success have been proven right time and time again, so I don't see why applying the same concept to funding free software projects would not work:

“One thing that we have learned is that piracy is not a pricing issue. It’s a service issue (...) The easiest way to stop piracy is not by putting anti-piracy technology to work. It’s by giving those people a service that’s better than what they’re receiving from the pirates.”

For a lot of people, it really is not about the price. It's about how encouraged and accessible a payment is, and what you get in return for going that route. It seems like Flathub is trying to go in the same direction here.

Whatever happens, what I personally hope is that it will be a good step forward in finally addressing FOSS maintainer burnout once and for all.