Version 1.0, 02.05.2004, Hauke Laging, hauke@laging.de, 030/32603660, 0172/7630883
Wenn Software für mehrere Kunden im Auftrag entwickelt wird, besteht das Problem, dass mit einer bestimmten (Mindest-)Kundenzahl kalkuliert werden muss, um den Preis so festsetzen zu können, dass der zugehörige Gesamtumsatz kostendeckend wird. Typischerweise wird die Software aber nicht nur von der Mindestzahl an Kunden gekauft. Das führt dazu, dass die ersten Kunden, die akquiriert werden mussten, um das Projekt anzuschieben, zu viel bezahlt haben, weil sich die Kosten letztendlich auf mehr Kunden als ursprünglich kalkuliert verteilen. Das Hauptärgernis liegt nun darin, dass es schwieriger ist, die nötigen Kunden zu akquirieren, wenn der Preis höher ist. Bei der zugrundegelegten Mindestkundenzahl ist er per se maximal.
Es profitierten also sowohl der Anbieter als auch die Kunden davon, wenn die Kunden vor ihrer Zusage wissen, dass sie im Ergebnis – aller Wahrscheinlichkeit nach – weniger als den anfangs geforderten Betrag zahlen müssen.
Da der "Preisnachlass" wegen der ex ante unbekannten genauen endgültigen Kundenzahl nicht garantiert, sondern nur in Aussicht gestellt werden kann, bleibt zur Realisierung dieses Gedankens nur irgendeine Art von Abrechnung im nachhinein. Nun verbietet sich eine Rückzahlung schon auf Grund des immensen Verwaltungsaufwands. Andererseits ist ein allen Beteiligten gemeinsames Interesse zu erkennen, in dessen Sinne die "zu viel" gezahlten Gelder der "Kunden der ersten Generation" eingesetzt werden können: die Weiterentwicklung von Software. Dieses gemeinsame Interesse besteht in unterschiedlicher Stärke, je nach dem konkreten Umfeld. Am stärksten ausgeprägt ist es bei der Weiterentwicklung einer konkreten Software.
Ich schlage vor, den Ausgleich des "überhöhten" Preises über Aufrechnung bei Folgeaufträgen vorzunehmen:
Quasi bei jedem neuen Kunden einer Software wird für die früheren Kunden die Differenz zwischen tatsächlich gezahltem Preis und dem, der der neuen Kundenzahl entspricht, ermittelt. Der Neukunde hätte nur den reduzierten Preis zu zahlen, den Altkunden würde die Differenz auf ein Bonuskonto gebucht.
Wenn ein Kunde sich für ein Folgeprojekt interessiert, könnte er sich den aktuellen Stand seines Bonuskontos auf den neuen Preis anrechnen lassen.
Wenn für das neue Projekt genauso wie für das vorige noch die Mindestzahl an Kunden akquiriert werden muss, hat das für Anbieter wie Kunden den Vorteil, dass diese Mindestzahl schneller erreicht wird, da zumindest einige der Kunden von ihren Bonuskonten profitieren und damit – wegen des für sie effektiv niedrigeren Preises – eine höhere Bereitschaft haben, sich an dem Folgeprojekt zu beteiligen.
Wenn ein Kunde bei einem Folgeprojekt nicht Kunde der "ersten", sondern erst der "zweiten Generation" ist, hätte die Aufrechnung dennoch den gewünschten Effekt für ihn und andere: Seine Erstzahlung hat ihm nicht nur eine, sondern (teilweise) auch eine zweite Leistung beschert, und seine Gesamtzahlung, die gemessen an den Kosten des Folgeprojekts sogar komplett "überschüssig" ist, kommt den Bonuskonten der Altkunden dieses Projekts zugute, wird also komplett in die Entwicklung zusätzlicher Software investiert.
Rein praktisch würde man nicht genutzte Boni irgendwann dergestalt verfallen lassen, dass sie z.B. gleichmäßig auf die übrigen Bonuskonten verteilt würden.
Die Gewissheit, nicht zu Gunsten des Gewinns des Anbieters "zu viel" zu bezahlen, erhöht sicherlich die Zahlungsbereitschaft, insbesondere dann, wenn der "Überschusserlös" derselben oder einer verwandten Software zugute kommt, so dass der potentielle Kunde auf jeden Fall einen Zusatznutzen realisierte. Bei Geschäftskunden ist dieser psychologische Effekt sicher weniger ausgeprägt als bei Privatkunden. Allerdings funktioniert das Modell auch ohne die Begeisterung der Teilnehmer. Es hat auch niemand Grund, sich benachteiligt zu fühlen (etwa derart, dass er an weiteren Projekten kein Interesse hat), weil er keinesfalls mehr zahlt als im klassischen Finanzierungsmodell.
Die gesamte Handhabung lässt sich ohne messbaren Zusatzaufwand realisieren. Alles, was eine entsprechende Software wissen muss, um den Bonus eines Kunden aus einem konkreten Projekt zu ermitteln, sind
die Gesamtkosten des Projekts
die Anzahl der Kunden zum Zeitpunkt der Beteiligung durch den jeweiligen Kunden
ggf. die Höhe seiner Zahlung (falls uneinheitlich)
die Anzahl der Kunden im fraglichen Moment
Die Berechnung wäre dann für alle Projekte durchzuführen, an denen der Kunde beteiligt war.
Der Kunde benötigte nur noch ein Login, um sich seinen aktuellen Stand anzusehen – wenn er seine Entscheidung für ein Folgeprojekt davon abhängig machen und sich nicht nur positiv überraschen lassen will.
Das oben skizzierte Szenario setzt eine nicht freie Software voraus, weil nur bei ihr im Laufe der Zeit immer mehr Kunden anfallen. Es ist daher nicht ohne weiteres möglich, die genannten Mechanismen auf Projekte anzuwenden, die eine freie Software zum Ziel haben.
Der Effekt ließe sich näherungsweise durch unterschiedliche Maßnahmen erreichen:
Die Tatsache, dass die Mindestkundenzahl erreicht ist, müsste nicht sofort bekanntgemacht werden. Es könnte zwar sofort mit der Entwicklung begonnen werden – worüber die betroffenen Kunden notfalls auch informiert werden könnten –, aber diese Tatsache könnte erst am Ende des jeweiligen oder sogar folgenden Quartals veröffentlicht werden. Die in der Zeitspanne vom Entwicklungsbeginn bis zur Veröffentlichung hinzugekommenen Kunden bildeten die Grundlage für die Finanzierungsoptimierung.
Die Quelloffenheit könnte von der Freiheit der Software zeitlich befristet getrennt werden: Der neue Code fließt in das vorhandene Projekt ein, aber unter einer kommerziellen Lizenz: Innerhalb einer geeigneten Sperrfrist, nach deren Ablauf der neue Code frei wird, dürfen nur zahlende Kunden die neue Funktion benutzen. Die OSS-Entwickler werden sich nicht dagegen sträuben, den Code dennoch zu übernehmen, da sie wissen,
dass er zu definierter Zeit frei wird
dass "viele" Kunden ihn bereits verwenden
dass diese Maßnahme allein der Entwicklung weiterer zukünftiger OSS dient
Für die Kunden wäre das kein Problem: Sie wären gegenüber einer üblichen OSS-Lösung nicht merklich schlechtergestellt. Sie dürften die Software auf beliebig vielen Systemen installieren und ggf. den Quellcode verändern. Im Gegenteil: Sie profitieren über ihr Bonuskonto direkt von dieser Vorgehensweise.
Wofür der Kunde seinen Bonus "ausgibt", wäre unerheblich. Für die Gesamtheit der Betroffenen wäre es natürlich am besten, die Boni würden ausschließlich – so, wie oben dargestellt – für die Entwicklung neuer Software ausgegeben, aber der Kern des Modells ist natürlich die Besserstellung des einzelnen Kunden, der die Angelegenheit weitgehend egoistisch betrachtet. Es wäre also durchaus möglich und statthaft, den Bonus auch z.B. auf Dienstleistungen anzurechnen, also "Support" – in welcher Weise auch immer. Ob die Höhe des Bonus gemessen an typischen Supportkosten einen relevanten Anteil erreicht, ist sicher vom konkreten Szenario abhängig.
In diesem Sinne könnten die Boni auch als "selbstfinanzierender" Anreiz genutzt werden, um den Kunden an neue Produkte/Dienstleistungen heranzuführen, da ihn das Ausprobieren weniger kostete als normalerweise.