The author is a strong proponent of Free Software and this text is aimed at a like-minded audience. The clearly formulated criticism is to be understood on this background. The text does not discuss why the promotion of Free Software is desirable, see (related to the university context). The article is heavily inspired by Colin Percival's plan for open source software maintainers and discussions in the FSFW groop meetings ("Plena"). This text was first published in German language: Funding Freedom Initiative - Idee zur Finanzierung freier Softwareprojekte.
Along with progressing digitalization software is becoming more and more important for private and professional use. More than 30 years after the constitution of the Free Software Foundation and 20 years after the establishment of the more "business oriented" concept Open Source for end users Free Software is still (or more than ever) a niche product.
Reasons are on the one hand the lack of prominence of the products and their advantages. But on the other hand we must also recognize quality issues such as usability weaknesses, missing features, stability problems and missing or outdated documentation.
For free decentralized services (e.g., Jabber-Server replacing WhatsApp) the situation is similarly. For the sake of simplicity, however, the following text is mainly concerned with desktop applications.
The business model (selling software and / or data) generates revenue. For this, labor force and public attention can be bought.
An essential feature of Free Software is that no one is excluded from use. Although a manufacturer could sell free software, they must assume that customers pass on the product - which the free license explicitly allows. In practice, selling (in the sense of "allow and enable the utilizatioin of the product in exchange for payment") of Free Software alone is not a viable business model.
Because there are people/organizations, whose actions are not exclusively guided by short-term benefit maximization. Specific sources of resources are: 1. working on free software as a hobby (problem-solving as personal joy and source of meaning, cooperation with others, recognition by positive feedback), 2. demonstration of own skills (e.g. for application procedures) 3. learning effect, 4. payments by companies or public institutions (for example, in the context of higher education), 5. donations (altruism or future-oriented self-interest) and 6. viable commercial business models (for example, selling support and adjustments).
However, despite there are amazing Free Software products out there, in most projects there is a significant lack of of resources for a desirable further development. In other words, above sources are not enough.
Wikipedia lists a total of 18 business models for "open source software" (as of November 2018). Some of these are not suitable for sustainable end-user applications, e. g. "Open sourcing on end-of-life" or "dual-licensing". Others are at least in conflict with the goal of getting the best possible Free Software (including self-explanatory documentation), e. g. "delayed open-sourcing" or "selling support".
Then of the listed business models about the half remains:
The following approach attempts to combine these models.
The above formulation "voluntary donations" suggests making payments "contrary to economic rationality" and solely from "irrational altruism". In many other areas, however, people are willing to spend considerable resources "against economic rationality", keywords: brand awareness and status consumption. In addition, as mentioned above, the financial support of a project from which one benefits individually can also be justified with future-oriented self-interest.
Suppose, there is an organization (working title: "Funding Freedom Initiative" (FFI)). All FOSS projects interested funding in receiving have registered and have an "account" at the FFI.
As an end user, you buy a Free Software Support Certificate (Bronze, Silver, Gold, Platinum (e. g. 10, 30, 100, 200 cents a day)). With the money thus received, projects are supported and (to a small extent) the administrative burden is financed.
1. You support Free Software (-> Voluntary Donation). 2. You get (optional) merchandise material (-> selling of branded merchandise), e. g. Stickers or a snappy T-shirt. In addition, "virtual accessories" are conceivable, for instance Badges for GitHub or other social networks. This basically satisfies the human wish for status consumption or the desire for distinction from others. 3. You get a privileged communication channel into the project team (e. g. higher priority for feature request polls (Bounty Driven Development) or support-requests) 4. You may get small extra-features (for projects that want this).
Billing takes place at certain intervals (e. g. per quarter). The certificate price is divided into four categories (K1-K4):
K1 (e. g. 60%) is distributed to the project accounts according to individual buyer wishes. As a decision support a software is offered (opt-in), which analyzes the local usage behavior and makes suggestions for the distribution. The premise here is: Frequently running programs are subjectively more important. A role model for this is the Debian Popularity Contest. But of course one can support any projects independently of these suggestions.
K2 (e. g. 30%) will be allocated to project accounts according to the organization. This is based on the assumption that the FFI has a better overview of the projects and can possibly also strategically promote projects with good potential that are not yet sufficiently well-known.
K3 (e. g. 10%) are operating costs (staff and infrastructure of the FFI)
K4 are material costs (for T-shirts etc.) and will be charged extra. A sticker is available on request but for free. ;-)
The allocation of funds is published "crypto-transparent":
When paying you get a token communicated. All sold Support Certificates will be released, including the following data: Token, Grand Total (K1 + K2 + K3) and K1 allocation scheme. As a result, every buyer can convince themselves whether the own certificate is correctly included in the total balance sheet (partial cash flows) and also each project can convince itself that it receives all entitled payments. In addition, everyone can convince themselves that the overall balance works out. The FFI can protect itself against allegations of embezzlement, since all sold certificates are cryptographically signed.
The registered projects can either a) have the money paid off or b) pass it on to other projects in a transparent way (e. g. to libs on which they depend). Formally, the money counts as donations. The use (and taxation) is the responsibility of the recipient.
When registering The projects pledge themselves to regularly (say two times a year) publish a report on the use of the funds. Possible examples might look like this:
For individual projects the fundraising effort is usually too big. That indicates a separate and specialized organization - which not necessarily needs to be new. Possibly an existing organization (obvious example: Free Software Foundation (FSFE)) could implement the idea. Due to the fact that the operating costs (see K3 above) already have been factored in, the project could be self-supporting - within a larger organization or possibly even as a classic start-up with venture capital. A new organization of its own would probably be more agile than an established one with grown structures and internal plurality of opinion. This is offset by the disadvantage that initially it would start with zero outreach and zero credit of trust. A hybrid approach would be that several established organizations jointly push a new one or support its foundation through their networks.
Bottom-Up: 1000 participants (100 Euro daily) would allow to fix a (small) bug every day. This might be the lower bound of long term sustainability and usefulness. At this level operating costs (10 Euro daily) would not suffice and volunteer organizational work would be necessary. Beginning with 10K participants (100 Euro daily operating costs) the concept could economically sustain it-self.
Top Down: There are estimated to be 1 billion PCs in operation worldwide. As a proxy estimate for confident FLOSS users we refer to Linux's market share as a desktop operating system. It is 1.3% (Source: statista.com). Of these, an estimated 10% would buy a certificate for an average price of 10 cents a day. This results in 10^9 (number of PCs) * 0.013 (Linux market share) * 0.1 (willingness to buy) * 0.1 (Euro / day) = 130K Euro per day for investing in the FOSS ecosystem. Depending on the region of the world, these are between 100 and 1000 full-time positions.
Both calculations show that the FFI-idea 1. is not completely utopian and 2. theoretically has great potential.
Note: If it were possible to include the app market of mobile devices, the cake would be significantly larger (and a smaller piece of it would suffice to get the project running).
Text is patient. For something to happen, it usually requires human activity. It is clear that starting such a project only makes sense in coordination with the FOSS community. Therefore the first step is to get feedback . Criticism (errors of reason?, unrealistic assumptions?, "overseen existing solutions"?) and encouragement are both equally important. Experience shows that criticism usually comes by itself :-).
If there is a sufficient amount of positive feedback, possibly even support, the next steps could be taken: consider names and reserving domains, specify the concept on a more detailed level, get legal advice, call for feedback on a larger scale (NGOs, distributors, Reddit, mailing lists), set up infrastructure, start crowdfunding campaign, ...
Nevertheless, feedback remains the first step.
Those who want good FOSS software, should be ready to do something or pay for it. The "Funding Freedom Initiative" is a proposal for the cooperative distribution of money from end users to Free Software projects. It aims to increase the spread and the quality of Free and Open Source Software. If you have an opinion regarding this topic we would be glad to hear from you. Feedback to email@example.com.