CyanogenMod está morto , morto pela empresa-mãe Cyanogen. A comunidade está tentando juntar as peças e criar um novo projeto, LineageOS, baseado no código. Mas é um lembrete de que o software de código aberto não é só luz do sol, arco-íris e estabilidade: na verdade, muitas vezes pode ser muito confuso.
Mesmo que um projeto seja de código aberto, ele não é necessariamente responsivo à comunidade, muito menos um software confiável do qual você pode confiar. Os projetos variam: alguns são executados por um ou dois desenvolvedores como um hobby, outros reúnem desenvolvedores pagos por muitas grandes corporações, enquanto outros são conduzidos por uma única empresa controladora. Cada situação tem seus próprios problemas e dramas.
Amamos software de código aberto – não nos leve a mal – mas ele apresenta um certo número de desafios. Vamos dar uma olhada em alguns.
Índice
O código-fonte aberto costuma sofrer atrasos e um ritmo de desenvolvimento glacial
Muitos projetos de código aberto parecem sofrer com um ritmo de desenvolvimento lento, onde novas versões são infinitamente atrasadas, novos recursos vêm lentamente, se nunca, e é difícil priorizar recursos difíceis, mas importantes.
Basta olhar para as tentativas do Ubuntu de lançar seu desktop Unity 8 e servidor de exibição Mir, permitindo sua visão de “convergência”. Essa nova versão do desktop Linux deveria ser estável há muitos anos, e ainda não é. O projeto avançou em um ritmo glacial, tanto que a Canonical foi derrotada pela Microsoft, que anunciou sua própria visão movida a PC por smartphone antes do Windows 10 – e entregou nele. A Canonical ainda não entregou sua visão há muito prometida. Talvez fique estável em mais alguns anos.
A Mozilla também teve alguma dificuldade em priorizar. Eles ainda não entregaram recursos de multiprocessos e sandbox no Firefox. Eles são essenciais para manter o navegador seguro, evitar travamentos que derrubem todo o navegador e utilizar melhor as CPUs de vários processos. Todos os outros navegadores principais forneceram esses recursos, incluindo o odiado Internet Explorer. A Mozilla criou o projeto “Eletrólise” para adicionar esses recursos, mas o interrompeu em 2011 porque era muito difícil. A Mozilla então teve que reiniciá-lo em 2013. Esse recurso parece prestes a chegar em 2017 – o que é muito, muito tarde. Nesse ínterim, a Mozilla perdeu tempo trabalhando no Firefox OS, um sistema operacional para smartphones que falhou.
Quando um projeto usa tantos desenvolvedores voluntários, pode ter dificuldade em encontrar as pessoas para fazer o trabalho árduo que não é divertido de fazer.
Drama interno gera garfos, garfos e mais garfos
O código-fonte de um projeto de código aberto está disponível para qualquer pessoa alterar. Essa é a questão! Se um projeto de código aberto muda de uma maneira 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 costumam estar tão envolvidos em um drama interno que fazem com que as coisas se dividam em vários projetos, confundindo e alienando os 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 distribuir o código GNOME em outros projetos como MATE e Cinnamon. Um ambiente de desktop se transformou em três, e os recursos de desenvolvimento são mais dispersos entre os projetos. Como resultado, demorou algum tempo para a comunidade iniciar 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, de código-fonte aberto, StarOffice, para “Oracle Open Office”. A comunidade teve que criar um novo fork, o LibreOffice , baseado no código do OpenOffice. Ele se tornou o pacote de escritório de código aberto de fato para muitas pessoas, mas outras ainda usam o OpenOffice porque não estão cientes da melhor bifurcação e do drama que o cerca. O OpenOffice simplesmente tem muito reconhecimento de nome construído.
E, claro, há CyanogenMod. A Cyanogen Inc acabou de desligar os serviços online do CyanogenMod – o que significa que eles preferem matar a ROM Android de terceiros mais popular do que entregá-la à comunidade, em vez de forçar a comunidade a criar um novo fork do CyanogenMod chamado LineageOS. Por que a Cyanogen simplesmente 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 que iria “enfiar uma bala na cabeça do Google”, afinal. Em vez disso, acabou colocando uma bala na cabeça do CyanogenMod.
Isso tudo acaba prejudicando os usuários do CyanogenMod, que receberam muito pouco aviso antes que os servidores e serviços do CyanogenMod fossem encerrados. Os telefones continuarão funcionando, mas as atualizações convenientes e outros serviços desaparecerão quase da noite para o dia. 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 baseados na comunidade
Projetos de código aberto nem sempre são conduzidos pela comunidade. Dizer que um programa é de código aberto significa apenas que o código está disponível para fazer o que você quiser. 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.
CyanogenMod é um bom exemplo disso. Depois que a Cyanogen Inc. surgiu, eles não se importaram muito com o CyanogenMod. O novo objetivo da Cyanogen passou a ser comercializar a plataforma Cyanogen Modular OS para os fabricantes, negociando com o grande reconhecimento do CyanogenMod após encerrar o projeto. Talvez seja aí que está o dinheiro.
A Oracle nunca se preocupou com o OpenOffice, mas inicialmente queria usar seu nome para impulsionar as vendas de sua suíte de escritório proprietária StarOffice, marcando-o com o nome “Open Office”. Em seguida, doou o projeto ao Apache após a maioria dos desenvolvedores voluntários partirem.
O Google também não se preocupa muito 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 que seja fácil para os fabricantes personalizá-lo, mas os aplicativos de código aberto, como teclado e discador, estão cada vez mais desatualizados. Em um dispositivo consumidor Android, o Google apenas empacota seu próprio teclado de código fechado, discador e outros aplicativos. O Google parece comprometido com um núcleo de código aberto do Android, mas não um sistema operacional de código aberto inteiro que as pessoas possam usar sem o software e os serviços do Google. Afinal, melhorar o Android Open Source Project apenas ajuda o Fire OS da Amazon , um concorrente dos dispositivos Android do Google. Qual é o objetivo disso?
Código aberto pode carecer de mão de obra séria, apesar de ser usado por milhões
Se um projeto for de código aberto, qualquer pessoa pode usá-lo sem contribuir – até mesmo grandes empresas. Isso leva a problemas quando um projeto importante e amplamente utilizado apresenta uma grave falta de mão de obra e fundos.
Vimos os resultados disso com a falha de segurança Heartbleed em 2014. Heartbleed explorou uma vulnerabilidade no OpenSSL. 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 $ 2.000 por ano em doações . O projeto conseguiu 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 Google e Facebook.
Heartbleed drew attention to just how underfunded this critical piece of software was, so big tech companies committed to chipping in money every year to fund the development of OpenSSL and other important projects as part of the “Core Infrastructure Initiative“.
There’s a good outcome to this particular story, sure—but only because so much attention was drawn to it. When you rely on an open source project to enable your infrastructure, it’s easy to end up depending on it and assume someone else is maintaining it well enough. What other important open-source project is critically underfunded? We may not notice until there’s another big problem.
Image Credit: snoopsmaus
