Índice
A maioria dos projectos de software livre fracassa.
Tendemos a não ouvir falar muito das falhas. Só os projectos bem sucedidos atraiem a atenção e há tantos projectos de software livre no total[2] que mesmo que só uma pequena percentagem seja bem sucedida, o resultado será ainda muitos projectos com visibilidade. Também não ouvimos falar das falhas pois tais falhas são um não evento. Não há um só momento em que um projecto deixa de ser viável; as pessoas simplesmente afastam-se e deixam de trabalhar nele. Pode haver um momento em que uma última alteração é efectuada ao projecto, mas aqueles que a fazem podem não saber nesse momento que essa alteração foi a última. Não há uma clara definição de quando um projecto expirou. Será quando deixa de se trabalhar activamente nele durante seis meses? Quando a sua base de utilizadores deixa de crescer, ser ter excedido a sua base de programadores? O que sucede quando os programadores de um projecto o abandonam porque perceberam que estavam a duplicar o trabalho de outros e se se juntarem a esse outro projecto e depois o expandirem de modo a incluirem muito do seu esforço anterior? O primeiro projecto morreu ou simplesmente mudou de nome?
Devido a tais complexidades é impossível precisar a taxa de morbilidade. Mas provas anedóticas de mais de uma década de «open source», algumas moldadas no SourceForge.net e alguma pesquisa no Google todas apontam para a mesma conclusão: a taxa é extremamente alta provavelmente na ordem dos 90–95%. O número aumenta se incluirmos projectos sobreviventes mas disfuncionais: aqueles que são código em execução em ambiente de produção, mas que não são uma boa vizinhança, ou que não estão a progredir tão rapidamente ou tão fielmente quanto podiam.
O tema deste livro é evitar falhar. Examina não só como fazer as coisas bem feitas, mas também como as fazer mal feitas, de modo a poder reconhecer e corrigir relativamente cedo os problemas. A minha esperança é que após a sua leitura, tenha um reportório de técnicas não só para evitar as armadilhas comuns do desenvolvimento do «open source», mas também para saber comportar-se com o crescimento e manutenção de um projecto bem sucedido. O sucesso não é um jogo de soma zero, e este livro não trata de ganhar ou ultrapassar a competição. De facto uma parte importante de gerir um projecto de «open source» é trabalhar suavemente com outros projectos relacionados. A longo prazo, cada projecto bem sucedido contribui para o bem estar de todo o corpo universal de software livre.
Seria tentador dizer que os projectos de software livre falham pelas mesmas ordens de razões que os projectos de software proprietários. Certamente, que o software livre não tem o monopólio de requisitos irrealistas, especificações vagas, má gestão recursos, fases de concepção insuficientes ou qualquer dos outros bichos maus que já tão bem conhecemos. Há um enorme corpo de documentação escrito sobre estes tópicos e não os irei aqui duplicar. Em vez disso irei tentar descrever os problemas específicos do software livre. Quando um projecto de software livre aterra é frequente que tal se deva a que programadores (ou gestores) não tenham gostado dos problemas únicos do desenvolvimento de software «opem source» mesmo que tenham estado bem preparados para as dificuldades mais conhecidas do desenvolvimento de código fechado.
Um dos erros mais comuns são expectativas irrealistas sobre as vantagens do próprio «open source». Uma licença «open source» não é garantia de que ordas de programadores activos voluntariem o seu tempo para o vosso projecto, nem efectuar «open-sourcing» cura automaticamente as mágoas de um projecto em problemas. De facto, normalmente o oposto: abrir um projecto pode adicionar um novo conjunto de complexidades, e custar a mais no curto prazo do que mantê-lo em casa. Abrir o código significa tornar o código compreensível a completos estranhos, criar um sítio na rede para o seu desenvolvimento e listas de correio, e frequentemente escrever documentação pela primeira vez. Tudo isto representa muito trabalho. E, claro está, se qualquer programador interessado aparecer há o peso adicional de lhes responder durante pelo menos algum tempo antes de começar a ver qualquer vantagem da sua presença. Como o programador Jamie Zawinski disse dos dias complicados iniciais do projecto Mozilla:
O «Open source» funciona mesmo, mas não é uma panaceia, de todo. Se há uma uma verdade a extrair daqui é que não pode tomar um projecto a morrer, deitar uns pós de perlim-pim- -pim do «open source», e tudo funcionar como que por magia. O software (moleware) é duro. Os problemas não são assim tão simples.
Um erro relacionado é o de aligeirar a apresentação e preparação do software, pensando que podem ser feitos sempre mais tarde, quando o projecto estiver já bem encaminhado. A apresentação e preparação compreendem uma larga variedade de tarefas, todas em torno da redução das barreiras à entrada. Tornar um projecto convidativo aos não-iniciados significa escrever documentação para os utilizadores e programadores, montar um sítio web com informações para visitantes novos, automatizando o mais possível a compilação e instalação do software, etc. Muitos programadores infelizmente consideram este trabalho como tendo importância secundária relativamente ao código em si. Há duas razões para isto. Em primeiro lugar, pode parecer trabalho suplementar, já que os seus benefícios são mais evidentes para os menos familiares com o projecto e vice-versa. Afinal, os que desenvolvem o código nao precisam verdadeiramente do software preparado. Eles sabem como instalar, administrar e usar o software, porque eles o escreveram. Em segundo lugar, as capacidades necessárias para uma boa apresentação e preparação são muitas vezes totalmente diferentes das necessárias para escrever o código. As pessoas tendem a concentrar-se naquilo em que são boas, mesmo se for mais benéfico para o projecto gastar algum tempo fazendo algo que lhes agrada menos. Capítulo 2, Getting Started discute a apresentação e a preparação de software em detalhe, explicando ainda porque razão é crucial fazê-las uma prioridade logo no início do projecto.
A seguir, surge a falácia de que pouca ou nenhuma gestão de projecto é necessária no open source ou, por outro lado, que as mesmas práticas de gestão utilizadas em desenvolvimento interno servem igualmente num projecto open source. A gestão num projecto open source não é sempre muito visível mas, em projectos bem sucedidos, está permanente " por detrás da cortina" de uma forma ou doutra. Uma pequena experiência conceptual basta para explicar o motivo. Um projecto open source consiste de um conjunto aleatório de programadores—já de si uma categoria notoriamente com pensamentos distintos— que quase certamente nunca se encontraram e que poderão ter objectivos pessoais diferentes quanto ao projecto. Imaginemos agora o que aconteceria a tal grupo sem gestão. Descartando milagres, ele simplesmente colapsaria ou desintegrar-se-ia muito rapidamente. As coisas não acontecem por si sós, por muito que o quiséssemos. Porém, a gestão, embora possa ser bastante activa, é muitas vezes informal, subtil e sem dar nas vistas. A única coisa que mantém um grupo de desenvolvimento unido é a crença partilhada de que podem fazer mais juntos do que individualmente. Logo, o objectivo da gestão é sobretudo assegurar que é possível manter essa crença, estabelecendo padrões de comunicação, garantindo que programadores úteis não são marginalizados devido a idiossincrasias pessoais e, em geral, tornando o projecto um espaço que atraia os programadores. Técnicas específicas para tornar isto possível serão discutidas no restante deste livro.
Finalmente, há uma categoria geral de problemas que podemos designar de "fracassos da navegação cultural." Há dez anos atrás, ou mesmo há cinco, teria sido prematuro falar de uma cultura global de software livre, mas não agora. Uma cultura distinta tem lentamente emergido e, embora não sendo certamente monolítica—é, no mínimo, tão sujeita a dissensões internas e faccionalismos como qualquer cultura de cariz geográfico—tem um núcleo com alguma consistência. A maioria dos projectos de software livre exibe algumas ou todas as características deste núcleo. Recompensam certos comportamentos e castigam outros; criam uma atmosfera que encoraja a participação não planeada, por vezes à custa de coordenação central; possuem conceitos de rudez e gentileza que podem diferir substancialmente dos encontrados noutros lados. De suma importância, os participantes de longa data têm geralmente estes padrões interiorizados, pelo que partilham de um consenso básico sobre condutas expectáveis. Os projectos mal sucedidos, em geral, desviam-se significativamente deste núcleo, ainda que não intencionalmente, não possuíndo muitas vezes um consenso sobre o que constitui um padrão de comportamento razoável. Significa isto que, quando surgem problemas, a situação pode deteriorar-se rapidamente, já que os participantes não possuem um conjunto já estabelecido de reflexos culturais a que possam recorrer para resolver os diferendos.
Este livro é um guia prático, não um estudo antropológico ou um histórico. Todavia, um conhecimento prático das origens da cultura actual de software livre é um fundamento essencial para qualquer conselho útil. Alguém que compreende a cultura pode cruzar livremente o mundo open source, encontrando muitas variações locais de costumes e dialectos, mas podendo sempre participar confortavelmente e eficazmente. Por contraste, quem não compreende a cultura vai achar todo o processo de organização e participação num projecto difícil e cheio de surpresas. Sendo que o número de todos os que desenvolvem software livre ainda cresce de forma irregular, há muitos que se enquadram na segunda categoria—esta é, em grande medida, uma cultura de imigrantes recém-chegados e continuará a sê-lo durante algum tempo. Se pensa ser um deles, a próxima secção fornece o contexto para discussões que encontrará mais à frente, tanto neste livro como na Internet. (Por outro lado, se já tem trabalhado com open source há algum tempo, poderá já conhecer muita da sua história; sinta-se à vontade para saltar a próxima secção.)
A partilha de software existe desde o início do próprio software. Nos primeiros tempos dos computadores, os fabricantes sentiram que as vantagens competitivas ocorreriam sobretudo na inovação do hardware e, por isso, não prestaram muita atenção ao software como um activo de negócio. Muitos dos clientes dessas primeiras máquinas eram cientistas ou técnicos, capazes de modificar e extender o software distribuído com as próprias máquinas. Os clientes por vezes distribuíam os seus patches não apenas ao fabricante, mas também a outros proprietários de máquinas semelhantes. Os fabricantes muitas vezes toleravam e até encorajavam esta situação: aos seus olhos, melhorias no software, independentemente da sua fonte, serviam apenas para tornar a máquina mais atractiva a outros potenciais clientes.
Embora este período inicial lembre a cultura actual do software livre em muitos aspectos, diferia em dois aspectos cruciais. Em primeiro lugar, havia muito pouca padronização do hardware—era um tempo de inovação florescente no projecto de computadores, mas a diversidade de arquitecturas de computadores significava incompatibilidade total. Logo, o software escrito para uma máquina não funcionaria em geral noutra. Os programadores tendiam a adquirir perícia numa dada arquitectura ou família de arquitecturas (enquanto hoje eles adquiririam mais provavelmente perícia numa linguagem ou família de linguagens de programação, confiantes na capacidade de transferir os seus conhecimentos para qualquer hardware com o qual viessem a trabalhar). Dado que a perícia de uma pessoa tenderia a ser específica de um tipo de computador, a sua acumulação de experiência tinha o efeito de tornar esse computador mais atractivo para ela e para os seus colegas. Era, por isso, do interesse do fabricante a maior distribuição possível de código e conhecimento específicos da máquina.
Em segundo lugar, não havia Internet. Embora houvesse menos restrições legais à partilha do que hoje, havia mais restrições técnicas: a forma de levar dados de um lugar para outro era inconveniente e relativamente desadequada. Havia algumas redes locais, pequenas, boas para partilhar informação entre funcionários no mesmo laboratório de investigação ou empresa. Existiam, contudo, barreiras a ultrapassar se alguém quisesse partilhar com todos, onde quer que estivessem. Essas barreiras foram ultrapassadas em muitos casos. Por vezes, diferentes grupos contactavam entre si independentemente, enviando discos ou fitas por correio terrestre e, às vezes, os próprios fabricantes serviam como centros de distribuição de patches. Também ajudou o facto de muitos dos primeiros programadores de computadores trabalharem em universidades, onde a publicação do próprio conhecimento era expectável. Apesar disso, a realidade física da transmissão de dados implicava existir sempre uma impedância à partilha, proporcional à distância (real ou organizacional) que o software tinha de percorrer. A partilha alargada, sem qualquer atrito, tal como conhecemos hoje, não era possível.
À medida que a indústria amadureceu, algumas mudanças interrelacionadas ocorreram em simultâneo. A imensa diversidade de formas de hardware gradualmente conduziu a alguns claros vencedores—vencedores por via de tecnologia superior, marketing superior, ou alguma combinação de ambos. Ao mesmo tempo, sem ser uma absoluta coincidência, o desenvolvimento das chamadas linguagens de "alto nível" levou a que se pudesse escrever um programa numa linguagem e tê-lo automaticamente traduzido ("compilado") para correr em diferentes tipos de computadores. As implicações deste facto não passaram despercebidas aos fabricantes de hardware: um cliente podia agora levar a cabo um esforço significativo de engenharia de software sem ser necessário ficar preso a uma dada arquitectura de computador. Combinando isto com a gradual indiferenciação nos desempenhos entre os vários computadores, à medida que as formas menos eficientes iam sendo afastadas, um fabricante que considerava o seu hardware como o seu único activo podia esperar um futuro de diminuição crescente das margens de lucro. O poder computacional em si tornava-se um bem fungível, enquanto o software se tornava o elemento diferenciador. Vender software, ou pelo menos tratá-lo como parte integrante das vendas de hardware, começava a parecer uma boa estratégia.
Isto fez com que os fabricantes tivessem de começar a impôr os direitos de autor no seu código mais estritamente. Se os utilizadores simplesmente continuassem a partilhar e a modificar código livremente entre eles, poderiam reimplementar de forma independente algumas das melhorias agora vendidas como "valor acrescentado" pelo fornecedor. Pior do que isso, o código partilhado poderia ir parar às mãos de concorrentes. Ironicamente, tudo isto acontecia no momento em que a Internet estava decisivamente arrancando. Precisamente quando a partilha de software verdadeiramente desimpedida tornava-se tecnicamente possível, mudanças no negócio dos computadores tornavam-na economicamente indesejável, pelo menos do ponto de vista de qualquer empresa. Os fornecedores impuseram restrições, negando aos utilizadores o acesso ao código que corria nas suas máquinas ou insistindo em contratos de confidencialidade que tornavam a partilha impossível na prática.
À medida que o mundo da troca irrestrita de código se ia desvanecendo lentamente, uma contra-reacção cristalizou-se na mente de, pelo menos, um programador. Richard Stallman trabalhou no Laboratório de Inteligência Artificial (Artificial Intelligence Lab—AI Lab) no Instituto de Tecnologia de Massachusetts (Massachusetts Institute of Technology—MIT) nos anos 1970 e início dos anos 1980, durante o que veio a ser uma época e uma localização de ouro para a partilha de código. O AI Lab tinha uma forte "ética hacker"[3]. Não apenas a partilha de quaisquer melhorias feitas no sistema era encorajada, como de facto esperava-se que todos o fizessem. Como Stallman escreveu mais tarde:
Não chamávamos ao nosso software "software livre", porque esse termo ainda não existia; mas era exactamente isso. Sempre que alguém de outra universidade ou empresa queria implementar ou usar um programa, nós permitíamos com agrado. Se visse alguém a usar um programa desconhecido e interessante, podia sempre pedir para ver o código, para que pudesse lê-lo, alterá-lo ou canibalizar partes dele para criar um novo programa.
Esta comunidade Edénica colapsou em torno de Stallman logo após 1980, quando as alterações que sucediam no restante da indústria finalmente alcançaram o AI Lab. Uma empresa em arranque contratou muitos dos seus programadores para trabalharem num sistema operativo semelhante ao existente no Lab, mas agora sob uma licença exclusiva. Ao mesmo tempo, o AI Lab adquiriu novo equipamento que trazia um sistema operativo proprietário.
Stallman vislumbrou o padrão dos acontecimentos:
Os computadores modernos da época, como o VAX ou o 68020, traziam o seu próprio sistema operativo, mas nenhum era software livre: era preciso assinar um contrato de confidencialidade mesmo para obter apenas uma cópia executável.
Isto significava que o primeiro passo para usar um computador era prometer não ajudar o colega. Uma comunidade cooperante era proibida. A regra definida pelos donos do software proprietário era, "Se você partilhar com o seu colega, é um pirata. Se quer alterações, suplique-nos para as fazermos."
Por algo peculiar na sua personalidade, ele decidiu resistir à tendência. Em vez de continuar a trabalhar no (agora dizimado) AI Lab, ou aceitar um emprego escrevendo código numa das novas empresas, onde os resultados do seu trabalho ficariam selados numa caixa, ele despediu-se do Laboratório e iniciou o Projecto GNU e a Fundação para o Software Livre (Free Software Foundation—FSF). O objectivo de GNU[4] era desenvolver um sistema operativo de computador e um conjunto de software de aplicações totalmente livres e abertos, nos quais os utilizadores nunca fossem impedidos de modificar ou de partilhar as modificações. Stallman estava essencialmente a tentar recriar o que tinha sido destruído no AI Lab, mas a uma escala mundial e sem as vulnerabilidades que tornaram a cultura do AI Lab susceptível à desintegração.
Para além de trabalhar no novo sistema operativo, Stallman elaborou uma licença de direitos de autor cujos termos garantiam que o seu código seria perpetuamente livre. A Licença Pública Geral GNU (GNU General Public License—GPL) é uma forma inteligente de judo legal: afirma que o código pode ser copiado e modificado sem restrição, e que as cópias e trabalhos derivados (i.e., versões modificadas) devem ser distribuídos sob a mesma licença, sem restrições adicionais. Na verdade, utiliza a lei dos direitos de autor para atingir um efeito contrário ao dos direitos de autor tradicionais: em vez de limitar a distribuição do software, impede qualquer um, até mesmo o autor, de a limitar. Para Stallman, isto era preferível a simplesmente colocar o seu código no domínio público. Se estivesse no domínio público, qualquer cópia do código poderia ser incorporada num programa proprietário (como se sabe ter acontecido a código sob licenças permissivas). Embora tal incorporação não diminua em nada a disponibilidade permanente do código original, implicaria um benefício dos esforços de Stallman por parte do inimigo—o software proprietário. A GPL pode ser vista como uma forma de proteccionismo do software livre, ao impedir o software não-livre de tirar proveito do código "GPLeado". A GPL e a sua relação com outras licenças de software livre são discutidas detalhadamente em Capítulo 9, Licenses, Copyrights, and Patents.
Com a ajuda de muitos programadores, alguns dos quais partilhavam a ideologia de Stallman e outros que queriam apenas muito código livre disponível, o Projecto GNU começou a lançar substitutos livres de muitos dos componentes mais críticos de um sistema operativo. Devido à agora generalizada padronização do hardware e software de computadores, era possível utilizar os substitutos GNU em sistemas não-livres e muitos fizeram-no. O editor de texto GNU (Emacs) e o compilador de C (GCC) foram particularmente bem sucedidos, adquirindo numerosos e fiéis seguidores, não pelas bases ideológicas mas simplesmente pelo seu mérito técnico. Cerca de 1990, GNU tinha produzido grande parte de um sistema operativo livre, exceptuando o kernel—o componente lançado no arranque pela máquina e responsável por gerir a memória, discos e outros recursos do sistema.
Infelizmente, o projecto GNU havia escolhido um tipo de kernel que acabou por ser mais difícil de implementar do que o esperado. O atraso resultante impediu a Free Software Foundation de fazer o primeiro lançamento de um sistema operativo totalmente livre. Em vez disso, a peça final foi colocada no lugar por Linus Torvalds, um estudante finlandês de ciência dos computadores que, com a ajuda de voluntários em todo o mundo, havia completado um kernel livre de tipo mais conservador. Ele chamou-o de Linux e, ao ser combinado com os programas GNU existentes, o resultado foi um sistema operativo totalmente livre. Pela primeira vez, era possível arrancar um computador e realizar trabalho sem qualquer software proprietário.[5]
Muito do software neste novo sistema operativo não havia sido produzido pelo projecto GNU. De facto, GNU não era sequer o único grupo a trabalhar num sistema operativo livre (por exemplo, o código que eventualmente originaria o NetBSD e o FreeBSD já estava sendo desenvolvido na altura). A importância da Free Software Foundation não estava apenas no código que havia escrito, mas também na sua retórica política. Ao falar de software livre como uma causa em vez de uma mera conveniência, tornava difícil aos programadores não ter uma consciência política a esse respeito. Mesmo aqueles que discordavam com a FSF tinham de encarar o assunto, nem que fosse para assumir uma posição distinta. A eficácia propagandista da FSF consistia em atar o seu código a uma mensagem, por meio da GPL e outros textos. À medida que o seu código se espalhava, o mesmo sucedia com a sua mensagem.
Muitas outras coisas sucediam na cena emergente do software livre, entretanto, sendo poucas tão ideologicamente explícitas como o Projecto GNU de Stallman. Uma das mais importantes foi a Berkeley Software Distribution (BSD), uma reimplementação gradual do sistema operativo Unix—que, até ao final dos anos 1970, havia sido um projecto de investigação vagamente proprietário na AT&T—por programadores na Universidade da Califórnia em Berkeley. O grupo BSD não fez quaisquer declarações políticas ostensivas sobre a necessidade de os programadores se unirem e partilharem entre si, mas eles praticaram a ideia com estilo e entusiasmo, coordenando um esforço massivo de desenvolvimento distribuído onde as utilidades de linha de comandos e bibliotecas de código, e eventualmente o próprio kernel do sistema operativo, foram reescritos de raíz sobretudo por voluntários. O projecto BSD tornou-se um exemplo importante de desenvolvimento não-ideológico de software livre, servindo também como campo de treino para muitos programadores que permaneceriam activos no mundo open source.
Outro núcleo de desenvolvimento cooperativo foi o X Window System, um ambiente de computação gráfico livre e transparente em rede, desenvolvido no MIT em meados dos anos 1980 em parceria com fabricantes de hardware que tinham um interesse comum de poderem oferecer um sistema gráfico aos seus clientes. Longe de se opôr ao software proprietário, a licença X deliberadamente permitia extensões proprietárias sobre o núcleo livre—cada membro do consórcio queria a possibilidade de poder valorizar a distribuição X de base e, dessa forma, obter vantagem competitiva sobre os outros membros. X Windows[6] era software livre, mas principalmente como uma forma de nivelar o campo entre interesses empresariais concorrentes e não por algum desejo de pôr fim ao domínio do software proprietário. Um exemplo mais, precedendo o projecto GNU em alguns anos, foi o TeX, sistema de tipografia livre com qualidade de publicação de Donald Knuth. Ele lançou-o sob uma licença que permitia a todos a modificação e distribuição do código, mas não chamando o resultado "TeX" a não ser que passasse um conjunto muito estrito de testes de compatibilidade (isto é um exemplo da classe de licenças livres "protectoras de marca", discutida adiante no Capítulo 9, Licenses, Copyrights, and Patents). Knuth não estava tomando posição sobre a questão software livre-versus-proprietário; ele precisava apenas de um melhor sistema de tipografia para poder completar o seu verdadeiro objectivo—um livro sobre programação de computadores—e não viu razão para não lançar o seu sistema livremente após conclusão.
Sem listar todos os projectos e todas as licenças, pode afirmar-se com segurança que, nos finais dos anos 1980, existia uma boa quantidade de software livre sob uma variedade apreciável de licenças. A diversidade de licenças reflectia uma correspondente diversidade de motivações. Mesmo alguns dos programadores que escolheram a licença GNU GPL eram muito menos motivados ideologicamente do que o próprio projecto GNU. Embora gostassem de desenvolver software livre, muitos programadores não consideravam o software proprietário um mal social. Alguns sentiam-se moralmente impulsionados a livrar o mundo do "aprisionamento de software" (termo de Stallman para o software não-livre), mas outros eram mais motivados pelo entusiasmo técnico ou pela satisfação de trabalhar com colaboradores de ideias semelhantes, ou até mesmo por simples desejo humano de glória. Apesar disso, maioritariamente, estas motivações díspares não interagiam de forma destrutiva. Isto sucede em parte porque o software, ao contrário de outras formas criativas como a prosa ou as artes visuais, precisa de passar testes semi-objectivos para ser considerado bem sucedido: precisa de correr e estar razoavelmente livre de erros. Isto dá a todos os participantes num projecto uma espécie de base comum automática, uma razão e uma plataforma para trabalhar em conjunto sem preocupação excessiva com qualificações para além das técnicas.
Os programadores tinham outra razão para se juntarem: verificou-se que o software livre estava produzindo algum código de excelente qualidade. Em alguns casos, constatava-se que era tecnicamente superior à alternativa não-livre mais próxima; noutros casos, era pelo menos comparável e, evidentemente, custava sempre menos. Embora apenas alguns pudessem estar motivados para correr software livre com base exclusivamente em preceitos filosóficos, um grande número de pessoas estava satisfeito por poder usar software com melhores resultados. Além disso, de entre os que o usavam, uma parte estava sempre disposta a dar do seu tempo e capacidades para ajudar a manter e a melhorar o software.
Esta tendência para produzir código de qualidade não era certamente universal, mas estava sucedendo com frequência crescente em projectos de software livre em todo o mundo. Empresas que dependiam fortemente de software começaram gradualmente a aperceber-se do facto. Muitas delas descobriram que já estavam usando software livre no seu quotidiano e simplesmente não sabiam (a gestão de topo nem sempre está atenta a tudo o que o departamente de TI faz). Grandes empresas começaram a assumir um papel mais activo e público em projectos de software livre, contribuíndo com tempo e equipamento e, por vezes, até mesmo financiando directamente o desenvolvimento de software livre. Tais investimentos poderiam, na melhor das hipóteses, dar origem a retornos muito significativos. O patrocinador paga apenas a um pequeno grupo de programadores experientes para se dedicarem a tempo inteiro ao projecto, mas beneficia das contribuições de todos, incluíndo de trabalho de voluntários não-pagos e de programadores financiados por outras empresas.
À medida que o mundo empresarial dava cada vez mais atenção ao software livre, os programadores enfrentavam novas questões de apresentação. Uma delas era a própria palavra "free" (livre, grátis). Ao ouvirem pela primeira vez o termo "free software", muitos associavam erradamente ao mero conceito de "software a custo zero". É um facto que todo o software livre tem custo zero[8], mas nem todo o software a custo zero é livre. Por exemplo, durante a "batalha dos browsers" nos anos 1990, ambas a Netscape e a Microsoft disponibilizaram os seus browsers web concorrentes sem custo, numa corrida para ganhar quota de mercado. Nenhum dos browsers era livre pelo conceito de "software livre". O código não era acessível e, mesmo que fosse, não havia permissão para modificá-lo ou redistribuí-lo.[9] Era possível apenas descarregar um ficheiro executável e corrê-lo. Os browsers não eram mais livres do que o software envolvido em película e vendido em lojas; eram apenas mais baratos.
Esta confusão em torno da palavra "free" deve-se inteiramente a uma infeliz ambiguidade na língua inglesa. A maioria das restantes línguas distingue preços baixos de liberdade (a distinção entre gratis e libre é imediatamente clara a todos os que falam línguas românicas, por exemplo). Todavia, a posição do Inglês como língua de ligação de facto da Internet significa que um problema para o Inglês é, em certa medida, um problema para todos. O desentendimento em torno da palavra "free" tornou-se tão evidente que os programadores de software livre eventualmente desenvolveram uma resposta: "It's free as in freedom—think free speech, not free beer."[10] Ainda assim, é cansativo dar constantemente esta explicação. Muitos programadores sentiram, com alguma razão, que a palavra ambígua "free" estava dificultando a compreensão deste software por parte do público.
O problema era, todavia, mais profundo. A palavra "free" trazia consigo uma conotação moral inescapável: se a liberdade era um fim em si mesma, não era importante se o software livre era também melhor, ou mais lucrativo em certas circunstâncias. Esses eram apenas efeitos laterais interessantes de um motivo que era, no fundo, nem técnico nem mercantil, mas moral. Além disso, a posição "free as in freedom" forçava uma inconsistência evidente nas empresas que queriam suportar certos programas livres numa área do seu negócio, mas que queriam continuar a comercializar software proprietário em outras áreas.
Estes dilemas entraram numa comunidade já de si perturbada por uma crise de identidade. Os programadores que realmente escrevem software livre nunca foram unânimes quanto ao objectivo global, se é que existe, do movimento do software livre. Até mesmo afirmar que as opiniões podem surgir de um extremo ao outro pode ser enganador, já que erroneamente implicaria uma variação linear onde, em vez disso, existe uma dispersão multidimensional. Todavia, podem ser distinguidas duas grandes categorias de opiniões, se estivermos dispostos neste momento a ignorar subtilezas. Um grupo assumiria o ponto de vista de Stallman, segundo o qual a liberdade de partilhar e modificar seria a coisa mais importante e, por isso, deixar de falar sobre liberdade seria esquecer o mais importante. Outros sentiam que o software em si era o argumento mais importante a seu favor, sentindo-se desconfortáveis em declarar o software proprietário como inerentemente mau. Alguns, mas não todos, dos programadores de software livre acreditam que o autor (ou empregador, no caso de trabalho contratado) deveria ter o direito de controlar os termos de distribuição e que nenhum julgamento moral deveria ser anexado à escolha de termos particulares.
Durante muito tempo, estas diferenças não precisaram de ser cuidadosamente examinadas ou articuladas, mas o sucesso crescente do software livre no mundo empresarial tornou a questão inevitável. Em 1998, o term open source foi criado como uma alternativa a "free", por uma coligação de programadores que eventualmente originou a Open Source Initiative (OSI).[11] A OSI sentiu não apenas que "free software" era potencialmente confuso, mas que a palavra "free" era apenas mais um sintoma de um problema geral: o movimento precisava de um programa de marketing para introduzi-lo no mundo empresarial e que falar de morais e dos benefícios sociais de partilhar nunca seria matéria para as salas de reuniões das empresas. Nas suas próprias palavras:
A Open Source Initiative é um programa de marketing para software livre. Fundamenta o "software livre" em bases pragmáticas sólidas em vez de meras discussões ideológicas. A substância vencedora não mudou, mudaram antes a atitude e o simbolismo perdedores. ...
O esclarecimento que deve ser dado a muitos técnicos não é sobre o conceito de open source, mas antes sobre o nome. Por que não chamar, como tem sido tradicionalmente feito, software livre?
Uma razão imediata é que o termo "software livre" é facilmente incompreendido levando a situações de conflito. ...
Mas a verdadeira razão para a renomeação é o marketing. Estamos a tentar dirigir o nosso conceito ao mundo empresarial neste momento. Temos um produto vencedor, mas o nosso posicionamento no passado tem sido péssimo. O termo "software livre" tem sido incompreendido por pessoas de negócios, que confundem o desejo de partilhar com anti-comercialismo ou, pior ainda, com roubo.
Directores executivos e técnicos[12] de empresas tradicionais nunca comprarão "software livre". E se pegarmos na mesma tradição, nas mesmas pessoas e nas mesmas licenças de software livre e alterarmos o rótulo para "open source" ? Isso, já comprarão.
Alguns hackers têm dificuldade em acreditar nisto, mas porque são técnicos que pensam em termos concretos e substanciais e não compreendem como é importante a imagem quando se quer vender algo.
Em marketing, a aparência é realidade. A aparência de que estamos dispostos a derrubar as nossas barricadas e trabalhar com o mundo empresarial conta tanto como a realidade do nosso comportamento, das nossas convicções e do nosso software.
(de http://opensource.feratech.com/advocacy/faq.php e http://opensource.feratech.com/advocacy/case_for_hackers.php#marketing)
As pontas de muitos icebergs de controvérsia são visíveis naquele texto. Refere-se às "nossas convicções", mas habilmente evita explicitar quais são essas convicções. Para alguns, pode ser a convicção de que código desenvolvido segundo um processo aberto será melhor código; para outros, pode ser a convicção de que toda a informação deve ser partilhada. Há o uso da palavra "roubo" para referir (presumivelmente) a cópia ilegal—uso contrariado por muitos, com base em não se poder considerar roubo se o possuidor original ainda mantém o objecto. Há uma suspeita pairante de que o movimento do software livre pode ser indevidamente acusado de anti-comercialismo, mas é deixada em aberto a questão de existir ou não uma base factual para tal acusação.
Nada disto significa que o sítio web da OSI é inconsistente ou enganador. Não o é. Pelo contrário, é um exemplo do que exactamente a OSI afirma ter faltado ao movimento de software livre: bom marketing, onde "bom" significa "viável no mundo empresarial." A Open Source Initiative deu a muitos exactamente o que procuravam—um vocabulário para falar de software livre como uma metodologia de desenvolvimento e estratégia de negócio, em vez de uma cruzada moral.
O surgimento da Open Source Initiative mudou o panorama do software livre. Formalizou uma dicotomia há muito sem nome e, ao fazê-lo, obrigou o movimento a reconhecer que possuía política interna e externa. O resultado hoje é que ambos os lados tiveram de encontrar terreno comum, já que a maioria dos projectos incorpora programadores de ambos os campos, bem como participantes que não se encaixam em nenhuma categoria distinta. Isto não significa que as pessoas não falam de motivações morais—lapsos na "ética hacker" tradicional são por vezes lembrados. É, todavia, raro um programador de software livre / open source questionar abertamente as motivações básicas de outros num projecto. As contribuições suplantam o que contribui. Se alguém escreve bom código, não lhe é perguntado se o faz por razões morais ou porque o seu empregador o contratou para tal, ou para construir o seu currículo, ou ainda outra razão qualquer. A sua contribuição é avaliada numa base técnica e discutida como tal. Mesmo organizações explicitamente políticas como o projecto Debian, cujo objectivo é fornecer um ambiente de computação 100% livre (segundo o conceito de liberdade), são relativamente abertas a integrar código não-livre e a cooperar com programadores que partilham exactamente do mesmo objectivo.
[2] O SourceForge.net, um popular local de hospedagem, tinha 79.225 projectos registados em meados de Abril 2004. Este não está sequer perto do número total de projectos de software livre na Internet, claro; este é só o número daqueles que escolheram usar o SourceForge.
[3] Stallman utiliza a palavra "hacker" no sentido de "alguém que adora programar e exulta na sua perícia", não no sentido relativamente recente de "alguém que invade computadores."
[4] Significa "GNU's Not Unix" (GNU não é Unix) e a palavra GNU naquela expansão significa ... o mesmo.
[5] Tecnicamente, Linux não foi o primeiro. Um sistema operativo para computadores IBM-compatíveis, designado de 386BSD, tinha surgido um pouco antes do Linux. Era, porém, muito mais difícil conseguir arrancar um 386BSD. Linux causou uma tal impressão não apenas por ser livre, mas porque havia realmente uma grande probabilidade de conseguirmos arrancar o computador com este sistema instalado.
[6] Os criadores preferem designá-lo como "X Window System" mas, na prática, o sistema é habitualmente designado de "X Windows", porque três palavras são excessivas.
[7] (N.T.) A ambiguidade do termo original free, discutida nesta secção, não surge no Português, onde livre associa o termo original ao conceito de liberdade e grátis ao conceito de gratuidade (custo zero).
[8] Pode cobrar-se um valor por fornecer cópias de software livre mas, dado que não se pode impedir os destinatários de eles próprios poderem oferecer o software sem custo, o preço rapidamente é levado a zero.
[9] O código do Netscape Navigator foi eventualmente lançado sob uma licença open source, em 1998, tornando-se a base do browser web Mozilla. Veja http://www.mozilla.org/.
[10] (N.T.) Dada a particularidade do termo "free" como forma ambígua, a tradução da frase fica necessariamente debilitada e até estranha, mas será algo como "É livre como em liberdade—pense discurso livre, não cerveja grátis."
[11] A página web da OSI é http://www.opensource.org/.
[12] (N.T.) No original, "CEOs and CTOs".