Die Weisheit, Open Source Code in einem kommerziellen Softwareprodukt zu verwenden

13

Ich möchte Open Source-Code in meiner ASP.NET-Webanwendung verwenden (speziell dapper ). Das Management ist kein Fan, denn Open Source wird als Risiko angesehen, das uns schon früher gebissen hat. Offenbar mussten frühere Entwickler nach dem Ausfall von Open-Source-Komponenten die Dinge neu schreiben.

Die Profis scheinen zu sein:

  • Es erledigt eine Menge Dinge für mich, die ansonsten entweder viel Boilerplate-Code oder die von Microsoft empfohlene, aber langsamere Lösung (Entity Framework) beinhalten würden.

Nachteile:

  • Es ist kompliziert genug, dass es mir schwer fällt, das Problem zu beheben, wenn es in der Produktion plötzlich ausfällt. Es wird jedoch auf einer viel stärker frequentierten Site als meiner verwendet, sodass ich nicht glaube, dass es ein Teil des Projekts mit hohem Risiko sein wird.

Was ist der Konsens hier? Ist es nicht ratsam, Open Source-Code in meinem Projekt zu verwenden, den ich nicht so gut kenne / verstehe wie meinen eigenen Code?

Mr. Jefferson
quelle
15
ASP.NET und sein Stack sind Open Source.
Andrew T Finnell
11
"Ist es unklug, Open Source Code in meinem Projekt zu verwenden, den ich nicht so gut kenne / verstehe wie meinen eigenen Code?" Im Gegensatz zu Closed-Source-Bibliotheken, die Black Boxes sind?
user16764
5
@ AndrewFinnell: Nicht durch die eigene Definition der FLOSS-Bewegung.
tdammers
6
Wenn Sie an ein bestimmtes OS-Projekt denken, kann es von Interesse sein, dass Dapper von StackExchange verwendet wird ...
Marjan Venema
4
Dies ist keine technische Frage, es geht nicht darum, was besser ist. Welches wird schief gehen. MFC ist tot, XP wird in weniger als 2 Jahren tot sein usw. Kostenloses und Open Source-Projekt wird nicht sterben, wenn sie gut sind, da Sie oder jemand anderes sie übernehmen können. Hier geht es darum, wem die Schuld gegeben wird. Wenn Sie sich für Microsoft entscheiden, wenn Sie unvorhergesehen sind oder wenn Microsoft einen Fehler begangen hat. Wenn Sie sich für Free / Open Source entscheiden, sind Sie schuld.
ctrl-alt-delor

Antworten:

20

Es ist eine Wahl, die Sie basierend auf den spezifischen Umständen treffen müssen. Sie können Ihre Risiken verringern, indem Sie:

  • gründliches Testen des Frameworks, um böse Überraschungen in einer Produktionsumgebung zu vermeiden, und
  • Verwenden Sie die lose Kopplung, um die Menge an Code zu minimieren, die direkt vom Framework abhängt, sodass Sie zu Ihrer eigenen Implementierung wechseln können, wenn Sie müssen, ohne Ihr gesamtes Produkt neu zu schreiben.

Letztendlich werden Sie mit einem stark genutzten Open-Source-Projekt wahrscheinlich viel mehr Zeit damit verbringen, Ihre eigenen zu schreiben, als die wenigen Probleme zu beheben, auf die Sie stoßen.

StriplingWarrior
quelle
16

Ich werde so weit gehen zu sagen, dass Sie zum Scheitern verurteilt sind, wenn Ihre erste Reaktion darin besteht, etwas selbst zu schreiben, anstatt zu sehen, ob jemand anderes es geschrieben hat. Nehmen Sie sich nicht all die Arbeitsstunden und Fehlerbehebungen, die in den Mainstream-Open-Source-Projekten stecken.

Sobald Sie in Ihre Geschäftsdomäne eingestiegen sind, werden Sie mehr Mühe haben, ein OSS zu finden, das Ihren Anforderungen entspricht. Es ist jedoch nicht erforderlich, ein weiteres ORM-Produkt erneut zu implementieren. Wenn dapper so komplex ist, dass Sie ihren Code nicht debuggen und korrigieren können, wie würden Sie es dann rechtfertigen, all die Arbeitsstunden damit zu verbringen, ihn von Grund auf neu zu schreiben? Außerdem können (sollten?) Sie NoSQL-Lösungen immer über den Tellerrand hinaus betrachten, während Sie sich damit beschäftigen.

Sogar Linus gab zu, dass er versucht hatte, eine SCM-Lösung zu finden, die alle seine Kriterien erfüllte, bevor er Git entwickelte. Zumindest konnte er erklären, warum keine der vorhandenen Lösungen gut genug war.

Irgendwann in meinem Leben hörte ich auf, alles selbst umschreiben zu wollen und wollte mich auf die Lösung von Problemen der realen Welt konzentrieren. Die meisten Probleme, die in einem Unternehmen gelöst werden müssen, sind domänenspezifisch. Wege finden, weniger Code zu schreiben, nicht mehr.

Andrew T. Finnell
quelle
2
+1 Ich bin mit all dem einverstanden, außer wenn Sie sagen, er solle sich NoSQL ansehen. Jede NoSQL-Datenspeicherlösung - es gibt viele - hat eine Reihe von Kompromissen gegenüber einer „standardmäßigen“ relationalen SQL-Datenbank. Daher ist es schwierig, ohne viele Informationen ein „Sollte“ zu sagen. Manchmal sind das gute Kompromisse und manchmal nicht, aber Sie können keine pauschalen Aussagen darüber machen. "NoSQL" ist nur das Branding von Müll um eine Reihe von Technologien, die nur wenig gemeinsam haben, außer dass sie nicht das gängigste Datenspeichersystem sind.
Donal Fellows
Aber alles andere, was du schreibst, stimme ich definitiv zu. Gutes OSS nimmt den normalen Entwicklern viel Mühe ab (und wer würde schlechtes OSS benutzen wollen?)
Donal Fellows
Dapper ist komplex, weil es verallgemeinert ist. Wenn ich meine eigene Lösung schreiben würde, würde ich eine Menge Code für die Konvertierung von Datensätzen in Objekte (dh MyClass.Property = set.Tables[0].Rows[i]["Property"].ToString()) in Boilerplate schreiben .
Mr. Jefferson
Sobald Sie in Ihre Geschäftsdomäne eingestiegen sind, werden Sie schwieriger sein, alles zu finden, was Ihren Anforderungen entspricht. Es sei denn, Microsoft geht Sie etwas an. (Aber ich mag den Rest von dem, was Sie gesagt haben.)
ctrl-alt-delor
@richard Einige meiner Antworten sind möglicherweise unklar. Ihre Aussage ist das, was ich auch sage. Warum sollten Sie sich auf die Teile konzentrieren, die wie ORM immer wieder gelöst wurden? Konzentrieren Sie sich auf den Geschäftsbereich. ORM ist keine Geschäftsdomäne, es sei denn, Sie verkaufen ein ORM-Produkt.
Andrew T Finnell
15

Hinweis: Ich bin kein Microsoft-Mitarbeiter. Die Meinung ist ganz persönlich. Viele Gedanken stammen aus den letzten 5 bis 7 Jahren, in denen beide Open Source im Mix mit großen Anbietern als Entwickler eingesetzt wurden.

Monokultur ist gut: Meine persönliche Regel für ASP.NET lautet, Microsoft den Vorzug zu geben und keinen Code von Drittanbietern (Open Source oder nicht) zu wählen, es sei denn, es gibt keine andere Wahl. Monokultur ist eine Belohnung, da Sie von einem großen Anbieter getragen werden und die Anzahl der Benutzer, die dieselbe Erfahrung wiederholen, jederzeit groß genug ist, um Hilfe zu erhalten und eine Lösung zu finden.

Geisterstädte: Das Problem mit Open Source im Jahr 2012 ist, dass es nicht mehr 2000 oder 2005 ist. Die Anzahl der Projekte wächst stetig, wenn die Anzahl der Benutzer, Adoptionen und Mitwirkenden etwa so hoch ist wie vor Jahren. Das Publikum ist dünn gestreckt. Viele interessante Projekte wurden abgestanden, aufgegeben. Es gibt kein Open-Source-Projektbudget. Wenn also das Interesse endet, gibt es niemanden, der ehrlich verkündet, dass die Unterstützung beendet ist, und der das Licht ausschaltet. Die Projekte sterben nie, um die Aufmerksamkeit der Öffentlichkeit auf etwas Besseres und Neues zu lenken. Open Source wird also immer weiter wachsen und fragmentieren. Da sie kein Feedback in Form einer finanziellen Belohnung oder eines finanziellen Todes haben, sind sie unsterbliche Wesen, die für den ewigen Ruhm existieren.

20 Grad der Trennung: Jede Annahme einer neuen Bibliothek trennt Sie vom Mainstream und versetzt Sie in die Minderheit der Randfälle. Nach 20 Schritten wie der Auswahl der Sicherheitskonfiguration, der Verwendung einer bestimmten Version, eines bestimmten Frameworks, eines bestimmten Plugins usw. wird Ihre Lösung zu einer einzigen, weltweit einzigartigen Kombination von Details. Googeln hilft nur, um zu beweisen, wie selten oder einzigartig das Problem ist. Es ist immer ein rein technisches Problem. Niemals relevant für echte Geschäfte.

Qualität kommt aus dem Fokus, Geld ist irrelevant: Es gibt keinen Unterschied zwischen kommerzieller Software und Open Source. Die ganze Gemeinschaft der Entwickler ist nur eine Gemeinschaft, wie es immer war. Große Anbieter haben einfach den Vorteil, dass sie den Code unter besseren Bedingungen länger altern lassen und ein breiteres Publikum haben als Open-Source-Gruppen.

Konsens: Sie fragen, ob Konsens besteht. Möglicherweise nicht. Leider sind viele Open Source-Nutzer viel zu politisiert. Immerhin ist Open Source eine soziale Bewegung. Open Source ist immun gegen Kritik, da sehr oft negative Meinungen als antitechnologischer, persönlicher Angriff wahrgenommen werden. Mein persönlicher Konsens: Halten Sie sich an Microsoft.


quelle
3
+1: Ich kann nicht sagen, dass ich ganz zustimme, aber es ist zu gut argumentiert, nicht zu .....
Mattnz
14
"Es gibt kein Open-Source-Projektbudget." ist falsch. Google verfügt über ein Budget für Open-Source-Projekte, und Red Hat Inc. kann beispielsweise sein Geschäft nicht betreiben, wenn die Software nicht genügend Programmierer enthält. Und was ist damit? microsoft.com/opensource/directory.aspx
ONOZ
14
Ich bin nicht mit einem einzigen Wort einverstanden, das Sie gesagt haben.
Avio
11
Alle diese Punkte gelten gleichermaßen für Closed-Source-Projekte. Das Hinzufügen von Nischen-Closed-Source-Bibliotheken / Frameworks erhöht die Vielfalt. Alte proprietäre Technologie wird aufgegeben, wenn sie kein Geld bringt. Sie können IIS weiterhin so konfigurieren, dass es ein eigener eindeutiger Schmetterling ist. Der Qualitätskommentar ignoriert, dass Open Source-Projekte größer sein können als (einige) Anbieter. Insbesondere bei Microsoft ist die Geschäftswelt stark politisiert.
Philip
3
Ich habe das Gegenteil erlebt. Wir haben SQLite auf ein Gerät portiert und konnten Unterstützung direkt von dem Typ bekommen, der das meiste geschrieben hat. Wir hätten dieses Serviceniveau auf keinen Fall von einem Closed-Source-Unternehmen erhalten können. Einige Open Source-Projekte sind absolut robuster und werden besser unterstützt als einige Closed Source-Projekte. Ich könnte eine Geschichte über die Verwendung des "Industriestandards" Microsoft C ++ - Compilers für OS / 2 erzählen und wie sich die Unterstützung dafür entwickelte, als Microsoft entschied, auf OS / 2 zu verzichten.
Gort the Robot
7

Ich habe an einer Reihe von erfolgreichen Projekten für ein großes Unternehmen gearbeitet, das umfangreiche Open-Source-Software verwendet hat. Insbesondere habe ich Curl, SQLite und Webkit für ein sehr großes Unternehmen für erfolgreiche Projekte verwendet, die an Endbenutzer ausgeliefert wurden. Wie andere bereits gesagt haben, müssen Lizenzen nur vorsichtig behandelt und im Idealfall von einem Anwalt überprüft werden.

Es gibt Hunderte von Open Source-Lizenzen, aber im Allgemeinen fallen sie in zwei Kategorien, BSD-Stil und GPL-Stil. Für BSD-Lizenzen ist es nicht erforderlich, dass Sie Ihren eigenen Code als Open Source-Version verwenden. Im Allgemeinen müssen Sie nur eine Art Attributionsklausel verwenden. Für Lizenzen im GPL-Stil müssen Sie Ihren eigenen Quellcode öffnen. Die meisten Unternehmen (einschließlich meiner) sehen das im Allgemeinen schief an, so dass Sie den GPL-Stil vermeiden möchten. Dapper verwendet anscheinend die Apache-Lizenz im BSD-Stil. Informieren Sie sich immer über die allgemeinen Lizenzbedingungen, bevor Sie mit dem Codieren beginnen.

Es gibt auch die LGPL, ein interessanter Grenzfall, in dem Sie diese verwenden können, ohne Ihren eigenen Code zu öffnen, wenn Sie den Zugriff auf eine binäre Grenze einschränken. (Dh auf die Bibliothek kann nur als dynamische Bibliothek zugegriffen werden.) Die Verwendung der LGPL-Bibliothek ist sehr gut möglich, Sie müssen nur vorsichtiger sein.

Meiner Erfahrung nach ist Open Source Code nicht wahrscheinlicher fehlerhaft oder fehlerhaft als kostenpflichtige Lösungen oder Roll-Your-Own-Lösungen. Wenn Sie sich einige der bekanntesten Open-Source-Tools ansehen, ist die Qualität sehr hoch.

Sie möchten wahrscheinlich Projekte vermeiden, die klein oder unvollständig sind. Es kann verlockend sein, sich etwas zu schnappen, das Ihren Bedürfnissen zu entsprechen scheint, aber wenn es sich um etwas handelt, das von ein paar Leuten zusammengestellt wurde, die nie fertiggestellt und nicht unterstützt wurden, ist es wahrscheinlich die Mühe nicht wert. (Sofern Sie nicht bereit sind, direkt am Code zu arbeiten.)

Gort den Roboter
quelle
7

Hatten Sie noch nie einen Ausfall von proprietären Komponenten? Ich habe viele Fehler in Software von großen und kleinen Unternehmen gefunden. Bei diesem Thema handelt es sich nicht um ein Open Source-Problem, sondern vielmehr um die Projektreife.

Es klingt so, als ob Sie ausgereifte Projekte verwenden möchten, die Unterstützung bieten. Einige Open Source-Projekte bieten kostenpflichtigen Support oder verfügen über eine Community, die groß genug ist, um Antworten in einem öffentlichen Forum zu erhalten. Vielleicht sollten Sie bei der Auswahl einer Bibliothek, egal ob es sich um eine geschlossene oder eine Open Source-Bibliothek handelt, Prioritäten für Reifegrad- und Unterstützungskriterien setzen.

Sie müssen sich darüber im Klaren sein, dass Sie ein höheres Risiko eingehen, wenn Sie sich für ein noch nicht ausgereiftes Projekt oder ein Projekt mit eingeschränkter Unterstützung entscheiden. Daher müssen Sie Ihren Risikominderungsplan festlegen. Sie können beispielsweise weitere Tests für die Software von Drittanbietern durchführen.

M. Dudley
quelle
6

Vorausgesetzt, die Lizenzprobleme sind hier kein Problem: Bei einem kurzen Blick auf Dapper fiel mir auf, dass es nur 2255 Zeilen gut dokumentierten, lesbaren Codes gab . Das ist

  • groß genug, dass Sie mehrere Tage oder Wochen investieren können, um Code von vergleichbarer Qualität zu erstellen, der dasselbe tut
  • Klein genug, dass Sie verstehen, was es tut, und alle Fehler in diesem Code beheben können, wenn sie in der Produktion auftreten

Wenn Sie so etwas selbst schreiben und "das Rad neu erfinden", haben Sie ein viel höheres Risiko, dass Ihr eigener Code Fehler in der Produktion aufdeckt, und Sie werden es wirklich "schwer haben, sie zu beheben".

Was Sie hier jedoch tun müssen, wenn Sie ein solches Stück Open Source in Ihr Projekt einführen, dann Sie müssen nehmen die volle Verantwortung für diesen Code, so als ob Sie es selbst geschrieben hatte. Stellen Sie sicher, dass der Code in einem Zustand ist, in dem Sie ihn bei Bedarf verwalten können. Beschuldigen Sie nicht "die Autoren" dieses Codes, wenn etwas nicht wie erwartet funktioniert.

In einem unserer Projekte haben wir auch einige Open-Source-Komponenten eingeführt, von Dapper bis zu Bibliotheken mit etwa 20 bis 30 KB Codezeilen. Wir mussten immer einige Änderungen vornehmen, einige Fehler beheben, etwas verkleinern usw., aber das war in Ordnung, da wir das erwartet hatten. Sogar die Zeit für das Debugging, einschließlich Open Source, hat uns viel Arbeit erspart.

Eines sollten Sie hier bedenken: In Ihrem Fall erwähnen Sie, dass es eine allgemein akzeptierte Alternative eines großen Anbieters gibt (MS Entity Framework, für das Sie keine zusätzlichen Lizenzgebühren zahlen müssen!). Sie möchten es aus Leistungsgründen nicht verwenden. Ich empfehle dringend, die Leistung nicht als einzigen oder primären Punkt zu betrachten. Die Fragen, die Sie hier stellen sollten: Hat Dapper alle Funktionen, die Sie jetzt und für die erwartete Lebensdauer Ihrer Software benötigen? Oder können Sie davon ausgehen, dass Sie schnell an die Grenzen von Dapper stoßen und eine Menge fehlender Funktionen hinzufügen müssen, was Sie wahrscheinlich nicht tun müssten, wenn Sie sich ursprünglich für EF entschieden hätten? In letzterem Fall würde ich empfehlen, Dapper nicht zu verwenden. Fragen Sie sich auch: Ist EF wirklich nicht schnell genug für Ihre Anwendung?

Doc Brown
quelle
1
+1 für Lizenzprobleme. Überprüfen Sie sorgfältig, ob Sie durch die Verwendung einer Open-Source-Komponente nicht auch gezwungen sind, Ihren eigenen Code zu öffnen. Ich glaube nicht, dass dies für die meisten Open-Source-Unternehmen der Fall sein wird, und wenn Sie es nur zum Produzieren oder Hosten Ihres Codes verwenden, wird es mehr geben, aber es lohnt sich trotzdem, es zu überprüfen.
Lunivore
Auch wenn die Leistung weniger wichtig ist, gibt mir die EF weniger Kontrolle. Die Einführung von Caching ist etwas schwieriger, wenn dies später erforderlich wird. Dapper lässt sich leichter in eine kundenspezifischere Lösung integrieren und macht es nicht nur notwendig, die Cachespeicherung erst später durchzuführen.
Mr. Jefferson
Auf der anderen Seite klingt der Wunsch nach einer benutzerdefinierten Lösung für die EF ein bisschen wie NIHS. Mein Datenschema ist sehr komplex mit vielen Beziehungen (Fremdschlüsseln), und es würde mit Sicherheit eine Weile dauern, bis meine benutzerdefinierte Lösung diese Beziehungen verwaltet und der EF sofort einsatzbereit ist.
Mr. Jefferson
@ Mr.Jefferson: im Ernst, ich kann dir keinen guten Rat geben, was die bessere Lösung in deinem Fall ist, das musst du selbst herausfinden. Ich wollte Ihnen nur einige Hinweise geben, worauf Sie achten sollten.
Doc Brown
+1. Sie haben in diesem Beitrag einige sehr gute Punkte angesprochen. @ Mr.Jefferson: Ich verwende Entity Framework bereits seit einiger Zeit und bin ziemlich erfolgreich darin, die Leistung über Ad-hoc-Caching auf bestimmten Repositorys zu verwalten, nachdem ich herausgefunden habe, wo die Engpässe liegen. Außerdem ist unser Produkt ziemlich komplex, aber ich musste immer noch nicht auf das Schreiben einer einzelnen SQL-Abfrage zurückgreifen. Ich habe das Gefühl, dass EF mir viel Kontrolle gegeben hat.
StriplingWarrior
2

Aus meiner Sicht ist es ein Spagat.

Wenn Sie sich von einem Anbieter abhängig machen, ist es fast sicher, dass die Unterstützung bald aufhört

  • Weil sie Programmierer zu bezahlen haben, müssen sie weiterhin neue Versionen erstellen und sicherstellen, dass die alten nicht mehr zu bekommen sind und nicht mehr funktionieren (auf neueren Plattformen), damit die neuen einen Markt haben.

  • Wenn sie nicht genug verkaufen können, um ein Geschäftsmodell zu rechtfertigen, geben sie es von Firma A an Firma B an C weiter, von denen jede es genug ändert. Sie können das neue Modell nicht verwenden, ohne es neu zu programmieren, und Sie können t den alten, der funktioniert.

  • Sie beschließen nur, es nicht länger zu unterstützen, weil es zu viel Ärger gibt und kein Geld mehr drin ist. Das ganze Geld steckt in neuen Apps.

Wenn Sie also etwas erstellen möchten, das nicht alle paar Jahre neu geschrieben werden muss, kann Open Source Ihr Freund sein.

Mike Dunlavey
quelle
1

Ich denke, es ist ratsam, wenn eine ausreichende Sorgfaltspflicht besteht und es den Anschein hat, dass Sie bereits einige Hausaufgaben in Bezug auf die Geschichte und Aktivität eines bestimmten Projekts gemacht haben. Die Möglichkeit, Funktionen im Quellcode zu erweitern / hinzuzufügen, ist ebenfalls ein großer Vorteil. Mit ausreichenden Tests können Sie das Risiko auf der Gegenseite minimieren. Es ist schwer, alle Abhängigkeiten in Ihrem Code vollständig zu verstehen, aber zumindest in diesem Fall können Sie den Code bei Bedarf vollständig debuggen und anzeigen.

Fragen Sie die Geschäftsleitung, warum dies zuvor fehlgeschlagen war. Wurde eine ausreichende Due Diligence durchgeführt?

Schlüsselfertig
quelle
Ich weiß nicht viel darüber, was passiert ist. Es war, bevor ich hier ankam.
Mr. Jefferson
0

jquery hat die Option, die MIT-Lizenz zu verwenden, so dass viele kommerzielle und staatliche Websites auch jquery verwenden. Microsofts Website verwendet auch jquery! Das Anliegen ist also die Lizenzierung. Vermeiden Sie die Verwendung von GPL / LGPL ist ausreichend.

"Wie lange brauchen Sie, um einen gemeldeten Defekt zu beheben?" Nachdem der Fehler gemeldet wurde, kann er innerhalb von Minuten, Stunden oder Tagen behoben werden. In dringenden Fällen kann das Personal einfach "Git-Pull" durchführen, um die Quelle zu ermitteln und sie selbst zu kompilieren. Er meldet einfach die Version wie "v1.2.3-101-gd62fdae" an das Management, was nachvollziehbar ist.

linquize
quelle
0

Bei Open Source geht es wirklich um Legalitäten, nicht um Codequalität. Es gibt gute und schlechte Open-Source-Produkte, genauso wie es gute und schlechte Closed-Source-Produkte gibt. Ich glaube, Ihr Dilemma besteht darin, ein Projekt zu nutzen, das von einer Gemeinschaft von Freiwilligen entwickelt wurde.

Nemanja Trifunovic
quelle
-1

Sind Sie sicher, dass es sich bei dem Managementproblem um ein technisches Problem handelt?

Ich sage dies, da das Mischen von Betriebssystem- und kommerziellen Aktivitäten ein rechtliches Minenfeld ist und mehr als ein Manager ein "Bitte erklären" vom Rechtsteam / CEO oder, schlimmer noch, von einer anderen Organisation erhalten hat. Die meisten Manager, die ich kenne, auch diejenigen, die sich aktiv mit Betriebssystemsoftware befassen, sind (zu Recht) sehr vorsichtig, um die rechtlichen Situationen, denen sie ausgesetzt sind, vollständig zu verstehen. Wenn Sie OS-Software übernehmen und Änderungen vornehmen, sind Sie verpflichtet, diese Änderungen an die Community zurückzugeben. In einigen Fällen ist diese Verpflichtung legal, in anderen moralisch. In einigen Betriebssystemlizenzen wird alles, was Sie tun, zum Betriebssystem, indem Sie nur eine Verknüpfung zu ihnen herstellen.

Aus technischer Sicht ist es wirklich nur eine Entscheidung zwischen konkurrierenden Produkten. - Stellen Sie einige grundlegende Fragen. - Können Sie den Support erhalten, den Sie für das ausgewählte Paket benötigen ?, Wie lange dauert es, eine Lösung für einen gemeldeten Defekt zu erhalten, wie viel kostet es pro Entwickler, pro Jahr oder einmalig usw. Das Betriebssystem hat viele Nullen in der Spalte "$", aber häufig auch Leerzeichen in den anderen - nur Sie und Ihr Chef können entscheiden, ob die Nullen die Leerzeichen wiegen oder nicht.

Und noch ein wichtiger Punkt: "Niemand wurde jemals gefeuert, als er IBM kaufte". (dh das Management spricht für "Wenn Sie viel Geld ausgeben, muss es ein besseres Produkt sein als eines, das kostenlos ist"

mattnz
quelle
5
Ironischerweise ist IBM wahrscheinlich der weltweit größte Verkäufer von Open Source-basierter Software. Apache http-Server, Eclipse usw. usw.
James Anderson
7
Der Verkauf von OSS ist nicht illegal. Warum sollte es sein?
tdammers
1
IBMS httpServer ist reiner Apache, es wird lediglich eine Supportvereinbarung mitgeliefert.
James Anderson
2
Dinge verändern sich. Jetzt denkt das Management, wenn Sie das Unternehmen für eine Komponente bezahlen lassen, die andere Unternehmen kostenlos hatten, sind Sie ein Trottel.
Avio
2
Die "anderen Spalten" sind für Open Source selten leer. Sie können immer Unterstützung von Beratern oder Vertriebsanbietern oder von jemandem erhalten, und Sie können sich auch selbst unterstützen. Weitere Spalten sind für die kommerzielle Software häufig leer, da Sie die Qualität der Unterstützung im Voraus nicht kennen und sie selten so hilfreich sind, wie Sie es benötigen.
Jan Hudec