Some Thoughts on Crowdfunding

[vmelnychenko]

I want to share some ideas about a crowdfunding platform. It is completely unactionable for me; I am not even sure what kind of feedback I expect. In essence, I wonder how many ppl feel the same, how often these ideas come up, and what’s wrong with them exactly.

A few days ago, I learned that yet another FOSS software piece I rely heavily on has become abandonware recently. Another project that I don’t use but have kept my eyes on, because it was so promising, is also officially labeled as abandonware, and the dev is currently searching for maintainers. While looking for alternatives, I suddenly realized that I don’t really want either a typical FOSS project with a mandatory list of longstanding bugs instead of features, barely maintained by a usually overloaded and burned-out single dev, or proprietary ones, even if they are free to use, because they are not adaptable and never follow the design choices I care about.

Between the two, I would rather go with the third alternative, which can be described as a flat, recurrent donations based crowdfunding platform that only works with interconnected projects that share core principles and vision. Think of it like Netflix/Spotify for software. This is my personal sentiment; I wonder how many ppl feel the same, how often these ideas come up, and what’s wrong with them exactly.

I’ll start with an opinionated list of core principles (PEA for short). Note that these are not technical ones; how they are technically achieved is beside the point.

• Privacy and Security. FOSS never really moved along with others to smartphones, leaving billions of users to deal with ad/tracking-infested apps and data breaches. Moreover, the world is moving further toward cloud-based solutions with the expanding use of LLMs, meaning almost mandatory sharing of sensitive info. Current wearable tech will eventually turn into implantable tech, gaining unprecedented access 24/7 to deeper-than-personal data. There has to be an alternative. As there is an incentive for companies to turn into centralized data silos, there should be an equal push to give users alternatives designed to be offline-first, secure tools that preserve privacy, allowing for analysis and independent audits.

• Productivity. It means having personalization, customization, and automation considerations in mind. Create modular software that relies on open standards so users can modify, mix, and match different components for their own needs, without any vendor lock-ins.

• Efficient and reliable software. It is about having enough testing manpower and releasing only audited, well-tested software. The specific development methodology or release model is beside the point.

• Appealing UI. In simple terms, build software that’s accessible to millions of people without a tech background.

Flat recurrent donation model: Instead of donating to individual projects, the platform’d serve as an umbrella, taking recurring donations on a monthly (or yearly) basis and automatically distributing them among the programs the user utilizes most. A good analogy is Netflix or Spotify (done right)—you make a donation, and it goes to what you actually use, removing a lot of friction.

Unlike traditional platforms, it’d aim to build a complete ecosystem of interdependent projects, from low-level frameworks to user-facing apps, to recreate a whole desktop experience, for example. This can be compared to a distro or DE-level organization. In fact, there could be many compatible PEA platforms, each focused on different aspects, like mobile experience, etc.

Primarily, this would enable the donation tree. Each partner project would be required to list a few of its dependencies and share a fixed percentage of received donations (think of it like a platform fee) with 2 or 3 of them. This would create a lattice-like cash flow from user-facing programs that receive direct donations to low-level frameworks that get their share from higher-level projects. The more projects that use a framework, the more (indirect) donations it receives (analogous to popularity). This idea primarily responds to the disastrous outcome of the widely used but little-known XZ Utils project.

To enforce PEA, each partner project’d has to define its single responsibility. For example, a backup solution project could either focus on the GUI (and provide at least a bare-bones demo of supporting another backend, even if it has its own) or act as a backup backend (and consequently define an interface to support alternative clients). More importantly, it should isolate web apps from user data and actual hosting providers. The downside is that it leads to a more expensive and lengthy dev cycle.

Platform staff would be there not only to manage the financial side but also to oversee the platform-wide beta testing program, making recommendations regarding UI/UX, code quality, and more.

To conclude, with this arrangement, end users would ideally receive modern-looking, reliable, tested, and audited ad/tracking-free software from a vendor they trust. Note that they may or may not need customization. Small businesses, on the other hand, would likely benefit from the automation and customization aspects, so they’d pay local developers to quickly modify or extend functionality with plugins to fit their processes and infrastructure, rather than relying on volunteers to fill in the gaps. These plugins may or may not eventually make it upstream. Public benefit companies, nonprofits, governmental and educational entities, and of course FOSS projects would use this code just like any other open-source code.

[ngraham]

What you’re envisioning is actually quite similar to the structure of KDE already. The difference is that when people donate or set up recurring payment plans to KDE e.V., the money is retained in the organization and used on the projects that the board of directors want, rather than being automatically distributed among the developers of all the projects.

The principal challenge with moving to that model is raising enough money to still make a difference after being divided many ways. There’s a practical minimum amount of money needed before a person will quit their existing job and agree to receive their livelihood from KDE in this manner. Below this threshold they’ll likely prefer to keep their existing job and let KDE remain a hobby. So in the end it’s not projects which receive the money, but rather people, and those people need a certain amount for it to work at all for them.

Let’s get specific. Imagine a yearly income of 1M€/year dedicated to just this funding model (i.e. not including Akademy, sprints, server hosting, office+office assistant, taxes, etc.). Take that 1M and divide it among the over 300 projects in KDE. Each one gets 3,333€, barely enough to pay one developer for one month! This money is almost completely wasted, because it’s been spread so thinly that it no longer pays for anything the moves the needle.

Let’s imagine for the sake of argument than only 50 are really widely used, so let’s divide it among the 50 instead (this is unrealistic, but again, just for the sake of argument). Now it’s 20,000€ per project, enough to pay a particularly cheap developer in a country with an expansive social safety net for 4-6 months.

Now let’s imagine that each project doesn’t need one developer, because developers tend to work on multiple inter-related projects. So instead of 50 developers, maybe there are only, say, 20. Ok, this is enough to pay each of them 50,000€ a year, which is looking a bit more sustainable.

But wait, which 20 developers get the money? There are way more than 20 volunteers doing dev work in kde, by at least an order of magnitude. Uh-oh, now you have a political problem. This is solvable by KDE e.V. picking and choosing who to hire based on its democratically elected board of directors, but then it starts to look an awful lot like the status quo. Maybe instead we can distribute the money based on commits or lines of code changed? Those are game-able metrics; this doesn’t work.

So let’s scrap that too and instead raise the initial income from 1M to 100M. Now each project gets 330k€ a year, enough to pay 3 or more full-time developers. This will fit the volunteers working on most projects. Now this is looking good! But of course, where does that 100M come from?

Ultimately the problem here is that the economic value of an endeavour the size of KDE is utterly vast, easily measured in the billions of euros if it were a commercial firm. The fact that it’s offered for free and much of it was built by volunteers is a modern miracle. It defies conventional economic logic in a lot of ways. If you want to improve it with money, you’re reduced to identifying specific areas that need improvement and paying trusted people (often the original developers) to make those improvements. Which is what KDE e.V. does, as well as the many companies in KDE’s orbit.