?Não existe almoço grátis?, diria Milton Friedman. A máxima tem um fundamento importante: mesmo quando as coisas não vêm com uma etiqueta indicando um preço, não quer dizer que elas não têm custo. O software pode ter sido obtido de graça (seja software de código-livre, seja software pirata), mas o desenvolvedor deseja certamente ser recompensado pelo tempo que dedicou ao trabalho.
Essa recompensa pode até não ser monetária. Muitas pessoas trabalham em busca de reconhecimento, ou por desejarem resolver um problema que o incomoda, ou por hobby – um mero passatempo que agrada. Sempre há algum tipo de recompensa desejada em troca.
Entretanto, há uma coisa diferente em software: depois do produto pronto, ele pode ser infinitamente consumido a um custo irrelevante. Duplicar software tem custo marginal zero, se comparado ao custo do desenvolvimento. O mesmo pode ser dito de qualquer produto que possa ser digitalizado: músicas, filmes, informação em geral. Esse é um dos pontos-chave para falarmos da economia digital.
Baseado nisso, eu deveria me esticar um pouco para justificar a seguinte afirmação: ?a melhor forma de garantir a produção de riquezas em uma sociedade cada vez mais baseada em uma economia digital está em buscar uma forma de fomentar e financiar os criadores, e buscar consumir apenas aquilo que possui um custo marginal de duplicação.?
Mas se esticar demais, a coisa complica. O que eu quero dizer é simples: se arrumarmos um sistema onde as pessoas que produzem tenham incentivo à produção ao mesmo tempo que o produto final seja livremente copiado, então toda a sociedade se beneficiaria, mais do que em uma sociedade onde há escassez artificial.
E o que é escassez artificial? Software proprietário. Música com proteção de DRM. Patentes sobre desenvolvimento de remédios. Livros que não podem ser copiados em universidades? qualquer coisa onde a tecnologia (ou a política) é usada para impedir o livre fluxo e consumo de bens e serviços.
Software as a service
O crescimento e a adoção do modelo de desenvolvimento open source levou a uma reação de algumas das empresas que possuem a propriedade intelectual como pilar estratégico. A reação foi simples: ?vamos deixar de pensar no software como um produto, e vamos transformar num serviço?.
Os consumidores não pagariam um valor grande para comprar o (direito de uso do) software, mas passariam a usar a infra-estrutura dos provedores de serviço em um modelo pay-as-you-go. Ou seja: ao invés de ter que comprar o carro, o consumidor passou a andar de táxi. O consumidor consegue o que quer e o fornecedor arrumou uma maneira de receber uma recompensa pelo seu trabalho. Todos saíram contentes, certo?
Ainda não. Isso pode ser ótimo para quem não quer ter a dor de cabeça de dirigir o carro, mas é péssimo para aqueles que não querem depender do taxista. É péssimo para aqueles que querem um carro para exercer eles mesmos uma outra atividade econômica.
Mesmo que as empresas não estejam mais cobrando pelo produto, ainda falta um mecanismo para permitir a livre duplicação de um produto depois de acabado.
Por que não o Open Source?
Porque não funciona como estímulo para a inovação. Qual é o projeto que você conheça que foi…
a) desenvolvido desde o começo de forma aberta;
b) razoavelmente original em sua concepção;
c) capaz de recompensar diretamente o idealizador do projeto apenas?
Linux? Cópia do Unix, feito há mais de 40 anos. Apache? Servidores web já existiam. Pessoas que trabalham em projetos de linguagens de programação abertas fazem isso ou por hobby ou são projetos financiados por terceiros. Android? Não há nada de novo.
Nenhum. O modelo open source é ótimo para implementar idéias que já se provaram, mas não funciona como campo de laboratório. Para idéias realmente inovadoras e para empreendedores, as recompensas possíveis não são maiores do que os riscos envolvidos. E as pessoas só trabalham em coisas arriscadas quando a recompensa é proporcional.
Sem contar que é difícil de engolir o papo de que as empresas que produzem software open source podem viver de suporte. Se o produto for realmente de qualidade, é de se esperar que ele não dê dor de cabeça para o consumidor final. Software de qualidade (just works) e dependência de equipe de suporte são qualidades mutuamente exclusivas.
Uma alternativa: o mercado de futuros
Se você já tentou comprar um imóvel, você deve ter percebido que existe a possibilidade de comprar o imóvel ?na planta?. Em miúdos, você fecha um contrato de um imóvel que ainda será construído. Obviamente, quem compra o imóvel na planta acaba pagando um valor menor do que os que compram o mesmo imóvel em etapas posteriores do empreendimento. Isso acontece por que um comprador de imóvel na planta está comprando não só o imóvel, mas está comprando risco. Não há nada que elimine a possibilidade de atrasos na execução, oscilações do mercado e até mesmo que o dono da construtora e sua secretária de 22 anos de idade fujam com o seu dinheirinho para alguma ilha remota do mundo.
Esse risco tem um valor a ser quantificado. Se para o comprador do imóvel o valor do risco é menor do que o desconto, certamente é vantajoso comprar o imóvel na planta. A empreendedora também vê vantagem. Ao ter clientes que compraram o imóvel na planta, ela pode arrumar recursos para iniciar as obras, garantindo a continuidade do empreendimento. Ela pode também não vender algumas das unidades e vender apenas com o imóvel pronto, obtendo assim uma margem de lucro maior.
Não creio ser tão difícil assim emular um modelo parecido para a economia digital. Nesse sistema, as pessoas que desejam algum software (ou música, ou livro, ou filme) compram um produto ?na planta? daquele que for capaz de oferecer o produto ao menor custo, incluindo o risco.
O vendedor, em troca, se comprometeria a disponibilizar livremente o produto do seu trabalho acabado. Dessa forma, temos o melhor dos dois mundos: o produtor só trabalha com a garantia de que será recompensado e o consumidor fica livre para usufruir do que comprou, como quiser.
Há ainda uma óbvia vantagem: se forem várias as pessoas interessadas em um produto similar, elas podem fazer o rateio do custo.
Já existem empresas que tentam levar o modelo adiante. Existe um site chamado Micropledge que atua como um mercado de projetos futuros. Consumidores se comprometem a pagar um pequeno valor em favor de um determinado projeto. Esses compromissos (pledges) são registrados no site e acumulados. Desenvolvedores podem ?dar o seu preço? para que trabalhem no projeto. No instante que o valor acumulado em pledges é satisfatório para o desenvolvedor, o trabalho se inicia. O desenvolvedor só pode receber o dinheiro e as pledges só são cobradas depois que o produto é entregue de forma satisfatória pela maioria das pessoas que fizeram o compromisso.
Na teoria e na prática, é um verdadeiro exemplo de como funciona uma economia de mercado. Entretanto, para que funcione, é preciso que acumule uma massa crítica.
É aí que você entra. [Webinsider]
.
Raphael Lullis
<strong>Raphael Lullis</strong> (raphael@log4dev.com) é Engenheiro de Computação, atua na área de telecom e mercado mobile e um dos autores do <strong><a href="http://log4dev.com/author/rglullis/" rel="externo">Log4dev</a></strong>, blog escrito por desenvolvedores para desenvolvedores.
11 respostas
Felipe, os pontos que você faz são muito bons. Mas eu creio que um projeto como o Micropledge é justamente o ponto para eliminar as questões burocráticas envolvidas com o processo de investimento de risco.
A minha resposta para a maior parte das suas perguntas é Não sei. Acho que a mesma resposta seria dada pelas pessoas que organizam o site.
Parece-me que a intenção é permitir que as pessoas possam participar usando valores irrisórios e só aumentar a sua participação à medida que investidores e desenvolvedores já tenham confiança mútua.
Eu já tratei desse assunto antes no log4dev, em um outro texto. Dê uma olhada e veja o que acha.
Obrigado,
Raphael Lullis
Caro Raphael,
Li os comentários e seus contra-argumentos e a questão da seleção adversa mencionada por Manuel me parece que precisaria ser melhor enfrentada. Acredito que certificações e um cadastro de projetos anteriores bem sucedidos podem ser uma maneira de distinguir os limões. De qualquer forma, pelo que entendi, a efetivação do pagamento só ocorreria após a aprovação dos participantes do fundo mútuo. Nesse caso, tenho dúvidas, sobretudo quando se insere o modelo numa cultura como a brasileira: qual a cobertura legal do compromisso assumido pelo interessado? O que garante que não haja desistências? Se o interessado compromissado já tem o produto na fase de avaliação, como prevenir o comportamento de que ele, ainda que tenha aprovado o produto, declare que não o satisfez somente para desfazer o compromisso de pagamento? Há um terceiro que faz a custódia dos compromissos e avalia sua conformidade à demanda?
Um apinhado geral dos comentários:
@Vinícius, o que faz o preço ser menor é a questão do risco, não do pagamento antecipado. Se você pensar em um modelo de consórcio (de carros ou de imóveis) o consumidor também paga antecipadamente, mas não há desconto.
@Manuel, é de esperar que em um economia de mercado haja competição e leve os preços para baixo. Thats A Good Thing(C). A alternativa é ainda pior: profissionais cartelizados, que estão acostumados a cobrar preços exorbitantes, sem a menor preocupação com qualidade e em satisfazer o cliente.
@André: suporte ou manutenção, tanto faz. Depois que o software estiver pronto e for adequado para as MINHAS necessidades, eu não quero ter que ficar pagando para mais ninguém. A idéia é que o desenvolvimento de software é o desenvolvimento de um produto, e que esse produto não tem que ser obrigatoriamente renovado, se me satisfaz.
Do mesmo jeito que o Office 2000 – por exemplo – satisfaz todas as minhas necessidades e todos reclamam quando a MS fica com a sua política de querer forçar updates a seus usuários a cada dois anos, eu acharia igualmente ruim ter que pagar periodicamente para uma empresa para poder continuar usando o produto.
@Valdir: jamais impliquei que a idéia que software livre é grátis. Justamente pelo contrário. O que eu quis dizer é que as empresas que fazem do desenvolvimento de Open Source a sua marca estratégica (Red Hat, ou o investimento da IBM no Linux, pra citar alguns exemplos) não possuem como característica a inovação tecnológica.
Essas empresas investem no open source para comoditizar produtos que são complementares aos seus. Por exemplo:
– Red Hat vende serviços de TI, então é inteligente fazer com que um produto complementar (Sistemas Operacionais) seja o mais barato possível para o consumidor.
– IBM vende consultoria: então faz sentido que o produto complementar seja barato (Sistemas Operacionais, hardware, ferramentas de desenvolvimento de Software e IDEs) para que o consumidor deixe de gastar seus recursos com os complementares e possa gastar com o produto principal.
@Alexandre: os sistemas e sites que você desenvolve são open source, e desenvolvidos pensando em livre distribuição? Por acaso algum cliente pediu que você fizesse o site para ele e permitiu que um concorrente usasse a tecnologia? Creio que não…
Em geral, o ponto central do Micropledge é que ele pode ser pensado como uma forma de fomentar o desenvolvimento de software que é comum a diversos clientes.
Exemplo, com números apenas para ilustração:
Se minha empresa precisa de um sistema para gerenciar, sei lá, fluxo de caixa, eu posso comprar um software de caixinha (software como produto) e vai me custar R$100 reais . Posso também usar uma solução hosted (software como serviço) e pagar R$8/mês.
Obviamente, a pessoa ou empresa que desenvolveu o software quer receber muito mais do que o valor pelo qual ele vende uma caixinha. Digamos que o desenvolvedor vai trabalhar 3 meses no produto, e gostaria de receber R$ 10 mil reais. Para que ele consiga isso, ele precisa vender 100 caixinhas, ou ter contratos de 1250 usuários * mês. Se o desenvolvedor conseguir essas metas, bom para ele. Se não, o prejuízo é dele.
O problema desse modelo é que não há livre duplicação de um bem, e o faturamento do produtor está ligado ao seu sucesso em vender unidades artificais do produto. A caixinha não custa R$100 reais. Custa muito menos. O que custa é o trabalho anterior, certo?
Outro problema: digamos que o desenvolvedor tenha tido sucesso e tenha vendido 2000 caixinhas. Ele terá ganho o dobro do que esperava. Isso serve como incentivo para que ele, ao invés de voltar a trabalhar e desenvolver outros produtos, que ele tente continuar vendendo mais caixinhas. É bem mais provável que ele vá gastar recursos com marketing do que com desenvolvimento.
Dificilmente o desenvolvedor vai chegar e falar Ok, já recebi o que eu queria por esse produto. A partir de agora, as cópias vão ser liberadas de graça e com o código-livre. O produtor tem muito mais incentivo a pensar em manter o produto artificialmente caro. E isso impede que outras empresas (empresas que não querem pagar R$100, mas aceitariam pagar R$10) consumam o produto, MESMO quando o produtor já conseguiu receber o que ele considerava justo pelo tempo que ele dedicou ao desenvolvimento.
O modelo do Micropledge é justamente para tentar resolver esses problemas. Se há justificativa no mercado para que um desenvolvedor consiga R$10 mil em um software de fluxo de caixa, ele poderia chegar no Micropledge e falar quero desenvolver um software de fluxo de caixa, e quero receber R$10 mil reais para isso.
Os consumidores que já pagariam R$100 reais por esse produto pronto, poderiam fazer pledges de R$ 50 reais. E os que não comprariam o produto por R$100, mas aceitariam comprar por R$20 podem fazer pledges de R$10, por exemplo.
Se houver muito interesse dos consumidores, o valor desejado pelo produtor será rapidamente alcançado. Se não houver interesse, não será alcançado, mas pode ser que chegue a um valor que o desenvolvedor aceite (por R$8 mil, até que vale a pena). De qualquer forma, elimina-se o risco para todas as partes e o produto não é mantido artificialmente caro, pois ele será liberado livremente depois que for desenvolvido.
Ao menos, esses são os princípios que eu vejo por trás do Micropledge. Quem vai reger isso no fim das contas é a velha lei de oferta e demanda.
Enfim, é isso. Eu agradeço ao feedback de todos. Dá pra ver que muitas idéias foram omitidas do texto. Talvez eu tenha (erradamente) assumido que os leitores já estivessem familiarizados com esses conceitos.
Interessante, mais interessante ainda os comentários… porém, me corrijam se entendi errado, mas o modelo de desenvolvimento de sites não é praticamente isso?
O cliente chega na empresa, diz o que quer, começa a pagar e só então o produto começa a ser produzido. Nada além de um contrato garante que o produto será entregue (risco) e empresa só produz com o dinehiro na mão (ou pelo menos parte dele).
Desde que conheço e trabalho com internet, sempre foi assim.
Muito bom o seu artigo, tem informações bem interessantes, contudo é dificil – e até um erro – chegar a um único modelo ou a um modelo ideal.
Acredito que para cada nicho de clientes, para cada necessidade, há um modelo melhor ou pior a ser adotado. O modelo da microPledge, como o nome diz, é micro, coisa pequena, você deve imaginar que nenhuma empresa de porte razoável vai entrar nessa, nem um desenvolvedor que ja tenha ferramentas sólidas… pode até ser uma entre várias alternativas, como existe tambem um outro servico em que o cliente diz o software que quer, como quer, recebe e responde perguntas dos desenvolvedores, que tambem dao um preço pelo projeto, e nesse modelo ganha que cobrar menos, tipo um leilão ao contrário. Esse modelo existe, mas é bom pra todo mundo? O tipico contrato de prestação de serviço é mais do que aberto a possibilidades, negociáveis caso a caso com um cliente.
O modelo open source promove a liberdade do código, nao tem mada a ver com ser grátis, nesse ponto voce errou ao fazer essa confusão e em dizer que não serve, na verdade serve tanto quanto os outros modelos sugeridos. Eu posso – e faço – projetos open source (código aberto) e cobro sim pelo software, a diferença é que o cliente fica com o codigo e ele proprio, caso queira, pode modificar. A principio esse modelo poderia servir pra me tirar da jogada, ou poderia perder grana com manutenção ja que o codigo está com o cliente, mas pelo contrário, é um circulo de confiança onde o codigo aberto apenas da a alternativa ao cliente, mas ele sempre vai preferir fechar novos contratos com o programador original, por razoes obvias. Em contrapartida, o desenvolvedor tem a chance de usar, comercializar ou negociar da forma como queira o codigo, e ainda melhorar esse codigo contribuindo com a comunidade (seria o lado hobby da coisa) para que o codigo melhore, realimentando o ciclo de codigos cada vez mais seguros e estaveis.
Na área da educação a distância, um software open-source tornou-se referência em todo o mundo: chama-se Moodle (www.moodle.org).
Utilizado em 70 países, incluindo o Brasil – adotado inclusive por diversas universidades em seus departamentos de educação a distância.
É um bom exemplo de iniciativa de software como serviço que deu certo.
Acíldon
Bom texto, faz pensarmos em muitas coisas sobre o mercado, mas algo me deixou muito encabulado:
Sem contar que é difícil de engolir o papo de que as empresas que produzem software open source podem viver de suporte. Se o produto for realmente de qualidade, é de se esperar que ele não dê dor de cabeça para o consumidor final.
As tais empresas não vivem do suporte, mas sim da manutenção, o que é algo completamente diferente, estamos tratando na manutenção a evolução do software como novas funções, maior escalabilidade e personalizações, afinal os domínios dos softwares mudam e cada empresa tem suas peculiaridades.
Interessante o texto, embora a idéia não seja realmente tão nova assim.
De qualquer modo, eu não acredito em um futuro de um modelo único. Acho que vários modelos de comercializar código e cultura vão conviver, e cada experiência se aplicará melhor a cada caso.
Mas este artigo me fez pensar um pouco com os meus botões.
Interessante o texto, especialmente para suscitar reflexão sobre o tema. No entanto, penso ainda que a solução para este problema passa por algum tipo de publicidade, cujo AdSense do Google (e afins) é apenas embrião.
Abraços,
Alexandre Gameiro
http://www.compensar.blogspot.com
micropledge é uma novidade?
Se eu percebi bem, este é mais um site tipo rent-a-coder.
Pelo que sei esses sites não são a melhor forma de compensar quem gostaria de viver do desenvolvimento de software, dado que a tendência é para o projeto ser dado a quem aceitar fazer por menos dinheiro. Por isso muitas vezes quem acaba por pegar é quem está mesmo desesperado por não ter trabalho.
Tendo em conta que não há falta de emprego nesta área e o que o mercado carece é de profissionais qualificados, quem sobra para participar de sites deste género normalmente não são os profissionais mais qualificados.
A idéia é interessante, mas falha num ponto básico na comparação com os imóveis na planta: o desenvolvedor só recebe quando o produto é entregue.
Quando compramos o imóvel na planta, pagamos menos porque começamos a pagar imediatamente no ato da assinatura do contrato. É assim que o construtor consegue mais recursos para iniciar a construção.
Já no caso do microPledge, o desenvolvedor não começa a receber quando o cliente assina o contrato.
Em outras palavras, o desenvolvedor continua arcando sozinho com o risco.
Seria uma mudança no modelo de desenvolvimento?