Como foi criado o Linux? Os Processos Por Detrás do Gerenciamento de 13.500 Desenvolvedores

Você provavelmente já usou Linux hoje – especialmente se você não tem um iPhone. E se você navegou na web hoje, há uma grande chance do site que você visitou ter sido servido pelo Linux também.

Linux é um sistema operacional, mas ao contrário de softwares como Microsoft Windows e macOS, Linux foi desenvolvido por uma comunidade auto-organizada de voluntários.

Todos os anos, com o esforço de mais de 10.000 desenvolvedores e processos evolutivos para gerenciar a escala de trabalho, o kernel Linux cresceu para mais de 20.000.000 de linhas de código no total. Ele forma a base estável para…

• Todos os telefones e tablets Android do planeta
• 66% dos servidores do mundo
• 100% dos 500 maiores supercomputadores

Esta tecnologia não veio de uma equipe orquestrada com um grosso livro de políticas e camadas de gerenciamento. Ela veio de algumas políticas cuidadosamente escolhidas e culturalmente incorporadas, e de uma missão compartilhada.

Neste post, eu vejo como uma tecnologia tão essencial, complexa e importante poderia ter sido produzida tão eficazmente sem a estrutura de gerenciamento tradicional. Mas primeiro…

Por que o kernel Linux é tão impressionante?

Um kernel é o próprio núcleo de um sistema operacional. É o orquestrador de todos os outros processos de software no seu computador ou smartphone, dividindo recursos e fornecendo uma forma para o hardware e software comunicarem.

Nas palavras de G. Pascal Zachary, o kernel de um sistema operacional pode ser comparado a “um chefe de família que foi tão diligente que serviu a família lá em cima a qualquer momento, noite ou dia de plantão, tratando de cada pedido”. O kernel mantém a máquina funcionando, não importa o que ele venha a enfrentar. Foi um salto essencial do mundo onde os computadores podiam executar apenas uma aplicação de cada vez, para o mundo que conhecemos hoje.

O kernel Linux, baseado no UNIX, foi desenvolvido no início dos anos 90 por Linus Torvalds.

Por volta de 1991, o Torvalds tinha lançado a primeira versão – apenas 10.000 linhas de código – e provocou excitação na comunidade de desenvolvimento de software com o humilde anúncio de e-mail visto acima.

Amparado pelo poder colaborativo da internet pela primeira vez na história, os desenvolvedores contribuíram com suas próprias habilidades de codificação e tempo de teste gratuitamente à medida que a base de usuários do kernel explodia em tamanho. Se eles estivessem dispostos a experimentar, os usuários poderiam tentar juntar um patch se encontrassem algo quebrado, e discutir como melhorar o software.

Como Eric S. Raymond olha em seu livro sobre software de código aberto, The Cathedral and The Bazaar, o gerenciamento de desenvolvedores de kernel por Linus Torvalds cresceu para ser eficiente, auto-organizador, e mais do que capaz de produzir uma das peças de software mais complexas e amplamente utilizadas no planeta.

Nesta peça, eu olho para os processos e políticas que surgiram como suporte necessário para o projeto do kernel Linux como ele tem evoluído ao longo dos anos.

Como, sem processo formal, como um estudante de 21 anos de informática, Torvalds guiou o projeto do kernel até as alturas que ele atingiu…

…E o que há de tão difícil no gerenciamento de desenvolvedores, de qualquer forma?

De acordo com pesquisas do Geneca, mais de 75% dos executivos de negócios e de TI acreditam que seus projetos de software estão fadados ao fracasso. A dificuldade de produzir software confiável e gerenciar aqueles que o fazem gerou inúmeros livros de gestão, estudos de produtividade e frameworks de liderança.

“A pura complexidade do software significa que é impossível testar todos os caminhos”, escreve Paul Smyth, CEO da Kynetix, no Finextra. “Uma aplicação de software é como um iceberg – 90% dela não é visível. A maior complexidade da aplicação está abaixo da linha de água”.

Any software project of significant size, quer seja um CRM ou um sistema operativo como o Microsoft Windows, é demasiado grande para caber na cabeça de qualquer pessoa. Requer o conhecimento compartilhado e a colaboração de muitos colaboradores. Isto significa que os desenvolvedores trabalham em partes especializadas da aplicação enquanto precisam entender como seu trabalho afeta o todo.

“Ninguém pode compreender tudo”, observou o gerente de uma equipe de 250 desenvolvedores de software da Microsoft enquanto eles estavam construindo um sistema operacional do zero, de acordo com G. Zachary in Show stoppers! um livro que conta a história de uma equipe de desenvolvedores de software da Microsoft correndo para completar o Windows NT em 1993.

Quanto maior o projeto, mais lentas as mudanças podem ser implementadas. A pesquisa do Steve McConnell prova isso, descobrindo que o código é escrito a uma taxa 5-10x mais lenta em projetos de mais de 10.000.000 linhas. Além disso, um estudo das práticas de desenvolvimento da Microsoft revelou que existem aproximadamente 10-20 bugs para cada 1.000 linhas de código.

Embora o tamanho do projeto e o número de contribuidores, o desenvolvimento do kernel Linux acontece rapidamente e sua grande e entusiasmada base de usuários captura bugs e escreve patches para enviar rapidamente melhorias.

Em seus primeiros dias de desenvolvimento – por volta de 1991 – não era inédito para o Torvalds lançar mais de um novo kernel por dia. Agora, em um estágio mais maduro e dependente de 80% dos smartphones e da maioria dos servidores de internet, o período de lançamento desejado é de 8 a 12 semanas. A cada lançamento, o kernel vê uma média de 10.000 patches de 2.000 desenvolvedores – todos lutando com mais de 20.000.000 linhas de código.

Quais são as técnicas e processos de gestão necessários para orquestrar este nível de colaboração e produtividade? Bem, elas não foram escritas por um chefe de departamento ou autor de um livro de negócios. Eles desenvolveram organicamente, com orientação do “ditador benevolente” do projeto, Linus Torvalds.

Even em sua forma nascente, o núcleo Linux estava sendo colaborado por centenas de voluntários que submeteram seu trabalho diretamente ao Torvalds para revisão. Como um hacker mal-humorado e anti-social gerenciou disputas, contribuições e comunicação entre milhares de desenvolvedores por quase duas décadas?

Como as políticas, processos e 15.000.000 linhas de código são documentados

Não como uma organização tradicional, os novos desenvolvedores do kernel não estão estritamente ‘onboarded’ dentro da comunidade, mas esperavam ter lido e entendido completamente a documentação introdutória. O foco do projeto do kernel na documentação foi uma necessidade tanto por causa da complexidade técnica quanto pelo grande número de desenvolvedores.

Numerosos FAQs, how-tos e guias de como começar existem no repositório de documentação do kernel, e ainda mais em wikis criados e mantidos por desenvolvedores do kernel ao redor do mundo.

A forma como a documentação é escrita e melhora reflete a forma como o kernel é desenvolvido; colaborativamente, abertamente e incrementalmente.

Ao aproveitar os olhos e as especializações de um enorme grupo de pessoas, a documentação pode ser criada, testada e revisada muito mais eficientemente do que se feita por uma equipe menor e dedicada. Para dobrar a Lei de Linus em termos que um editor de conteúdo possa entender melhor: com olhos suficientes, todos os typos são óbvios.

Como material para suporte técnico, a comunidade de desenvolvimento do kernel criou uma biblioteca de documentação de processos projetada para suavizar o lado humano da colaboração.

Na página de índice de “A guide to the Kernel Development Process”, um parágrafo diz:

“O propósito deste documento é ajudar desenvolvedores (e seus gerentes) a trabalhar com a comunidade de desenvolvimento com um mínimo de frustração. É uma tentativa de documentar como esta comunidade funciona de uma forma que seja acessível para aqueles que não estão intimamente familiarizados com o desenvolvimento do kernel Linux (ou, de fato, desenvolvimento de software livre em geral)”

Ninguém nasce com um conhecimento inato do sistema de controle de versão git, ou como submeter um patch para uma lista de discussão. É por isso que o processo de desenvolvimento deve ser documentado – explicando a mesma informação básica para uma pessoa de cada vez não escalona!

Como a comunicação entre 1000s de desenvolvedores é gerenciada

Conversações entre os desenvolvedores aconteceram em aberto, nas listas de discussão de desenvolvimento do kernel. Até hoje, o e-mail ainda é a ferramenta preferida por causa de sua simplicidade. Estas listas de discussão foram arquivadas e organizadas, formando um corpo de documentação viva e história.

O efeito de comunicar em público tem um efeito semelhante aos benefícios de usar uma ferramenta como Slack hoje – qualquer informação é tornada segura e pesquisável, ao invés de evaporar. No entanto, para gerenciar uma tal mangueira de fogo de informação, o projeto kernel desenvolveu uma política de comunicação e a distribuiu como parte da documentação.

Comunicação e colaboração em tal escala não era possível antes da internet, então projetos iniciais como este precisavam escrever e distribuir soluções rápidas e eficazes para o gerenciamento da comunidade, etiqueta e problemas de apresentação de código.

A documentação do kernel inclui regras para a submissão de correções, de modo a facilitar a revisão, edição e teste do código contribuído por outros. Isto significa que as correções devem ser enviadas por e-mail em texto simples, não anexadas. As correções devem ser mantidas uma vez por email, e obedecer a diretrizes específicas de estilo de codificação:

Esta padronização rígida é absolutamente necessária para um projeto tão grande quanto o kernel, como é para projetos de qualquer tamanho. Ela ajuda a reduzir erros em um espaço onde um único erro pode ter um efeito de ondulação que produz código instável no futuro, ou desperdiça o tempo de muitos testadores e desenvolvedores.

Como decisões críticas são (não) tomadas

Para citar Torvalds:

“O nome do jogo é para evitar ter que tomar uma decisão. Em particular, se alguém lhe disser “escolha (a) ou (b), nós realmente precisamos que você decida sobre isso”, você está com problemas como um gerente. As pessoas que tu geres conhecem melhor os detalhes do que tu, por isso, se eles vêm ter contigo para uma decisão técnica, estás lixado. Você claramente não é competente para tomar essa decisão por eles”. – Documentação de Desenvolvimento do Kernel Linux

Além de evitar uma hierarquia gerencial, o projeto Linux tinha regras e documentação claras que ajudavam a tomar decisões sem a necessidade de discussão, debate, ou (muitas) guerras de chamas em listas de discussão. Uma olhada nos arquivos irá mostrar que a parte da guerra de chamas nem sempre é possível, mas o que é possível é criar uma política que negue o peso da decisão.

“Assim, a chave para evitar grandes decisões torna-se apenas evitar fazer coisas que não podem ser desfeitas. Não se deixe enganar por um canto do qual não se pode escapar. Um rato encurralado pode ser perigoso – um gerente encurralado é apenas lamentável.”

Show Stoppers! revela que a filosofia de Bill Gates é semelhante. Ele “admirava programadores e invariavelmente os colocava a cargo de projetos, onde ambos poderiam gerenciar e programar para evitar uma situação em que gerentes profissionais, sem experiência em programação ou com conhecimento ultrapassado, mantivessem o controle”.

Como os contribuidores são orientados em torno de um forte objetivo comum

No caso do Linux, como é com muitos projetos open source populares, o kernel não surgiu tendo sido projetado colaborativamente por um grande grupo de contribuidores; ao contrário, foi melhorado incrementalmente sem tomar decisões que desestabilizassem a forte base de trabalho até agora. Isso se encaixa bem na filosofia do Torvalds sobre a tomada de decisões em gerenciamento, mas também com uma filosofia embutida no próprio código.

Linux é baseado no UNIX, que é um sistema operacional anterior projetado em torno de um conjunto de princípios semelhantes ao zen. Como explicitamente declarado na filosofia do UNIX:

“Conceber e construir software, mesmo sistemas operacionais, para ser experimentado mais cedo, idealmente dentro de semanas”. Não hesite em jogar fora as partes desajeitadas e reconstruí-las.”

Both Torvalds e Raymond (que buscaram replicar o sucesso da construção da comunidade Torvalds) descobriram que o lançamento precoce e muitas vezes ajudou a reunir os colaboradores em torno de um projeto excitante e crescente no qual eles podem ver um futuro. Raymond resumiu-o a duas coisas fundamentais que um projeto não pode deixar de fazer quando lançado ao mundo:

1. Executar
2. Convitar potenciais co-desenvolvedores (usuários) que o projeto pode evoluir para algo grande em breve

É com esses mesmos princípios que muitos dos lançamentos de hoje – Process Street incluíram:

Acima está Process Street em 2014. Assine uma conta para ver até onde chegamos.

É este um processo repetível?

Na superfície, o súbito encontro de uma das mais intrincadas criações humanas parece ser alquimia. Mas, ao separar os componentes, é mais fácil ver um processo subjacente. No momento de escrever The Cathedral e The Bazaar, Eric S. Raymond estava simultaneamente a executar o desenvolvimento de um cliente de email de código aberto. Ao fazer o open-sourcing, Raymond estava tentando replicar o envolvimento da comunidade e o sucesso final do projeto kernel.

Muitos dos princípios básicos do modelo Bazaar, como ele o cunhou, serão imediatamente familiares a qualquer um no mundo da inicialização:

• Muito bom trabalho de software começa arranhando a coceira pessoal de um desenvolvedor.
• Tratar seus usuários como co-desenvolvedores é a sua rota menos complicada para a melhoria rápida do código e depuração eficaz.
• Largar mais cedo. Solte frequentemente. E ouça seus clientes.
• Dado um beta-tester e uma base de co-desenvolvedores suficientemente grande, quase todos os problemas serão caracterizados rapidamente e a correção óbvia para alguém.
• Se você tratar seus beta-testers como se eles fossem seu recurso mais valioso, eles responderão tornando-se seu recurso mais valioso.
• A próxima melhor coisa a ter boas idéias é reconhecer boas idéias de seus usuários. Às vezes a última é melhor.
• As soluções mais impressionantes e inovadoras vêm da percepção de que o seu conceito do problema estava errado.
• Para resolver um problema interessante, comece por encontrar um problema que seja interessante para você.
• Desde que o coordenador de desenvolvimento tenha um meio de comunicação pelo menos tão bom como a Internet, e saiba liderar sem coerção, muitas cabeças são inevitavelmente melhores que uma.

Em suma, é um processo que se pode repetir. E um que tem sido adotado com sucesso do mundo do código aberto para a mentalidade de inicialização. Ele se manifesta em ágil, enxuto, seis sigma, e as atitudes e políticas iniciais de hoje se desenvolveram. Embora não seja mencionado com frequência na mesma conversa, a metodologia que evoluiu em torno dos sistemas operacionais iniciais compartilha muito com a idéia de hoje de iterar sobre um produto mínimo viável.