Funding Freedom Initiative - Idee zur Finanzierung freier Softwareprojekte


Note:

An english version of this blog post and presentation slides prepared for 35C3 are availible in the wiki.

tl;dr

Dieser Text beschreibt eine Idee zur Steigerung der Verbreitung und Qualität von freier quelloffener Software (kurz: FLOSS). Durch die Kombination existierender Geschäftsmodelle (Spenden, Merchandise, Bounties, Funding-Organisationen) sollen Finanzmittel akquiriert werden, die FLOSS-Projekten für Entwicklung, Design, Marketing, Dokumentation etc. nutzen können. Kernidee ist der „Verkauf“ von FLOSS-Support-Zertifikaten.

Vorbemerkung

Der Autor ist ein starker Befürworter Freier Software und richtet sich an ein gleichgesinntes Publikum. Vor diesem Hintergrund ist auch die im folgenden deutlich formulierte Kritik einzuordnen. Der Text geht nicht darauf ein, warum die Förderung Freier Software erstrebenswert ist, siehe dazu (bezogen auf den Hochschul-Kontext) https://fsfw-dresden.de/programm. Der Beitrag ist stark inspiriert durch Colin Percivals Plan für Open Source Software Maintainer und Diskussionen im FSFW-Plenum.

Bestandsaufnahme

Ausgangslage: Mit zunehmend fortschreitender Digitalisierung wird Software privat und beruflich immer wichtiger. Freie quelloffene Software ist über 30 Jahre nach Gründung der Free Software Foundation und 20 Jahre nach Etablierung des eher „business-orientierten“ Konzeptes Open-Source für Endbenutzer*innen dabei immer noch (oder mehr denn je) ein Nischenprodukt. Gründe sind einerseits mangelnde Bekanntheit der Produkte und ihrer Vorteile, andererseits aber auch Qualitätsfragen wie Usability-Schwächen, fehlende Features, Stabilitätsprobleme und fehlende bzw. veraltete Dokumentation.

Mit freien dezentralen Diensten (z. B. Jabber-Server als Ersatz für WhatsApp) verhält es sich ähnlich. Der Einfachheit halber geht der folgende Text aber hauptsächlich auf Desktop-Applikationen ein.

Warum ist proprietäre Software meist verbreiteter und in den genannten Punkten oft qualitativ besser?

Das Geschäftsmodell (Verkauf von Software und/oder Daten) generiert Einnahmen. Dafür kann Arbeitskraft und Aufmerksamkeit eingekauft werden.

Warum funktioniert das bei Freier Software so nicht?

Ein wesensbestimmendes Merkmal Freier Software ist, dass niemand von der Nutzung ausgeschlossen ist. Ein Hersteller könnte zwar Freie Software verkaufen, muss aber davon ausgehen, dass Kunden das Produkt weitergeben - was die freie Lizenz ausdrücklich erlaubt. Praktisch ist der Verkauf (im Sinne von „Ermöglichung der Nutzung als Gegenleistung für die Bezahlung“) von Freier Software allein also kein tragfähiges Geschäftsmodell. Dadurch ist es deutlich schwieriger, Einnahmen zu generieren.

Warum funktioniert das Konzept „Freie Software“ dann überhaupt?

Weil für manche Menschen/Organisationen nicht nur kurzfristige Nutzenmaximierung handlungsleitend ist. Konkrete Quellen von Ressourcen sind 1. Arbeit an Freier Software als Hobby (Sinnstiftung durch Problemlösen, Zusammenarbeit mit anderen, Anerkennung durch positives Feedback), 2. Demonstration eigener Fähigkeiten (z. B. für Bewerbungsverfahren) 3. Lerneffekt, 4. auf Grund von konkretem Eigeninteresse durch Unternehmen oder öffentliche Einrichtungen bezahlte Entwicklung (z. B. im Hochschulkontext), 5. Spenden (Altruismus oder zukunftsorientiertes Eigeninteresse) und 6. tragfähige kommerzielle Geschäftsmodelle (z. B. Verkauf von Support und Anpassungen).

Fakt ist aber: In den allermeisten Projekten fehlt es an Ressourcen für eine wünschenswerte Weiterentwicklung. Mit anderen Worten, obige Quellen von Ressourcen sind nicht ausreichend.

Analyse existierender Geschäftsmodelle

Wikipedia listet insgesamt 18 Geschäftsmodelle für „Open-Source-Software“ auf (Stand Juni 2018). Einige davon kommen für nachhaltige Endanwender-Applikationen nicht in Frage z. B. „open sourcing on end-of-life“ oder „dual-licensing“. Andere stehen zumindest im Konflikt mit dem Ziel die bestmögliche Freie Software (inkl. selbsterklärender Doku) zu bekommen, z. B. „delayed open-sourcing“ oder „Verkauf von Support“.

Von den gelisteten Geschäftsmodellen verbleibt dann die knappe Hälfte:

  1. Selling of branded merchandise
  2. Selling of certificates and trademark use
  3. Partnership with funding organizations
  4. Voluntary donations
  5. Bounty driven development
  6. Pre-order/crowdfunding/reverse-bounty model
  7. Crowdsourcing
  8. Advertising-supported software

Der folgende Ansatz versucht diese Modelle zu kombinieren.

Ideenskizze zur Kombination einiger dieser Methoden

Vorbemerkung

Die obige Formulierung „Voluntary donations“ legt nahe, Zahlungen zu leisten „entgegen der ökonomische Vernunft“ und allein aus „irrationalem Altruismus“. In vielen anderen Bereichen sind Menschen aber bereit, erhebliche Mittel „gegen die ökonomische Vernunft“ auszugeben, Stichworte: Markenbewusstsein und Statuskonsum. Zudem kann, wie oben schon erwähnt, die finanzielle Unterstützung eines Projektes von dem man individuell profitiert, auch mit zukunftsorientiertem Eigeninteresse begründet werden.

Beschreibung des Kombinationsmodells

Es gibt eine Organisation (Arbeitstitel: „Funding Freedom Initiative“ (FFI)). Bei dieser haben sich alle an Finanzierung interessierten FLOSS-Projekte registriert und haben ein „Konto“.

Als Endbenutzer*in kauft man ein Free-Software-Support-Zertifikat (Bronze, Silber, Gold, Platin (z. B. 10, 30, 100, 200 Cent pro Tag)). Mit dem so eingenommen Geld, werden Projekte unterstützt und (zu einem kleinen Teil) der Verwaltungsaufwand finanziert.

Warum sollten Menschen für sowas Geld ausgeben?

1. Man unterstützt Freie Software („Voluntary Donation“). 2. Man bekommt (optional) Merchandise-Material („Selling of branded merchandise“), z. B. Aufkleber oder ein schickes T-Shirt. Zusätzlich sind „virtuelle Accessoires“ denkbar, also z. B. Badges für GitHub oder andere soziale Netzwerke. Das geht in Richtung Statuskonsum bzw. Distinktionsbedürfnis. 3. Man bekommt privilegierten Kommunikationskanal ins Projektteam (z. B. höhere Priorität bei Feature-Wunsch-Abstimmungen (Bounty driven development) oder Support-Anfragen) 4. Man bekommt ggf. kleine extra-Features (Für Projekte, die das wollen).

Wie erfolgt die Verteilung des Geldes?

Abgerechnet wird in bestimmten Intervallen (z. B. pro Quartal). Der Zertifikatspreis wird in vier Kategorien (K1-K4) aufgeteilt:

K1 (z. B. 60 %) wird nach individuellen Käufer-Wünschen auf die Projektkonten verteilt. Als Entscheidungshilfe wird eine Software angeboten (opt-in), die lokal das Nutzungsverhalten analysiert und Vorschläge für die Verteilung macht. Die Prämisse dabei ist: Häufig laufende Programme sind subjektiv wichtiger. Vorbild: Debian Popularity Contest. Man kann aber unabhängig von diesen Vorschlägen beliebige Projekte unterstützen.

K2 (z. B. 30 %) werden nach Einschätzung der Organisation auf die Projektkonten verteilt. Die Annahme dabei ist: Die FFI hat besseren Überblick über die Projekte und kann ggf. auch strategisch Projekte mit Potential fördern, die noch nicht hinreichend bekannt sind.

K3 (z. B. 10 %) sind Betriebskosten (Personal und Infrastruktur der FFI)

K4 sind Materialkosten (für T-Shirts etc.) und werden zusätzlich berechnet. Einen Aufkleber gibt es auf Wunsch aber „gratis“. ;-)

Wie wird Veruntreuung verhindert?

Die Zuteilung der Gelder wird „crypto-transparent“ veröffentlicht:

Beim Bezahlen bekommt man einen Token mitgeteilt. Alle verkauften Support-Zertifikate werden veröffentlicht, inkl. der folgenden Daten: Token, Gesamtsumme (K1 + K2 + K3) und K1-Zuteilungsschema. Dadurch kann jede*r Käufer*in sich überzeugen, ob das eigene Zertifikat korrekt in der Gesamtbilanz enthalten ist (partielle Geldflüsse) und auch jedes Projekt kann sich überzeugen, dass es alle zustehenden Zahlungen erhält. Zudem können sich alle überzeugen, dass die Gesamtbilanz aufgeht. Die FFI kann sich vor Anschuldigung der Unterschlagung schützen, da alle verkauften Zertifikate signiert sind.

Was passiert mit dem Geld bzw. durch das Geld?

Die registrierten Projekte können sich das Geld a) auszahlen lassen oder b) transparent an andere Projekte weiterleiten (z. B. zu Libs von denen sie abhängen). Formal gesehen sind es Spendengelder. Die Verwendung (und Versteuerung) liegt in der Verantwortung der Empfänger*innen.

Die Projekte verpflichten sich bei der Registrierung regelmäßig einen Bericht zur Verwendung der Gelder zu veröffentlichen. Mögliche Beispiele könnten folgendermaßen aussehen:

Wird dafür eine eigene (neue) Organisation gebraucht?

Für einzelne Projekte ist der Fundraising Aufwand meist zu groß. Das spricht für eine separate Organisation. Eine solche muss aber nicht notwendigerweise neu gegründet werden. Ggf. könnte eine bestehende Organisation (naheliegend: Free Software Foundation, FSFE) die Idee umsetzen. Durch den einkalkulierten Betriebskosten-Anteil könnte sich das Projekt selbst tragen - innerhalb einer größeren Organisation oder ggf. sogar als klassisches StartUp mit Risiko-Kapital. Eine eigene neue Organisation wäre vermutlich agiler als eine etablierte mit gewachsenen Strukturen und interner Meinungspluralität. Dem steht der Nachteil gegenüber, dass sie unbekannt wäre und sich Vertrauen erst mühsam erarbeiten müsste. Denkbar wäre auch, dass mehrere etablierte Organisationen gemeinsam eine neue anschieben bzw. deren Gründung durch ihre Netzwerke unterstützen.

Potentielle Kritikpunkte und mögliche Gegenargumente

Potentielle positive Effekte

  1. Es gäbe eine positive Rückkopplung: Qualität steigt -> Anzahl der Nutzer*innen steigt -> Anzahl der verkauften Zertifikate steigt -> Verfügbare Ressourcen steigen -> Qualität steigt -> usw.
  2. Mit guter Freier Software könnte man tatsächlich ordentlich Geld verdienen. Es ergäben sich bessere berufliche Perspektiven für Fans Freier Software.
  3. Es gäbe die Möglichkeit eines opt-in-Kommunikationskanals von Entwickler*innen zu Anwender*innen: Wenn man für ein Projekt Geld gespendet hat, ist man bestimmt auch bereit, an einer Umfrage teilzunehmen. -> Mehr Identifikation zwischen Nutzer*innen und Projekt.
  4. Man könnte Freie Software verschenken (z. B. Zertifikats-Abo. + T-Shirt). Das wäre auch aus Nachhaltigkeitssicht ein sinnvolles Geschenk (hoher immaterieller Anteil).

Kurze Überschlagsrechnungen zur Wirtschaftlichkeit

Bottom-Up: Ab 1000 Leuten (100 Euro täglich), die mitmachen, könnte man jeden Tag einen (kleinen) Bug fixen lassen. Ab da wäre es sinnvoll (ehrenamtlich). Ab 10K Leuten (100 Euro Betriebskosten täglich) könnte Konzept als StartUp überleben.

Top-Down: Es gibt geschätzt weltweit 1 Mrd. PCs in Betrieb. Als Proxy-Schätzwert für überzeugte FLOSS-Nutzer*innen dient der Marktanteil von Linux als Desktop-Betriebssystem. Er beträgt 1.3 % (Quelle: statista.com). Von diesen würden geschätzt 10 % ein Zertifikat für Durchschnittspreis von 10 Cent pro Tag kaufen. Das ergibt 10^9 (Anzahl der PCs) * 0.013 (Linux-Marktanteil) * 0.1 (Kaufbereitschaftsquote) * 0.1 (Euro / Tag) = 130K Euro pro Tag für Investitionen in das FLOSS-Ökosystem. Je nach Weltregion sind das zwischen 100 und 1000 Vollzeit-Stellen.

Beide Rechnungen zeigen, dass das ganze 1. nicht komplett utopisch ist und 2. theoretisch großes Potential hat.

Anmerkung: Wenn es gelänge, den App-Markt auf mobilen Endgeräten einzubeziehen, wäre der Kuchen nochmal deutlich größer (und ein kleineres Stück davon würde reichen).

Ausweitung auf dezentrale IT-Dienste

Genau wie die Entwicklung guter Freier (Desktop-)Software, verursacht auch der Betrieb von freier dezentraler IT-Infrastruktur Aufwand und Kosten. Die Situation ist strukturell ähnlich zu FLOSS-Software und die gesellschaftliche Bedeutung ist langfristig ggf. sogar größer. Bisherige Geschäftsmodelle basieren oft auf dem Verkauf von Daten. Das ist aus vielen Gründen nicht erstrebenswert. Beispiele für Bedarf an Finanzierung (digitale Infrastruktur für eine lebendige Zivilgesellschaft):

Natürlich besteht auch bei der Infrastruktur-Software teils erheblicher Entwicklungsbedarf (laut FSFW-Infrastruktur-Haufen z. B. bei Etherpad). Auch dieser ließe sich ggf. durch die FFI finanzieren.

Wie gehts weiter?

Text ist geduldig. Damit etwas passiert, braucht es meist menschliche Aktivität. Klar ist: So ein Projekt sollte man nur in Abstimmung mit der FLOSS-Community anfangen und deswegen ist der erste Schritt: Feedback einholen. Kritik (Prinzipielle Denkfehler?, Unrealistische Annahmen?, „Konkurrenzprodukt“?) und Zuspruch sind beide gleich wichtig. Die Erfahrung zeigt dabei: Kritik kommt meist von alleine :-).

Sollte es hinreichend viel positives Feedback geben, eventuell sogar Unterstützungszusagen, könnten die nächsten Schritte angegangen werden: Namen überlegen und Domains sichern, Konzept präzisieren und ins Englische übersetzen, Feedback im größeren Rahmen einholen (NGOs, Distributoren, Reddit, Mailinglisten, Jurist*innen), Infrastruktur aufsetzen, Crowdfunding-Kampagne starten, ...

Nicht desto trotz: Feedback bleibt der erste Schritt.

Zusammenfassung

Wer gute FLOSS-Software will, sollte bereit sein, dafür auch etwas zu tun bzw. zu bezahlen. Die „Funding Freedom Initiative“ ist ein Vorschlag zur kooperativen Verteilung von monetärer Anerkennung. Feedback an kontakt@fsfw-dresden.de.

Zur Verbreitung dieses Beitrags kann bei Bedarf der Tweet https://twitter.com/fsfwdresden/status/1029988144949731328 genutzt werden.

Potenziell relevante Links

Beispiele für spendenfinanzierte Infrastruktur

https://uberspace.de/prices, https://riseup.net/de/spenden, https://www.zwiebelfreunde.de/,