A importância de padrões

Para pensar : lendo o blog do Ian Murdock, me deparei com um post curto de duas linhas (ou de uma única linha se você é louco o suficiente para usar fontes de tamanho oito) onde Ian cita um comentário de Mike Melanson, engenheiro líder da equipe que desenvolve o porte para Linux do Flash Player da Adobe.

Mike responde a pergunta de um jornalista da ZDNet sobre qual é a parte mais difícil no processo de desenvolvimento do Flash Player para Linux. Sua resposta, citada pelo Ian, foi :

“I would say the hardest part is selecting APIs that have broad coverage across distributions.”

Ou, em uma tradução livre :

“Eu diria que a parte mais difícil é selecionar APIs que possuam grande cobertura entre as distribuições.”

Estamos em uma posição bem diferente hoje em dia, com empresas desenvolvedoras de softwares comerciais bastante conhecidas querendo portar suas aplicações para Linux, situação bem diferente de alguns anos atrás, quando ainda éramos tratados como um bando de adolescentes malucos e drogados sem noção da realidade.

Porém, agora parece que temos mais um problema : padronização. Sim, porque nenhuma grande empresa desenvolvedora de software vai se dar ao trabalho de submeter sua equipe de desenvolvimento ao trabalho sujo de aprender inúmeras APIs diferentes para poder suportar diversas distribuições distintas.

Sou a favor de que cada distribuição deva ter sua própria identidade e ser livre para poder focar em seu público alvo específico ou seja lá no que quiser focar, afinal, liberdade é bom e eu gosto. Por isso, creio que seja praticamente impossível um mundo onde todas as distribuições GNU/Linux sejam 100% compatíveis. Essa á a razão de existirem inúmeras distribuições.

Mas também creio que deva sim existir um certo nível de compatibilidade, até certo ponto que permita que desenvolvedores de softwares comerciais que pretendam lançar versões de seus softwares para GNU/LInux consigam fazê-lo sem que sejam obrigados e ter um trabalho espetacularmente grande para fazer com que o mesmo funcione no maior número possível de distribuições.

Veja bem, eu não sou a favor de softwares comerciais, mas em alguns casos não adianta, você (ou seu cliente) precisa deles e não há como fugir. Nesses casos, é melhor rodar o software comercial em um sistema operacional livre do que optar por utilizar outro sistema operacional comercial e com isso ter todo o sofrimento e as desvantagens que já conhecemos.

Por isso, creio que a idéia do LSB seja importante, uma vez que a o objetivo é criar padrões comuns à todas as distribuições, mas não ao ponto de “desfigurá-las” e fazer com que existam milhares de clones de distribuições GNU/Linux por aí. Com isso, um fornecedor de software comercial pode homologar sua aplicação comercial para LSB e não para cada uma das inúmeras distribuições separadamente.

Sem algo como a LSB, com certeza a homologação para inúmeras distribuições não vai acontecer. E por razões óbvias : é muito caro manter equipes de homologação para cada distribuição, mesmo para somente as distribuições mais conhecidas.

E, como a homologação em massa não vai acontecer mesmo, o que acaba acontecendo na prática é que as empresas desenvolvedoras de softwares comerciais acabam criando parcerias com as empresas responsáveis pelo desenvolvimento de distribuições comerciais e homologando seus produtos somente para essas distribuições.

Nessa, distribuições comunitárias como Debian, Gentoo, Slackware e outras ficam de fora e não podem ser consideradas em nenhum projeto que envolva o uso de algum desses softwares comerciais. Além do motivo óbvio disso ser ruim, acredito que isso pode ser também ruim a longo prazo, pois acaba colocando distribuições comunitárias como uma opção de segundo nível ou sem importância.

A longo prazo, se esse problema persistir, podemos ter um mundo onde Linux = Red Hat Enterprise ou Linux = SuSE Enterprise (ou seja lá como essa distribuição é chamada hoje em dia). Devido a isso, todas as distribuições comunitárias deveriam sim apoiar o LSB e se tornarem compatíveis.

Um dos release goals do Etch, o codinome da próxima versão estável do Debian, é justamente compatibilidade com o padrão LSB 3.1. Logicamente, a versão estável atual do Debian, o Sarge, já é pelo menos parcialmente compatível com versões anteriores do padrão LSB.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s