As desvantagens do software de código aberto

CyanogenMod está morto, morto pela empresa-mãe Cyanogen. A comunidade está tentando pegar as peças e criar um novo projeto, o LineageOS, baseado no código. Mas é um lembrete de que o software de código aberto não é todo o sol, arco-íris e estabilidade: na verdade, muitas vezes pode ser muito confuso.

Mesmo que um projeto seja de código aberto, ele nem sempre é responsivo à comunidade, muito menos um software confiável no qual você pode confiar. Os projetos variam: alguns são executados por um ou dois desenvolvedores como hobby, outros reúnem desenvolvedores pagos por muitas corporações gigantescas, enquanto outros são dirigidos por uma única empresa controladora. Cada situação tem seus próprios problemas e drama.

Nós amamos o software de código aberto - não nos leve a mal - mas apresenta um certo número de desafios. Vamos dar uma olhada em alguns.

Open Source frequentemente sofre atrasos e um ritmo de desenvolvimento glacial

Muitos projetos de código aberto parecem sofrer um ritmo lento de desenvolvimento, onde novas versões são interminavelmente atrasadas, novos recursos vêm lentamente, se é que há, e é difícil priorizar recursos difíceis, mas importantes.

Basta olhar para as tentativas do Ubuntu de lançar seu desktop Unity 8 e o servidor de exibição Mir, permitindo sua visão de “convergência”. Esta nova versão do desktop Linux deveria estar estável há muitos anos e ainda não está. O projeto mudou a um ritmo glacial, tanto que a Canonical foi superada pela Microsoft, que anunciou sua própria visão de PC-powered-by-smartphone antes do Windows 10 e entregou nele. A Canonical ainda não entregou sua visão há muito prometida. Talvez seja estável em mais alguns anos.

A Mozilla também teve alguma dificuldade em priorizar. Eles ainda não entregaram recursos multi-processo e sandbox no Firefox. Eles são essenciais para manter o navegador seguro, impedir que os acessos abatem todo o navegador e utilizem melhor as CPUs de vários processos. Todos os outros principais navegadores forneceram esses recursos, incluindo o odiado Internet Explorer. A Mozilla criou o projeto “Eletrólise” para adicionar esses recursos, mas parou em 2011 porque era muito difícil. A Mozilla teve que reiniciá-lo em 2013. Esse recurso deve chegar em 2017 - o que é realmente muito tarde. Nesse meio tempo, a Mozilla perdeu tempo trabalhando no Firefox OS, um sistema operacional de smartphone com falha.

Quando um projeto usa tantos desenvolvedores voluntários, pode ter dificuldade em encontrar pessoas que façam o trabalho duro que não é divertido de se fazer..

Drama Interno Cria Garfos, Garfos e Mais Garfos

O código fonte de um projeto de código aberto está disponível para qualquer um mudar. Essa é a questão! Se um projeto de código aberto muda de uma forma que você não gosta, então você ou a comunidade - pode pegar o código-fonte antigo e continuar trabalhando nele como um novo projeto. Mas os projetos comunitários são tão envolvidos em dramas internos que fazem as coisas se dividirem em múltiplos projetos, confundindo e alienando usuários..

Por exemplo, quando o GNOME 3 foi lançado e muitos usuários do GNOME 2 não ficaram felizes, não havia um caminho óbvio imediato. Os desenvolvedores tiveram que desembolsar o código do GNOME em outros projetos como o MATE e o Cinnamon. Um ambiente de área de trabalho se transformou em três e os recursos de desenvolvimento estão mais dispersos entre os projetos. Como resultado, levou algum tempo para a comunidade fazer com que esses novos projetos fossem lançados..

Da mesma forma, a comunidade OpenOffice não ficou feliz quando a Oracle adquiriu a Sun. A Oracle chegou a renomear brevemente seu pacote de escritório proprietário e não de código aberto, o StarOffice para “Oracle Open Office”. A comunidade teve que criar um novo fork, o LibreOffice, baseado no código do OpenOffice. Tornou-se a suíte de escritório de código aberto para muitas pessoas, mas outras ainda usam o OpenOffice porque não estão cientes do melhor fork e do drama que o envolve. O OpenOffice tem um monte de reconhecimento de nome.

E, claro, há o CyanogenMod. A Cyanogen Inc acaba de desconectar os serviços on-line do CyanogenMod - o que significa que eles preferem matar o Android ROM de terceiros mais popular do que entregá-lo à comunidade, forçando a comunidade a criar um novo fork do CyanogenMod chamado LineageOS. Por que a Cyanogen não entrega o projeto CyanogenMod para a comunidade? A resposta parece ser drama interno (você está vendo um padrão aqui?). A Cyanogen foi a empresa cujo CEO prometeu “colocar uma bala na cabeça do Google”, afinal de contas. Acabou colocando uma bala na cabeça do CyanogenMod,.

Isso tudo acaba prejudicando os usuários da CyanogenMod, que receberam muito pouca atenção antes que os servidores e serviços da CyanogenMod fossem desligados. Os telefones continuarão funcionando, mas atualizações convenientes e outros serviços estão em alta quase instantaneamente. Os usuários só precisam esperar que o projeto LineageOS se torne rapidamente um substituto.

Nem todos os projetos de código aberto são orientados pela comunidade

Projetos de código aberto nem sempre são conduzidos pela comunidade. Dizer que um programa é open source significa apenas que o código está disponível para fazer o que você gosta. A empresa que desenvolve o software não precisa necessariamente executá-lo como um projeto comunitário, ou pode ter interesse em usar o projeto para promover seu outro software..

O CyanogenMod é um bom exemplo disso. Quando a Cyanogen Inc. surgiu, eles não se importavam com o CyanogenMod. O novo objetivo da Cyanogen tornou-se a comercialização da plataforma Cyanogen Modular OS para os fabricantes, negociando o grande reconhecimento do CyanogenMod após o assassinato do projeto. Talvez seja apenas onde o dinheiro é.

A Oracle nunca se importou com o OpenOffice, mas inicialmente queria usar seu nome para impulsionar as vendas de sua suíte de escritório proprietária do StarOffice marcando-a com o nome “Open Office”. Em seguida, doou o projeto para o Apache depois que a maioria dos desenvolvedores voluntários.

O Google também não se importa com o Android como um projeto de código aberto completo, e é por isso que mais e mais partes do “Android Open Source Project” (ou “AOSP”) estão sendo deixadas para trás. O Google quer manter o Android aberto, por isso é fácil para os fabricantes personalizarem, mas os aplicativos de código aberto, como o teclado e o discador, estão se tornando cada vez mais desatualizados. Em um dispositivo Android de consumo, o Google apenas inclui seu próprio teclado de código fechado, discador e outros aplicativos. O Google parece comprometido com um núcleo de código aberto Android, mas não com todo o sistema operacional de código aberto que as pessoas podem usar sem o software e os serviços do Google. Afinal, melhorar o Android Open Source Project apenas ajuda o Amazon Fire OS, um concorrente dos dispositivos Android do Google. Qual é o sentido disso?

Open Source pode faltar mão de obra séria, apesar de ser usado por milhões

Se um projeto é de código aberto, qualquer um pode usá-lo sem contribuir, mesmo com grandes empresas. Isso leva a problemas quando um projeto importante e amplamente utilizado tem uma grave falta de mão-de-obra e fundos.

Vimos os resultados disso com a brecha de segurança do Heartbleed em 2014. O Heartbleed explorou uma vulnerabilidade no OpenSSL. O OpenSSL é uma importante biblioteca de criptografia usada por muitas empresas de tecnologia gigantes e centenas de milhares de servidores web. Mas tinha apenas um funcionário em tempo integral sem emprego externo e US $ 2000 por ano em doações. O projeto recebeu dinheiro adicional de contratos de suporte comercial e consultoria, mas apenas um único funcionário em tempo integral parece chocantemente baixo para uma peça crítica de infraestrutura usada por corporações multibilionárias como o Google e o Facebook..

A Heartbleed chamou a atenção para o quanto essa peça crítica de software era insuficiente, de modo que grandes empresas de tecnologia se comprometeram a gastar dinheiro todos os anos para financiar o desenvolvimento do OpenSSL e de outros projetos importantes como parte da "Iniciativa de Infraestrutura Básica"..

Há um bom resultado para essa história em particular, com certeza - mas apenas porque muita atenção foi atraída para ela. Quando você confia em um projeto de código aberto para habilitar sua infraestrutura, é fácil acabar dependendo dele e assumir que alguém o mantém bem o suficiente. Que outro importante projeto de código aberto está criticamente subfinanciado? Podemos não notar até que haja outro grande problema.

Crédito de imagem: snoopsmaus