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.
Adoramos 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
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 ser estável há muitos anos, e ainda não é. 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 entregue nele. A Canonical ainda não entregou sua visão há muito prometida. Talvez seja estável daqui a alguns anos.
A Mozilla também teve alguma dificuldade em priorizar. Eles ainda não entregaram recursos de vários processos 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 ser difícil encontrar pessoas que façam o trabalho difícil que não é divertido.
Drama Interno Cria Garfos, Garfos e Mais Garfos
Por exemplo, quando o GNOME 3 foi lançado e muitos usuários do GNOME 2 não estavam 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 conseguir esses novos projetos.
Da mesma forma, a comunidade OpenOffice não ficou feliz quando a Oracle adquiriu a Sun. A Oracle até mesmo renomeou 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 acabou de desconectar os serviços on-line da 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 o Cyanogen não entrega o projeto CyanogenMod para a comunidade? A resposta parece ser um 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 pouco aviso 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 sendo consumidos durante a noite. 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
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 nome da CyanogenMod depois de matar o projeto. Talvez seja exatamente onde está 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 saiu.
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 para facilitar a personalização dos fabricantes, 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?
Código aberto pode não ter mão de obra séria, apesar de ser usado por milhões
Vimos os resultados disso com a falha 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 gigantes de tecnologia 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ê conta com um projeto de código aberto para ativar sua infraestrutura, é fácil acabar dependendo dele e assumir que outra pessoa o mantém bem o suficiente. Que outro importante projeto de código aberto está criticamente subfinanciado? Podemos não perceber até que haja outro grande problema.
