Prefácio
Por quê escrever este livro?
Nas festas que participo agora, as pessoas não mais fazem
uma cara de espanto quando eu digo que desenvolvo software livre.
"Ah sim, software livre—como o Linux?" elas dizem. Prontamente
respondo: "Sim, exatamente! É isto que eu faço."
É bom não me sentir mais completamente um estranho. No passado, a próxima
questão era altamente previsível: "Como você ganha dinheiro com
isto?". Para responder, eu resumia a economia do código aberto:
que existem organizações as quais os interesses são de que certos
software existam, mas eles não precisam vender cópias, eles somente
precisam ter certeza de que o software está disponível e sendo
mantido, como uma ferramenta, não como uma mercadoria.
Ultimamente, entretanto, a pergunta seguinte não tem sempre sido sobre
dinheiro. O modelo de negócios para Software Livre e de Código
AbertoOs termos "Código Aberto" e "Livre", neste contexto,
são essencialmente sinônimos. Eles são discutidos em mais detalhes em
na
. não é mais tão
misterioso e muitos não-programadores já entendem ou, pelo menos, não se
surpreendem em ver gente empregada em tempo integral com isto. Ao invés
disto, a pergunta que eu tenho ouvido com mais frequência é "Uau,
como isto funciona?"
Eu não tinha uma resposta satisfatória pronta e cada vez que eu me
empenhava mais em preparar uma, mais eu percebia a complexidade deste
assunto. Tocar um projeto de Software Livre não é exatamente como
gerenciar um negócio (imagine ter que negociar constantemente sobre a
natureza do seu produto com um grupo de voluntários, a maioria dos quais
você nunca encontrou pessoalmente!). Também não é, por diversos motivos,
o mesmo que manter uma organização sem fins lucrativos, nem um governo. Há
similaridades com todas estas coisas mas eu cheguei lentamente à conclusão
de que Software Livre é algo sui generis (único em seu
gênero). Há várias coisas com as quais isto pode ser
eficientemente comparado mas nenhuma com a qual possa ser equiparado. De fato,
o simples fato de se assumir que projetos de Software Livre possam ser "tocados"
é uma falácia. Um projeto de Software Livre pode ser
iniciado e ser influenciado por interessados,
frequentemente de forma bastante forte. Mas seus resultados não podem ser
transformados em propriedade de nenhum único dono e, enquanto houver gente em
algum lugar, —qualquer lugar—, interessada em dar continuidade, ele
não poderá ser encerrado unilateralmente. Todos tem poder infinito, ninguém tem
força. Isto gera uma dinâmica interessante.
Este foi o motivo pelo qual eu quis escrever este livro. Projetos de
Software Livre evoluiram uma cultura distinta, uma moral na qual a liberdade
de fazer o software e realizar qualquer coisa que se deseje é o foco, e ainda
assim o resultado desta liberdade não é uma dispersão de indivíduos cada
um indo em direções separadas com o código, mas sim uma entusiasmada
colaboração. De fato, competência na própria colaboração é uma das mais
valiosas habilidades em Software Livre. Gerenciar estes projetos é como se
engajar em uma espécie de cooperação hipertrofiada, onde a habilidade não só
de trabalhar com outros mas de produzir novas formas de colaboração, podem
resultar em benefícios tangíveis para o software. Este livro tenta descrever
as técnicas pelas quais isto pode ser feito. Ele não é de forma nenhuma
completo mas é pelo menos um início.
Software Livre de qualidade é uma meta valiosa por si só e eu espero
que leitores que procurem meios atingi-la, se satisfaçam com o que
encontrarão aqui. Mas, além disto, eu espero também transmitir algo sobre o
puro prazer que se tem em trabalhar com uma equipe motivada de
desenvolvedores de Código Aberto e em interagir com usuários na forma
maravilhosamente direta que o Código Aberto promove. Participar de um
projeto de sucesso de Software Livre é divertido e, em
última instância, o que mantém o sistema todo funcionando.
Quem deve ler este livro?
Este livro é dirigido a desenvolvedores de software e gestores que
estejam considerando iniciar um projeto de software livre ou que tenham
iniciado um e estejam cogitando o que fazer agora. Ele também deve ser útil
para quem queira apenas participar de um projeto de software livre mas nunca
tenha feito isto antes.
O leitor não precisa ser um programador mas deve conhecer os conceitos
básicos de engenharia de software, como código fonte, compiladores e
patches.
Não é necessária nenhuma experiência anterior com software livre, seja como
desenvolvedor ou como usuário. Quem já participou de projetos de software
livre antes provavelmente achará um pouco óbvias pelo menos algumas partes
do livro e poderão querer saltá-las. Por causa da potencialmente grande e
variada experiência da audiência, fiz um esforço para nomear claramente
os capítulos, identificando o que pode ser saltado pelos que já tem
conhecimento do conteúdo.
Fontes
Grande parte da matéria-prima para este livro é fruto de cinco anos de
trabalho no projeto Subversion ().
Subversion é um sistema de controle de versão, livre e de código aberto,
original e destinado a substituir o CVS como o de facto
Sistema de Controle de Versão da comunidade de software livre e de código
aberto. O projeto foi iniciado por meu empregador, CollabNet
(), no início do ano 2000 e,
felizmente, CollabNet entendeu de imediato que ele deveria ser tocado como
um esforço verdadeiramente colaborativo e distribuído. Tivemos muitos
desenvolvedores voluntários desde o início, hoje somos em torno de 50
desenvolvedores no projeto, dos quais apenas poucos são funcionários da
CollabNet.
Subversion é, em muitos aspectos, um exemplo clássico de um projeto de
software livre e de código aberto e eu acabei me baseando nele mais do que
esperava inicialmente.
Isto foi em parte uma questão de conveniência: Sempre que eu precisava
de um exemplo de um aspecto específico, eu conseguia me lembrar de cabeça de
algo ocorrido com o Subversion.
Mas foi também uma questão de verificação. Embora eu esteja envolvido em
outros projetos de software livre em diversos níveis e interagindo com
amigos e conhecidos em muitos outros, nos damos conta rapidamente de que, quando
estamos escrevendo algo para ser impresso, as declarações precisam ser
confirmadas por fatos. Eu não quis fazer afirmações sobre eventos em outros
projetos baseado apenas no que eu podia encontrar nos arquivos públicos das
listas de discussão. Sei que se alguém tentasse fazer isto com o Subversion
estaria certo na metade dos casos e errado na outra metade. Assim, quando
precisei buscar inspiração ou exemplos de um projeto com o qual eu não tinha
nenhuma experiência direta, eu tentei primeiramente contactar alguém
envolvido, em quem eu pudesse confiar para explicar o que realmente estava
acontecendo.
Subversion tem sido meu emprego pelos últimos 5 anos mas tenho me
envolvido com software livre nos últimos 12. Alguns outros projetos que
influenciaram este livro são:
O editor de textos GNU Emacs, da Free Software Foundation,
projeto no qual mantenho alguns poucos e pequenos pacotes.
Concurrent Version System (CVS), projeto no qual trabalhei
intensamente em 1994–1995 com Jim Blandy, mas tenho estado envolvido
apenas ocasionalmente desde então.
A coleção de projetos de software livre e de código aberto
conhecida como Apache Software Foundation, especialmente o Apache Portable
Runtime (APR) e o Servidor HTTP Apache.
OpenOffice.org, o programa de Banco de Dados de Berkeley
Sleepycat e o programa de Banco de Dados MySql. Não tenho participado
destes projetos pessoalmente mas tenho acompanhado e, ocasionalmente, me
comunicado com gente por lá.
O depurador GNU Debugger (GDB) (como acima).
O projeto da distribuição Debian GNU/Linux (como acima).
Esta, claro, não é uma lista completa. Como a maioria de programadores
Open Source, eu mantenho vínculos leves com diversos projetos diferentes,
apenas para ter uma visão geral sobre as coisas. Não vou relaciona-los todos
aqui mas eles serão mencionados no texto quando for o caso.
Agradecimentos
Este livro demorou quatro vezes mais tempo para ser escrito do
que eu esperava e durante grande parte deste tempo eu senti como se
um piano de cauda estivesse suspenso sobre a minha cabeça onde quer que eu
fosse. Sem a ajuda de muitas pessoas, eu não teria sido capaz de terminá-lo
sem perder a sanidade.
Andy Oram, meu editor na O'Reilly, foi o sonho de qualquer escritor. Além de
conhecer o assunto intimamente (ele sugeriu diversos tópicos), ele tem o raro dom
de saber o que alguém quer dizer e ajudar esse alguém a encontrar o jeito
certo de dizer. Tem sido uma honra trabalhar com ele. Obrigado também a
Chuck Toporek por imediatamente encaminhar esta proposta ao Andy.
Brian Fitzpatrick revisou quase todo o material a medida que eu o
escrevia, o que fez não apenas o livro melhor, mas me manteve escrevendo
enquanto eu queria estar em qualquer lugar do mundo ao invés de em frente
ao computador. Ben Collins-Sussman e Mike Pilato também por checar o
progresso, e estarem sempre dispostos a dicutir—algumas vezes
longamente—em qualquer tópico que eu estivesse tentando cobrir
naquela semana. Eles também notaram quando eu diminuia o ritmo, e
gentilmente me cutucavam quando necessário. Obrigado, rapazes.
Biella Coleman estava escrevendo sua dissertação na mesma época
em que eu escrevia este livro. Ela sabe o que significa sentar e escrever
todos os dias, e serviu de um exemplo inspirador assim como um ouvido
simpático. Ela também teve uma fascinante visão com seu olhar de
antropóloga do movimento de software livre, dando ideias e referências
que eu pude utilizar no livro. Alex Golub—outro antropólogo com
um pé no mundo do software livre, e também finalizando sua dissertação
a mesma época—estava apoiando excepcionalmente no início, o que
foi de grande ajuda.
Micah Anderson de alguma forma nunca pareceu muito oprimido em
sua escrita, o que foi inspirador e até causou uma certa inveja, mas ele
sempre estava disponível com sua amizade, conversas, e (pelo menos em uma
ocasião) suporte técnico. Obrigado, Micah!
Jon Trowbridge e Sander Striker deram encorajamento e ajuda
contreta—sua vasta experiência com software livre forneceu
materiais que eu não poderia obter de nenhuma outra forma.
Agradeço a Greg Stein não só por sua amizade e encorajamento nos
momentos certos, mas por mostrar ao projeto Subversion o quão importante
é a revisão regular de código ao construir uma comunidade programadora.
Agradeço também ao Brian Behlendorf, quem habilmente colocou nas nossas
cabeças a importância de ter discussões publicamente; Eu espero que
este princípio esteja refletido por todo o livro.
Obrigado ao Benjamin "Mako" Hill e Seth Schoen, por diversas
conversas sobre software livre e suas políticas; ao Zack Urlocker e
Louis Suarez-Potts por acharem tempo em suas agendas lotadas para
darem entrevista; ao Shane da lista Slashcode por permitir que seu
post fosse citado; e ao Haggen So por sua enome e útil comparação
de soluções de site prontas.
Agradeço a Alla Dekhtyar, Polina, e Sonya por seus encorajamentos
pacientes e incansáveis. Eu sou muito grato de que não vou mais ter que
acabar (ou melhor, tentar acabar sem sucesso) nossas noitadas cedo
para ir pra casa e trabalhar no "Livro."
Obrigado ao Jack Repenning pela amizade, conversas, e uma temosia
em sempre recusar uma análise fácil e errada quando uma mais difícil e
certa está disponível. Espero que algo de sua longa experiência tanto
com desenvolvimento de software quanto a indústria de software tenha
permeado este livro.
A CollabNet foi excepcionalmente generosa ao permitir que eu
tivesse uma agenda flexível para escrever, e não reclamou quando levou
mais tempo que o planejado originalmente. Eu não sei todos os detalhes
de como o gerenciamente chega a tais decisões, mas eu suspeito que
Sandhya Klute, e mais tarde Mahesh Murthy, tiveram algo a ver com
isso—meus agradecimentos para os dois.
Todo o time de desenvolvimento do Subversion tem sido uma
inspiração nos últimos cinco anos, e muito do que está neste livro eu
aprendi tralhando com eles. Eu não irei agradecer a todos nominalmente
aqui, por que eles são muitos, mas eu imploro a qualquer leitor que possa
encontrar um commiter do Subversion a imeditamente pagar um drink a sua
escolha—Eu certamente planejo fazer isso.
Muitas vezes discuti com Rachel Scollon sobre a situação do livro;
ela sempre estava disposta a ouvir, e de alguma forma conseguia fazer
os problemas parecerem menores do que antes de nós conversarmos. Isso
ajudou muito—obrigado.
Obrigado (novamente) ao Noel Taylor, quem com certeza deve ter
imaginado porque eu queria escrever outro livro dado o quanto eu
reclamei da última vez, mas ao qual a amizade e liderança de Golosá
ajudou a manter a música e o companheirismo na minha vida, mesmo nos
momentos mais apertados. Obrigado també a Matthew Dean e Dorothea Samtleben,
amigos e parceiros musicais sofredores, que foram muito compreensivos
sempre que surgiam as minhas desculpas por não praticar. Megan Jennings
apoiou constatemente, e esteve verdadeiramente interessada no tópico
mesmo que não fosse familiar para ela—uma grande força para um
escritor inseguro. Obrigado, companheira!
Eu tive quatro revisores conhecedores e diligentes para este livro:
Yoav Shapira, Andrew Stellman, Davanum Srinivas, e Ben Hyde. Se eu fosse
capaz de incorporar todas as suas excelentes sugestões, este seria um
livro melhor. Sendo assim, restrições no tempo me forçaram a escolher
algumas, mas essas melhorias foram significantes. Qualquer erro que
tenha restado é de minha responsabilidade.
Meus pais, Frances e Henry, me apoiaram maravilhosamente como
sempre, e como este livro é menos técnico que o anterior, eu espero
que eles o achem de alguma forma mais legível.
Finalmente, eu gostaria de agradecer os devotos, Karen Underhill
and Jim Blandy. A amizade e a compreensão da Karen significou tudo para
mim, não somente durante a concepção deste livro, mas pelos últimos
sete anos. Eu simplesmente não teria terminado sem sua ajuda. Da mesma
forma com o Jim, um verdadeiro amigo e haker dos hackers, que primeiro
me ensinou sobre software livre, tanto quanto um pássaro ensinaria
um avião sobre como voar.
Aviso
Os pensamentos e opiniões expressas neste livro são de minha
autoria. Eles não representam necessariamente as visões da CollabNet ou
do projeto Subversion.