Finanzierung freier Software: Spekulaten gegen Trittbrettfahrer

[Thomas Leske]

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