Como explicar que escrever código C ++ de plataforma cruzada universalmente e enviar produtos para todos os sistemas operacionais não é fácil?

Nossa empresa envia uma variedade de produtos de desktop para Windows e muitos usuários de Linux reclamam nos fóruns de que deveríamos ter sido versões escritas de nossos produtos para Linux anos atrás e a razão pela qual não fazemos isso é

• somos uma corporação gananciosa
• todos os nossos especialistas técnicos são idiotas subqualificados

Nosso produto médio é algo como 3 milhões de linhas de código C ++.

Minha análise e meus colegas são os seguintes:

• escrever código C ++ multiplataforma não é tão fácil
• preparar muitos pacotes de distribuição e mantê-los para todas as versões difundidas do Linux leva tempo
• nossa estimativa é de que o mercado Linux seja algo entre 5 e 15% de todos os usuários e esses usuários provavelmente não quererão pagar por nosso esforço

quando isso é apresentado, a resposta é novamente que somos gananciosos idiotas subqualificados e que, quando tudo é feito corretamente, tudo isso é fácil e indolor.

Quão razoáveis ​​são nossas avaliações do fato de que escrever código de plataforma cruzada e manter vários pacotes de distribuição exige muito esforço? Onde podemos encontrar uma análise fácil, porém detalhada, com histórias da vida real que mostram além da sombra de uma dúvida quanto esforço é necessário?

Lembre-se de que a maioria das pessoas são funcionários e, portanto, não vive em um mundo em que precisa se preocupar em obter lucro. Eles aparecem no trabalho, fazem suas coisas e vão para casa, nunca pensando realmente em como todo o processo funciona. E, apesar de muito inteligentes, muitos técnicos ignoram positivamente os negócios e muitas vezes são cegados por dogmas.

Você está certo, é claro, criar software de plataforma x dessa escala não é uma coisa simples. Especialmente quando você não é uma empresa que possui muitas dezenas de desenvolvedores e milhões de usuários. E não são apenas limitações técnicas. É tudo sobre custo versus benefício. Sim, você pode passar o próximo ano portando o aplicativo no Linux (apesar de, como você notar, já estar rodável no WINE). Obviamente, esse ano de tempo de desenvolvimento não é gratuito. E, no final, você renderá talvez5-15% de usuários adicionais (com base na sua estimativa). Ou você pode pegar o mesmo dinheiro / esforço e concentrá-lo no desenvolvimento do Windows como uma nova versão ou colocar tudo no marketing e adicionar 50% à sua base de usuários. O que soa como a escolha inteligente? (obviamente, os números precisam ser personalizados para sua empresa, e o resultado final pode favorecer a transferência).

Não sei se isso ajudará a convencer 'verdadeiros crentes', mas é o movimento dos negócios inteligentes. E se você não fizer movimentos comerciais inteligentes, estará fora do negócio. E então não haverá uma versão do Linux, com certeza.

Há duas coisas a considerar aqui, eu acho:

A primeira é que, de certa forma, eles estão certos. Escrever C ++ entre plataformas não é tão difícil se você planejou isso desde o início . Este é quase certamente o problema que você está vendo. A maioria dos aplicativos de código aberto (a maioria dos aplicativos que um usuário Linux toca em um dia comum) são absurdamente multiplataforma. Pense no número de aplicativos com os quais o usuário comum do Linux interage diariamente, escritos em C ou C ++ e executa não apenas no Windows e Linux, mas também em MacOS, BSD, Solaris etc. em x86, x86-64, ARM, SPARC, etc. Isso ocorre em parte porque as pessoas com vontade de arranhar a porta codificam o código para execução em seus sistemas, mas também porque a convenção é planejar a portabilidade entre plataformas.

A segunda coisa é que o mercado pode ser mais viável do que você pensa. Há um enorme equívoco de que as pessoas no Linux não querem pagar por software. Para algumas pessoas, isso pode ser verdade, mas há muitas pessoas (a maioria, eu acho) que usam o Linux porque funciona melhor para elas e elas preferem, não por preço. Além disso, se sua empresa estiver produzindo um produto usado principalmente em um ambiente profissional, as empresas estão acostumadas a pagar pelo software para executar nos sistemas Linux.

Quanto ao ponto que você enfatiza sobre embalagem, como outros já disseram, você realmente só precisa produzir pacotes para a versão mais recente das principais distribuições. Na verdade, criar os pacotes não é tão difícil assim, e a maioria das principais distribuições usa pacotes debian (debian, ubuntu etc.) ou RPMs (fedora, suse, centos, mandrake), por isso é muito pequeno modificar alguns scripts para produzir vários pacotes a partir de uma linha de base .deb e uma linha de base .rpm, e para todos os outros simplesmente jogar um tarball com binários e um leia-me, as pessoas descobrirão como instalá-lo. Como alternativa, você pode pular todas as embalagens e apenas postar um único tarball com um script bash ou perl para fazer a instalação.

Quanto a como abordar os usuários nos seus fóruns reclamando, como Joe Internet disse, eles podem ser apenas a porcentagem de pessoas que vão reclamar, não importa o quê, mas a primeira coisa que eu faria é tentar explicar que você tem um grande quantidade de código legado que não foi projetado com o suporte a várias plataformas. Segundo, veja honestamente se daria apoio financeiro para criar uma porta Linux e se abra com os resultados disso. Por fim, se uma porta não for financeiramente viável, tente fazer algum trabalho para que o programa funcione bem com o WINE. O WINE não deve ser a primeira solução, mas pode atenuar as pessoas que desejam apenas usar seu aplicativo no Linux e ser um projeto mais barato que uma porta completa. De fato, se você adicionar código à base de código WINE como parte do projeto, não apenas poderá se abrir para um novo mercado,

Adobe, é você?

Sério, coloque algum tipo de recompensa para que eles possam encomendar versões do Linux. Se você receber pedidos suficientes para fazer com que uma porta valha a pena no tempo, devolva-a e agora você tem a prova de que não há pessoas suficientes para fazer valer a pena.

Se você receber algo portado, basta direcionar a versão mais recente do Ubuntu LTS, RHEL, SLED, e talvez fornecer um tar.gz para as pessoas tentarem trabalhar se quiserem usar outra coisa. Isso deixa você com 3 pacotes com os quais se preocupar e provavelmente qualquer outra pessoa sabe o suficiente para obter a versão tar.gz.

escrever código C ++ multiplataforma não é tão fácil

Pelo contrário. Quando você planeja o trabalho entre plataformas e fornece abstrações para as APIs específicas da plataforma que usa, a grande maioria do seu código já é entre plataformas. Se você já está usando uma biblioteca popular como Boost, Qt ou NSPR, já está muito perto de ter uma compilação de plataforma cruzada.

O problema mais comum ao executar uma porta no final do ciclo de desenvolvimento é que existem partes significativas do código que dependem de APIs específicas da plataforma em partes do programa que não precisam usá-las diretamente e provavelmente não deveriam. (Um bom design terá módulos fortemente dissociados e grupos de classes podem ser trocados com substituições reescritas à vontade. Se esse não for o caso de um determinado módulo, é um forte cheiro de código.)

O caminho mais fácil é escrever apenas uma classe "Utilitário" e lançar todas as suas coisas específicas da plataforma. Não é "fácil e indolor", mas certamente menos difícil do que você imagina.

preparar muitos pacotes de distribuição e mantê-los para todas as versões difundidas do Linux leva tempo

Este é um equívoco infeliz. Embora seja verdade que a manutenção de compilações para várias plataformas exija esforço adicional (na configuração de um servidor de compilação diário dedicado e em aprender a empacotar uma distribuição específica), não é verdade que você precise mantê-las para "muitas distribuições [s ]. " Pelo contrário. Você precisa apenas manter um pequeno punhado de pacotes - digamos, Ubuntu, Fedora e um único tarball compatível com LSB - e as várias comunidades Linux farão o resto do trabalho. Especialmente se o seu software for popular, os HOWTOs surgirão para todas as distribuições, fornecendo as instruções de configuração necessárias. Ou, se o seu software puder ser distribuído livremente (o que você pode fazer mesmo que não seja um produto gratuito, desde que seu licenciamento permita), as distribuições mais populares terão algum tipo de repositório alternativo carregando cópias do seu software.

As comunidades geralmente são muito boas sobre isso, e usuários experientes farão muito desse trabalho árduo por você, se você permitir.

nossa estimativa é de que o mercado Linux seja algo entre 5 e 15% de todos os usuários e esses usuários provavelmente não quererão pagar por nosso esforço

Outro equívoco infeliz e muito equivocado .

Só porque os usuários do Linux obtêm seu sistema operacional gratuitamente, não significa que não estejam dispostos a pagar pelo software. Se o software for muito bom e houver uma grande demanda por ele, os usuários do Linux geralmente estarão mais dispostos a gastar com seu dinheiro do que os usuários do Windows. Basta olhar para os Humble Indie Bundles , onde os usuários do Linux, em média, pagam mais do que o dobro por usuário em comparação aos usuários do Windows.

Também é possível que seu produto tenha uma demanda maior entre os usuários de Linux do que em outras plataformas (o que não podemos saber sem conhecer seu produto), dependendo de que tipos de software existentes existem nessa arena. Você pode ter um mercado potencial maior do que imagina.

Com atitudes assim, eu simplesmente as ignorava. Soam como o segmento de X, onde X pode ser qualquer coisa , que reclamará, não importa o que você faça. Lance uma versão do Linux ou não, a escolha é sua, não deles.

Se você trabalha para a Nvidia ...

Pelo amor de Deus, aproveite e escreva alguns drivers decentes.

Caso contrário, se você estiver executando aplicativos de negócios regulares, direcione futuros projetos para execução em C #.

O Mono é totalmente compatível com o .NET 3.5 e pode até usar a GUI do winforms. Os únicos módulos que você precisa observar são os específicos do sistema operacional, mas são poucos e distantes entre si.