Warum gibt es keine Kultur, für Frameworks zu bezahlen? [geschlossen]

Einer der Nebeneffekte des jüngsten Trends von "Lean" -Starts und der App Store-Ära ist, dass sich die Verbraucher eher daran gewöhnt haben, kleine Preise für kleine Spiele / Produkte zu zahlen.

Z.B.:

• Online-SAAS, für die ~ 5 USD / Monat berechnet werden (Produktstil im Basislager)
• Spiele, die kurz, unterhaltsam und günstig sind (0,99 US-Dollar im App Store)

Dieser Markt wurde definiert durch "eine Sache gut zu machen und die Leute dafür zu belasten". DHH of Rails / 37 Signals Ruhm argumentiert, wenn Ihre Website kein Geld verdienen wird, machen Sie sich nicht die Mühe, es zu machen.

Warum gilt die gleiche Regel nicht für Frameworks?

Es gibt viele Software-Framework-Projekte - viele davon sind ausgereift und funktionsreich, bieten Entwicklern einen erheblichen Mehrwert, aber es scheint keinen Markt oder keine Kultur zu geben, für diese zu bezahlen.

Es scheint, dass die Projekte, für die Geld berechnet wird, häufig Dinge wie UI-Komponenten-Toolsets sind und häufig zugunsten kostenloser Alternativen an den Rand gedrängt werden.

Warum ist das?

Sicherlich sehen Programmierer / Unternehmen den Wert darin, einen Beitrag zu Projekten wie Ruby, Rails, Hibernate, Spring, Ant, Groovy, Gradle zu leisten (die Liste geht weiter).

Ich schlage nicht vor, dass diese Frameworks für jeden, der sie verwenden möchte, Gebühren erheben sollten, sondern dass es ein aussagekräftiges Geschäftsmodell geben muss, mit dem die Entwickler ab dem Zeitpunkt, an dem sie in die Entwicklung des Frameworks investieren, Geld verdienen können.

Irgendwelche Gedanken darüber, warum dieses Modell nicht entstanden ist / gelungen ist?

Bearbeiten Um es klar zu sagen: In diesem Beitrag geht es nicht darum, die Bedeutung von freier Open-Source-Software herunterzuspielen. In diesem Beitrag wird gefragt, warum es keine Kultur des Bezahlens von Frameworks gibt.

Es gibt absolut eine Ethik des Wert-für-Wert-Handels mit freier / Open-Source-Software.

In den meisten Wirtschaftsbereichen handeln wir mit Geld für Produkt oder Geld für Dienstleistung. Das ist sehr bequem. In der Tat tun wir dies im kommerziellen Softwareteil der Wirtschaft.

Aber wir tauschen im Allgemeinen kein Geld gegen Freundschaft oder Geld gegen Romantik. Wir tauschen Freundschaft gegen Freundschaft und Romantik gegen Romantik.

In freier / Open-Source-Software besteht die Ethik darin, DHH und die Mitwirkenden an Rails zurückzuzahlen, indem: Fehler gemeldet, Patches für Ruby, Rails, Linux und alle geschrieben, aktualisiert / repariert und evangelisiert werden der Free / Open-Source-Softwareprojekte im Allgemeinen. So handeln wir Wert für Wert.

Die Frage, warum "dieses Modell [Geld für Frameworks in Rechnung stellen] nicht entstanden / erfolgreich war", ist vergleichbar mit der Frage, warum dasselbe Modell nicht entstanden / erfolgreich war, wenn es um Freundschaften oder Romantik geht. Jemand, der Freundschaft anbietet, will kein Geld - er will Freundschaft als Gegenleistung. Ebenso Romantik. Ebenso in vielen Fällen Software.

Ich denke, diese Frage kann durch Antworten in dieser Frage beantwortet werden. Warum schreiben Programmierer Closed-Source-Anwendungen und machen sie dann kostenlos? .

Und ich würde nur hinzufügen:

Was ich glaube ist, dass wir durch die Freigabe des Frameworks Anfängern und Hobbyprogrammierern ermöglichen, Interesse an ernsthafter Programmierung zu gewinnen. Dies erleichtert ihnen den Weg. Wir haben bereits gesehen, dass Plattformen, die nicht kostenlos sind, oft weniger angenommen werden als solche. Darüber hinaus werden freie Rahmenbedingungen normalerweise von einer Gruppe von Menschen entwickelt, die einen Beitrag zur Gemeinschaft leisten möchten.

Es scheint immer auf eine von zwei verschiedenen Kulturen zurückzuführen zu sein. Es gibt die Gruppe "Ich bezahle für Software mit Geld" und die Gruppe "Ich bezahle für Software mit Zeit".

Betrachten Sie die IT in einer Organisation. Angenommen, ein Unternehmen möchte eine Netzwerküberwachung durchführen. Es ist entweder A) geschäftskritisch und es wert, Tonnen von Geld in (Openview, Netcool) zu pumpen. Oder B) Enges Budget, tun Sie, was Sie können, mit weniger (Nagios, MRTG).

Ebenso gibt es Menschen, die mit der Microsoft / Apple-Herangehensweise an Software "aufgewachsen" sind. Sie zahlen Geld und Sachen sollten funktionieren. Sie wollen neue Funktionen, Sie bezahlen dafür. Auf der anderen Seite gibt es Menschen, die sich daran gewöhnt haben, mit ihrer Zeit zu bezahlen. Unix, Open Source, Java usw. Wenn Sie mehr Funktionen wünschen, schreiben Sie diese selbst oder ermöglichen es jemandem, sie für Sie zu reparieren.

Betrachten Sie Apples App Store für Android Market. Sie kaufen Angry Birds auf dem iPhone, erhalten es aber kostenlos (mit Werbung) auf Android. Unterschiedliche Kulturen bei der Arbeit. Angry Birds ist im App Store äußerst erfolgreich und berechnet nur 0,99 Cent. Sie wussten jedoch, dass dies einen sehr geringen Marktanteil haben würde, wenn sie im Android Market sogar 0,25 Cent verlangen würden.

Ich denke, die Rahmenbedingungen haben im letzteren Lager begonnen, und so ist es vorerst. Sie können ein Framework nicht vermarkten, wie es ein Oma für ein fertiges Produkt verwenden kann. Jemand muss Zeit investieren, um es zu einem Verbrauchsmaterial zu machen. Die Leute, die es gewohnt sind, Zeit zu investieren, sind es nicht gewohnt, sowohl mit Zeit als auch mit Geld zu bezahlen.

Sicherlich sehen Programmierer / Unternehmen den Wert darin, einen Beitrag zu Projekten wie Ruby, Rails, Hibernate, Spring, Ant, Groovy, Gradle zu leisten (die Liste geht weiter).

Aufgrund meiner Erfahrung mit Kunden und Arbeitgebern habe ich mehrere Gründe festgestellt, warum Unternehmen, die Open Source-Software stark nutzen (und damit viel Geld verdienen oder sparen), nicht so viel zurückgeben, wie sie könnten:

• Kein Verständnis dafür, wie das Open Source-Modell funktioniert, und daher ein fehlendes Bewusstsein für die Notwendigkeit von Spenden, um Projekte stark zu halten

• Oft mangelt es an Klarheit, was mit einer Spende passieren wird

• Steuerfragen, Unsicherheit über die Abzugsfähigkeit

• Schwierigkeiten für Techniker, die Spenden (oder andere Mittel zur Rückgabe wie das Ausrichten von Veranstaltungen usw.) vor nicht aufgeklärtem Management / Controlling rechtfertigen ("Wenn wir nicht dafür bezahlen müssen, warum sollten wir ihnen Geld geben? Um nett zu sein." ? Wir haben nicht das Budget dafür. Vielleicht nächstes Jahr ")

Ich bin der Meinung, dass jedes dieser Probleme in einem Open-Source-Projekt bis zu einem gewissen Grad angegangen werden könnte, dies wird jedoch meistens nicht getan, da es an Fachwissen für eine klarere Kommunikation mangelt und Unternehmen nicht bereit sind, Spenden in Zukunft zu beantragen Weg.

Ich liebe den Geist der Open Source-Community "kein Geld, keine Bürokratie, keine Verpflichtungen", aber ich denke manchmal - was wäre, wenn jedes Unternehmen, das beispielsweise OpenOffice anstelle einer MS Office-Arbeitsplatzlizenz für 200 US-Dollar verwendet, nur 2 US-Dollar an OOo spenden würde, oder ein anderes Open Source Projekt?

Das größte Risiko bei der Verwendung von Open Source-Software besteht darin, dass keine offizielle Unterstützung vorhanden ist. Grundsätzlich besitzen Sie den Code. Während es auf den ersten Blick rentabler erscheint, "freie" Software zu verwenden, müssen Sie die Möglichkeit berücksichtigen, dass die internen Wartungskosten letztendlich die Kosten einer proprietären Lösung abwägen können. Einige Organisationen sind nicht bereit, dieses Risiko einzugehen.

Ein Teil der Frage scheint Frameworks mit dem Bezahlen von Anwendungen zu vergleichen (z. B. lustige Spiele, 37 Signalprodukte, Online-SAAS), aber das sind Äpfel und Orangen. Verbraucher kaufen Anwendungen, während Entwickler Frameworks verwenden, um Anwendungen für Verbraucher zu erstellen. Und sicher, Ihr Entwickler kann ein Verbraucher sein, wenn er ein Benutzer ist und Anwendungen kauft, wenn diese nicht auf Frameworks entwickelt werden.

Frameworks machen nichts sofort, bis sie in Anwendungen umgewandelt werden, die verkauft werden können.

Wenn wir jedoch nur Entwicklertools wie Frameworks mit Komponentensätzen und RAD-Suiten usw. vergleichen, gibt es meiner Meinung nach einige gute Diskussionen darüber, wofür bezahlt wird und welche nicht.

Stellen wir uns vor, ich erstelle ein Framework namens "AwesomeWork" (Original, oder?). Jetzt haben die Leute es noch nie benutzt und sind sich nicht sicher, ob es ihnen helfen wird und wollen kein Geld für etwas bezahlen, das ihnen vielleicht kein bisschen nützt (wenn sie es überhaupt mögen!), Also veröffentliche ich es kostenlos. Bin ich jetzt ein Dummkopf, weil ich potenzielle Gewinne verloren habe, weil ich es vielleicht geschafft habe, sie für 5 USD pro Lizenz zu verkaufen? Nein, denn als ich das Wort erhalte und die Leute anfangen, mein Framework zu nutzen, hat sich ein Sekundärmarkt geöffnet: Bücher. Ich kann jetzt ein Buch über AwesomeWork schreiben (nennen wir es "Do [Awesome] Work Son!", Tut mir leid, dass ich das durchmachen musste). Der Verkauf des Buches geht also stetig voran. Jetzt entscheide ich mich, einige Updates für AwesomeWork vorzunehmen und es unter AwesomeWork 2.0 zu veröffentlichen. Und siehe da, ich kann "Do [Awesome] Work Son!" Verkaufen.

Ich sage nicht, dass das obige Szenario der Hauptgrund dafür ist, dass jemand sein Framework kostenlos veröffentlicht, aber es zeigt, dass er damit immer noch Geld verdienen kann.

Randnotiz: Es gibt einige Frameworks, die kostenpflichtig sind (obwohl sie möglicherweise eine kostenlose Community Edition anbieten, jedoch mit eingeschränkten Funktionen). Das, was mir in den Sinn kommt, ist WebSharper , mit dem Websites vollständig in F # geschrieben werden können.