Mas será que um projeto gerenciado melhor por uma única pessoa com a palavra final ou através da construção de consenso com um comitê de várias pessoas?

Quando você está escrevendo código para um empregador, seja uma empresa ou um cliente, você geralmente sabe quem está no comando. Você tem líderes de equipe que aprovam PRs, diretores e gerentes de produtos que determinam os recursos para o próximo lançamento, e um CTO e CEO que tomam as grandes decisões.

Com código aberto, essas linhas de autoridade podem ser mais embaçadas. Os contribuintes são voluntários e podem ir e vir quando quiserem. Determinar como as decisões são tomadas e os projetos avançam é chamado de governança. Dependendo do projeto, o estilo de governança pode ser tão aberto quanto o próprio código, ou tudo pode depender da liderança de um único fundador, às vezes referido como um ditador benevolente para a vida (ou BDFL, para abreviar). Alguns nomeiam um conselho por mérito e votos comunitários, enquanto outros têm patrocinadores corporativos que escolhem seu povo para tomar decisões.

Porque não importa o quão bem-intencionado e livre um projeto seja, em algum momento, para ter sucesso em escala, as decisões precisam ser tomadas e os conflitos precisam ser resolvidos. Um pequeno projeto pode operar com regras compartilhadas não ditas. Uma vez que um projeto forma uma comunidade maior, os processos para tomar essas decisões precisam ser anotados e explicitados para que novos colaboradores saibam como se engajar com sucesso. "É um pré-requisito fundamental para alcançar qualquer tipo de escala", disse Tim Lehnen, CTO da Drupal. 

A governança, não importa a forma que tome, está lá para promover o progresso do projeto de código aberto e incentivar as contribuições. "É crucial criar estruturas que apoiem os colaboradores e que ajudem a garantir que suas contribuições sejam reconhecidas", disse Nicholas Matsakis,engenheiro principal de pesquisa da Mozilla e membro da equipe do núcleo rust e co-líder das equipes de compilação e design de idiomas. "Afinal, a principal força da OSS é sua capacidade de atrair tantas pessoas. As pessoas ficam por perto quando seus esforços são valorizados e podem ter um impacto no projeto."

" O código aberto pode ter uma cultura de cowboy", que tem estado no conselho da fundação .NET e no OpenJS Cross Project Council. "Quando você introduz guardrails, você garante que há um ambiente seguro, encorajador e aberto para que cada projeto seja bem sucedido."

Falei com várias pessoas envolvidas em projetos da OSS para ver se os guardrails mais eficazes vêm de um BDFL, uma única pessoa com a palavra final, ou através da construção de consenso com um comitê de várias pessoas.

Estilo BDFL: Heavy é a cabeça que usa a coroa

O termo "ditador benevolente para toda a vida" foi cunhado por Guido van Rossum, o criador de Python, principalmente como uma piada, mas o nome ficou. O termo cresceu para cobrir qualquer projeto de código aberto liderado por fundadores,incluindo o kernel Linux, Drupal, Clojure e Ruby. Há um número significativo de projetos populares da OSS que dependem de um fundador dedicado para governá-los, então deve haver alguns benefícios para ele.

Perguntei à comunidade sobre isso na Open Source Stack Exchange. "Sempre vi o modelo BDFL como a meio caminho entre uma estrutura tradicional de projetos de código aberto e uma estrutura tradicional de projetos corporativos", respondeu um usuário que atende pelo BTA. "Você tem a abertura, transparência e cultura geral da OSS, mas com um único gerente de projeto forte para tomar decisões de alto nível e direcionar o esforço geral."

Um BDFL pode sinalizar que um projeto tem uma visão forte e manterá essa visão a longo prazo. "Permite que a liderança se desenvolva e se atenha a uma visão coesa de longo prazo, em vez de uma série de líderes de curta duração constantemente mudando planos e direções", continuou bta. "Se você está alinhado com o BDFL em termos de visão para o projeto, contribuir para um projeto gerenciado pelo BDFL faz sentido", escreveu outro usuário que atende pelo D. SM.

Não é por acaso que tantas línguas populares hoje operam no modelo BDFL. Perl, Ruby, Rails, Python e Scala começaram como projetos liderados por criadores. Até a C++ teve uma criadora, Bjarne Stroustrup, que permaneceu como membro ativo do comitê de normas, presidindo o subgrupo de extensão linguística por 24 anos. "Ter alguém com uma visão muito de longo prazo da linguagem, e uma participação pessoal investida em seu sucesso, é fundamental nos estágios iniciais de uma linguagem ("cedo" sendo os primeiros 10-20 anos de uma língua)", disse Ryan Cavanaugh, o principal líder de engenharia para a linguagem TypeScript na Microsoft. "Não acho que seja coincidência que quase todas as línguas em uso amplo começaram hoje com um designer centralizado forte."

Com um BDFL que se alinha com a visão dos colaboradores, um projeto pode seguir essa visão e fazer progressos reais em direção a um lançamento. "Você tem um pequeno grupo de pessoas que está tentando fazer algo", disse Rob Tomkins, engenheiro da DevOps e membro da Apache Software Foundation. "Eles podem se mover mais rápido e tomar decisões mais rápidas em oposição a um grande grupo, uma grande equipe de pessoas que tem que se mover mais devagar. Eu tento ser o mais aberto possível porque Linus [Torvalds, criador do Linux] tem sido tremendamente bem sucedido."

Embora a Linux Foundation hospede um grande número de projetos populares de código aberto, incluindo jQuery, Kubernetes e Node.js com diferentes formas de governança, o kernel Linux ainda tem uma estrutura BDFL frouxa. Mike Dolan, GM e vice-presidente sênior de Programas Estratégicos da Linux Foundation, disse: "O kernel Linux segue um modelo onde a Linus supervisiona os detalhes finais de lançamento, mas quase todas as decisões são tomadas pelos respectivos mantenedores do subsistema, ou mantenedores de grupos de subsistemas. Todos os projetos são inclusivos, ou seja, qualquer pessoa pode contribuir e participar da comunidade técnica."

À medida que o projeto cresce, porém, outros contribuintes podem se encontrar ganhando experiência e, por vezes, liderança não oficial em certas áreas. "Em qualquer grande projeto, sempre haverá pelo menos um lócus informal de poder em torno de vários assuntos", disse Manish Goregaokar, engenheiro de pesquisa da Mozilla e membro da Equipe do Núcleo de Ferrugem. "Não é possível que um BDFL esteja em todos os lugares o tempo todo, então o mínimo que você pode fazer é formalizar seus papéis e facilitar a responsabilidade de se envolver."

Parece que projetos BDFL de longo prazo movem o líder para uma posição mais removida, como um

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.