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. 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. 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. 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. 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.