Spenden und Open Source

[Sven Rautenberg]

Moin!

irgendwie verstehe ich Wolfgang, dass er die Arbeit finanziert haben will.
Sobald er das Programm unter der GPL veröffentlicht hat, kann er damit fast kein Geld mehr verdienen.
Einer besorgt sich das Programm und veröffentlicht es auf einer anderen Seite.
Und das darf er auch noch.

Noch viel schlimmer: Wolfgang veröffentlicht das Programm selbst auf seiner eigenen Seite - kein Re-Publishing notwendig.

Falls das Programm wirklich so gut sein soll, wie Wolfgang glaubt könnte er es ja auch Verkaufen (kommerzielle Lizenz).

Das ist mit einem gewissen Extra-Aufwand verbunden, den man vielleicht vermeiden möchte.

Die Idee, dass er einen bestimmten Spendenbetrag haben möchte, bevor er das Programm veröffentlicht ist etwas komisch. Ich glaube mit dieser Möglichkeit wird sicher niemand Spenden. Ich würde nur für Software spenden, die ich auch testen konnte.

Sagen wir's mal so: Niemandem ist damit geholfen, eine Software einfach mit dem "Open Source"-Aufkleber zu bekleben. Das macht die Software nicht attraktiver, nicht besser, nicht beliebter, es zieht keine automatische Community an - absolut nichts passiert automatisch, nur weil irgendwas "Open Source" ist.

Persönlich bevorzuge ich Software, deren Lizenz mir die kostenfreie Nutzung einräumt. Klingt ja auch irgendwie logisch, das spart eine Menge Geld. Ob die Software nun quelloffen ist, oder nicht, ist allerdings nicht mein erstes Kriterium, denn mein initiales Interesse ist, eine funktionierende Software zu installieren - nicht in deren Quellcode herumzuwerkeln, um Bugs zu fixen. Das dürfte auch für den überwiegenden Rest der (potentiellen) Benutzer zutreffen.

Ich habe allerdings schon einige Programme nach der Installation "gekauft", zuletzt das Quicktext-Plugin für Thunderbird. Warum genau? Weil ich mit dem Plugin in seiner kostenlosen Version schon extrem zufrieden war, aber einfach den zusätzlichen Scripting-Support brauchte, und der Preis von 9 Euro problemlos und ohne weitere Zusatzkosten per Europaüberweisung bezahlbar war.

Ich denke, daraus läßt sich ein generelles Muster für Programmanbieter ableiten:

1. Löse ein Problem, für das es bislang noch keine oder keine ausreichende Lösung gibt (es reicht aus, wenn diese Sichtweise auf deine Zielgruppe zutrifft).
2. Löse das Problem möglichst perfekt. Bugs sind ein Showkiller.
3. Mache das Bezahlen einfach.

Daraus folgt aber, dass ein Projekt, das erst noch im Entstehen begriffen ist, und keinerlei ausführbaren Code liefern kann, auch keinerlei Einkommen generieren wird.

Es ist sogar so, dass die meisten Projekte, die von niemandem gebraucht werden, die nur unzureichende Lösungen anbieten, oder die ein Allerweltsproblem zum 1325.sten Mal lösen (Texteditoren!!!), niemals nennenswertes Einkommen generieren werden.

Als Nebenbemerkung und Beispiel zu "Zielgruppe": GIMP wird oft und leider irrtümlich als Open-Source-Ersatz für Adobe Photoshop angeführt. Das ist falsch. Richtig ist, dass beide Programme Bildbearbeitung machen. Vermutlich richtig ist auch, dass beide Programme ähnliche Leistungen bzw. Ergebnisse erbringen können. Aber GIMP hat nicht (oder sollte es zumindest nicht) zum Ziel, ein Ersatz für Photoshop zu sein. GIMP hat das Ziel, den GIMP-Usern ihre Ansprüche an GIMP-artige Bildbearbeitung zu erfüllen - und das unterscheidet sich zwangsläufig von der Art, wie Photoshop-User ihre Ansprüche stellen und erfüllt kriegen. Es wäre vermutlich fatal (gewesen) und der Open-Source-Entwicklergemeinde um GIMP abträglich, würde man den Versuch unternehmen, in GIMP alles so zu lösen, wie es Photoshop tut. Es gibt schon eine Software, die die Ansprüche von Photoshop-Usern perfekt erfüllt, und die heißt "Photoshop". Warum etwas duplizieren, was es schon gibt? Kein freiwilliger Programmierer, der bei Sinnen ist, wird ein Programm mit eigenen "Worten" nochmal exakt kopieren, nur weil ihm der Preis nicht gefällt. Er wird immer auch Änderungen, Verbesserungen einbringen, die ihm am Original nicht gefallen. Er wird erstmal genau die 80% der Funktionen weglassen, die er sowieso nicht benutzt (die berühmte 80/20-Regel, 80% der User nutzen nur 20% der Funktionen - dummerweise jeder ein anderes 20%-Stück, aber wenn man erstmal der einzige User der eigenen Software ist, weiß man ja genau, welche 20% man braucht).

Es kommt also darauf an, dass man sich eine Zielgruppe definiert, die durchaus scharf umrissen sein sollte, und die nicht einfach 50% der Weltbevölkerung abdeckt.

Auch die Erfahrung, die wir (ich spreche da in meiner Funktion als Vereinsvorsitzender) mit SELFHTML gemacht haben, zeigt in diese Richtung: Zuallererst war die freiwillige und öffentlich verfügbare Leistung von Stefan Münz da. Dann hat sich eine interessierte und wohlwollende Community gebildet, die ihren Nutzen aus dieser Leistung gezogen hat. Die Veröffentlichung der Dokumentation als Buch war der einzige, aber funktionierende Versuch einer kommerziellen Nutzung der geschaffenen Leistung. Als es darum ging, den Fortbestand des Projektes durch neue Serverhardware zu sichern, wurde der Spendenaufruf mit einem überwältigenden Echo beantwortet (und schon zuvor wurde der Rechtsstreit gegen Günni in ähnlicher Weise beantwortet).

Das alles wurde aber nur dadurch überhaupt möglich, weil zuvor in selbstloser Weise eine qualitativ hochwertige Arbeit frei verfügbar gemacht wurde, die durch sich selbst eine Vielzahl von Menschen überzeugt hat.

Ich denke daher, die korrekte Reihenfolge bei solchen Vorhaben lautet: Erst geben, dann nehmen.

Und weil das Nehmen nur erfolgen kann, wenn das Projekt die Öffentlichkeits-Qualitätskontrolle erfolgreich passiert hat, dies aber für die Mehrzahl von Projekten aus den dargelegten Überlegungen nie der Fall sein wird, ergibt es wenig Sinn, solche Projekte zu beginnen, die nur des eventuellen späteren Erfolgs willen gestartet werden.

Sehr sinnvoll hingegen sind Projekte, die persönliche Problemlösungen darstellen und/oder aus Spaß und Interesse an der Thematik entstehen. Diese Sichtweise und Einstellung kann man übrigens auch gut dem von Edgar verlinkten "Die Kathedrale und der Basar" entnehmen.

- Sven Rautenberg