¿Cómo explicar que escribir código C ++ universalmente multiplataforma y enviar productos para todos los sistemas operativos no es tan fácil?

Nuestra compañía envía una gama de productos de escritorio para Windows y muchos usuarios de Linux se quejan en foros de que deberíamos haber sido versiones escritas de nuestros productos para Linux hace años y la razón por la que no lo hacemos es

• somos una corporación codiciosa
• todos nuestros especialistas técnicos son idiotas subcalificados

Nuestro producto promedio es algo así como 3 millones de líneas de código C ++.

El análisis de mi y mis colegas es el siguiente:

• escribir código C ++ multiplataforma no es tan fácil
• preparar muchos paquetes de distribución y mantenerlos para todas las versiones extendidas de Linux lleva tiempo
• nuestra estimación es que el mercado de Linux es algo así como el 5-15% de todos los usuarios y es probable que esos usuarios no quieran pagar por nuestro esfuerzo

Cuando se menciona esto, la respuesta es nuevamente que somos idiotas codiciosos y poco calificados y que cuando todo se hace bien, todo esto es fácil e indoloro.

¿Cuán razonables son nuestras evaluaciones del hecho de que escribir código multiplataforma y mantener numerosos paquetes de distribución requiere mucho esfuerzo? ¿Dónde podemos encontrar un análisis fácil pero detallado con historias de la vida real que muestren más allá de la duda qué cantidad de esfuerzo requiere exactamente?

Tenga en cuenta que la mayoría de las personas son empleados y, por lo tanto, no viven en un mundo donde deben preocuparse por obtener ganancias. Aparecen en el trabajo, hacen lo suyo y se van a casa, sin pensar realmente en cómo funciona todo el proceso. Y aunque son muy inteligentes, muchos tecnólogos ignoran positivamente los negocios y, a menudo, están cegados por el dogma.

Tiene razón, por supuesto, hacer que el software de la plataforma x de esa escala no sea algo simple. Particularmente cuando no eres una empresa que tiene muchas docenas de desarrolladores y millones de usuarios. Y no se trata solo de limitaciones técnicas. Se trata de costo vs beneficio. Sí, podría pasar el próximo año portando la aplicación a Linux (a pesar de que, como notará, ya es ejecutable en WINE). Por supuesto, ese año de tiempo de desarrollo no es gratis. Y al final, te ganará tal vezun 5-15% de usuarios adicionales (según su estimación). O puede tomar el mismo dinero / esfuerzo y enfocarlo en su desarrollo de Windows como una nueva versión, o ponerlo todo en marketing y agregar un 50% a su base de usuarios. ¿Cuál suena como la elección inteligente? (obviamente, los números deben personalizarse para su empresa, y el resultado final puede favorecer la transferencia).

No sé si eso ayudará a persuadir a los "verdaderos creyentes", pero es el movimiento comercial inteligente. Y si no hace movimientos inteligentes de negocios, está fuera del negocio. Y luego no habrá una versión de Linux con seguridad.

Hay dos cosas a considerar aquí, creo:

La primera es que, en cierto modo, tienen razón. Escribir multiplataforma C ++ no es tan difícil si lo planeaste desde el principio . Este es casi seguramente el problema que estás viendo. La mayoría de las aplicaciones de código abierto (la mayoría de las aplicaciones que un usuario de Linux toca en un día promedio) son absurdamente multiplataforma. Piense en la cantidad de aplicaciones con las que el usuario promedio de Linux interactúa diariamente que están escritas en C o C ++ y se ejecutan no solo en Windows y Linux, sino también en MacOS, BSD, Solaris, etc. en x86, x86-64, ARM, SPARC, Esto se debe en parte a que las personas con ganas de rascar portan el código para que se ejecute en sus sistemas, pero también porque la convención es planificar la portabilidad multiplataforma.

Lo segundo es que el mercado puede ser más viable de lo que piensas. Existe una gran idea errónea de que las personas en Linux no quieren pagar por el software. Para algunas personas eso puede ser cierto, pero hay muchas personas (la mayoría, creo) que usan Linux porque les funciona mejor y lo prefieren, no por el precio. Además, si su empresa está produciendo un producto que se utiliza principalmente en un entorno profesional, las empresas están acostumbradas a pagar por el software que se ejecuta en sistemas Linux.

En cuanto al punto que señala sobre el empaque, como han dicho otros, realmente solo necesita producir paquetes para la última versión de las principales distribuciones. En realidad, hacer los paquetes no es realmente tan difícil, y la mayoría de las distribuciones principales usan paquetes debian (debian, ubuntu, etc.) o RPM (fedora, suse, centos, mandrake), por lo que es muy pequeño modificar algunos scripts para producir múltiples paquetes a partir de una línea de base .deb y una línea de base .rpm, y para todos los demás simplemente lanzar un tarball con binarios y un archivo Léame, la gente descubrirá cómo instalarlo. Alternativamente, puede omitir todos los paquetes y simplemente publicar un tarball único con un script bash o perl para realizar la instalación.

En cuanto a cómo dirigirse a los usuarios en sus foros quejándose, como dijo Joe Internet, podrían ser el porcentaje de personas que se quejarán sin importar qué, pero lo primero que haré es tratar de explicar que usted tiene un gran cantidad de código heredado que no fue diseñado teniendo en cuenta el soporte multiplataforma. En segundo lugar, honestamente vea si sería un apoyo financiero para hacer un puerto Linux, y sea abierto con los resultados de eso. Finalmente, si un puerto no es financieramente factible, vea cómo hacer un trabajo para que el programa funcione bien con WINE. WINE no debería ser la primera solución, pero podría calmar a las personas que solo quieren usar su aplicación en Linux y ser un proyecto menos costoso que un puerto completo. De hecho, si agrega código a la base de código WINE como parte del proyecto, entonces no solo podría abrirse a un nuevo mercado,

Adobe, ¿eres tú?

En serio, ofrezca algún tipo de recompensa para que puedan reservar versiones de Linux. Si recibe suficientes pedidos para hacer que un puerto valga la pena ponerlo en el tiempo, de lo contrario, reembolsarlos y ahora tiene pruebas de que a la gente no le importa que valga la pena.

Sin embargo, si obtiene algo portado, solo diríjase a la última versión de Ubuntu LTS, RHEL, SLED, y tal vez proporcione un tar.gz, las personas pueden intentar ponerse a trabajar si quieren usar otra cosa. Eso te deja con 3 paquetes de los que preocuparte y cualquier otra persona probablemente sepa lo suficiente como para que funcione la versión tar.gz.

escribir código C ++ multiplataforma no es tan fácil

Todo lo contrario. Cuando planifica el trabajo multiplataforma y proporciona abstracciones para las API específicas de la plataforma que utiliza, la gran mayoría de su código ya es multiplataforma. Si ya está utilizando una biblioteca popular como Boost o Qt o NSPR, ya está muy cerca de tener una compilación multiplataforma que funcione.

El problema más comúnmente experimentado cuando se realiza un puerto al final del ciclo de desarrollo es que hay porciones significativas de código que dependen de API específicas de la plataforma en partes del programa que no necesitan usarlas directamente y probablemente no deberían hacerlo. (Un buen diseño tendrá módulos fuertemente desacoplados, y los grupos de clases pueden intercambiarse con reemplazos reescritos a voluntad. Si este no es el caso para un módulo dado, es un fuerte olor a código).

La salida fácil es a menudo escribir una clase de "Utilidad" y tirar todas las cosas específicas de su plataforma allí. No es "fácil e indoloro", pero ciertamente es menos difícil de lo que piensas.

preparar muchos paquetes de distribución y mantenerlos para todas las versiones extendidas de Linux lleva tiempo

Este es un concepto erróneo desafortunado. Si bien es cierto que mantener compilaciones para múltiples plataformas requiere un esfuerzo adicional (para configurar un servidor de compilación diario dedicado y aprender a empaquetar para una distribución en particular), no es cierto que necesite mantenerlas para "mucha distribución [s ] ". Todo lo contrario. Solo necesita mantener un pequeño puñado de paquetes, por ejemplo, Ubuntu, Fedora y un único tarball compatible con LSB, y las diversas comunidades de Linux se encargarán del resto del trabajo. Especialmente si su software es popular, los CÓMO surgirán para cada distribución, proporcionando las instrucciones de configuración necesarias. O, si su software se puede distribuir libremente (lo que puede hacer incluso si no es un producto gratuito), siempre que su licencia lo permita), las distribuciones más populares tendrán algún tipo de repositorio alternativo con copias de su software.

Las comunidades generalmente son muy buenas con respecto a esto, y los usuarios experimentados estarán dispuestos a hacer mucho de este trabajo por usted, si usted lo permite.

nuestra estimación es que el mercado de Linux es algo así como el 5-15% de todos los usuarios y es probable que esos usuarios no quieran pagar por nuestro esfuerzo

Otro concepto erróneo desafortunado y muy equivocado .

El hecho de que los usuarios de Linux obtengan su sistema operativo de forma gratuita no significa que no estén dispuestos a pagar por el software. Si el software es muy bueno y existe una gran demanda, los usuarios de Linux a menudo estarán más dispuestos a desprenderse de su dinero que sus usuarios de Windows. Solo mire los Humble Indie Bundles , donde los usuarios de Linux, en promedio, pagaron más del doble por usuario en comparación con los usuarios de Windows.

También es posible que su producto tenga una mayor demanda entre los usuarios de Linux que en otras plataformas (que no podemos saber sin conocer su producto), dependiendo de qué tipo de software existente haya en ese ámbito. Es posible que tenga un mercado potencial más grande de lo que cree.

Con actitudes como esa, simplemente los ignoraría. Suenan como el segmento de X, donde X puede ser cualquier cosa , que se quejará sin importar lo que hagas. Lanza una versión de Linux o no, es tu elección, no la de ellos.

Si trabajas para Nvidia ...

Por el amor de Dios, aguanta y escribe algunos controladores decentes.

De lo contrario, si está haciendo aplicaciones comerciales regulares, apunte a proyectos futuros para ejecutar en C #.

Mono es totalmente compatible con .NET 3.5 e incluso puede usar winforms GUI. Los únicos módulos que debe tener en cuenta son los específicos del sistema operativo, pero son pocos y distantes entre sí.