Lá e de Volta

Num post anterior falei de quatro problemas do software livre. Inerentes a eles está o aspecto social do desenvolvimento de qualquer software, e principalmente de sistemas de informação. Muitas pessoas ainda não se dão conta que todas as etapas de desenvolvimento, da sua concepção enquanto idéia, até o seu uso se dá de forma social e, mais importante, com a participação do usuário. Pelo menos deveria ser assim para todo sistema de informação, já que este tipo de software é uma construção inerentemente social e tem por objetivo atender a uma demanda social (Brooks 1995). Pense em um sistema de controle de estoque, educacional, de controle bancário, de uma loja,  etc. e fica fácil perceber que estes ficam sempre no meio de alguma interação social. Por isto, o desenvolvimento de um sistema para uma empresa sem a contribuição de seus potenciais usuários é um sistema fadado ao fracasso já na sua concepção.

No caso do software livre este aspecto social é ainda mais importante pelas características da equipe de desenvolvimento (Weber 2004). Elas são, em geral, dispersas geograficamente e possuem programadores trabalhando por uma motivação pessoal, às vezes sem nenhum tipo de compensação financeira. Por este motivo, os programadores precisam ser e estar motivados para trabalhar num projeto de software livre. Motivação esta que está diretamente atrelada a dois componentes do software: 1) o desafio técnico que ele oferece e 2) a grande base de usuários que terá acesso a seu código e usará o sistema, formando uma comunidade ativa de pessoas discutindo o mesmo. Pense em todos os softwares livre de sucesso: WordPress, Linux, Firefox, Apache, etc. São todos aplicativos de complexidade mais alta e de aplicação mais genérica, multi-uso, com uma comunidade ativa de usuários e desenvolvedores.

Este tipo de software motiva os melhores programadores do mundo inteiro. É exatamente o oposto de trabalhar num software para, digamos, uma loja no Brasil. Construir um software destes é relativamente simples e está restrito apenas aos usuários brasileiros; porque o conjunto de regras aqui é diferente das de outros países para este tipo de software. Assim,  como os melhores programadores brasileiros dedicam seus tempos livres a projetos como o Linux, sobram para estes projetos específicos os programadores pagos pelo governo ou empresas, ou aqueles despreparados e que não conseguem contribuir em projetos mais desafiadores.

Não estou dizendo com tudo isto que sou contra o software livre. Também não o acho uma alternativa melhor ou pior que outras formas de desenvolvimento (e.g., software customizado ou produto) sem levar em conta o contexto. Ele é, para mim, apenas mais uma opção a ser considerada, com seus prós e contras. Não acho, por exemplo, que o governo brasileiro está errado em adquirir software livre. Acho que ele está errado em fazer este tipo de aquisição quando o faz porque o software é livre. É preciso sempre ponderar qual é a melhor solução para as necessidades de uso, sendo o tipo de licença do software e a forma de produzi-lo variáveis no processo.

A diretriz arbitrária do governo brasileiro de sempre optar por software livre é ruim para ele, para a população e para a indústria. De maneira análoga, o governo poderia também arbitrariamente decidir por comprar software brasileiro em detrimento de software de outros países. Fazendo isto, ele deixa de fazer a aquisição considerando o mais importante, a compra do software com o melhor potencial de atendê-lo em suas necessidades. A analogia é importante porque a indústria de tecnologia no Brasil era exatamente protegida desta forma até o começo da década de 90. O resultado foi um atraso tecnológico pelo qual até hoje pagamos o preço.

Note que adotar software proprietário não significa adotar padrões fechados ou bloquear o acesso à informação. É perfeitamente possível, comum até, utilizar um software proprietário com padrões abertos e que torne a informação mais acessível e disponível para todos. Basta lembrar que a base da Internet, o conjunto de protocolos TCP/IP, não nasceu aberto, muito pelo contrário, foi desenvolvido pelos militares americanos e com o objetivo de uso exclusivo. Mesmo hoje, o principal conjunto de protocolos e padrões da Internet são mantidos por uma organização americana patrocinada pela gigante VeriSign e pela Agência Nacional de Segurança dos EUA. É uma questão política complexa mas, simplificando, a Internet só é livre hoje porque os EUA deixa. (Sobre este assunto, recomendo o excelente conjunto de visualizações mostrando a geopolítica da Internet – em francês)

Concluindo, software livre não é solução de problemas por ser livre. Aliás, software livre, em si, não é solução de nada. Do ponto de vista do desenvolvimento, ele pode ser visto como uma modalidade de criação do software. Uma muito mais apropriada para alguns tipos de projeto, aqueles com potencial de atrair uma comunidade de desenvolvedores abrangente. Do ponto de vista do usuário final, é apenas mais uma variável a ser considerada no processo de aquisição. E uma que não deveria se sobrepor às suas necessidades de uso.

Telefonia

Separação entre redes de telefonia e serviços é prevista em lei desde 1997 – O tão discutido “unbundling” deveria ter ocorrido desde àquela época. Porém, “a desagregação de redes não surtiu efeito porque as concessionárias acharam [os] preços muito baixos e uma das concessionárias reclamou das regras da cessão da estrutura de redes.” Só que há exemplos de sucesso contra esta defesa das concessionárias e já passou da hora do Brasil dar esta passo em favor do consumidor e do desenvolvimento tecnológico.

Entrevista – Telecom: por que é tão ruim? – Discutirei este artigo no post da próxima quarta-feira. Para o ex-diretor da Embratel, da Telebrás e da Telesp, dos sistemas de celulares da Nortel, e ex-presidente da Lucent e da Vésper, há vários problemas no setor, inclusive a falta do “unbundling”, que torna as telecomunicações no Brasil cara e ruim.

Desenvolvimento de Software

Why Can’t Programmers… Program? [en] – Por que programadores não conseguem… Programar? Jeff Atwood contribui para uma discussão recente sobre a falta de programadores aptos a escrever até os mais simples programas em entrevistas de emprego.

Toyota’s journey from Waterfall to Lean software development [en] – A Toyota, quem diria, não usava (e ainda não usa por completo) seus princípios de produção, conhecidos como Toyotismo, em seus processos de desenvolvimento de software. Ao contrário, durante várias décadas eles mantiveram (com sucesso, vale destacar) o uso do modelo em cascata, tão criticado por quem adota práticas mais modernas e estuda o assunto.

The socialist state of ThoughtWorks [en] – Um pouco sobre Roy Singham, fundador e atual presidente do conselho da ThoughtWorks, empresa na vanguarda do movimento de práticas ágeis para o desenvolvimento de software. Roy se diz socialista, gosta do Hugo Chavez e do modelo de governança da China, ao mesmo tempo em que gera lucros recordes todos os anos em sua empresa.

Outros

Rastreio de satélites em tempo real – Veja a posição dos satélites e da estação espacial em tempo real. Dá para se programar e ver a estação cruzar o céu em diversos pontos do Brasil.

O software livre também tem a sua fatia de problemas exclusivos, que não são encontrados no software proprietário. Existem pelo menos quatro deles que precisam ser destacados para que produtores e consumidores possam se beneficiar mais e melhor dos softwares que, respectivamente, produzem e usam. Isto porque software livre, por si só, não é solução para nada. Para o desenvolvedor, ele precisa ser entendido como uma modalidade de desenvolvimento, e para o usuário como uma alternativa para aquisição.

Primeiro, software livre não te dá, necessariamente, livre acesso ao código fonte. Nem mesmo para vê-lo. Muitas vezes você precisa ser parte da comunidade de desenvolvedores de uma organização para poder ter acesso ao código. E mesmo que você seja um membro da equipe de desenvolvimento do, digamos, Firefox, isto não te dará o direito de mudar o código ao seu bel prazer. Software livre não significa desenvolvimento livre.

Muito pelo contrário, a maioria dos grandes e mais interessantes projetos possui toda uma hierarquia definida na equipe e modularização do código. Se por um lado esta divisão e controle garante maior eficiência ao desenvolvimento, por outro, torna o processo mais rígido e menos prazeroso, obrigando programadores a muitas vezes trabalhar em tarefas que não gostariam. Veja, por exemplo, a história de Con Kolivas, ex-desenvolver do núcleo do Linux e que parou de contribuir porque cansou de ter suas contribuições rejeitadas. Como consequência, todo software livre possui sempre o risco potencial de se dividir, o chamado ‘fork’. Em outras palavras, um mesmo projeto pode se transformar em dois ou três porque alguns programadores não estão satisfeitos e preferem criar uma nova continuação do projeto a suas maneiras.

Outro problema deste tipo de controle é a estratégia de algumas empresas em iniciar um projeto de software livre para atrair desenvolvedores e baratear seu custo de desenvolvimento. Depois, com um software um pouco mais robusto e bem acabado, esta mesma empresa fecha o projeto e torna-o proprietário. Nem sempre é possível reaver o código fonte depois que isto ocorre e os programadores que haviam contribuído para o código ficam a ver navios. Assim, seja  porque um grupo de programadores dividiu o projeto ou porque uma empresa fechou seu código, os usuários de software livre correm sempre o risco de ficarem desamparados da noite para o dia.

Segundo, software livre não é software gratuito. Este é um erro muito comum mas que pode ter graves consequências. O Google, por exemplo, tem um discurso muito bonito de uso de software livre. Mas a maioria de seus principais produtos e serviços não são livres, são gratuitos. O conceito de livre é uma questão de liberdade. Deve ser pensado como em “liberdade de expressão”, não em “cerveja grátis”.

Não é possível nem ao menos ver o código fonte do Gmail, do Google Reader, Google Docs, do mecanismo de busca, dentre tantos outros produtos da empresa. Não temos esta liberdade. Pior, os dados dos usuários ficam nos servidores do Google e não nos computadores dos usuários. Para Richard Stallman [en], fundador da Free Software Foundation (Fundação para o Software Livre), “a computação na nuvem é uma armadilha (…) O conceito de usar programas na web como o Gmail do Google é pior que a estupidez.” Isto porque, em tese, não dá para simplesmente copiar os seus e-mails do Gmail de uma pasta para outra como você faria se estivesse usando um programa instalado no seu computador. É preciso toda uma sequência de passos para que você possa mover os seus e-mails para outro provedor. E, pior, você não tem como saber de fato o que uma empresa como o Google está realmente fazendo com seus dados.

Ter a liberdade de fazer o que quiser com o código-fonte de um software não significa que será possível usufruí-la. A maioria dos usuários não o faz (nem se importa) e apenas usa o software livre que também é grátis. Para ter a liberdade de alterar o código é preciso entendê-lo e/ou custear uma equipe ou uma empresa terceira para mantê-lo atualizado e em sintonia com seus interesses (ou da sua empresa).

Terceiro, software livre não é necessariamente melhor para o usuário final. Michelle Levesque, por exemplo, discute em um artigo científico seu (publicado no periódico First Monday – de acesso gratuito ao conteúdo) cinco potenciais problemas do software livre neste sentido: 1) A frequente falta de investimentos no desenvolvimento da interface com o usuário, 2) a pouca documentação disponível, 3) a falta de foco em tornar o software mais robuto, 4) a falta de foco também no desenvolvimento de recursos para o usuário final e, finalmente, 5) muitas vezes por teimosia, a recusa de alguns programadores em aprender com o software proprietário e a usar inovações destes no software livre que desenvolvem.

A comparação entre a qualidade de software livre e proprietário é tema de muita discussão. Em geral, pode-se dizer que na média o software livre tem menos erros que os proprietários. Isto ocorre porque o software livre depende de sua qualidade para sobreviver já que não investe praticamente nada em marketing. Entretanto, um estudo publicado na Business Week em 2006 afirma que dentre os melhores softwares de cada um dos 15 mercados analisados, o software proprietário está na frente em 11. Em outras palavras, há muito mais software proprietário ruim que livre mas os melhores softwares proprietários são muito melhores que os melhores livres.

Quarto, software livre nem sempre é mais barato como a ilusão da palavra “livre” faz parecer.  Afinal, os produtores dele também precisam ganhar dinheiro de alguma forma. Mas é difícil medir os custos de software de maneira agregada. Cada implantação tem suas particularidades e custos específicos, o que prejudica a medição precisa. Assim, sites que defendem o software proprietário publicam estudos a seu favor, da mesma forma que sites a favor do software livre o fazem com estudos a favor do software livre. Sobra para o usuário negociar o seu caso com as opções disponíveis.

Por exemplo, por conta da competição com o software livre empresas de software proprietário estão cada vez mais dispostas a baixar seus preços tornando-as uma opção mais barata – se já não a são. Mais ainda se os usuários que usarão o sistema proprietário já estiverem familiarizado com ele e se ele for, de fato, melhor. Mudar de software (independente da licença) significa arcar com os custos da mudança (os chamados “switching costs”), o que pode significar altos custos na troca do servidor, no treinamento dos usuários, e na migração dos dados.

Em outro cenário, ao optar por desenvolver um software livre que não existe, com o objetivo de substituir um software proprietário, muito dinheiro vai para o ralo por um motivo muito simples: Para a maioria dos projetos, pode não haver adesão de desenvolvedores voluntários o suficiente. Aí, no meio do caminho o projeto corre o risco de ser interrompido. E, neste caso, todos os esforços e recursos usados até aquele momento irão para o ralo também. Veja, por exemplo, os relatos de quem trabalha em projetos de software livre do governo federal:

“(…) Realmente falta massa. É um tanto difícil criar uma comunidade, um ecossistema de colaboração, já observado em projetos como Drupal e WordPress. No desenvolvimento do i-Educar, no qual participo, basicamente essa tarefa tem sido feita por 2 pessoas, num universo de 5.500 pessoas cadastradas na comunidade do projeto.

A missão é difícil. Muitos prestadores de serviços nesses softwares são despreparados e não possuem ainda a consciência de que é necessário contribuir aos projetos, nem que sejam pequenas contribuições.”

Demais comentários na discussão em torno dos projetos do governo também contém reclamações da burocracia para participação e da baixa qualidade atual dos mesmos. A iniciativa do governo é louvável mas é preciso a ele perceber que não é qualquer projeto que dará certo no modelo de desenvolvimento do software livre.

Na próxima semana: porque estes problemas são inerentes ao atual paradigma de desenvolvimento de software livre.

PS: As imagens que ilustram este texto são de Phillip Torrone e fazem parte do guia de 2009 da revista Make para hardwares desenvolvidos de forma aberta e livre.