Wie konkurrieren Sie effektiv mit einem Open Source-Projekt?

Ein Unternehmen mit einem soliden Open-Source-Projekt, das mit einem traditionellen Closed-Source-Produkt konkurriert, scheint unschlagbar.

Ich habe diesen Artikel gelesen, in dem der Autor dieses Szenario darstellt:

Angenommen, man könnte einen Softwaremarkt - etwa das Netzwerkmanagement - auf zwei Produkte aufteilen. Einer tat alles Mögliche und kostete eine Million Dollar, der andere tat nur 10 Prozent, war aber frei und offen.

Der Preis der kommerziellen Lösung würde automatisch eine große Anzahl von Benutzern herausfiltern, und diese Personen müssten sich an Open Source wenden. Einige Benutzer wären jedoch mit der 10% -Funktionalität zufrieden und würden sie direkt auswählen.

Ich habe zum Beispiel einen Original-Macintosh-Computer auf meinem Schreibtisch. Es wird ein Textverarbeitungsprogramm namens MacWrite ausgeführt. Mit Ausnahme der Rechtschreibprüfung wird alles ausgeführt, wofür ich ein Textverarbeitungsprogramm benötige. Ich kann Absätze formatieren, Schriftarten auswählen, Text fett oder kursiv formatieren und sogar Bilder und Grafiken einfügen. Alles in einer "was Sie sehen, ist was Sie bekommen" -Benutzeroberfläche.

Es nimmt 76 KB Speicherplatz in Anspruch. Das ist "K" wie in "Kilobyte".

Vergleichen Sie das mit Microsoft Word. Ich denke, das letzte Mal, als ich nur Word installiert habe, waren es ungefähr 30 MB, vielfach größer als MacWrite, aber ich verwende es nicht viel häufiger als MacWrite. Wie ich sind viele Benutzer mit der Grundfunktionalität zufrieden. Sie brauchen nicht alle Schnickschnack.

Aber zurück zu meiner Analogie. Am Anfang würde das kommerzielle Unternehmen das Open-Source-Projekt wahrscheinlich ignorieren. Es stellt keine Bedrohung für ihre Einnahmequelle dar. Warum sollten sie also auf einen Emporkömmling achten?

Wenn dieses Projekt jedoch gesund und nachhaltig ist, macht es in etwa einem Jahr 15% -20% der Leistung des kommerziellen Produkts aus. Dies sollte ein paar weitere Benutzer aus ihrem Unternehmen entlassen, und vielleicht fangen sie jetzt an, aufmerksam zu sein.

Höchstwahrscheinlich würde diese Aufmerksamkeit in Form von Marketing gegen das Projekt erfolgen. Sie würden behaupten, es sei zu klein oder zu schwach, um es ernst zu nehmen. Und auf kurze Sicht würde dies wahrscheinlich funktionieren. Aber die bloße Tatsache, dass sie das Projekt anerkannten, würde Interesse erregen. Einige Leute würden für sich selbst feststellen, dass es weder zu klein noch zu schwach ist und würden anfangen, es zu benutzen.

Ein oder zwei Jahre später macht das Projekt bis zu 50% der Funktionalität des kommerziellen Produkts aus. Die Leute schließen sich dem Projekt in Scharen an. Das Handelsunternehmen muss jetzt etwas unternehmen. Was machen Sie? Sie fügen weitere Funktionen hinzu.

Denken Sie daran, das kommerzielle Produkt hat bereits 100% dessen getan, was die Leute brauchten. Welche Art von Funktionen könnten sie hinzufügen? Unnötige. Sie können das Erscheinungsbild der Benutzeroberfläche ändern oder Funktionen außerhalb der Netzwerkverwaltung hinzufügen. In jedem Fall wird diese Entwicklung Geld kosten und die Margen des Unternehmens belasten.

Mit einer gesunden Community und diesem Zustrom neuer Benutzer wird das Open-Source-Projekt schließlich 80% -90% dessen erreichen, was das kommerzielle Produkt leistet. Nachdem alle Einnahmequellen erschöpft sind, hat das Handelsunternehmen noch eine letzte Option: die Schrauben an die verbleibenden Kunden zu bringen. Finden Sie Wege, um mehr Geld für sie zu verlangen, um herauszufinden, was sie aus ihrer Investition herausholen können, was letztendlich ihre Kunden vertreibt.

Weit hergeholt? Ich glaube nicht. Es gibt nur zwei Hauptanforderungen:

Suchen Sie zunächst einen Markt, in dem Open Source eine überzeugende Alternative bietet, wie z. B. das Netzwerkmanagement.

Zweitens: Bauen Sie eine nachhaltige Community rund um das Open Source-Projekt auf.

Es scheint sehr plausibel. Wenn Sie das Closed-Source-Unternehmen wären, wie würden Sie konkurrieren?

Da Sie nicht mit dem Preis konkurrieren können, konkurrieren Sie mit allen anderen Verkaufsargumenten der Software:

• Eigenschaften
• Qualität
• Wirksamkeit
• Integration mit anderer Software
• Bedienung
• Unterstützung
• Direktverkauf

Grundsätzlich tun Sie, was jedes andere Unternehmen im Preiswettbewerb tut: Schritt halten oder das Spiel ändern.

Indem Sie Ihr Produkt besser machen als das Open-Source-Angebot. So kann Photoshop mit GIMP mithalten.

Ich denke, das Stück, das Sie erwähnen, ist sehr irreführend, da es die Qualität des Open-Source-Angebots völlig missachtet. Stellen Sie sich eine etwas andere, aber verwandte Frage:

Wie kann ein Unternehmen überleben, wenn es Open-Source-Software verkauft?

Da ich häufig selbst an einigen Open-Source-Projekten mitarbeite, fühle ich mich berechtigt, ein paar Schlammrunden dort hinzuschleudern, wo es das verdient.

Nichts von dem, was folgt, gilt für Star-OSS-Projekte wie Linux, Firefox, MySQL oder PostgreSQL. Diese sind untypisch, da sie von Firmen und / oder erfahrenen Programmierern unterstützt werden.

Wie auch immer, aus welchen Gründen der Kunde für Software bezahlt:

OSS ist anfällig für Kriechen / Kunden zahlen für einfachere Software

OSS-Mitwirkende haben alle ihre Haustierfunktion. Diese werden irgendwann ihren Weg in die Codebasis finden. Es bedarf einer äußerst erfahrenen, festen und charismatischen Führung, um das Problem zu vermeiden, und wie bei jedem anderen Typ fehlt vielen OSS-Kernentwicklern mindestens eines dieser Merkmale.

Wenn Sie die Verletzung zusätzlich beleidigen, wird dies für jedes nicht wesentliche Merkmal, das sich einschleicht, von einem anderen nicht gewünscht, und dies führt dazu, dass Optionen hinzugefügt werden. Codierer neigen dazu, Optionen zu lieben, aber vom Standpunkt der Benutzeroberfläche aus sind sie ein sicherer Weg zu einem langsamen und schmerzhaften Tod durch tausend Schnitte.

Endbenutzer möchten einfache Tools. Sie müssen ihre Arbeit ohne Lernschwierigkeiten und Aufhebens erledigen. Sie möchten, dass ihre Werkzeuge die richtigen Entscheidungen für sie treffen. keine Optionen. Wenn Sie etwas liefern können, das einfacher als die eigenständige OSS-Implementierung ist, erhalten Sie zahlende Kunden.

OSS ist in der Regel von geringer Qualität / Kunden zahlen für höhere Qualität

Es ist an sich nichts Falsches daran, das Codieren zu lernen, indem man zu OSS beiträgt.

Es muss jedoch gesagt werden, dass für jedes hochwertige OSS oder jede Bibliothek, die aus den unterschiedlichsten Gründen von Unternehmen und erfahrenen Programmierern unterstützt wird, ein Ozean von fehleranfälligen Spaghetti-Codes vorhanden ist, die von unerfahrenen Programmierern geschrieben wurden, die OSS in ihren Bemühungen einbringen zu lernen , Programmierung, und die über wenig oder gar keine Vorstellung davon , was sie tun.

Beispielsweise wurde WordPress von einem Studenten aus B2 (selbst entworfen von einem Studenten) herausgegeben. Mehrere Versionen und unzählige Klebebänder später erledigen Sie Ihre Arbeit. Aber unter der Haube ist es eine Flut von Fehlern mit wenig oder gar keiner Qualitätskontrolle. (Zuletzt habe ich es versucht, es hat seine eigene Testsuite nicht erfolgreich bestanden.)

Kunden zahlen für gut gewartete und getestete Software. Sie werden fast alle das kostenlose Zeug ausprobieren, wohlgemerkt, und viele werden sogar Bugs bis zu einem gewissen Punkt tolerieren. Aber wenn ihre Einnahmen davon abhängen, werden sie sich irgendwann nach qualitativ hochwertiger Software umsehen und dafür bezahlen.

OSS hat in der Regel einen zu kurzen Entwicklungszyklus / Kunden zahlen, um Ärger zu vermeiden

Dies ist dem Entwicklungsprozess inhärent. Pet-Features, die in die Codebasis aufgenommen werden, müssen in einem angemessenen Zeitraum freigegeben werden. Andernfalls besteht das Risiko, dass das OSS-Projekt einige seiner Mitwirkenden verliert.

Langfristig bevorzugen Unternehmen jedoch lange Veröffentlichungszyklen. je länger, desto besser. Es ist weniger Planung und weniger Arbeit für die IT-Abteilung. Es ist keine große Sache, wenn Endbenutzer ihren Browser etwa alle drei Monate aktualisieren. Ganz anders sieht es aus, wenn Sie geschäftskritische Anwendungen aktualisieren.

In der PostgreSQL-Hackerliste wurde kürzlich die Beschleunigung des Veröffentlichungszyklus erörtert. Das abschließende Argument dagegen betraf nicht die Qualitätssicherung und die Notwendigkeit längerer Beta-Testperioden. Einige Unternehmen haben bereits jede andere Veröffentlichung übersprungen, da der aktuelle (einjährige) Veröffentlichungszyklus für sie bereits zu schnell war.

Im Gegensatz zu WordPress, das trotz eines ohnehin zu kurzen Zyklus immer wieder über einen 3-monatigen Release-Zyklus debattiert. (Ihre Betas sind in jeder Hinsicht die xy0-Version jeder Veröffentlichung.)

Mit ein paar Kunden, die WordPress verwenden, kann ich Ihnen versichern, dass sie mehr als glücklich sind, dass ich mich um sie kümmere, um sicherzustellen, dass ihre Websites beim Upgrade nicht in die Luft jagen. Kunden zahlen dafür, dass sie sich keine Sorgen um diese Art von Ärger machen müssen.

OSS neigt dazu, offene Standards sinnlos zu akzeptieren / Kunden brauchen nur Dinge, die funktionieren

Das HTML5-Video-Tag ist hier ein typisches Beispiel.

Mozillas Argument für die Ablehnung von h.264 ist, dass sie einen Open-Source-Codec wollen. Und in diesem Sinne sind sie absolut richtig: Das Letzte, was sie wollen, ist, auf der Hitliste der Patenttrolle zu stehen. Also drängen sie auf Ogg.

Im Gegensatz dazu ist Apples Argument für die Einführung von h.264 praktisch: Es wird bereits weitgehend unterstützt und es wird eine Hardwarebeschleunigung durchgeführt (wodurch die Akkulaufzeit von iPhones verlängert werden kann). Für Ogg gibt es so etwas nicht.

Millionen von iOS-Geräten, die später verkauft wurden, und Websites, die sich Sorgen um die Bereitstellung von Videos für diese iOS-Benutzer machen, unterstützen html5 / h.264. Anders ausgedrückt, Kunden haben gesprochen: Sie interessieren sich nicht für offene Formate.

Das einzige Unternehmen, das mit dem Ergebnis dieses giftigen Kampfes um Codecs zufrieden ist, ist Adobe: Firefox-Benutzer benötigen de facto weiterhin Flash, wenn sie Videos abspielen möchten. Wenn eine größere Site auf Nur-HTML5- / H.264-Videos umschaltet, wird ein Codierer schnell eine Erweiterung oder ein Plug-in finden, um die benötigten Video-Tags in Flash-Video-Player zu konvertieren. (Es könnte sogar schon existieren.) Im Namen der Unterstützung offener Standards (was übrigens kein Flash ist).

Niemand wurde jemals entlassen, weil er sich für IBM entschieden hatte

Es ist ein alter Branchenwitz, aber es gibt eine Wahrheit: Wenn Sie über ein IT-Budget verfügen, werden Sie nicht entlassen, wenn Sie entscheiden, welche Kollegen als die Besten der Rasse gelten.

Große Unternehmen, die kein Risiko eingehen möchten, kaufen weiterhin Microsoft-basierte Desktops, Office, SAP und andere Produkte. auch wenn es Open Source Alternativen gibt. Ähnlich wie Scheiße passiert .

Wenn OSS in große Unternehmensumgebungen vordringt, liegt dies normalerweise nicht daran, dass der CTO das Licht der Welt erblickte und sich für kostenlose Tools entschied. Vielmehr wird es von einem Dritten kanalisiert, der (teure) Dienste an der Spitze anbietet.

Ich denke, der Kern des Arguments, dass "das kommerzielle Produkt bereits 100% dessen getan hat, was die Menschen brauchten", ist, wo das Argument auseinanderfällt. Kein Produkt kann von sich behaupten, 100% dessen zu tun, was Menschen benötigen, und dies auf absolut effiziente (in Bezug auf die Bedienereffizienz), benutzerfreundliche und allgemein anerkannte "beste" Weise.

Wenn so etwas möglich wäre, wäre natürlich nur noch der Preis zu konkurrieren. Aber da eine objektive "beste" und eine universelle "effizienteste" Anwendung unmöglich ist, wird es immer mehr als nur einen Preis geben, auf dem man konkurrieren kann.

Es gibt einige gute Punkte in diesem Artikel, aber andererseits scheint die reale Welt viele Beispiele zu geben, bei denen es nahestehenden Unternehmen gut geht. Hier sind nur ein paar

1. Linux gegen Windows
2. PHP gegen ASP.NET
3. [irgendetwas] vs. Visual Studio
4. GIMP vs. Photoshop (es wurde vor mir beantwortet, aber ich brauchte wirklich kein MS-Beispiel :))
5. vBulletin im Vergleich zu mehr als 30 anderen Bulletin-Board-Paketen

Das Problem mit Open Source ist, dass es offen ist. Wenn Sie diesen Code haben, erhalten Sie Produkt A. Alle Ihre Mitbewerber haben denselben Code. Sie verbringen also die ganze Zeit damit, Software zu schreiben, und ein Teil davon könnte von anderen Mitwirkenden erstellt werden. Wenn Sie jedoch ein Unternehmen leiten, verbrauchen Sie Ressourcen, und dennoch kann jeder mitmachen und genau so verkaufen, wie Sie es jahrelang getan haben Entwicklung. Die größte Bedrohung für ein Open-Source-Unternehmen ist also möglicherweise nicht ein quellnahes Unternehmen, sondern die anderen 5 Open-Source-Unternehmen.

Auf der anderen Seite, wenn ich Closed-Source-Software entwickle, können Sie meine Ideen kopieren, aber ich könnte Ihnen bei der Entwicklung von Software noch Jahre voraus sein, und wenn Sie in den Markt eintreten, könnte ich bereits 90% davon besitzen.

Schließlich erzielen Unternehmen, die Code nicht gemeinsam nutzen, sondern für ihre Software eine Gebühr erheben, im Allgemeinen mehr Einnahmen als Open-Source-Projekte. Sobald diese Einnahmen generiert sind, wird ein Teil davon nicht mehr in das Engineering investiert (von dem Sie behaupten könnten, dass es kostenlos ist, wenn Sie viele Open-Source-Mitarbeiter haben), sondern in das Marketing und die Werbung für das Produkt, und jetzt sprechen Sie für Millionen von Dollar Was gibt es nicht so etwas wie freie Arbeit.

Letztendlich ist dies die Formel für Ihren Erfolg: [technische Innovation] x [Marketing] = Gewinn. Sie können das beste Produkt haben, aber wenn niemand davon weiß, verwendet niemand es. Und klar, wenn Sie etwas beschissenes bauen, wird keine Menge Werbung es retten. Ich glaube, viele Open-Source-Projekte hatten schon immer Probleme mit [Marketing], wenn es darum ging, allgemeine Verbrauchermärkte zu durchdringen.

Ein Bereich, in dem die meisten Open Source-Programme nicht mit proprietärer Software konkurrieren können, ist die Lernkurve.

In der Vergangenheit fiel es mir schwer, alle bis auf einige der beliebtesten Open-Source-Software in mein Toolset zu integrieren. Sie sind normalerweise großartig, wenn ich sie herausfinde, aber ich empfinde diese anfängliche Frustration normalerweise nicht bei proprietärer Software.

Ich bin mir nicht sicher, warum das so ist. Ich kann jedoch sagen, dass ich mehr als bereit bin, für Software zu bezahlen, die meine Arbeit mit minimalem Aufwand erledigt. Das ist schließlich der Zweck von Software .

Machen Sie es einfacher zu implementieren als der Open-Source-Wettbewerb und die Leute zahlen.

Benutzerfreundlichkeit und Funktionen - das einzige, was ein kommerzielles Closed-Source-Projekt haben wird, ist die Fähigkeit, eine klare Vorstellung davon zu haben, was das Produkt sein soll und was es tun soll.

Dies alles hängt von der Größe / Komplexität ab, aber ein kleineres Einzel-Team-Softwareprodukt kann sich auf den Markt konzentrieren, den es ansprechen möchte. (Das andere Beispiel - wie BBEdit und TextMate eine Gruppe von Leuten ansprechen können, die bereit sind, für einen Texteditor zu bezahlen , wenn jEdit, gEdit usw. verfügbar sind.) - 30 US-Dollar?)

Indem wir uns auf spezifische Kundenprobleme konzentrieren. Oft habe ich gesehen, wie Unternehmen Tausende von Dollar für "dieses eine Feature" ausgaben.

Als Open-Source-Produkt müssen sie sich auf Massen konzentrieren (leider kaufen Massen diese 10K + -Software nicht), als eine enge Quelle für die Profit-Organisation, wenn Sie den Bedarf Ihrer wichtigsten / kritischen Kunden befriedigen können, würde mehr Geschäft folgen.

Wie bereits bei @SnOrfus erwähnt, sind Service und Support von entscheidender Bedeutung. Ich habe unzählige Male erlebt, wie Organisationen Closed Source gegenüber Open Source bevorzugten (und sogar extra bezahlten), um den Komfort zu haben, jemanden zu finden, der nur_in_case ist!

(Dies könnte ein bisschen auf Firmenkunden ausgerichtet sein.)

Die kommerzielle Lösung kann zu Recht behaupten, dass ihr Vermögen am Erfolg ihrer Kunden ausgerichtet ist. Darum geht es bei der Produktpositionierung. Mit einigen Ausnahmen werden Open Source-Tools im Allgemeinen als Paradies für Hacker angesehen und nicht als kundenorientierte Einzellösung.

Wenn Ihr Kunde eine Funktion benötigt, haben Sie die finanziellen Mittel, um diese rechtzeitig bereitzustellen. Sie können Support rund um die Uhr (und gegen Gebühr) bereitstellen, die Behebung kritischer Probleme der Stufe 0 garantieren und auf Technologien der neuen Generation weit früher zugreifen als die Open-Source-Community, wenn Sie mit OEMs zusammenarbeiten.

Nutzen Sie diese zu Ihrem Vorteil. Lassen Sie das freie Produkt auch auf dem Markt sein, seien Sie nicht feindlich. Wenn überhaupt, erweitert dies den Markt - irgendwann möchten die Benutzer des kostenlosen Produkts vielleicht die Grundlagen Ihrer kommerziellen Lösung ausprobieren.

Lassen Sie uns der Einfachheit halber die Erfolgsfaktoren einer Software in drei "Investitionen" zusammenfassen:

("Investition" ist hier ein Sammelbegriff für Aktivitäten, bei denen Sie jetzt bezahlen müssen, um später Einnahmen zu erzielen.)

• Verkauf und Marketing
• Entwicklung (einschließlich Quellcode, Produkt- / UI-Design, Dokumentation und Schulungsunterlagen. Menge multipliziert mit Qualität. Jedes hier produzierte Arbeitsprodukt kann kostengünstig für eine unbegrenzte Anzahl von Benutzern repliziert werden.)
• Services (Know-how in Software und Domain sowie die Fähigkeit, Verbesserungen auf Kundenbasis zu erzielen)

Der KPI für die Entwicklung ist einfach: Können Sie dasselbe besser und billiger entwickeln als andere? Ein Teil davon ist reine Ressourceninvestition und der andere Teil ist die Weisheit des Architekten und der Designer.

Für Dienstleistungen ist der Zugriff auf den Quellcode des Produkts ein großer Bonus. Ein Unternehmen, das keinen Zugriff auf Quellcode hat, kann häufig nicht den gleichen Service bieten wie ein anderes Unternehmen, das Zugriff hat.

Nun zurück zur Frage des OP: Hat ein Closed-Source-Unternehmen eine Überlebensstrategie?

Der von OP zitierte Artikel scheint sich selbst zu beschränken, da er nur zwei Extreme berücksichtigt:

• Ein Closed-Source-Unternehmen entwickelt den gesamten Quellcode aus eigener Tasche und verfügt über null Zeilen Open-Source-Code.
• Ein Open-Source-Unternehmen steht voll und ganz hinter dem Prinzip und öffnet jede Codezeile, die jemals entwickelt wurde.

Wie wäre es mit dem Mittelgrund?

• Mehrere Softwareunternehmen unterzeichnen Kreuzlizenzvereinbarungen, um einen Teil des Quellcodes und / oder der API gemeinsam zu nutzen. (In welchem ​​der Parteien ist Service-orientiert.)
• Unternehmen, die lizenzierte Open-Source- Komponenten oder -Bibliotheken im BSD-Stil nutzen (und Sachleistungen erbringen), ohne den Quellcode des Hauptprodukts zu öffnen?
• Unternehmen, die den Quellcode laufender Software über eine zeitlich begrenzte "Community Preview" -Vereinbarung bereitstellen?
• "Available-Source": Unternehmen, die zahlenden Kunden Quellcode zur Verfügung stellen?

Meiner Ansicht nach können Unternehmen überleben, wenn sie eine teilweise offene, teilweise geschlossene Quellcode-Strategie verfolgen und sich in allen drei Bereichen (Marketing, Entwicklung und Dienstleistungen) gut behaupten. Unternehmen, die eine offenherzige Philosophie verfolgen, können auch überleben, und sie müssen sich auch an den gleichen drei Fronten gut behaupten.

Es gibt jedoch eine Einschränkung: Wenn eine Software kostenlos ist, werden Kunden sie dann anstelle von Alternativen auswählen, auch wenn die Software bei einigen Messwerten schlecht abschneidet?

• Vertrieb und Marketing: Können Sie ein Produkt durch virales Marketing fast kostenlos bewerben?
• Entwicklung: Kann ein Open-Source-Projekt den größten Teil seines Designs / seiner Entwicklung / Dokumentation von unbezahlten Freiwilligen erhalten? Kann ein Unternehmen von einem solchen Projekt profitieren?
• Dienstleistungen: Kann ein Softwareprojekt seine Software-Domäne so revolutionieren, dass sie sehr einfach ist, sodass jeder sofort zum Experten wird und die Eintrittsbarriere auf Null sinkt?

Das Open-Source-Projekt verfolgt das kommerzielle Projekt in Bezug auf Features. Dies lässt dem kommerziellen Unternehmen eine Art zeitliche Arbitrage, um mit Features zu konkurrieren. Sie müssen ständig um die Implementierung von Funktionen kämpfen, um einen Vorteil gegenüber dem Open Source-Unternehmen zu erzielen. Es ist teuer, aber es kann funktionieren.

Wie andere bereits erwähnt haben, können die Funktionen Dokumentation und Benutzerfreundlichkeit umfassen.

Das Unternehmen kann versuchen, eine Lieferantenbindung zu schaffen, was den Verlust jedoch nur verlangsamt. Sie gewinnen keine Kunden.

Damit bleiben zwei wichtige Möglichkeiten, um Marktanteile zu halten: Unterstützung und Ausnutzung des Misstrauens von Managern gegenüber Open-Source-Software. Letzteres wird dich leider ziemlich weit bringen. Der Verkauf von Support funktioniert jedoch, und selbst wenn das Open-Source-Projekt so erfolgreich ist, dass ein Unternehmen Support dafür verkauft, hat die kommerzielle Lösung den Vorteil, dass sie amtiert und über mehr Erfahrung verfügt und auch den Eindruck hat, dass dies der Fall ist vertrauter mit ihrem Produkt.

Langfristig werden Sie wahrscheinlich geschraubt, aber dies kann "kurzfristig" zu "absehbarer Zukunft" führen.

Eine Sache, die sonst niemand erwähnt hat, ist Dokumentation. Viele Programme brauchen nicht viel, um nutzbar zu sein (Firefox, Openoffice), aber wenn Sie eine Bibliothek, eine Art Server, eine Programmiersprache oder nur ein wirklich kompliziertes Programm schreiben, kann Ihre Dokumentation auffallen.

Durch das Verbessern der Dokumentation kann die Frustration Ihrer Benutzer verringert werden (wodurch die Wahrscheinlichkeit steigt, dass sie Ihr Produkt weiterhin verwenden und es in Zukunft empfehlen). Außerdem können Sie damit werben, dass das Geld gut angelegt ist, da Ihre Kunden weniger Zeit für das Codieren aufwenden (und Zeit == Geld).

Dies ist jedoch nicht unbedingt Open Source oder Closed Source - so ziemlich alles ist schlecht dokumentiert. Es könnte sein, dass Ihr Konkurrent an 1% der Projekte beteiligt ist, die die Dinge gut dokumentieren, aber es ist unwahrscheinlich;)

Der Trick ist ganz einfach, weiterhin 100% neu zu definieren. FOSS hat einfach nicht den gleichen Umfang und die gleiche Personalstärke wie ein kommerzielles Projekt, und es gibt Grenzen, wie eng Sie mit einem vorhandenen Produkt konkurrieren können. Closed-Source-Unternehmen verwenden UI-Hooks, sodass sich die Verwendung eines Konkurrenzprodukts aufgrund unterschiedlicher Tastaturkürzel als unmöglich anfühlt. Darüber hinaus werden ständig wichtige Funktionen hinzugefügt, die ein FOSS-Konkurrent einfach nie in Betracht ziehen könnte. Betrachten Sie beispielsweise Visual Studio. Es war nur eine C ++ - IDE, aber dann begannen sie, völlig neue Sprachen und Frameworks wie .NET zu bündeln. Oder Visual Studio 2010, das eine kommerzielle Threading-Bibliothek für C ++ enthält (wie in Intel, das eine entsprechende eigenständige Threading-Bibliothek verkauft). FOSS kann mit dieser Art von Entwicklung und oft auch Zuverlässigkeit nicht Schritt halten.

Greifen Sie auf traditionelle Unternehmensmärkte zu und werden Sie beliebt.

Für viele große Traditionsunternehmen läuft es auf drei Dinge hinaus:

• einen Lieferanten, mit dem sie einen verbindlichen Vertrag abschließen können (Fähigkeiten und Zuverlässigkeit)
• einem Anbieter, mit dem er eine bestimmte Service-Level-Vereinbarung vertraglich durchsetzen kann (schnelle Qualität des Supports)
• gartner reviews (dies ist die moderne Entsprechung von "niemand wird wegen der Wahl von IBM entlassen")

Alle drei werden gedankenlos befolgt und sind nicht besonders gültig. Fähigkeitsprobleme sind immer überverkauft, SLAs haben immer eine Ausrede und Gärtner befragt nur die Art von Leuten, die Gärtner zuhören, aber wenn Sie mittleres Management in einem Unternehmen sind, das eine ganze Menge oberes und mittleres Management hat, das Probleme mit oberem Management hat Wenn die Geschäftsleitung schließlich erfährt, dass eine Entscheidung ohne Kopf einen großen Haufen Geld gekostet hat, benötigen Sie Unterlagen von einem Dritten, der Ihre Position unterstützt, wenn Sie Ihren Job retten möchten. Selbst wenn Sie genau wissen, dass Sie aus technischer Sicht viel Geld in die Toilette spülen, ist es das Risiko nicht wert, das Richtige zu tun.

Wie viele Missbräuche von SAP oder SharePoint haben Sie in der Branche gesehen? Wie viele davon wären besser gewesen, wenn sie mit etwas anderem gemacht worden wären, das besser zu Ihnen passte, aber nicht zu einer großen Branche gehörte?

Ich verwende viele Microsoft-Tools und habe ein MSDN-Konto, aber ich bekomme ehrlich gesagt bessere Hilfe von MS-Leuten auf Twitter als über das MSDN-Telefoncenter. Ich kann mir nicht vorstellen, dass ich von den Leuten, die hinter Open Source-Projekten stehen, schlechtere Hilfe bekommen würde als von Leuten, die in ihrer Freizeit nicht tweeten, aber das geht nicht in die Liability / Gartner-Gleichung ein.

Wie SnOrfus sagte, verkaufen wir die Funktionen, die wir anbieten.

ZB: Wir entwickeln Plugins mit einigen gemeinsamen Funktionen und stellen sie auf der Wordpress-Website kostenlos zum Download bereit. Gleichzeitig haben wir unser kostenpflichtiges Versions-Plugin mit Pro-Funktionen.

Dies hilft Ihnen, Ihr Produkt einem breiten Publikum vorzustellen, dh der Macht von Open Source und Menschen.