[linux-l] Open Source bezahlen

[Volker Grabsch]

On Wed, Jan 24, 2007 at 12:46:25AM +0100, olafBuddenhagen at gmx.net wrote:
> On Tue, Jan 23, 2007 at 05:44:31PM +0100, Thomas Schmidt wrote:
> 
> > Gibt es eine zentrale Stelle, bei der man Geld für bestimmte
> > Softwareänderungen bieten kann?
> 
> Das hört sich einfach an, ist aber organisatorisch ziemlich
> problematisch.

ACK.

[sehr gute Ausführungen]
> Was ist wenn die Änderung funktioniert, aber Upstream sie nicht
> akzeptieren will? Vielleicht hat der Programmierer gepfuscht, und sollte
> kein Geld bekommen? Oder er hat eigentlich alles richtig gemacht, nur es
> passt dem Maintainer irgendwie nicht ins Konzept; der Programmierer
> müsste also eigentlich bezahlt werden, obwohl die Nutzer im Endeffekt
> wenig davon haben?

Das ist ein weiteres Problem: Der Programmierer darf nicht "extern" sein
bzw. wenn er das ist, sollte er dennoch aktiv im Projekt mitwirken.
Sonst kann er die zahlende Kundschaft nicht sinnvoll beraten. (Was ist
möglich? Was ist vertretbarer Aufwand? Welches Problem sollte lieber
an anderer Stelle gelöst werden? etc.)

Der von dir erwähnte Akzeptanz-Faktor seitens des Projektes kommt hinzu.

Nein, der Verwaltungsaufwand klingt für mich mehr nach einer Behörde
oder Großfirma als nach einem OpenSource-Projekt.

Was ich mir eher vorstellen könnte: Freiberufliche Programmierer
arbeiten sich in diverse OpenSource-Projekte ein und bieten als
Dienstleistung, dort bestimmte Features/Module einzubauen.

Solch ein Entwickler müsste zwischen verschiedenen Kunden-Interessen
vermitteln ("wenn ihr euch einig werdet, wird's für euch alle
preiswerter"), und kommuniziert mit dem Entwickler-Team. Er sollte in
erster Linie für seine Beratung bezahlt werden, vielleicht sind Kunden-
probleme auch ohne Programmierarbeit lösbar, oder mit einem völlig
anderen viel einfacheren Feature.

Das wäre also mehr ein Support-Job für die Benutzer, der manchmal
Programmierarbeit nötig macht. So könnte ich es mir eher vorstellen.

Natürlich kann er auf seiner Rechnung gleich auch ne Spende aufschlagen
(bzw. je nach Kundenwunsch), die er gesammelt an das Projekt weiterreicht.
Bei Debian-CD-Verkäufern klappt's ja auch: Ich kaufe die CD und bezahle
X Euro mehr als Debian-Spende. Die CD-Verkäufer leiten das dann
gebündelt zum Debian-Projekt.

Auf diese Weise werden die Micro-Payment-Probleme geschickt umgangen.

> Was ist, wenn manche Leute nur Interesse haben, falls es in einem
> bestimmten Zeitrahmen fertig wird?

Bei OpenSource hast du immer die Möglichkeit, einen Fork zu starten.
Muss man dem Kunden natürlich vermitteln, dass das Feature in
zukünftigen Versionen erstmal nicht dabei sein wird. Aber wenn die
Zeit drängt, ist das wohl nebensächlich.

Dann würde die aktuelle Version hergenommen, weiterentwickelt und
der Kunde erhält "sofort" ein angepasstes Produkt. Der Entwickler
kann seinen Patch dem Projekt anbieten, der Kunde könnte das theoretisch
auch.

Ist der Kunde clever, zahlt er dem Entwickler etwas mehr, wenn er jede
neue Version entsprechend mit dem Feature ausstattet. Und zwar einen
festen Preis pro neuer Version, nicht nach Stundenlohn. Dann hätte der
Entwickler ein sehr großes Interesse, seinen Patch in das Projekt zu
bringen und dort lauffähig zu halten, statt jedes Mal neu zu patchen.

Außerdem hätte der Entwickler dann auch Interesse daran, dem Projekt
etwas zu spenden bzw. den Kunden zu ermuntern, eine Spende zu
entrichten, die er weiterreicht. Dann hat nämlich auch das Projekt
ein Interesse daran, seinen Patch mit einzupflegen, und es entstünde
nicht der Eindruck, er wolle die Arbeit, für die er bezahlt wird, dem
Projekt unterschieben.

> In der Praxis ist es wohl meistens wesentlich realistischer, einfach
> allgemein für das Projekt zu spenden, mit der Anmerkung welche
> Änderungen man am liebsten sehen will -- in der Hoffnung, dass sich die
> Programmierer etwas danach richten.

Auch ein Weg. Das mit dem Spenden-Aufschlag auf die Rechnung finde ich
dennoch eleganter. Es senkt die Hemmschwelle des Kunden, etwas zu
spenden, weil's ein Abwasch ist.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR