Dinheiro 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. Tipos de Envolvimento 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: Partilhar o peso 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: , Ampliando serviços 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 (aviso à navegação: trata-se do meu emprego, mas também é um exemplo perfeito deste modelo). Suporte de vendas de hardware 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. Minar um concorrente 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: (Não, não é esta a única razão pela qual existe o OpenOffice, mas o software é parcialmente uma resposta ao Microsoft Office). Marketing Ter a sua empresa associada a uma aplicação popular de open source pode ser simplesmente uma boa gestão de marca. Duplo licenciamento 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 em ). 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. Doações 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. Empregue a Longo Prazo Se gere programadores num projecto de open source, mantenha-os tempo suficiente de modo a que adquiram as capacidades técnicas e políticas — pelo menos dois anos no mínimo. Claro que nenhum projecto, open source ou não, tira partido de frequente troca de programadores. A necessidade de um recém chegado aprender os detalhes de cada vez será um travão em qualquer ambiente. Mas a penalidade é ainda maior nos projectos open source, porque programadores que saiam levam com eles não só o seu conhecimento do código mas também o seu estatuto na comunidade e as relações humanas que aí tenham feito. A credibilidade que um programador tenha acumulado não é transferida. Para escolher o exemplo mais óbvio, um programador não pode herdar o acesso de submissão de alguém que tenha saído (ver adiante neste capítulo), assim se o novo programador não tiver já acesso de submissão, terá que submeter as diferenças até o ter. Mas o acesso de submissão é só a manifestação mais mensurável dessa perca de influência. Um programador de longo prazo também conhece todos os argumentos antigos que foram apresentados e reapresentados nas listas de discussão. Um programador novo, não tendo memória dessas conversações pode tentar levantar esses tópicos novamente, levando a uma perca de credibilidade da sua organização; os outros podem imaginar que "eles não se lembram de nada?" Um novo programador não terá sentido político das personalidades do projecto, e não será capaz de influenciar a direcção do desenvolvimento de modo tão rápido e suave do que um que já por aí ande à muito tempo. Treine novos programadores através de um programa de envolvimento supervisionado. O novo programador deve ter contacto directo público com a comunidade de desenvolvimento desde o primeiro dia, começando por correcções de erros e tarefas de limpeza, de modo a poder aprender os fundamentos do código e adquirir uma reputação na comunidade, mas não em algo grande e não sendo envolvido nas discussões de concepção. Durante algum tempo um ou mais programadores experientes devem estar disponíveis para interrogatório e devem ler cada entrada que o programador novato faça para as listas de desenvolvimento, mesmo que se tratem de ramificações as quais os programadores experientes normalmente não prestem atenção. Isto irá ajudar a que o grupo de aperceba de pedras potenciais antes que o programador novato se enterre. Orientação privada e encorajamento nos bastidores podem também ajudar muito, em especial se o novato não estiver acostumado a uma revisão do seu código feita em paralelo de modo massivo por pares. Quando a CollabNet emprega um novo programador para trabalhar no Subversion, sentamos-nos com ele e escolhemos uns quantos erros em aberto para que essa pessoa possa ter um cheirinho. Discutiremos os aspectos técnicos gerais das soluções e depois escolheremos pelo menos um programador experiente para (publicamente) rever as diferenças que o novo programador irá (também publicamente) colocar. Normalmente não iremos sequer olhar para a diferença antes da lista principal de desenvolvimento o ver, embora o possamos fazer se houver alguma razão para isso. O importante é que o novo programador passe pelo processo de revisão pública, aprendendo as fundações do código e em simultâneo se habitue a receber críticas de completos estranhos. Mas tentamos coordenar os tempos de modo a que as nossas próprias críticas apareçam imediatamente após a colocação da diferença. Assim a primeira crítica que a lista vê é a nossa, o que pode ajudar a estabelecer o tom para as críticas dos restantes. Também contribui para a ideia de que esta nova pessoa é para ser levada a sério: se os outros virem que estamos a gastar tempo para fazermos uma crítica detalhada, com explicações profundas e referências ao arquivo quando apropriado, irão perceber que está a ser efectuada formação, e que tal será indicativo de investimento a longo prazo. Isso pode levar a que fiquem mais favoráveis em relação ao programador, pelo menos até ao ponto de gastarem um pouco mais de tempo em responder às questões e criticar diferenças. Aparecer como Vários e Não como Um Os seus programadores devem tentar aparecer nos foruns públicos com participantes individuais e não como uma presença corporativa monolítica. Isto não se deve a haver alguma conotação negativa em relação às presenças corporativas (bem, talvez seja, mas não é disso que trata este livro). Em vez disso deve-se a que os indivíduos são o único tipo de entidade para o qual os projectos open source estão preparados estruturalmente. Um contribuinte individual, tem discussões, submete diferenças, adquire credibilidade, vota, etc... Uma empresa não o pode fazer. Além disso, comportando-se de uma forma descentralizada evita estimular a centralização da oposição. Deixe que os seus programadores discutam entre si nas listas de distribuição de correio. Encoraje a crítica do código uns dos outros de forma frequente, tal como criticariam qualquer outra pessoa. Desencoraje a votação em bloco, porque se o fizerem, os restantes participantes podem começar a sentir isso, só em princípios gerais deve haver uma esforço organizado de modo a manterem-se alinhados. Há uma diferença entre ser de facto descentralizado e simplesmente parecer descentralizado. Em algumas circunstâncias fazer com que os seus programadores se comportem em concerto pode ser muito útil, e devem preparar-se para se coordenar nos bastidores quando necessário. Por exemplo, quando se faz uma proposta, ter várias pessoas a afirmar-se como estando de acordo relativamente cedo pode ajudar dando a impressão de um consenso crescente. Os restantes podem achar que a proposta ganhou ímpeto e que se objectarem, podem estar a parar esse mesmo ímpeto. Assim, as pessoas só irão objectar se houver uma boa razão para o fazerem. Não há nada de errado na orquestração de um acordo como este, desde que as objecções sejam, ainda, levadas a sério. As manifestações públicas de acordos privados não são menos sinceras por terem sido coordenadas anteriormente, e não são danosas desde que não sejam usadas para mascarar argumentos opostos. A sua finalidade é meramente de inibir aquele tipo que pessoa que goste de objectar só para se manter em forma; ver em para informação adicional sobre esse tipo de pessoa. Seja Aberto Sobre as Suas Motivações Seja tão aberto quanto possível quanto aos objectos da sua empresa sem contudo comprometer segredos comerciais. Se desejar que o projecto adquira certa característica, diga, que os seus clientes a têm solicitado, diga-o directamente nas listas de distribuição de correio. Se os clientes desejarem manter-se anónimos, como é por vezes o caso, pelo menos pergunte-lhes se os pode usar como exemplos não identificados. Quanto mais a comunidade pública de desenvolvimento souber sobre as razões de querer o que quer, mas confortável ficaram com aquilo que lhe seja proposto. Isto contradiz o instinto —tão fácil de adquirir e tão difícil de afastar — de que conhecimento é poder, e o de que quanto mais os outros saibam sobre os vossos objectos, mais controlo têm sobre vós. Mas esse instinto estaria aqui errado. Ao advogar publicamente uma característica (uma correcção, ou o que quer que seja), já terá lançado as suas cartas na mesa. Agora a única questão é se é bem sucedido na orientação da comunidade para partilhar o seu objectivo. Se não passar do enunciado do que quer, mas não conseguir oferecer exemplos concretos do porquê, a sua argumentação é fraca e as pessoas poderão começar a suspeitar que tem uma agenda secreta. Mas se lhes der alguns cenários do mundo real que demonstrem a razão pela qual a característica proposta é importante isso pode ter um efeito dramático no debate. Para ver como é que isto ocorre, tenha em mente a alternativa. É demasiado frequente, os debates sobre novas características e orientações são longos e cansativos. Os argumentos avançados pelas pessoas podem resumir-se "eu pessoalmente quero isto" ou o ainda mais popular "na minha experiência como conceptor de software, X é extremamente importante para os utilizadores / algo inútil que não irá agradar a ninguém." Provavelmente a ausência de utilização de dados reais não reduz nem regula estes debates, mas permite em vez disso a deriva cada vez maior sobre o suporte em qualquer experiência de utilizador. Sem alguma vigilância o resultado último é tão provável como não ser determinado pelo mais articulado, ou o mais persistente ou o mais sénior. Como uma organização com disponibilidade de dados dos clientes, tem a oportunidade de oferecer exactamente essa força de contra-vigilância. Pode ser uma conduta para informação que de outro modo não tinha meios para alcançar a comunidade de desenvolvimento. O facto de essa informação auxiliar os seus desejos não é nada de que o deva embaraçar. A generalidade dos programadores não têm individualmente uma experiência tão abrangente de como o software que escrevem é usado. Cada programador usa o software do seu próprio e idiossincrático método. Em relação aos padrões de uso de terceiros, esses programadores dependem da sua intuição e capacidade de adivinhação, e bem lá no fundo compreendem isso mesmo. Ao providenciar dados reais sobre um número significativo de utilizadores está a dar à comunidade pública de desenvolvimento algo equivalente a oxigénio. Desde que os apresente de modo correcto, eles serão muito bem recebidos e pode propulsionar as coisas na orientação que deseje. A chave, claro, é apresentar as coisas de modo correcto. Nunca funcionara insistir que tem um grande número de utilizadorfes e porque necessitam (ou pensam necessitar) de uma dada capacidade e por isso a sua solução tem que ser implementada. Em seu lugar deve focar as suas mensagens iniciais sobre o problema e não numa solução determinada. Descreva com grande detalhe as experiências que os seus clientes estão a encontrar, ofereça tanta análise quanta a que tenha disponível, e tantas soluções razoáveis quantas as que consiga pensar. Quando as pessoas começarem a especular sobre a eficácia das várias soluções pode continuar a esboçar sobre os seus dados de modo a ajudar ou refutar o que digam. Pode ter uma solução determinada em mente desde o início mas não lhe dê uma atenção especial de início. Isto não é enganar, é um comportamento normal de um "operador de bolsa honesto". Realmente você só quer resolver o problema; a solução é um mero meio para um fim. Se a solução que preferir for realmente superior, os outros programadores irão reconhecer isso por sí próprios eventualmente —e depois irão por-se a seu lado de sua livre vontade o que é muito melhor que dar-lhes umas chicotadas para que a implementem. (Há ainda a possibilidade de eles pensarem numa solução melhor.) Isto não quer dizer que é proíbido aparecer a favor de uma solução específica. Mas tem que ter a paciência para ver a análise que efectuou internamente repetida nas lista de desenvolvimento públicas. Não faça entradas do género "Sim, já passamos por isso aqui, mas não funciona devido às razões A, B, e C. Depois de se ver bem o assunto a única forma do resolver é esta..." O problema não é tanto parecer arrogante mas sim o de dar a impressão que já investiu uma quantidade (mas, as pessoas presumem que grande) de recursos analíticos ao problema, por detrás de portas. Isto pode fazer parecer que forma efectuados esforços fontes e que talvez se tenham tomado decisões, às quais o público não teve acesso e isto é uma receita para ressentimento. Naturalmente, você sabe quanto esforço foi devotado ao problema internamente, e esse conhecimento é, de certo modo, uma desvantagem. Coloca os seus programadores num espaço mental diferente das restantes pessoas nas lista de distribuição de correio, reduzindo a sua capacidade de ver as coisas do ponto de vista daqueles que ainda não se debruçaram tanto sobre o problema. Quanto mais cedo puder colocar os restantes a pensarem sobre as coisas no mesmo pé que você, menor será o efeito de distanciamento. Esta lógica aplica-se não só a situações técnicas individuais, mas sim ao mandato mais alargado de tornar os seus objectivos tão claros quanto possível. O desconhecido é sempre mais destabilizador do que aquilo que sabe. Se as pessoas compreenderem porque é que deseja o que deseja, ficam mais abertos a falar-lhe mesmo que não concordem consigo. Se não souberem o que é que faz bater o seu coração, presumem o pior, pelo menos, algum tempo.. Não irá ser capaz de publicitar tudo, claro e as pessoas não esperam isso. Todas as organizações têm segredos; talvez as organizações comerciais tenham mais, as entidades sem fins lucrativos também os têm. Se tiver de advogar um certo trajecto mas não puder revelar nada sobre o porquê, então simplesmente apresente os seus melhores argumentos que puder sob esse constrangimento e aceite o facto de poder não ter a mesma influência que queria na discussão. É um dos compromissos que tem que fazer de modo a ter uma comunidade de desenvolvimento que não esteja na sua lista de pagamento de ordenados. O Dinheiro Não lhe Pode Comprar Amor Se for um programador pago no projecto então estabeleça as regras daquilo que o dinheiro pode ou não comprar. Isto não significa que tenha que escrever duas vezes por dia para as listas de distribuição de correio reiterando a sua natureza nobre e incorruptível. Isto só quer dizer que deve estar atento a oportunidades onde possa reduzir tensões que possam ser geradas pelo dinheiro. Não necessita de começar presumir que as tensões já existam por aí; necessita, isso sim, de demonstrar que tem consciência de elas poderem potencialmente ecludir. Um exemplo perfeito surgiu no projecto Subversion. O projecto Subversion foi iniciado em 2000 pela CollabNet, que tem sido o principal financiador do projecto desde o seu início, pagando os salários de vários programadores (nota: sou um deles). Pouco tempo após o início do projecto, contratamos outro programador, Mike Pilato, to join the several developers (disclaimer: I'm one of them). Soon after the effort. By then, coding had already started. Although Subversion was still very much in the early stages, it already had a development community with a set of basic ground rules. Mike's arrival raised an interesting question. Subversion already had a policy about how a new developer gets commit access. First, he submits some patches to the development mailing list. After enough patches have gone by for the other committers to see that the new contributor knows what he's doing, someone proposes that he just commit directly (that proposal is private, as described in ). Assuming the committers agree, one of them mails the new developer and offers him direct commit access to the project's repository. CollabNet had hired Mike specifically to work on Subversion. Among those who already knew him, there was no doubt about his coding skills or his readiness to work on the project. Furthermore, the volunteer developers had a very good relationship with the CollabNet employees, and most likely would not have objected if we'd just given Mike commit access the day he was hired. But we knew we'd be setting a precedent. If we granted Mike commit access by fiat, we'd be saying that CollabNet had the right to ignore project guidelines, simply because it was the primary funder. While the damage from this would not necessarily be immediately apparent, it would gradually result in the non-salaried developers feeling disenfranchised. Other people have to earn their commit access—CollabNet just buys it. So Mike agreed to start out his employment at CollabNet like any other volunteer developer, without commit access. He sent patches to the public mailing list, where they could be, and were, reviewed by everyone. We also said on the list that we were doing things this way deliberately, so there could be no missing the point. After a couple of weeks of solid activity by Mike, someone (I can't remember if it was a CollabNet developer or not) proposed him for commit access, and he was accepted, as we knew he would be. Este tipo de consistência dá-lhe uma credibilidade que o dinheiro nunca conseguirá comprar. E credibilidade é uma moeda valiosa a ter em discussões técnicas: é uma imunização contra ver serem questionadas as motivações em discussões técnicas mais tarde. No calor da argumentação, por vezes, as pessoas vêm maneiras não técnicas de ganhar a batalha. O financiador principal do projecto devido aos seu profundo envolvimento e preocupação óbvia quanto à orientação que o projecto toma, apresenta um flanco maior que a maior parte. Sendo escrupuloso na observação de todas as directrizes do projecto desde o início, o financiador apresentará um flanco do mesmo tamanho que os restantes participantes. (Ver ainda o blogue de Danese Cooper em para uma história similar sobre acesso ao commit. Cooper era a "Open Source Diva" — da Sun Microsystems julgo que era essa a sua designação oficial — e nessa entrada no blogue, descreve como a comunidade de desenvolvimento levou a Sun a aplicar aos seus programadores os mesmos padrões de acesso a commit que os dos programadores não-Sun.) A necessiade dos financiadores jogarem pelas mesmas regras que todo o mundo significa que será mais difícil aplicar o modelo de governo do Ditador Benevolente (ver em ) na presença de financiamento, particulamente se o ditador trabalhar para o financiador principal. Visto a ditadura ter poucas gregas, é mais difícil ao financiador provar que está a cumprir as normas da comunidade, mesmo quando está. Certamente não é impossível. Só exige um líder de projecto que seja capaz de ver as coisas do ponto de vista dos programadores externos, assim como o do financiador e agir em conformidade. Mesmo assim é provavelmente boa ideia ter uma proposta para um governo não ditaturial à espera no bolso de trás, pronto a ser puxado no momento em que haja indicativos de insatizfação generalizada na comunidade. Contracting O trabalho contratado necessita de ser cuidadosamente tratado em projectos de software livre. Idealmente deseja que o trabalho executado pelo contratado seja aceite pela comunidade e englobado na distribuição pública. Teoricamente, não importa quem seja o contratado, desde que o seu trabalho seja bom e esteja em conformidade com as directrizes do projecto. A teoria e a prática podem por vezes corresponder: um completo estranho que aparece com um bom patch irá geralmente ser capaz de entrar no software. O problema é que é muito difícil produzir um bom patch para uma melhoria não trevial ou uma nova capacidade sendo um completo estranho; em primeiro lugar é necessário discutir-la com o resto do projecto. A duração da discussão não pode ser prevista com precisão. Se o contratado trabalhar à hora, poderá acabar por lhe pagar mais do que o esperado; se lhe pagar uma soma pré-determinada ele poderá ficar prejudicado. Há duas maneiras de contornar isto. A maneira preferida é efectuar uma estimativa sobre a duração do processo de discussão, baseada em experiência passada, dar alguma folga para erro de estimativa e finalmente basear o contrato no resultado. Ajuda dividir o problema em tantas componentes independentes mais pequenas quanto possível, de modo a aumentar a previsibilidade de cada porção. A outra maneira é contratar com base na entrega de um patch, e tratar da aceitação do path pelo projecto público como um assunto separado. Assim torna-se mais fácil escrever o contrato, mas ficará com o peso de manter um patch privado enquanto depender do software ou pelo menos até que consiga que o patch ou funcionalidade equivalente seja encorporada no corpo principal. Claro que mesmo da forma preferida o contrato propriamente dito não pode exigir que o patch tenha que ser aceite no código, porque isso seria vender algo que não está à venda. (O que sucederia se o projecto inesperadamente decidisse não suportar a capacidade?) Contudo o contrato pode exigir esforço bona fide de modo a que a alteração seja aceite pela comunidade, e que seja committed no repositório se a comunidade concordar com isso. Por exemplo, se o projecto tiver normas escritas para alterações do código, o contrato pode referir-se a essas normas e especificar que o trabalho deve ser feito em conformidade com as mesmas. Na prática, normalmente isto funciona de acordo com o que as pessoas esperam. The best tactic for successful contracting is to hire one of the project's developers—preferably a committer—as the contractor. This may seem like a form of purchasing influence, and, well, it is. But it's not as corrupt as it might seem. A developer's influence in the project is due mainly to the quality of his code and to his interactions with other developers. The fact that he has a contract to get certain things done doesn't raise his status in any way, and doesn't lower it either, though it may make people scrutinize him more carefully. Most developers would not risk their long-term position in the project by backing an inappropriate or widely disliked new feature. In fact, part of what you get, or should get, when you hire such a contractor is advice about what sorts of changes are likely to be accepted by the community. You also get a slight shift in the project's priorities. Because prioritization is just a matter of who has time to work on what, when you pay for someone's time, you cause their work to move up in the priority queue a bit. This is a well-understood fact of life among experienced open source developers, and at least some of them will devote attention to the contractor's work simply because it looks like it's going to get done, so they want to help it get done right. Perhaps they won't write any of the code, but they'll still discuss the design and review the code, both of which can be very useful. For all these reasons, the contractor is best drawn from the ranks of those already involved with the project. This immediately raises two questions: Should contracts ever be private? And when they're not, should you worry about creating tensions in the community by the fact that you've contracted with some developers and not others? It's best to be open about contracts, when you can. Otherwise, the contractor's behavior may seem strange to others in the community—perhaps he's suddenly giving inexplicably high priority to features he's never shown interest in in the past. When people ask him why he wants them now, how can he answer convincingly if he can't talk about the fact that he's been contracted to write them? At the same time, neither you nor the contractor should act as though others should treat your arrangement as a big deal. Too often I've seen contractors waltz onto a development list with the attitude that their posts should be taken more seriously simply because they're being paid. That kind of attitude signals to the rest of the project that the contractor regards the fact of the contract—as opposed to the code resulting from the contract—to be the important thing. But from the other developers' point of view, only the code matters. At all times, the focus of attention should be kept on technical issues, not on the details of who is paying whom. For example, one of the developers in the Subversion community handles contracting in a particularly graceful way. While discussing his code changes in IRC, he'll mention as an aside (often in a private remark, an IRC privmsg, to one of the other committers) that he's being paid for his work on this particular bug or feature. But he also consistently gives the impression that he'd want to be working on that change anyway, and that he's happy the money is making it possible for him to do that. He may or may not reveal his customer's identity, but in any case he doesn't dwell on the contract. His remarks about it are just an ornament to an otherwise technical discussion about how to get something done. That example shows another reason why it's good to be open about contracts. There may be multiple organizations sponsoring contracts on a given open source project, and if each knows what the others are trying to do, they may be able to pool their resources. In the above case, the project's largest funder (CollabNet) is not involved in any way with these piecework contracts, but knowing that someone else is sponsoring certain bug fixes allows CollabNet to redirect its resources to other bugs, resulting in greater efficiency for the project as a whole. Will other developers resent that some are paid for working on the project? In general, no, particularly when those who are paid are established, well-respected members of the community anyway. No one expects contract work to be distributed equally among all the committers. People understand the importance of long-term relationships: the uncertainties involved in contracting are such that once you find someone you can work reliably with, you would be reluctant to switch to a different person just for the sake of evenhandedness. Think of it this way: the first time you hire, there will be no complaints, because clearly you had to pick someone—it's not your fault you can't hire everyone. Later, when you hire the same person a second time, that's just common sense: you already know him, the last time was successful, so why take unnecessary risks? Thus, it's perfectly natural to have one or two go-to people in the community, instead of spreading the work around evenly. Review and Acceptance of Changes The community is still important to the success of contract work. Their involvement in the design and review process for sizeable changes cannot be an afterthought. It must be considered part of the work, and fully embraced by the contractor. Don't think of community scrutiny as an obstacle to be overcome—think of it as a free design board and QA department. It is a benefit to be aggressively pursued, not merely endured. Case study: the CVS password-authentication protocol In 1995, I was one half of a partnership that provided support and enhancements for CVS (the Concurrent Versions System; see ). My partner Jim and I were, informally, the maintainers of CVS by that point. But we'd never thought carefully about how we ought to relate to the existing, mostly volunteer CVS development community. We just assumed that they'd send in patches, and we'd apply them, and that was pretty much how it worked. Back then, networked CVS could be done only over a remote login program such as rsh. Using the same password for CVS access as for login access was an obvious security risk, and many organizations were put off by it. A major investment bank hired us to add a new authentication mechanism, so they could safely use networked CVS with their remote offices. Jim and I took the contract and sat down to design the new authentication system. What we came up with was pretty simple (the United States had export controls on cryptographic code at the time, so the customer understood that we couldn't implement strong authentication), but as we were not experienced in designing such protocols, we still made a few gaffes that would have been obvious to an expert. These mistakes would easily have been caught had we taken the time to write up a proposal and run it by the other developers for review. But we never did so, because it didn't occur to us to think of the development list as a resource to be used. We knew that people were probably going to accept whatever we committed, and—because we didn't know what we didn't know—we didn't bother to do the work in a visible way, e.g., posting patches frequently, making small, easily digestible commits to a special branch, etc. The resulting authentication protocol was not very good, and of course, once it became established, it was difficult to improve, because of compatibility concerns. The root of the problem was not lack of experience; we could easily have learned what we needed to know. The problem was our attitude toward the volunteer development community. We regarded acceptance of the changes as a hurdle to leap, rather than as a process by which the quality of the changes could be improved. Since we were confident that almost anything we did would be accepted (as it was), we made little effort to get others involved. Obviously, when you're choosing a contractor, you want someone with the right technical skills and experience for the job. But it's also important to choose someone with a track record of constructive interaction with the other developers in the community. That way you're getting more than just a single person; you're getting an agent who will be able to draw on a network of expertise to make sure the work is done in a robust and maintainable way. Funding Non-Programming Activities Programming is only part of the work that goes on in an open source project. From the point of view of the project's volunteers, it's the most visible and glamorous part. This unfortunately means that other activities, such as documentation, formal testing, etc., can sometimes be neglected, at least compared to the amount of attention they often receive in proprietary software. Corporate organizations are sometimes able to make up for this, by devoting some of their internal software development infrastructure to open source projects. The key to doing this successfully is to translate between the company's internal processes and those of the public development community. Such translation is not effortless: often the two are not a close match, and the differences can only be bridged via human intervention. For example, the company may use a different bug tracker than the public project. Even if they use the same tracking software, the data stored in it will be very different, because the bug-tracking needs of a company are very different from those of a free software community. A piece of information that starts in one tracker may need to be reflected in the other, with confidential portions removed or, in the other direction, added. The sections that follow are about how to build and maintain such bridges. The end result should be that the open source project runs more smoothly, the community recognizes the company's investment of resources, and yet does not feel that the company is inappropriately steering things toward its own goals. Quality Assurance (i.e., Professional Testing) In proprietary software development, it is normal to have teams of people dedicated solely to quality assurance: bug hunting, performance and scalability testing, interface and documentation checking, etc. As a rule, these activities are not pursued as vigorously by the volunteer community on a free software project. This is partly because it's hard to get volunteer labor for unglamorous work like testing, partly because people tend to assume that having a large user community gives the project good testing coverage, and, in the case of performance and scalability testing, partly because volunteers often don't have access to the necessary hardware resources anyway. The assumption that having many users is equivalent to having many testers is not entirely baseless. Certainly there's little point assigning testers for basic functionality in common environments: bugs there will quickly be found by users in the natural course of things. But because users are just trying to get work done, they do not consciously set out to explore uncharted edge cases in the program's functionality, and are likely to leave certain classes of bugs unfound. Furthermore, when they discover a bug with an easy workaround, they often silently implement the workaround without bothering to report the bug. Most insidiously, the usage patterns of your customers (the people who drive your interest in the software) may differ in statistically significant ways from the usage patterns of the Average User In The Street. A professional testing team can uncover these sorts of bugs, and can do so as easily with free software as with proprietary software. The challenge is to convey the testing team's results back to the public in a useful form. In-house testing departments usually have their own way of reporting test results, involving company-specific jargon, or specialized knowledge about particular customers and their data sets. Such reports would be inappropriate for the public bug tracker, both because of their form and because of confidentiality concerns. Even if your company's internal bug tracking software were the same as that used by the public project, management might need to make company-specific comments and metadata changes to the issues (for example, to raise an issue's internal priority, or schedule its resolution for a particular customer). Usually such notes are confidential—sometimes they're not even shown to the customer. But even when they're not confidential, they're of no concern to the public project, and therefore the public should not be distracted with them. Yet the core bug report itself is important to the public. In fact, a bug report from your testing department is in some ways more valuable than one received from users at large, since the testing department probes for things that other users won't. Given that you're unlikely to get that particular bug report from any other source, you definitely want to preserve it and make it available to the public project. To do this, either the QA department can file issues directly in the public issue tracker, if they're comfortable with that, or an intermediary (usually one of the developers) can "translate" the testing department's internal reports into new issues in the public tracker. Translation simply means describing the bug in a way that makes no reference to customer-specific information (the reproduction recipe may use customer data, assuming the customer approves it, of course). It is somewhat preferable to have the QA department filing issues in the public tracker directly. That gives the public a more direct appreciation of your company's involvement with the project: useful bug reports add to your organization's credibility just as any technical contribution would. It also gives developers a direct line of communication to the testing team. For example, if the internal QA team is monitoring the public issue tracker, a developer can commit a fix for a scalability bug (which the developer may not have the resources to test herself), and then add a note to the issue asking the QA team to see if the fix had the desired effect. Expect a bit of resistance from some of the developers; programmers have a tendency to regard QA as, at best, a necessary evil. The QA team can easily overcome this by finding significant bugs and filing comprehensible reports; on the other hand, if their reports are not at least as good as those coming from the regular user community, then there's no point having them interact directly with the development team. Either way, once a public issue exists, the original internal issue should simply reference the public issue for technical content. Management and paid developers may continue to annotate the internal issue with company-specific comments as necessary, but use the public issue for information that should be available to everyone. You should go into this process expecting extra overhead. Maintaining two issues for one bug is, naturally, more work than maintaining one issue. The benefit is that many more coders will see the report and be able to contribute to a solution. Legal Advice and Protection Corporations, for-profit or nonprofit, are almost the only entities that ever pay attention to complex legal issues in free software. Individual developers often understand the nuances of various open source licenses, but they generally do not have the time or resources to follow copyright, trademark, and patent law in detail. If your company has a legal department, it can help a project by vetting the copyright status of the code, and helping developers understand possible patent and trademark issues. The exact forms this help could take are discussed in . The main thing is to make sure that communications between the legal department and the development community, if they happen at all, happen with a mutual appreciation of the very different universes the parties are coming from. On occasion, these two groups talk past each other, each side assuming domain-specific knowledge that the other does not have. A good strategy is to have a liaison (usually a developer, or else a lawyer with technical expertise) stand in the middle and translate for as long as needed. Documentation and Usability Documentation and usability are both famous weak spots in open source projects, although I think, at least in the case of documentation, that the difference between free and proprietary software is frequently exaggerated. Nevertheless, it is empirically true that much open source software lacks first-class documentation and usability research. If your organization wants to help fill these gaps for a project, probably the best thing it can do is hire people who are not regular developers on the project, but who will be able to interact productively with the developers. Not hiring regular developers is good for two reasons: one, that way you don't take development time away from the project; two, those closest to the software are usually the wrong people to write documentation or investigate usability anyway, because they have trouble seeing the software from an outsider's point of view. However, it will still be necessary for whoever works on these problems to communicate with the developers. Find people who are technical enough to talk to the coding team, but not so expert in the software that they can't empathize with regular users anymore. A medium-level user is probably the right person to write good documentation. In fact, after the first edition of this book was published, I received the following email from an open source developer named Dirk Reiners: One comment on Money::Documentation and Usability: when we had some money to spend and decided that a beginner's tutorial was the most critical piece that we needed we hired a medium-level user to write it. He had gone through the induction to the system recently enough to remember the problems, but he had gotten past them so he knew how to describe them. That allowed him to write something that needed only minor fixes by the core developers for the things that he hadn't gotten right, but still covering the 'obvious' stuff devs would have missed. His case was even better, as it had been his job to introduce a bunch of other people (students) to the system, so he combined the experience of many people, which is something that was just a lucky occurrence and is probably hard to get in most cases. Providing Hosting/Bandwidth For a project that's not using one of the free canned hosting sites (see in ), providing a server and network connection—and most importantly, system administration help—can be of significant assistance. Even if this is all your organization does for the project, it can be a moderately effective way to obtain good public relations karma, though it will not bring any influence over the direction of the project. You can probably expect a banner ad or an acknowledgment on the project's home page, thanking your company for providing hosting. If you set up the hosting so that the project's web address is under your company's domain name, then you will get some additional association just through the URL. This will cause most users to think of the software as having something to do with your company, even if you don't contribute to development at all. The problem is, the developers are aware of this associative tendency too, and may not be very comfortable with having the project in your domain unless you're contributing more resources than just bandwidth. After all, there are a lot of places to host these days. The community may eventually feel that the implied misallocation of credit is not worth the convenience brought by hosting, and take the project elsewhere. So if you want to provide hosting, do so—but either plan to get even more involved soon, or be circumspect about how much involvement you claim. Marketing Although most open source developers would probably hate to admit it, marketing works. A good marketing campaign can create buzz around an open source product, even to the point where hardheaded coders find themselves having vaguely positive thoughts about the software for reasons they can't quite put their finger on. It is not my place here to dissect the arms-race dynamics of marketing in general. Any corporation involved in free software will eventually find itself considering how to market themselves, the software, or their relationship to the software. The advice below is about how to avoid common pitfalls in such an effort; see also in . Remember That You Are Being Watched For the sake of keeping the volunteer developer community on your side, it is very important not to say anything that isn't demonstrably true. Audit all claims carefully before making them, and give the public the means to check your claims on their own. Independent fact checking is a major part of open source, and it applies to more than just the code. Naturally no one would advise companies to make unverifiable claims anyway. But with open source activities, there is an unusually high quantity of people with the expertise to verify claims—people who are also likely to have high-bandwidth Internet access and the right social contacts to publicize their findings in a damaging way, should they choose to. When Global Megacorp Chemical Industries pollutes a stream, that's verifiable, but only by trained scientists, who can then be refuted by Global Megacorp's scientists, leaving the public scratching their heads and wondering what to think. On the other hand, your behavior in the open source world is not only visible and recorded; it is also easy for many people to check it independently, come to their own conclusions, and spread those conclusions by word of mouth. These communications networks are already in place; they are the essence of how open source operates, and they can be used to transmit any sort of information. Refutation is usually difficult, if not impossible, especially when what people are saying is true. For example, it's okay to refer to your organization as having "founded project X" if you really did. But don't refer to yourself as the "makers of X" if most of the code was written by outsiders. Conversely, don't claim to have a deeply involved volunteer developer community if anyone can look at your repository and see that there are few or no code changes coming from outside your organization. Not too long ago, I saw an announcement by a very well-known computer company, stating that they were releasing an important software package under an open source license. When the initial announcement came out, I took a look at their now-public version control repository and saw that it contained only three revisions. In other words, they had done an initial import of the source code, but hardly anything had happened since then. That in itself was not worrying—they'd just made the announcement, after all. There was no reason to expect a lot of development activity right away. Some time later, they made another announcement. Here is what it said, with the name and release number replaced by pseudonyms:
We are pleased to announce that following rigorous testing by the Singer Community, Singer 5 for Linux and Windows are now ready for production use.
Curious to know what the community had uncovered in "rigorous testing," I went back to the repository to look at its recent change history. The project was still on revision 3. Apparently, they hadn't found a single bug worth fixing before the release! Thinking that the results of the community testing must have been recorded elsewhere, I next examined the bug tracker. There were exactly six open issues, four of which had been open for several months already. This beggars belief, of course. When testers pound on a large and complex piece of software for any length of time, they will find bugs. Even if the fixes for those bugs don't make it into the upcoming release, one would still expect some version control activity as a result of the testing process, or at least some new issues. Yet to all appearances, nothing had happened between the announcement of the open source license and the first open source release. The point is not that the company was lying about the community testing. I have no idea if they were or not. But they were oblivious to how much it looked like they were lying. Since neither the version control repository nor the issue tracker gave any indication that the alleged rigorous testing had occurred, the company should either not have made the claim in the first place, or provided a clear link to some tangible result of that testing ("We found 278 bugs; click here for details"). The latter would have allowed anyone to get a handle on the level of community activity very quickly. As it was, it only took me a few minutes to determine that whatever this community testing was, it had not left traces in any of the usual places. That's not a lot of effort, and I'm sure I'm not the only one who took the trouble. Transparency and verifiability are also an important part of accurate crediting, of course. See in for more on this. Don't Bash Competing Open Source Products Refrain from giving negative opinions about competing open source software. It's perfectly okay to give negative facts—that is, easily confirmable assertions of the sort often seen in good comparison charts. But negative characterizations of a less rigorous nature are best avoided, for two reasons. First, they are liable to start flame wars that detract from productive discussion. Second, and more importantly, some of the volunteer developers in your project may turn out to work on the competing project as well. This is more likely than it at first might seem: the projects are already in the same domain (that's why they're in competition), and developers with expertise in that domain may make contributions wherever their expertise is applicable. Even when there is no direct developer overlap, it is likely that developers on your project are at least acquainted with developers on related projects. Their ability to maintain constructive personal ties could be hampered by overly negative marketing messages. Bashing competing closed-source products seems to be more widely accepted in the open source world, especially when those products are made by Microsoft. Personally, I deplore this tendency (though again, there's nothing wrong with straightforward factual comparisons), not merely because it's rude, but also because it's dangerous for a project to start believing its own hype and thereby ignore the ways in which the competition may actually be superior. In general, watch out for the effect that marketing statements can have on your own development community. People may be so excited at being backed by marketing dollars that they lose objectivity about their software's true strengths and weaknesses. It is normal, and even expected, for a company's developers to exhibit a certain detachment toward marketing statements, even in public forums. Clearly, they should not come out and contradict the marketing message directly (unless it's actually wrong, though one hopes that sort of thing would have been caught earlier). But they may poke fun at it from time to time, as a way of bringing the rest of the development community back down to earth.