Unser Unternehmen liefert eine Reihe von Desktop-Produkten für Windows aus, und viele Linux-Benutzer beschweren sich in Foren, dass wir vor Jahren Versionen unserer Produkte für Linux hätten schreiben sollen, und der Grund dafür ist, dass wir dies nicht tun
- Wir sind eine gierige Firma
- Alle unsere technischen Spezialisten sind unterqualifizierte Idioten
Unser durchschnittliches Produkt besteht aus 3 Millionen Zeilen C ++ - Code.
Meine und meine Kollegen analysieren Folgendes:
- Das Schreiben von plattformübergreifendem C ++ - Code ist nicht so einfach
- Viele Distributionspakete zu erstellen und für alle gängigen Linux-Versionen zu warten, braucht Zeit
- Unsere Schätzung ist, dass der Linux-Markt etwa 5-15% aller Benutzer ausmacht und diese Benutzer wahrscheinlich nicht für unsere Bemühungen zahlen möchten
Wenn dies erwähnt wird, ist die Antwort erneut, dass wir gierige, unterqualifizierte Idioten sind und dass, wenn alles richtig gemacht wird, dies alles einfach und schmerzlos ist.
Wie vernünftig sind unsere Bewertungen der Tatsache, dass das Schreiben von plattformübergreifendem Code und die Pflege zahlreicher Distributionspakete viel Aufwand erfordert? Wo finden wir eine einfache und dennoch detaillierte Analyse mit Geschichten aus dem wirklichen Leben, die zweifelsohne zeigen, wie viel Aufwand genau erforderlich ist?
quelle
Antworten:
Denken Sie daran, dass die Mehrheit der Menschen Angestellte sind und daher nicht in einer Welt leben, in der es für sie wichtig ist, Gewinne zu erzielen. Sie tauchen bei der Arbeit auf, machen ihr Ding und gehen nach Hause, ohne wirklich darüber nachzudenken, wie der ganze Prozess funktioniert. Und obwohl sie sehr schlau sind, kennen viele Technikfreaks das Geschäft überhaupt nicht und werden oft vom Dogma geblendet.
Sie haben natürlich Recht, dass es keine einfache Sache ist, X-Plattform-Software dieser Größenordnung herzustellen. Besonders, wenn Sie kein Unternehmen sind, das viele Dutzend Entwickler und Millionen von Benutzern hat. Und es sind nicht nur technische Einschränkungen. Es geht nur um Kosten und Nutzen. Ja, Sie könnten dann nächstes Jahr die App auf Linux portieren (obwohl sie, wie Sie bemerken, bereits in WINE lauffähig ist). Natürlich wird dieses Jahr der Entwicklungszeit nicht frei. Und am Ende werden Sie vielleicht netzusätzliche 5-15% Benutzer (basierend auf Ihrer Schätzung). Oder Sie können das gleiche Geld / die gleiche Anstrengung in Ihre Windows-Entwicklung als neue Version investieren oder alles in Marketing umwandeln und 50% zu Ihrer Benutzerbasis hinzufügen. Was klingt nach der klugen Wahl? (Natürlich müssen die Nummern an Ihr Unternehmen angepasst werden, und das Endergebnis kann die Portierung begünstigen.)
Ich weiß nicht, ob das dazu beitragen wird, "wahre Gläubige" zu überzeugen, aber es ist der kluge Schritt des Geschäfts. Und wenn Sie keine klugen Geschäfte machen, haben Sie keine Geschäfte mehr. Und dann wird es mit Sicherheit keine Linux-Version geben.
quelle
Hier sind meines Erachtens zwei Dinge zu beachten:
Das erste ist, dass sie in gewisser Weise Recht haben. Das plattformübergreifende Schreiben von C ++ ist nicht so schwierig, wenn Sie es von Anfang an geplant haben . Dies ist mit ziemlicher Sicherheit das Problem, das Sie sehen. Die meisten Open-Source-Anwendungen (die meisten Anwendungen, die ein Linux-Benutzer an einem durchschnittlichen Tag berührt) sind absurd plattformübergreifend. Überlegen Sie, mit wie vielen Anwendungen der durchschnittliche Linux-Benutzer täglich interagiert, die in C oder C ++ geschrieben sind und nicht nur unter Windows und Linux, sondern auch unter MacOS, BSD, Solaris usw. unter x86, x86-64, ARM, SPARC ausgeführt werden. usw. Dies liegt zum Teil daran, dass Leute, die es lieben, den Code zu portieren, der auf ihren Systemen ausgeführt werden soll, aber auch daran, dass plattformübergreifende Portabilität geplant werden soll.
Die zweite Sache ist, dass der Markt möglicherweise überlebensfähiger ist, als Sie denken. Es gibt ein großes Missverständnis, dass Linux-Benutzer nicht für Software bezahlen möchten. Für einige Leute mag das stimmen, aber es gibt eine Menge Leute (die meisten, glaube ich), die Linux verwenden, weil es für sie besser funktioniert und sie es bevorzugen, nicht wegen des Preises. Wenn Ihr Unternehmen ein Produkt herstellt, das hauptsächlich für den professionellen Einsatz bestimmt ist, sind Unternehmen es gewohnt, für die Ausführung von Software auf Linux-Systemen zu zahlen.
Was das Thema Verpackung betrifft, müssen Sie, wie andere bereits gesagt haben, nur Pakete für die neueste Version der wichtigsten Distributionen erstellen. Das Erstellen der Pakete ist eigentlich gar nicht so schwierig, und die meisten der Hauptdistributionen verwenden entweder Debian-Pakete (Debian, Ubuntu usw.) oder RPMs (Fedora, Suse, Centos, Mandrake). Daher ist es sehr unwesentlich, einige Skripte zu ändern Um mehrere Pakete aus einer Basis-.deb- und einer Basis-.rpm-Datei zu erstellen und für alle anderen Benutzer ein Tarball mit Binärdateien und einer Readme-Datei zu erstellen, müssen die Benutzer herausfinden, wie sie es installieren können. Alternativ können Sie das gesamte Paket überspringen und einen einzelnen Tarball mit einem Bash- oder Perl-Skript bereitstellen, um die Installation durchzuführen.
Wie man sich an die Benutzer in Ihren Foren wendet, die sich beschweren, könnte, wie Joe Internet sagte, nur der Prozentsatz der Leute sein, die sich beschweren, egal was passiert, aber das erste, was ich tun würde, ist zu erklären, dass Sie eine haben große Menge an Legacy-Code, der nicht für plattformübergreifende Unterstützung entwickelt wurde. Zweitens: Mal ehrlich, ob es finanzielle Unterstützung bringt, einen Linux-Port einzurichten, und ob man mit den Ergebnissen offen ist. Wenn ein Port finanziell nicht realisierbar ist, lesen Sie zum Schluss, wie Sie etwas tun, damit das Programm mit WINE funktioniert. WINE sollte nicht die erste Lösung sein, aber es kann die Leute beruhigen, die Ihre App nur unter Linux verwenden möchten, und ein kostengünstigeres Projekt als ein vollständiger Port sein. Wenn Sie im Rahmen des Projekts Code zur WINE-Codebasis hinzufügen, können Sie sich nicht nur einem neuen Markt öffnen,
quelle
Adobe, bist du das?
Im Ernst, stellen Sie eine Art Kopfgeld auf, damit sie Linux-Versionen vorbestellen können. Wenn Sie genug Aufträge erhalten, damit sich ein Hafen in der Zeit lohnt, erstatten Sie sie andernfalls zurück, und Sie haben jetzt den Beweis, dass nicht genügend Leute dafür sorgen, dass sich dies lohnt.
Wenn Sie jedoch etwas portiert bekommen, zielen Sie einfach auf die neueste Ubuntu LTS-Version, RHEL, SLED, und stellen Sie vielleicht ein tar.gz zur Verfügung. Die Leute können versuchen, zu arbeiten, wenn sie etwas anderes verwenden möchten. Sie haben also 3 Pakete, um die Sie sich Sorgen machen müssen, und jeder andere weiß wahrscheinlich genug, um die tar.gz-Version zum Laufen zu bringen.
quelle
Ganz im Gegenteil. Wenn Sie plattformübergreifende Arbeit planen und Abstraktionen für die von Ihnen verwendeten plattformspezifischen APIs bereitstellen, ist der überwiegende Teil Ihres Codes bereits plattformübergreifend. Wenn Sie bereits eine beliebte Bibliothek wie Boost, Qt oder NSPR verwenden, können Sie schon bald einen plattformübergreifenden Build erstellen.
Das Problem, das am häufigsten auftritt, wenn ein Port spät im Entwicklungszyklus ausgeführt wird, besteht darin, dass in Teilen des Programms erhebliche Teile des Codes auf plattformspezifischen APIs basieren, die nicht direkt verwendet werden müssen und wahrscheinlich gar nicht verwendet werden sollten. (Ein gutes Design wird stark entkoppelte Module haben, und Klassengruppen können nach Belieben durch neu geschriebene Ersetzungen ausgetauscht werden. Wenn dies für ein bestimmtes Modul nicht der Fall ist, ist es ein starker Codegeruch.)
Der einfache Ausweg besteht oft darin, einfach eine "Utility" -Klasse zu schreiben und all Ihre plattformspezifischen Dinge hineinzuwerfen. Es ist nicht "einfach und schmerzlos", aber sicherlich weniger schwer als Sie vielleicht denken.
Dies ist ein unglücklicher Irrtum. Zwar erfordert das Verwalten von Builds für mehrere Plattformen zusätzlichen Aufwand (beim Einrichten eines dedizierten täglichen Buildservers und beim Erlernen des Paketierens für eine bestimmte Distribution), Sie müssen sie jedoch nicht für "viele Distributionen" verwalten ]. " Ganz im Gegenteil. Sie müssen nur eine kleine Handvoll Pakete warten - beispielsweise Ubuntu, Fedora und einen einzelnen LSB-kompatiblen Tarball - und die verschiedenen Linux-Communities werden den Rest der Arbeit übernehmen. Besonders wenn Ihre Software beliebt ist, werden für jede Distribution HOWTOs erstellt, die die erforderlichen Setup-Anweisungen enthalten. Oder wenn Ihre Software frei verbreitet werden kann (was Sie tun können) können, wenn es sich nicht um ein freies Produkt handelt)Sofern Ihre Lizenz dies zulässt, verfügen die beliebtesten Distributionen über ein alternatives Repository, in dem Kopien Ihrer Software gespeichert sind.
Die Communities sind im Allgemeinen sehr gut darin, und erfahrene Benutzer werden bereitwillig eine Menge dieser Vorarbeiten für Sie erledigen, wenn Sie dies zulassen.
Ein weiteres unglückliches und sehr falsches Missverständnis.
Nur weil Linux-Benutzer ihr Betriebssystem kostenlos erhalten, heißt das nicht, dass sie nicht bereit sind, für Software zu bezahlen. Wenn die Software sehr gut ist und eine große Nachfrage besteht, sind Linux-Benutzer häufig eher bereit, sich von ihrem Geld zu trennen als Ihre Windows-Benutzer. Schauen Sie sich nur die Humble Indie Bundles an , bei denen Linux-Benutzer im Durchschnitt mehr als doppelt so viel bezahlt haben pro Benutzer wie Windows-Benutzer.
Es ist auch möglich, dass Ihr Produkt unter Linux-Benutzern eine größere Nachfrage hat als auf anderen Plattformen (die wir ohne Kenntnis Ihres Produkts nicht kennen), je nachdem, welche Art von vorhandener Software sich in diesem Bereich befindet. Möglicherweise haben Sie einen größeren potenziellen Markt als Sie denken.
quelle
Mit solchen Einstellungen würde ich sie einfach ignorieren. Sie klingen wie das Segment von X, in dem X alles sein kann , was sich beschwert, egal was Sie tun. Geben Sie eine Linux-Version frei oder nicht, Sie haben die Wahl, nicht ihre.
quelle
Wenn Sie für Nvidia arbeiten ...
Um Gottes willen, nimm es auf und schreibe schon ein paar anständige Fahrer.
Andernfalls sollten Sie bei normalen Geschäftsanwendungen darauf abzielen, dass zukünftige Projekte auf C # ausgeführt werden.
Mono ist vollständig kompatibel mit .NET 3.5 und kann sogar Winforms GUI verwenden. Die einzigen Module, auf die Sie achten müssen, sind die betriebssystemspezifischen, aber es gibt nur wenige.
quelle