Im Prinzip kann sich eine Gruppe Freiwilliger zusammenschließen, um die Weiterentwicklung einer freien Software zu finanzieren. Tatsächlich hat aber jeder einzelne einen Vorteil, wenn er zum Trittbrettfahrer wird: Sich also nicht an der Finanzierung beteiligt und hofft, dass die Software ohne ihn fortentwickelt wird.
Dieses Problem tritt beim Wetten nicht auf: Jemand, dem in einer vorhandenen freien Software ein Leistungsmerkmal fehlt, oder der unter einem Fehler leidet, würde sich vielleicht gerne dagegen versichern, dass der Mangel nicht bis zu einem bestimmten Zeitpunkt behoben ist. (Stallmans Gesetz besagt ihm Grunde, dass der Fortschritt monopolisiert wird. Warum also keine Versicherung gegen ausbleibenden freien Fortschritt?)
Ein Wetteinsatz auf Nicht-Implementierung ist praktisch eine Versicherung. Wenn die Summe dieser Wetteinsätze hoch genug ist, kann die Entwicklung davon finanziert werden und ein Gewinn an die Wettgegner ausgeschüttet werden. Beim Wetten über einen Totalisator ergeben sich die Quoten erst im Nachhinein aus Verhältnis von Angebot und Nachfrage.
Details: http://freie-software.minimalstaat.de/Wetten_auf_freie_Software.txt
Gruß Thomas
P.S.: Aus aktuellem Anlass: Man kann mit dem nötigen Kleingeld auch gegen einen börsennotierten Anbieter von Software as a Service (oder proprietärer Software) spekulieren, indem man im großen Stil Verkaufsoptionen aufkauft und dann eine freie Software finanziert, die diesem Anbieter das Wasser abgräbt.
On Tuesday 15 May 2012 17.39:34 Thomas Leske wrote:
http://freie-software.minimalstaat.de/Wetten_auf_freie_Software.txt
Ich finde das sehr interessant.
Was mir noch nicht klar ist: Wer finanziert den Wettanbieter? Denn die Analyse des Problems um seine Kosten abzuschätzen ist oft ein erheblicher Teil der Arbeit und erfordert sehr tiefes Spezialwissen zur Aufgabe.
Dieses ist aber oft nur bei denen vorhanden die das Problem lösen könnten, wobei der Wettanbieter natürlich nicht selber teilnehmen kann.
Und was passiert, wenn bei der Lösung des Problems andere Probleme offensichtlich werden, die Lösung dann also nicht akzeptiert wird und somit nicht wirklich in die Freie Software Lösung einfliesst?
Was wenn der Lösende zwar das Problem löst, aber die Qualität nicht bietet?
Gerade bei Technologie gibt es auch "technologische Schulden" die eingegangen werden können, um ein bestimmtes Problem billiger zu lösen.
Hier wird also bewusst ein schlechterer Lösungsweg gewählt, um das Problem schneller oder günstiger zu erledigen - aber zum Preis, dass hinterher Erweiterungen teurer oder Nachbesserungen notwendig werden.
Man kann diese Schulden eben nur bis zu einem gewissen Punkt eingehen.
Ist nicht letztlich der finanzielle Anreiz darauf ausgerichtet, ebendiese Schulden zu maximieren an den Punkt wo es gerade eben nicht auseinander bricht? Dann ist es wie ein Mikado-Gebäude, wo jeder hofft, dass es bei ihm gerade noch nicht zerbröselt.
Ob das aber die Anwendung ist, die die Nutzer wollen...
Hast Du Dir dazu schon was überlegt?
Beste Grüsse, Georg
Am 15.05.2012 20:15, schrieb Georg C. F. Greve:
Was mir noch nicht klar ist: Wer finanziert den Wettanbieter? Denn die Analyse des Problems um seine Kosten abzuschätzen ist oft ein erheblicher Teil der Arbeit und erfordert sehr tiefes Spezialwissen zur Aufgabe.
Der Wettanbieter schätzt die Kosten nicht ab, sondern schreibt das Projekt am Ende aus, um das niedrigste Angebot einzuholen.
Der relevante Absatz aus meinem Vorschlag (http://freie-software.minimalstaat.de/Wetten_auf_freie_Software.txt) ist:
"Der Wettleiter finanziert die Formulierung der Wette (= die Softwarespezifikation und eventuell Testfälle), indem er einen gewissen Prozentsatz aus dem Gewinnpool entnimmt. Die Endabnahme durch durch einen neutralen Dritten, ist Teil der Ausschreibung."
Der Wettanbieter muss aber grob abschätzen, wie für wahrscheinlich die Softwarefirmen es halten, dass sie an dem Projekt scheitern: Die Wetteinsätze auf Implementierung entsprechen einer Konventionalstrafe, die eine scheiternde Firma zu zahlen hätte. Dies werden die Softwarefirmen bei ihrem Angebot einkalkulieren.
Der Wettanbieter sorgt dafür, dass die Zusatzkosten, die mit einem Wetteinsatz auf Implementierung einhergehen, nicht andere belasten, die auch auf Implementierung setzen:
"Weil ein höheres Wettrisiko die Angebote verteuert, muss es schon beim Wetten berücksichtigt werden. Der Wettleiter schätzt dazu ab, wie komplex das Problem ist. Wenn er meint, die späteren Bieter werden einkalkulieren, dass sie mit einer Wahrscheinlichkeit von 5% scheitern, dann wird er vorschreiben, dass ein Wetteinsatz auf Implementierung in Höhe von 95€ mit einem Einsatz von 5€ auf den umgekehrten Ausgang einhergehen muss."
Dieses ist aber oft nur bei denen vorhanden die das Problem lösen könnten, wobei der Wettanbieter natürlich nicht selber teilnehmen kann.
Wenn die Wetteinsätze über einen Treuhänder laufen, hat auch der Wettanbieter keinen Informationsvorsprung und kann selber mitwetten.
Die Ausschreibungsangebote könnte man ebenfalls kryptographisch verschleiern und am Schluss aufdecken, so dass der Wettanbieter auch selbst ein Angebot abgeben kann.
Theoretisch kann der Wettanbieter die Ausschreibung auf seine Firma zuschneiden. Aber dann wird er weniger Wettumsatz machen, weil man der Ausschreibung ansieht, dass sie technische Vorgaben macht, auf welche die wenigsten Nutzer später wert legen. Auch wenn der neutrale Dritte, der die Endabnahme macht, gar nicht als neutral anerkannt ist, wird der Wettumsatz klein bleiben. Weil der Wettanbieter aber am Wettumsatz verdient, würde er sich damit selber schaden.
Und was passiert, wenn bei der Lösung des Problems andere Probleme offensichtlich werden, die Lösung dann also nicht akzeptiert wird und somit nicht wirklich in die Freie Software Lösung einfliesst?
Was wenn der Lösende zwar das Problem löst, aber die Qualität nicht bietet?
Man könnte in der Ausschreibung festlegen, dass die Softwarefirma einen bestimmten Prozessreifegrad (z. B. im Capability-Maturity-Model) erreicht haben muss.
Gerade bei Technologie gibt es auch "technologische Schulden" die eingegangen werden können, um ein bestimmtes Problem billiger zu lösen.
Hier wird also bewusst ein schlechterer Lösungsweg gewählt, um das Problem schneller oder günstiger zu erledigen - aber zum Preis, dass hinterher Erweiterungen teurer oder Nachbesserungen notwendig werden.
Man kann diese Schulden eben nur bis zu einem gewissen Punkt eingehen.
Ich bin mir nicht sicher, ob es "technologische Schulden" unabhängig davon gibt, in welche Richtung man die Software später weiterentwickeln will. Im Nachhinein hätte man sicher vieles anders gelöst.
Allgemein erwünschte Eigenschaften kann man in Codier- und Dokumentationsrichtlinien festlegen. Z. B. Man kann Vor- und Nachbedingungen von Funktionen beschreiben und ggf. auch über Assertions testen.
Ist nicht letztlich der finanzielle Anreiz darauf ausgerichtet, ebendiese Schulden zu maximieren an den Punkt wo es gerade eben nicht auseinander bricht? Dann ist es wie ein Mikado-Gebäude, wo jeder hofft, dass es bei ihm gerade noch nicht zerbröselt.
Ob das aber die Anwendung ist, die die Nutzer wollen...
Hast Du Dir dazu schon was überlegt?
Das Problem ist schwierig, weil man nicht so einfach sagen kann, wer schuld ist, wenn es zu einem Fork kommt.
Man müsste in der Ausschreibung festschreiben, dass kontinuierliche Integration betreiben werden muss: Alle unumstrittenen Patches müssen übernommen werden, die also Verbesserungen ohne ersichtliche Nachteile bringen.
Auf diese Weise könnte ein Nutzer, der z. B. später ein anderes Datenbankverwaltungssystem anbinden will als das Ausgeschriebene, eine zusätzliche Abstraktionsschicht einbauen. (Aber der Code für das andere Datenbankverwaltungsystem bliebe trotzdem in einem getrennten Entwicklungszweig, so dass keine Bugs eingeschleppt werden.) Die alten Hasen im Projekt können frühzeitig Refactoring betreiben, falls sie Änderungen aus dem Projekt in den Hauptentwicklungszweig übernehmen wollen.
Die Softwarefirma hat auch einen Vorteil davon, wenn ihre Entwicklung im Hauptentwicklungszweig stattfindet, weil ihr Code dann eher beachtet und getestet wird. Und als Faustregel gilt: Je früher ein Fehler entdeckt wird, um so billiger lässt er sich beheben. Am besten sie stellt den Entwurf bereits vor dem Codieren zur Diskussion, damit dieser auf Zuwachs angelegt ist, und die spätere Kodierung weniger durch fremde Änderungen gestört wird.
Viele Grüße Thomas