O Linux, o projeto de código aberto mais conhecido na história, transformou o trabalho de um grupo disperso de programadores, que empenharam seus esforços gratuitamente, em produtos de classe mundial. Ao longo dos anos, os softwares produzidos dessa maneira impuseram mudanças estratégicas significativas à Microsoft e a outras empresas de alta tecnologia, como IBM, Sun, Hewlett-Packard e Oracle, que tiveram de enfrentar não só o Linux, mas outros programas de código aberto, como servidores da web e processadores de texto gratuitamente disponíveis e, o que é mais importante, livremente aperfeiçoáveis. Mas seria um erro supor que, pelo fato de o Linux ser um projeto de código aberto, todos os projetos de código aberto assemelhem-se a ele. Na verdade, quando examinamos com atenção o ecossistema do código aberto, o quadro que emerge se caracteriza mais pelo fracasso do que pelo sucesso. A maior coleção de projetos de código aberto no mundo está no Source-Forge.net, que fornece hospedagem gratuita para projetos de software. O SourceForge gaba-se de abrigar mais de 100 mil projetos de código aberto; ao todo, os mais populares foram baixados milhões de vezes, e atualmente vários vêm sendo baixados mais de 10
mil vezes por dia. É nesse tipo de atenção popular que a imprensa tem se concentrado ao cobrir o código aberto.
Logo abaixo desses projetos de desempenho excepcional, porém, o quadro muda. O SourceForge classifica os projetos hospedados por ordem de atividade. Aqueles situados no percentil 95 de atividade não alcançam 10 mil downloads por dia; na verdade, a maioria não chegou sequer a ser baixada mil vezes. Esses projetos são mais ativos que todos, exceto 5% dos que estão hospedado
no SourceForge. Apesar disso, a frequência com que são baixados não chega 0,1% daquela dos 5% mais populares.
Os projetos abaixo do percentil 75 de atividade não têm nenhum download registrado. Nenhum. Quase três quartos dos projetos de código aberto propostos no SourceForge nunca alcançaram o grau de acabamento e utilidade necessários para a obtenção de sequer um usuário. Os projetos mais populares, com milhões de usuários, são de fato tão anômalos que podem ser vistos como golpes de
sorte. (Essa é, mais uma vez, uma distribuição de lei de potência aproximada.)
Terá a imprensa, então, cometido um engano com relação ao código aberto? Terá caracterizado o movimento erroneamente, com base em sucessos como o Linux, quando a condição normal de um esforço de código aberto é o fracasso? A resposta é sim, óbvia e comprovadamente sim. A massa dos projetos de código aberto fracassa, e a maioria dos sucessos que restam é muito modesta. Mas significaria isso que a ameaça representada pelos sistemas abertos em geral é superestimada e a indústria comercial dos softwares pode respirar aliviada? Aqui a resposta é não. O código aberto é uma ameaça profunda, não porque o ecossistema do código aberto esteja tendo mais sucesso que esforços comerciais, mas porque está tendo mais fracassos que ele. Como o ecossistema do código aberto, e por extensão dos sistemas sociais abertos em geral, baseia-se em produção entre pares, o trabalho nesses sistemas pode ser consideravelmente mais experimental, a um custo consideravelmente menor, do que qualquer coisa que uma empresa tenha condições de fazer. Por quê? As razões mais importantes são que sistemas abertos reduzem o custo do fracasso, não favorecem resultados previsíveis mas aquém do desejável, e tornam simples integrar as contribuições de pessoas que oferecem apenas uma única ideia.
O efeito global de fracasso é sua probabilidade multiplicada por seu custo. A maioria das organizações tenta reduzir o efeito de fracasso diminuindo sua probabilidade. Imagine que você está dirigindo um esforço para uma empresa que quer se tornar mais inovadora. Dão-lhe uma lista de ideias promissoras, mas especulativas, e você precisa escolher um subconjunto delas para investir. Trata-se, portanto, de avaliar a probabilidade de sucesso ou fracasso de cada projeto. O problema óbvio é que ninguém sabe ao certo o que vai funcionar e o que vai fracassar. Um problema menos óbvio, mas potencialmente mais significativo, é que o possível valor de vários projetos não tem relação com nada que seus autores dizem sobre ele. (Lembre que Linus declarou especificamente que seu sistema operacional seria um hobby.) Nessas circunstâncias, será inevitável que você dê luz verde para fracassos e descarte sucessos em potencial. Pior ainda, mais pessoas se lembrarão das vezes em que você disse sim para um fracasso do que daquelas em que
você disse não para uma ideia radical, mas promissora. Diante dessa assimetria, você é impelido a fazer escolhas seguras, solapando assim, de maneira sistemática, as bases para tentar ser mais inovador.
O movimento do código aberto não comete nenhum desses erros, porque não tem funcionários, não faz investimentos, nem sequer toma decisões. Ele não é uma organização, é um ecossistema, e um ecossistema dotado de extraordinária tolerância ao fracasso. O código aberto não reduz a probabilidade de fracasso, reduz seu custo; em essência, seus fracassos saem de graça. Essa inversão, em que o custo de se decidir que ideias tentar é mais alto que o custo de realmente experimentá-las, vale para os sistemas abertos em geral. Como no caso da amadorização em massa da mídia, o código aberto baseia-se no padrão “publique, depois filtre”. Em organizações tradicionais, tentar qualquer coisa é dispendioso, mesmo que custe apenas o tempo de a equipe discutir a ideia, então é necessário que alguém tente separar de antemão os sucessos dos fracassos. Em sistemas abertos, o custo de se tentar algo é tão baixo que privilegiar a probabilidade de sucesso costuma ser uma preocupação desnecessária. Mesmo em uma empresa comprometida com a experimentação, dedica-se considerável trabalho à redução da probabilidade de fracasso. Isso não significa que comunidades de código aberto não discutam – ao contrário, há mais discussão nelas que na produção administrada, porque ninguém está em condições de impor o trabalho em um
projeto específico. Ao reduzir o custo do fracasso, os sistemas abertos permitem a seus participantes fracassar loucamente, absorvendo os sucessos à medida que avançam.
O fracasso barato, valioso por si só, é também elemento-chave de uma vantagem mais complexa: a exploração de inúmeras possibilidades. Imagine um deserto vasto e não mapeado contendo um punhado de oásis dispersos aleatoriamente. Ao viajar por um lugar assim, é provável que você se
estabelecesse no primeiro oásis que encontrasse, simplesmente porque, se o abandonasse e não achasse outro, o prejuízo seria muito alto. Você gostaria de fazer com que várias pessoas explorassem o terreno ao mesmo tempo e comunicassem seus achados umas às outras, mas para isso seriam necessários grandes recursos e você teria de ser capaz de tolerar taxas de sucesso muito diferentes entre os grupos. Esse ambiente metafórico é por vezes chamado de “paisagem de aptidão” – a ideia é que, para qualquer problema ou objetivo, há uma vasta área de possibilidades a explorar, mas, dentro dela, poucos pontos valiosos a descobrir. Quando uma companhia, ou na verdade qualquer organização, encontra uma estratégia que funciona, o impulso de adotá-la e aferrar-se a ela é forte. Mesmo quando existe uma estratégia melhor, descobri-la pode ser proibitivamente dispendioso.
Para trabalhos que dependem de custos transacionais que acabam de despencar, no entanto, fornecer recursos básicos aos grupos que exploram a paisagem de aptidão custa pouco, e mesmo o fracasso de um número considerável de grupos acarreta poucos prejuízos. Em Wikinomics, Don Tapscott e Anthony Williams contam a história de uma paisagem de aptidão quase literal. A mineradora Goldcorp, após tornar públicos seus dados proprietários sobre um sítio de mineração em Ontário, desafiou terceiros a lhe dizer onde cavar em seguida, oferecendo um prêmio em dinheiro. Os participantes na disputa sugeriram mais de cem sítios possíveis, muitos dos quais não haviam sido explorados pela Goldcorp e muitos dos quais acabaram produzindo ouro. Tirar proveito da participação de muitas pessoas de fora foi uma maneira melhor de explorar a paisagem
de aptidão do que se valer de especialistas da própria empresa.
O Meetup colhe os benefícios desse tipo de exploração, arregimentando seus usuários para a tarefa de encontrar novas propostas úteis. Ao não se comprometer em ajudar nenhum grupo específico a ter sucesso, e ao não orientar seus usuários na exploração de possíveis tópicos, o Meetup tem sido sempre capaz de encontrar esses grupos sem precisar prever sua existência nem arcar com os custos da experimentação. Ao criar um serviço que permite que grupos se estabeleçam por si próprios, o Meetup consegue explorar uma seção mais vasta da paisagem de aptidão, a um custo menor, que qualquer instituição já conseguiu contratando e dirigindo funcionários. Como no caso do mundo dos blogs, que opera como um ecossistema completo, serviços que toleram fracassos como se fossem a norma geram uma espécie de valor simplesmente inalcançável por instituições que tentam assegurar o sucesso da maior parte de seus esforços.
O custo de tentar coisas é o ponto de interseção entre a teoria coaseana sobre os custos transacionais e a lei de potência aplicada à participação. Instituições existem porque reduzem os custos transacionais em relação ao que o mercado poderia suportar. Mas, como toda instituição precisa de alguma estrutura formal para permanecer coesa, e como essa própria estrutura formal
requer recursos, há um número considerável de ações potencialmente valiosas que nenhuma instituição tem condições de empreender. Para experimentá-las, seria preciso investir recursos muitas vezes maiores que os possíveis resultados. Isso, por sua vez, significa que há muitas ações que poderiam compensar, mas que não serão tentadas nem mesmo por empresas inovadoras, porque
seu sucesso final não é previsível o bastante.
É dessa lacuna que a exploração distribuída tira proveito: em um mundo no qual qualquer pessoa pode tentar qualquer coisa, até o que é arriscado pode acabar sendo tentado. Se uma população
grande o bastante de usuários estiver tentando coisas, os acidentes felizes têm uma chance muito maior de serem descobertos.
Isso constitui um enigma para os negócios. Sendo a economia coaseana o que é, uma empresa não pode experimentar tudo. Os custos gerais da administração são reais, e os custos dos fracassos não podem simplesmente ser jogados no colo dos funcionários; a empresa tem de absorvê-los de alguma maneira. Em consequência, a produção entre pares precisa necessariamente avançar livre da capacidade das empresas de dirigir todo o seu valor ou de se apossar dele.
Isso acontece em parte porque os respectivos custos de filtragem versus publicação se inverteram. No mundo tradicional, o custo de se publicar qualquer coisa cria não só um incentivo, mas uma necessidade imperiosa de se filtrar de antemão o bom do ruim. No mundo do código aberto, tentar alguma coisa muitas vezes sai mais barato que tomar uma decisão formal sobre experimentá-la ou não.
Nos negócios, o custo de investimento para produzir qualquer coisa pode impelir à aceitação do que é insuficiente. Você já experimentou esse efeito se alguma vez viu até o fim um filme de que não gostava muito para “compensar o dinheiro do ingresso”. O dinheiro já foi gasto, e você continuar ou não vendo Rocky XVII não mudará esse fato. Depois que você já está sentado no cinema, o único gasto que pode decidir despender ou não é o do seu tempo. Curiosamente, nesse momento muitas pessoas optam por continuar assistindo ao filme de que já constataram não gostar, em parte como uma maneira de evitar admitir que desperdiçaram dinheiro.
Em razão dos custos transacionais, as organizações não podem se dar o luxo de contratar funcionários que dão apenas uma contribuição importante – elas precisam contratar pessoas que tenham boas ideias dia após dia. Contudo, como sabemos, a maioria das pessoas não é tão prolífica, e em qualquer área muitas pessoas têm apenas uma ou poucas ideias boas, assim como a maioria dos fotógrafos que documentam a Mermaid Parade ou o furacão Katrina fornece apenas uma foto cada (a distribuição da lei de potência mais uma vez). A resposta institucional a esse desequilíbrio é ignorar as pessoas com uma única boa contribuição; os ditames da otimização 80/20 forçam uma empresa a maximizar seus resultados ignorando participantes esporádicos. Em consequência, muitas boas ideias (ou boas fotos, ou boas músicas) são simplesmente inacessíveis em um contexto institucional, porque na maior parte do tempo a maioria das instituições tem de escolher a pessoa “de desempenho regular” em detrimento daquela “brilhante, mas errática”. Não é que as organizações não gostariam de se beneficiar da ideia do participante ocasional – é que elas não podem. Os custos transacionais tornam isso caro demais.
Em 2005, Nick McGrath, um executivo da Microsoft no Reino Unido, disse o seguinte sobre o Linux:
Existe um mito no mercado de que há centenas de milhares de pessoas escrevendo código para o kernel do Linux. Isso não acontece; elas são centenas, não milhares. Se considerar o número de pessoas que contribuem para a árvore do kernel [a parte essencial do sistema], você verá que parte significativa do trabalho é feita por apenas um punhado.
Se você prestar atenção, perceberá que McGrath está delineando uma distribuição de lei de potência – só centenas, não milhares, com o trabalho significativo sendo feito apenas por um punhado de pessoas.
É fácil ver por que, do ponto de vista de McGrath, o modelo de código aberto é a maneira errada de se projetar um sistema operacional: quando você contrata programadores, eles drenam seus recursos por meio de salários, planos de saúde, incluindo Coca-Colas gratuitas na sala de descanso. Nesse tipo de ambiente, é claro que é ruim contratar um programador que tem apenas uma boa ideia na vida. Mas não há funcionários sugando os recursos do Linux, porque o Linux não tem funcionários, tem apenas colaboradores. A Microsoft simplesmente não pode se dar o luxo de aproveitar qualquer boa ideia, onde quer que a encontre; os custos transacionais que advêm do fato de ser a Microsoft asseguram isso. A vantagem aparentemente óbvia de se possuir o código-fonte traz consigo todos os custos gerais de se administrar essa posse. Quando os concorrentes da Microsoft eram todos empresas que enfrentavam os mesmos problemas, essas despesas representavam apenas o custo de se fazer negócio, e empresas maiores podiam se valer de economias de escala para competir nos custos gerais. O desenvolvimento do Linux, por outro lado, não se baseia na ideia de posse corporativa, o que reduz vastamente esses custos operacionais. O Linux pode aproveitar uma boa ideia de qualquer pessoa, e frequentemente o faz. Ele se torna mais do que um novo concorrente da Microsoft; isso muda o ambiente competitivo dela, na medida em que as desvantagens do dilema institucional deixam de pesar de maneira uniforme sobre todos os concorrentes.
Em 2005, a Microsoft sugeria desesperadamente que um grupo ungido de profissionais pagos para criar softwares era o único modelo de desenvolvimento sensato, em grande parte porque ela não tinha nenhuma alternativa real. A Microsoft opera em um mundo regido pela regra 80/20; como o custo de se explorar todas as ideias possíveis é simplesmente alto demais, resta-lhe otimizar os recursos que possui. O modelo de desenvolvimento com código aberto, por outro lado, vira a regra 80/20 de cabeça para baixo, perguntando: “Por que se abster dos últimos 20%?” Se os custos transacionais são uma barreira ao aproveitamento do indivíduo que tem uma única boa ideia (e em um contexto comercial eles são), a única resposta possível é baixar os custos transacionais mediante uma drástica reorganização das relações entre os colaboradores.
O movimento do código aberto introduziu essa maneira de trabalhar, mas o padrão de agregar contribuições individuais para formar algo mais valioso tornou-se geral. Um exemplo da expansão para outros domínios é o Groklaw, um site para a discussão de questões jurídicas relativas ao reino
digital. Quando a empresa de software Santa Cruz Operation (SCO) ameaçou processar a IBM, alegando que, ao oferecer o Linux a seus clientes, ela violava patentes que lhe pertenciam, esperava claramente que a IBM não quisesse enfrentar os custos de uma batalha judicial nem a possibilidade de perder e que pagasse para licenciar as patentes ou simplesmente comprasse a
SCO imediatamente. Em vez disso, a IBM levou a SCO aos tribunais e iniciou o complexo processo de revelar e reunir o que se sabia sobre as patentes e os argumentos legais da SCO. O que esta não esperava era que o Groklaw, um site dirigido por uma assistente jurídica chamada Pamela Jones, se tornaria uma espécie de terceira parte na luta. Quando a IBM pagou para ver as cartas da SCO e o processo ameaçado foi adiante, o Groklaw passou a postar e depois explicar todos os vários documentos legais que estavam sendo apresentados. Isso por sua vez transformou o Groklaw em leitura obrigatória para todos os interessados no caso. O público instruído que Jones reuniu
começou a postar comentários sobre a disputa, incluindo, de maneira mais danosa, comentários de ex-engenheiros da SCO que contradiziam explicitamente a versão que a empresa estava alegando no julgamento. O Groklaw funcionou como uma espécie de amicus curiae gratuito e disperso, revelando material que teria sido difícil e dispendioso demais para a IBM obter de qualquer outra maneira. O curso normal para uma ação judicial como aquela teria sido a disputa no tribunal entre a SCO e a IBM, enquanto a comunidade do código aberto observava. O que o Groklaw fez foi reunir essa comunidade de uma maneira que mudou efetivamente o panorama do caso.