Comment expliquer qu'écrire du code C ++ multi-plateforme universellement et expédier des produits pour tous les OS n'est pas si simple?

Notre société propose une gamme de produits de bureau pour Windows et de nombreux utilisateurs de Linux se plaignent sur les forums que nous aurions dû être des versions écrites de nos produits pour Linux il y a des années et la raison pour laquelle nous ne le faisons pas est

• nous sommes une entreprise gourmande
• tous nos spécialistes techniques sont des idiots sous-qualifiés

Notre produit moyen est d'environ 3 millions de lignes de code C ++.

Mon analyse et celle de mes collègues sont les suivantes:

• écrire du code C ++ multiplateforme n'est pas si simple
• préparer beaucoup de packages de distribution et les maintenir pour toutes les versions répandues de Linux prend du temps
• notre estimation est que le marché Linux représente environ 5 à 15% de tous les utilisateurs et ces utilisateurs ne voudront probablement pas payer nos efforts

quand cela est soulevé, la réponse est à nouveau que nous sommes des idiots sous-qualifiés avides et que lorsque tout est bien fait, tout cela est facile et indolore.

Dans quelle mesure nos évaluations du fait que l'écriture de code multiplateforme et la maintenance de nombreux packages de distribution nécessitent beaucoup d'efforts sont-elles raisonnables? Où pouvons-nous trouver une analyse simple mais détaillée avec des histoires de la vie réelle qui montrent sans l'ombre d'un doute quelle quantité d'effort cela prend exactement?

Gardez à l'esprit que la majorité des gens sont des employés et ne vivent donc pas dans un monde où ils doivent se soucier de faire des bénéfices. Ils se présentent au travail, font leur travail et rentrent chez eux, sans jamais vraiment penser au fonctionnement de l'ensemble du processus. Et bien que très intelligents, beaucoup de techniciens ignorent franchement les affaires et sont souvent aveuglés par le dogme.

Vous avez raison, bien sûr, fabriquer un logiciel x-platform de cette échelle n'est pas une chose simple. Surtout lorsque vous n'êtes pas une entreprise qui compte plusieurs dizaines de développeurs et des millions d'utilisateurs. Et ce ne sont pas seulement des limitations techniques. Tout est question de coûts et d'avantages. Oui, vous pourriez passer l'année prochaine à porter l'application sur Linux (malgré, comme vous le constatez, elle est déjà exécutable dans WINE). Bien sûr, cette année de développement n'est pas gratuite. Et à la fin, ça vous rapportera peut-être5 à 15% d'utilisateurs supplémentaires (selon votre estimation). Ou vous pouvez prendre le même argent / effort, et le concentrer dans votre développement Windows en tant que nouvelle version, ou tout mettre dans le marketing, et ajouter 50% à votre base d'utilisateurs. Qui ressemble au choix intelligent? (évidemment, les chiffres doivent être personnalisés pour votre entreprise, et le résultat final peut favoriser le portage).

Je ne sais pas si cela aidera à persuader les «vrais croyants», mais c'est le mouvement commercial intelligent. Et si vous ne faites pas de bonnes affaires, vous êtes en faillite. Et puis il n'y aura pas de version Linux à coup sûr.

Il y a deux choses à considérer ici, je pense:

La première est que, d'une certaine manière, ils ont raison. L'écriture multiplateforme C ++ n'est pas si difficile si vous l'aviez prévu depuis le début . C'est presque certainement le problème que vous voyez. La plupart des applications open source (la plupart des applications qu'un utilisateur Linux touche une journée moyenne), sont absurdement multiplateformes. Pensez au nombre d'applications avec lesquelles un utilisateur Linux moyen interagit quotidiennement et qui sont écrites en C ou C ++ et exécutées non seulement sur Windows et Linux, mais aussi sur MacOS, BSD, Solaris, etc. sur x86, x86-64, ARM, SPARC, etc. Ceci est en partie dû au fait que les gens qui ont envie de porter le code à exécuter sur leurs systèmes, mais aussi parce que la convention consiste à planifier la portabilité multiplateforme.

La deuxième chose est que le marché peut être plus viable que vous ne le pensez. Il y a une énorme idée fausse selon laquelle les gens sur Linux ne veulent pas payer pour un logiciel. Pour certaines personnes, cela peut être vrai, mais il y a beaucoup de gens (la plupart, je pense) qui utilisent Linux parce que cela fonctionne mieux pour eux et ils le préfèrent, pas en raison du prix. De plus, si votre entreprise produit un produit qui est utilisé principalement dans un cadre professionnel, les entreprises sont bien habituées à payer pour que les logiciels fonctionnent sur les systèmes Linux.

En ce qui concerne l'argument que vous faites à propos de l'empaquetage, comme d'autres l'ont dit, il vous suffit vraiment de produire des packages pour la dernière version des principales distributions. En fait, faire les paquets n'est pas si difficile que ça, et la plupart des principales distributions utilisent des paquets Debian (debian, ubuntu, etc.) ou des RPM (fedora, suse, centos, mandrake), il est donc très mineur de modifier certains scripts pour produire plusieurs packages à partir d'un fichier de base .deb et d'un fichier de base .rpm, et pour tout le monde, lancez simplement une archive tar avec des binaires et un fichier Lisezmoi, les gens trouveront comment l'installer. Alternativement, vous pouvez ignorer tous les packages, et poster simplement un tarball unique avec un script bash ou perl pour faire l'installation.

Quant à savoir comment adresser les utilisateurs sur vos forums pour se plaindre, comme l'a dit Joe Internet, ils pourraient simplement être le pourcentage de personnes qui vont se plaindre quoi qu'il arrive, mais la première chose que je ferais est d'essayer d'expliquer que vous avez un grande quantité de code hérité qui n'a pas été conçu avec un support multiplateforme à l'esprit. Deuxièmement, voyez honnêtement si cela apporterait un soutien financier pour créer un port Linux, et soyez ouvert aux résultats. Enfin, si un port n'est pas financièrement réalisable, pensez à faire quelques travaux pour que le programme fonctionne bien avec WINE. WINE ne devrait pas être la première solution, mais il pourrait bien apaiser les personnes qui souhaitent simplement utiliser votre application sous Linux, et être un projet moins cher qu'un port complet. En fait, si vous ajoutez du code à la base de code WINE dans le cadre du projet, vous pouvez non seulement vous ouvrir à un nouveau marché,

Adobe, c'est toi?

Sérieusement, mettez en place une sorte de prime pour qu'ils puissent précommander les versions Linux. Si vous recevez suffisamment de commandes pour qu'un port en vaille la peine dans le temps, sinon remboursez-les et vous avez maintenant la preuve que pas assez de gens se soucient d'en faire la peine.

Si vous obtenez quelque chose, cependant, ciblez la dernière version d'Ubuntu LTS, RHEL, SLED, et peut-être fournir un tar.gz que les gens peuvent essayer de travailler s'ils veulent utiliser autre chose. Cela vous laisse 3 paquets à vous soucier et n'importe qui d'autre en sait probablement assez pour lancer la version tar.gz.

écrire du code C ++ multiplateforme n'est pas si simple

Bien au contraire. Lorsque vous planifiez un travail multiplateforme et fournissez des abstractions pour les API spécifiques à la plate-forme que vous utilisez, la grande majorité de votre code est déjà multiplateforme. Si vous utilisez déjà une bibliothèque populaire comme Boost ou Qt ou NSPR, vous êtes déjà très près d'avoir une construction multiplateforme fonctionnelle.

Le problème le plus souvent rencontré lors de la réalisation d'un port à la fin du cycle de développement est qu'il existe des portions importantes de code qui dépendent des API spécifiques à la plate-forme dans certaines parties du programme qui n'ont pas besoin de les utiliser directement et ne devraient probablement pas du tout. (Une bonne conception aura des modules fortement découplés, et des groupes de classes peuvent être échangés avec des remplacements réécrits à volonté. Si ce n'est pas le cas pour un module donné, c'est une forte odeur de code.)

La solution la plus simple consiste souvent à simplement écrire une classe "Utilitaire" et à y jeter tous vos éléments spécifiques à la plate-forme. Ce n'est pas «facile et indolore», mais certainement moins difficile que vous ne le pensez.

préparer beaucoup de packages de distribution et les maintenir pour toutes les versions répandues de Linux prend du temps

C'est une fausse idée malheureuse. S'il est vrai que la maintenance des builds pour plusieurs plates-formes nécessite des efforts supplémentaires (dans la configuration d'un serveur de build quotidien dédié et dans l'apprentissage du package pour une distribution particulière), il n'est pas vrai que vous devez les maintenir pour "beaucoup de distribution [s ]. " Bien au contraire. Vous n'avez besoin que de maintenir une petite poignée de packages - disons, peut-être, Ubuntu, Fedora et un seul tarball compatible LSB - et les différentes communautés Linux prendront le reste du travail. Surtout si votre logiciel est populaire, des HOWTO apparaissent pour chaque distribution, fournissant les instructions de configuration nécessaires. Ou, si votre logiciel peut être distribué librement (ce que vous pouvez faire même s'il ne s'agit pas d'un produit gratuit, à condition que votre licence le permette), les distributions les plus populaires auront une sorte de référentiel alternatif contenant des copies de votre logiciel.

Les communautés sont généralement très bonnes à ce sujet, et les utilisateurs expérimentés feront volontiers beaucoup de travail pour vous, si vous les laissez.

notre estimation est que le marché Linux représente environ 5 à 15% de tous les utilisateurs et ces utilisateurs ne voudront probablement pas payer nos efforts

Un autre malheureux, et très erronée idée fausse.

Ce n'est pas parce que les utilisateurs de Linux obtiennent leur système d'exploitation gratuitement qu'ils ne veulent pas payer pour le logiciel. Si le logiciel est très bon et qu'il y a une forte demande, les utilisateurs de Linux seront souvent plus disposés à se départir de leur argent que vos utilisateurs Windows. Il suffit de regarder les Humble Indie Bundles , où les utilisateurs Linux, en moyenne, ont payé plus du double par utilisateur par rapport aux utilisateurs Windows.

Il est également possible que votre produit ait une plus grande demande parmi les utilisateurs de Linux que sur d'autres plates-formes (que nous ne pouvons pas connaître sans connaître votre produit), en fonction du type de logiciel existant dans ce domaine. Vous pouvez avoir un marché potentiel plus grand que vous ne le pensez.

Avec des attitudes comme ça, je les ignorerais. Ils sonnent comme le segment de X, où X peut être n'importe quoi , qui se plaindra quoi que vous fassiez. Publier une version Linux ou non, c'est votre choix, pas le leur.

Si vous travaillez pour Nvidia ...

Pour l'amour de Dieu, aspirez-le et écrivez déjà des pilotes décents.

Sinon, si vous utilisez des applications métier normales, ciblez les futurs projets à exécuter sur C #.

Mono est entièrement compatible jusqu'à .NET 3.5 et peut même utiliser l'interface graphique de Winforms. Les seuls modules que vous devez surveiller sont ceux spécifiques au système d'exploitation, mais ils sont rares.