Trabalho com Linux e sofware livre de maneira profissional desde 1998. Mas nunca havia trabalhado de maneira tão direta e intensa como trabalhei no Tapioca nestes últimos dois anos.
Nesse tempo, recuperei minha fé no código aberto, que devo admitir, ficou um tanto abalada devido à certas experiências ruins (ou talvez pela minha falta de experiência). Tudo bem, quem trabalha com isso diariamente deve saber do que estou falando. Mas o importante é que de um jeito ou de outro, trabalhar em um projeto de software livre te ensina muitas coisas. Há muitas lições a aprender, e eu vou falar sobre algumas que aprendi nos ultimos anos.
1. Ame o seu projeto: É mais fácil quando a idéia foi sua e você começou a coisa toda. Mas as vezes você é simplesmente designado para trabalhar nele. Não importa. A única maneira de produzir algo com qualidade é abraçar a causa. Acredite no que está fazendo, codifique, revise o código feito, teste e refaça o que achar ruim. Pense no que pode ser melhorado. Procure features novas, organize o código, organize o projeto. É como estar à bordo de um veleiro. O trabalho nunca acaba, há sempre algo que deve ser feito ou observado, caso contrário perde-se o rumo.
2. Aprenda com ele: Na minha opinião, a oportunidade de aprender algo novo é a melhor parte do trabalho.
3. Estabeleça metas: "
Quem não sabe o que procura, não vê o que encontra". Procure definir bem o que seu programa vai fazer. Feche o escopo, defina as funcionalidades prioritárias e estabeleça prazos para terminá-las. Aprenda a priorizar. Deixe estas metas claras para todos os desenvolvedores e usuários, em algum lugar que todos possam ver. Muitos projetos simplesmente não dão certo porque querem abraçar o mundo. Veja o Emacs, por exemplo. :)
4. Integre: De nada adianta todo o esforço se o que você fez não pode ser instalado em lugar algum. Uma interface gráfica que não segue as "UI guidelines" do Gnome ou do Kde, uma biblioteca compartilhada que sobrescreve uma previamente instalada por outro pacote, um framework distribuído que derruba o D-Bus, e por aí vai. Tenha em mente que você deve preservar a harmonia do sistema, e tentar ao máximo usar os recursos existentes no sistema antes de reinventar a roda. Por exemplo: use o D-Bus para trocar mensagens, o GStreamer para tocar músicas, o GConf para guardar suas configurações... Faça parte do todo.
5. Evite "forks": "fork" nesse contexto significa baixar o código de um projeto em um determinado momento e começar um novo projeto a partir do original. Os forks começam geralmente porque desenvolvedores ou empresas que trabalham com software decidem transformar um projeto em um de seus produtos e tem pouca experiência com comunidades de software livre. Até aí tudo bem, só que as alterações feitas nesse novo produto muitas vezes não são devolvidas como melhorias ao projeto inicial. No longo prazo, o projeto original tende a ganhar mais adeptos e a se desenvolver mais rapidamente. O projeto derivado acaba ficando para trás, porque a empresa ou o desenvolvedor não tem "fôlego" para acompanhar as mudanças. Dividir é enfraquecer.
6. Não corrija só os seus bugs: Você certamente vai utilizar componentes externos, e muitas vezes vai se deparar com bugs nestes componentes. Seu primeiro impulso é fazer algum tipo de contorno no seu programa para evitar o bug. Antes de fazer isso, tente outra coisa. Investigue o problema, se você se sentir capaz de consertar, o faça. Mande o patch para os desenvolvedores, sugira melhorias, ou ao menos relate o bug. Desta forma você vai ganhar parceiros importantes para o seu projeto.
7. Documente: Se você não souber explicar muito bem o que você fez, ninguem vai usar.
8. Ouça os usuários: Saint-Exupery disse que "
Tu te tornas eternamente responsável por aquilo que cativas". Se seu projeto evoluiu o bastante a ponto de ter usuários, você está no caminho sem volta. À partir de agora você tem a responsabilidade de mantê-los satisfeitos, responder às suas perguntas e atender às suas solicitações. Aceite as críticas e avalie a viabilidade das sugestões.
9. Termine o que começou: Não deixe o projeto parado. Lance versões novas, conserte os bugs, responda às listas de discussão. De fato seu programa nunca vai ficar "pronto", mas deve haver sempre uma versão funcional estável.
10. Ninguém é santo: O open source é uma causa nobre, revolucionária, idealista. Mas isso não quer dizer que só existem pessoas bem intencionadas e dispostas a te ajudar de maneira incondicional. Tome cuidado com oportunistas. Libere o código, mas proteja suas idéias. Não permita que decisões chave para o seu projeto acabem em mãos erradas antes de você implementá-las. Nesse caso um projeto igualzinho ao seu pode aparecer muito rapidamente, e você não levará crédito algum por isso.