Índice
Este capítulo examina como trazer fundos para o ambiente do software livre. Destina-se não só aos programadores quer são pagos para trabalhar em projectos de software livre, mas também os seus gestores, que necessitam de compreender as dinâmicas sociais do ambiente de desenvolvimento. Nas secções seguintes, o destinatário ("você") presume-se ser ou um programador pago ou alguém que gere tais programadores. O conselho será frequentemente o mesmo para ambos; quando não, a audiência destinatária será tornada clara pelo contexto.
O custeio por parte de empresas de desenvolvimento de software livre não é um fenómeno novo. Muito do desenvolvimento foi sempre informalmente subsidiado. Quando um administrador de sistemas escreve uma ferramenta de análise de rede para o ajudar nas suas tarefas e que depois a coloca em linha e obtém correcções de erros e contribuições com novas características de outros administradores de sistemas, o que sucedeu foi ter-se formado um consórcio não formal. Os fundos do consórcio provêm dos salários dos administradores de sistemas e do seu espaço de escritório e largura de banda doados, mesmo que ignorado, pelas organizações onde trabalham. Estas organizações tiram benefícios do investimento, claro, embora possam não estar institucionalmente conscientes de tal facto.
A diferença actualmente é que muitos destes esforços estão a ser formalizados. As empresas ficaram conscientes das vantagens do software open source, e começaram-se a envolver elas próprias mais directamente no seu desenvolvimento. Os programadores também começaram a ter expectativas que os projectos importantes atraíssem doações senão mesmo apoios de longo prazo. Enquanto a presença do dinheiro não alterou a dinâmica fundamental do desenvolvimento do software livre, mudou grandemente a escala de como as coisas sucedem, tanto em termos de número de programadores como de número de horas por programador. Também teve efeitos em como os projectos são organizados e como é que as várias entidades envolvidas interagem. Os assuntos não são de mera atribuição de despesas ou como é que o retorno do investimento é medido. Trata-se também de gestão e processo: como é que estruturas hierárquicas de comando das empresas e de comunidades de voluntários semi-descentralizadas de projectos de software livre trabalham produtivamente umas com as outras? Será que conseguem acordar sobre o que significa "produtividade"?
O suporte financeiro, em geral, é bem vindo pelas comunidades de open source. Pode reduzir a vulnerabilidade do projecto às Forças do Caos, que deitam abaixo muitos projectos mesmo antes de eles começarem, e assim pode tornar as pessoas mais dispostas a dar uma oportunidade ao software — As pessoas sentem estar a investir o seu tempo em algo que ainda andará por cá nos próximos seis meses. Quando, digamos, a IBM suporta um projecto de open source, as pessoas presumem que o projecto não será deixado falhar e ficam com mais disposição para envidarem esforços para tornar tal um profecia auto-induzida.
Contudo, o suporte financeiro trás uma percepção de controlo. Se não for cuidadosamente tratado, o dinheiro pode dividir um projecto em programadores do cerne e programadores externos. Se os voluntários não pagos ficam a sentir que as decisões de concepção ou as introduções de características estão simplesmente disponíveis para quem paga mais, saiam do projecto para se integrarem num que se assemelhe mais a uma meritocracia e menos como trabalho subordinado para proveito de outrem. Podem nunca reclamar abertamente nas listas de distribuição de correio. Em vez disso, haverá simplesmente menos e menos ruído de fontes externas, à medida que os voluntários gradualmente deixarem de tentar ser levados a sério. O ruído da actividade de pequena escala irá continuar, na forma de relatórios de erros e correcções pequenas ocasionais. Mas não haverá contribuições significativas de código ou participação externa em discussões sobre concepção. As pessoas sentem o que se espera delas, e vivem (ou não) de acordo com essas expectativas.
Embora o dinheiro necessite ser usado com cuidado, isso não significa que não possa comprar influência. Claro que pode. O truque é que não pode comprar influência de modo directo. Numa transacção comercial directa, troca dinheiro por aquilo que deseja. Se necessita de ver introduzir uma característica, assina um contrato, paga-o e isso é feito. Num projecto open source, tal não é assim tão simples. Pode assinar um contrato com alguns programadores, mas eles estarão a enganar-se a si próprios — e a si — se lhe garantirem que o trabalho que pagou será aceite pela comunidade de desenvolvimento simplesmente porque pagou por ele. O trabalho só poderá ser aceite se tiver mérito próprio e se se enquadrar na visão da comunidade para o software. Poderá ter algo a dizer nessa visão, mas não vai ser a única voz.
Assim o dinheiro não pode comprar influência mas pode comprar coisas que conduzam à influência. A coisa mais óbvia são programadores. Se os bons programadores forem empregues e se se mantiverem durante tempo suficiente, então eles podem influenciar o projecto da mesma forma que qualquer outro membro. Eles irão ter um voto, ou se forem vários um bloco de votação. Se forem respeitados no projecto, irão influenciar para além dos seus próprios votos. Não é necessário aos programadores mascararem os seus motivos. Independentemente de qualquer outra coisa, todos os que desejem que uma mudança seja feita ao software desejam-na por alguma razão. As razões da sua empresa não são menos legítimas do que as razões de qualquer outra pessoa. Só que o peso dado aos objectivos da sua empresa serão determinados pelo estatuto dos seus representantes no projecto e não pelo tamanho, orçamento ou plano de negócios da empresa.
Há muitas razões diferentes pelas quais os projectos open source são financiados. Os itens nesta lista não são mutuamente exclusivos; frequentemente o financiamento do projecto irá resultar de várias ou mesmo todas estas motivações:
Organizações separadas com necessidades de software relacionadas por vezes duplicam esforços, ou escrevendo código similar de modo redundante dentro de portas ou adquirindo produtos similares ou a fornecedores de código proprietário. Quando percebem o que está a suceder as organizações podem consorciar-se juntando recursos ou criando (ou juntando-se a) um projecto open source adequado às suas necessidades. As vantagens são óbvias: os custos de desenvolvimento são repartidos, mas as vantagens são totais são para todos. Embora este cenário possa parecem intuitivo para organizações sem fins lucrativos, pode fazer sentido estratégico mesmo para concorrentes comerciais.
Exemplos: http://www.openadapter.org/, http://www.koha.org/
Quando uma companhia vende serviços dos quais dependem, ou são tornados mais atraentes por, determinados programas de open source, é do interesse natural da companhia assegurar que esses programas sejam mantidos activamente.
Exemplo: CollabNet O apoio da Collabnet ao http://subversion.tigris.org/ (aviso à navegação: trata-se do meu emprego, mas também é um exemplo perfeito deste modelo).
O valor dos computadores e dos componentes de computadores está directamente relacionado com a quantidade de software neles disponível. Fornecedores de hardware — não só fornecedores de máquinas completas, mas também fabricantes de dispositivos periféricos e microchips — perceberam que ter software livre de elevado calibre para correr no seu hardware é importante para os seus clientes.
Por vezes as companhias suportam um projecto open source de modo a minar o produto de um concorrente, o qual pode ou não ser ele próprio open source. Comer uma parte da quota de mercado de um concorrente não é normalmente a única razão para se envolver num projecto open source, mas pode ser um factor.
Exemplo: http://www.openoffice.org/ (Não, não é esta a única razão pela qual existe o OpenOffice, mas o software é parcialmente uma resposta ao Microsoft Office).
Ter a sua empresa associada a uma aplicação popular de open source pode ser simplesmente uma boa gestão de marca.
O duplo licenciamento é a prática de um software ser oferecido sob uma licença proprietária tradicional a clientes que a desejem revender como parte de uma aplicação proprietária própria, e simultaneamente sob uma licença livre para os que a desejem usar sob licença open source (ver “Dual Licensing Schemes” em Capítulo 9, Licenses, Copyrights, and Patents). Se a comunidade de desenvolvimento open source é activa o software obtém as vantagens de uma área alargada de depuração e desenvolvimento e contudo a empresa continua a obter um fluxo de royalty para suportar alguns dos programadores a tempo inteiro.
Dois exemplos bem conhecidos são MySQL, produtores da do software de gestão de base de dados do mesmo nome e Sleepycat, a qual oferece distribuições e suporte para a gestão de base de dados Berkeley Database. Não se trata de coincidência que sejam ambas empresas de sistemas de gestão de bases de dados. O software de gestão de base de dados tende a ser integrado em aplicações em vez de ser vendido directamente aos utilizadores, sendo pois um caso bem adequado ao modelo do duplo licenciamento.
Um projecto que seja usado de modo alargado pode por vezes obter contribuições significativas, quer de indivíduos quer de organizações, tendo só um botão para doações em linha, ou vendendo merchandise com a marca tal como chávenas de café, camisolas, tapetes para rato, etc. Uma palavra de cuidado: se o seu projecto aceitar doações, faça o planeamento da utilização do dinheiro antes de ele entrar e apresente o orçamento no sítio web do projecto. As discussões sobre como atribuir dinheiro tendem a ser mais fáceis quando tidas antes de haver dinheiro para gastar; de qualquer modo, se houver desentendimentos significativos, é melhor saber enquanto tais desentendimentos sejam académicos.
Um modelo de negócios do financiador não é o único factor de como ele se relaciona com a comunidade open source. A relação histórica entre os dois também tem importância: a empresa começou o projecto ou juntou-se já com esforço de desenvolvimento existente. Em ambos os casos o financiador terá que ganhar credibilidade, mas, sem ser surpreendente há algo mais a fazer no último caso para a ganhar. A organização necessita ter objectivos claros em relação ao projecto. Se a empresa estiver a tentar manter a liderança, ou simplesmente a tentar ser uma voz na comunidade, para guiar mas não necessariamente para governar a direcção do projecto? Ou deseja só tem um par de submetedores por aí, de modo a serem capazes de corrigir erros de clientes e obter alterações na distribuição pública sem complicações?
Lembre-se destas questões à medida que for lendo as directrizes que se seguem. Estas destinam-se a ser aplicadas em qualquer envolvimento num projecto de software livre, mas cada projecto é um ambiente humano e assim não haverá dois exactamente iguais. Até certo ponto, terá sempre que tocar de ouvido, mas seguindo estes princípios aumentará a probabilidade de as coisas decorrerem como deseja.