Como o desenvolvimento de software GNU se sustenta economicamente?

Peço desculpas se esta questão está fora de tópico, mas é simultaneamente uma questão de economia e de programação. Se for para outra comunidade SE, por favor me indique.

Em teoria, o software GNU é inteiramente desenvolvido por voluntários durante seu tempo livre ou por empresas que financiam programadores para desenvolver software GNU (usando a renda de outro setor de sua atividade).

Entendo como ele pode funcionar perfeitamente bem em projetos de pequena escala que podem ser realizados em alguns fins de semana chuvosos por um único indivíduo (digamos, por exemplo, um jogo de sudoku), porque afinal de contas a programação de computadores é um hobby extremamente divertido e gratificante, e não tenho problemas em ver pessoas desenvolvendo programas pequenos ou médios durante seu tempo livre e compartilhá-los com o mundo.

O problema é que isso é extremamente ruim para programas maiores pelos seguintes motivos:

1. Por mais divertida que seja a programação, à medida que o projeto que precisa ser implementado se torna maior, o tempo necessário para implementar a funcionalidade desejada cresce extremamente rapidamente. Um programa em larga escala leva uma incrível quantidade de tempo para ser desenvolvido, por exemplo, pode levar 15 anos de tempo livre e férias para um indivíduo programar um sistema operacional e, quando o software for lançado, estará completamente obsoleto .
2. À medida que outras pessoas escrevem programas de outra maneira como você faria, ler e entender o código de outra pessoa leva muito tempo, na maioria dos casos, tanto quanto escrever seu próprio código do zero. Modificar o código de outras pessoas e tentar melhorá-lo, como é incentivado pela filosofia GNU, é quase tão demorado quanto o desenvolvimento de seu próprio clone do referido programa com a funcionalidade que você gostaria de adicionar.
3. Assim que duas ou mais pessoas tiverem que colaborar para desenvolver um programa maior, isso cria muitos problemas de tomada de decisão que nunca surgiriam em um projeto de desenvolvedor único. O resultado é que, por exemplo, se um grupo de 2 programadores colaborar para um projeto que levaria 10 anos para um único homem fazer, eles não o farão em 5 anos, mas provavelmente em 8.
4. Se as pessoas que colaboram para o mesmo projeto se encontrarem apenas na Internet, é fácil que um membro do projeto desapareça repentinamente (ou porque ele perdeu o interesse ou porque ele não pode mais estar fisicamente na Internet), tornando a colaboração ainda mais mais difíceis

Portanto, enquanto eu entendo perfeitamente como programas simples podem ser desenvolvidos com a mentalidade GNU, absolutamente não vejo como programas enormes como o GNU / Linux ou o gcc são possíveis nesse modelo. O gcc tem cerca de 7 milhões de linhas de código. Eu sei que linhas de código não significam muito, pois em um estágio posterior de um projeto, o programador mais produtivo é aquele que removerá as linhas de código (simplificando e / ou otimizando o projeto), mas isso dá uma visão geral da quantidade enorme de um projeto gcc é.

Então, em teoria, qualquer pessoa pode modificar livremente o gcc durante seu tempo livre, mas na prática? Foi desenvolvido por pessoas muito profissionais como um trabalho, não como um hobby. Qualquer um que criar um compilador como hobby passará a desistir, pois o custo / benefício não vale a pena:

• Desenvolver um programa grande é um projeto tão grande a longo prazo, que eles preferem usar seu tempo livre para realizar outras atividades que sejam mais gratificantes ou agradáveis ​​a curto prazo
• Se eles desenvolvessem um programa grande de qualquer maneira, prefeririam fazê-lo por uma empresa que os pagaria do que fazê-lo gratuitamente.

Para atrair as pessoas interessadas em desenvolver um programa como GNU / Linux, gcc ou Open Office a longo prazo, deve ser gratificante. Então, minha pergunta é: Por que há pessoas contribuindo para um grande projeto GNU, se não estão recebendo um salário por isso?

Gostaria de começar dizendo que não sou programador e nunca contribuí com nenhum projeto de código aberto. No entanto, estou interessado em código aberto há muito tempo e acredito que entendo os conceitos gerais de código aberto e como ele funciona.

Para começar, gostaria de dizer que o código aberto não significa que você não pode ganhar dinheiro com o software. Significa apenas que o código deve estar disponível ao público. Empresas como Red Hat e Canonical ganham dinheiro não vendendo o software, mas vendendo seus conhecimentos. Se eu não for minha empresa para executar um servidor Linux, posso obter o software gratuitamente. Mas preciso de alguém para instalá-lo, configurá-lo e dar suporte. É aqui que um especialista da Red Hat entra e ganha dinheiro. Para a empresa, faz sentido, porque contratar um especialista próprio provavelmente seria muito mais caro. Isso também incentiva essas empresas a contribuir com o código. Eles querem que seu produto seja bom para que as pessoas o usem e por seus serviços.

Mas vamos falar sobre seus pontos de vista sobre escalabilidade.

1. O legal do código aberto é que você não precisa desenvolver tudo do zero. Um sistema operacional como o Ubuntu não foi construído por uma única pessoa. Em vez disso, muitas pessoas contribuíram para diferentes partes do sistema (na verdade, acho que seria difícil encontrar uma pessoa com todas as habilidades necessárias para criar um sistema operacional eficaz). Por exemplo, o pessoal do Ubuntu não desenvolve o kernel do Linux. Eles apenas usam um desenvolvido por outros. Então, o que era sem código aberto provavelmente impossível, agora é possível, porque você pode aproveitar o trabalho de outras pessoas.

2. Ler e entender os outros não consome mais tempo do que escrever os seus. Pelo menos não em muitos casos. Além disso, você não precisa entender todo o código que usa. Se eu quiser escrever um programa para Linux, não preciso entender como todas as partes desse programa funcionam em detalhes. Eu só tenho que saber o que eles fazem. Posso então pegar essas partes e juntá-las a outras para criar meu programa. Ou posso pegar um programa existente e modificá-lo de acordo com minhas necessidades.

3. ferramentas como git e github tornam incrivelmente fácil a colaboração. Você acabou de obter o código e fazer modificações. Em seguida, você as envia à pessoa responsável pelo projeto. Se for bom, será aceito.

4. as pessoas entram e saem de projetos o tempo todo. Mas se o projeto for popular, o suficiente estará trabalhando nele.

Aqui estão algumas razões pelas quais o código aberto funciona.

1. Eu acho que a principal razão pela qual o software de código aberto se tornou tão bom é que o grande número de pessoas trabalhando em um projeto garante um nível de conhecimento que é difícil arquivar em uma pequena equipe de desenvolvedores. Embora possa parecer estranho, esse único fato parece compensar todos os problemas negativos que podem surgir no código aberto.

2. Na programação comercial, o projeto morre com a empresa. Vamos dizer que por algum software de uma empresa que fecha. Em seguida, você ferrou, pois você não receberá atualizações e correções de bugs, e precisará de um novo software para acompanhar. Com o código aberto, você pode encontrar outra empresa para dar suporte ao seu software ou desenvolvê-lo.

Se você ainda estiver interessado, sugiro que você leia A Catedral e o Bazar

O desenvolvimento de software de código aberto é feito por diversas razões, mas é um mal-entendido comum que seja feito principalmente por entusiastas ou profissionalmente, mas como um projeto paralelo. Estou respondendo a esta pergunta para software livre em geral, não para software licenciado GNU em particular. Mas minha resposta é inclusiva.

Digamos que eu sou desenvolvedor de software (eu sou) e estou trabalhando em um projeto de software complexo (eu sou). A boa arquitetura divide um problema em partes independentes e, à medida que o desenvolvimento avança, os desenvolvedores frequentemente reconhecem que alguma peça de que precisam é aquela que é comum a muitos problemas. Aqui estão alguns caminhos típicos adiante:

1. Eles mesmos desenvolvem essa peça e ela se torna propriedade da empresa. Ou eles compram uma solução de código fechado de outra empresa.
2. Eles encontram um projeto de código aberto que resolve esse problema e é um ajuste perfeito e a licença é adequada. Eles apenas o incorporam ao projeto, que pode ou não precisar de código aberto, dependendo da licença e de como é usada. Eles não contribuem de volta para o projeto.
3. Eles encontram um projeto de código aberto que quase resolve esse problema, mas tem defeitos ou deficiências. Eles aprimoram e podem contribuir com essas melhorias de volta ao projeto base.
4. Eles não encontram o que gostam o suficiente, então iniciam seu próprio projeto e decidem abri-lo.

As vantagens do 2-4 são que mais pessoas acabam contribuindo para o design e o código do projeto, e ele entra em um tipo de ecossistema em que idéias fortes sobrevivem (por procriação, se você quiser) e outras fracas não. Correção de erros e adição de recursos tornam-se esforços da comunidade. Nos cenários 2 e 3, os desenvolvedores que adotam o projeto se beneficiam de sólidos princípios de engenharia e código maduro. 3 e 4 são correlativos. No cenário # 4, os desenvolvedores se beneficiam quando outras pessoas adotam e melhoram o código e devolvem (# 3). É vantajoso contribuir de volta ao projeto para que suas melhorias sejam consolidadas à medida que outras correções e melhorias forem superadas, das quais você continua se beneficiando. Na minha experiência, todos esses cenários são comuns.

No meu projeto de software atual, sou um dos 12 desenvolvedores e trabalho em um sistema há cerca de dois anos. Incorporamos cerca de 5.000 projetos de código aberto! Geramos apenas alguns novos projetos de software livre e contribuímos com cerca de meia dúzia. Não somos cidadãos particularmente bons nesse caso (outras empresas são muito melhores), mas isso mostra a escala completa de como tudo isso funciona. Mesmo em pequenos projetos, as contribuições do código aberto podem ser facilmente numeradas em dezenas ou centenas. Se não usássemos nenhum software de código aberto, os custos de desenvolvimento aumentariam de 100 a 10.000.

A escalabilidade ocorre por causa da modularidade do design e também por esse tipo de processo de sobrevivência do mais apto, em que o código pode ser refatorado, bifurcado e assim por diante. A capacidade de sobrevivência geralmente é melhor do que as alternativas proprietárias, porque mesmo que o código não seja mais mantido, ele existe e outras pessoas que encontram valor nele podem manter seu próprio garfo. As empresas vêm e vão e os funcionários são contratados e saem ainda mais rapidamente. Se você adicionar uma dependência de software para a qual não possui o código-fonte ou apenas uma pequena equipe interna para manter, terá um risco substancial. Grandes projetos como o kernel do Linux, gcc, Android e outros geralmente têm um grande número de empresas contribuindo ativamente.

Não é verdade que é mais fácil escrever um código bom e correto do que lê-lo (na maioria dos casos). Você também não precisa ler todo o software que está usando, mesmo que esteja fazendo modificações. Você tem que mergulhar profundamente em seções e ler muito, mas não o todo. Eu poderia dizer mais aqui sobre testes de unidade, mas omitirei isso por uma questão de brevidade.

A maioria dos softwares de código aberto não é desenvolvida por pessoas em seu tempo livre. A prática é tão fenomenalmente benéfica que funciona sem um mercado otimizado. Pessoalmente, suspeito que algum tipo de abordagem orientada pelo mercado ajudaria muito, mas não sei como essa abordagem pode ser. As pessoas argumentam que existe um mercado em que a reputação é a moeda, mas não acho que esse seja um modelo preciso. Uma moeda no trabalho é o tempo necessário para adotar um novo software. Você deseja encontrar e usar algo ativo, simples, com boa documentação, etc. Portanto, como um comprador, você procura o produto de melhor qualidade pelo menor tempo investido.