Na
última reunião da comunidade Apache Ignite em Moscou, falei sobre:
- Comunidade de código aberto;
- Poder e dinheiro em código aberto;
- Como se tornar um colaborador e colaborador e por que você precisa.
O tempo limitado do relatório não permitiu dar mais exemplos; por isso, posto a versão estendida no Habré. Todos os itens acima são baseados na minha experiência pessoal e não são uma posição oficial de nenhuma empresa ou organização.
O que é uma comunidade?
Isso pode parecer óbvio, mas ainda vamos esclarecer o que queremos dizer com comunidade. Primeiro de tudo, estamos falando de uma comunidade online. Esse é um tipo de plataforma para as pessoas interagirem umas com as outras. Se uma comunidade é dedicada, por exemplo, à saúde, condicionamento físico e atividades semelhantes, sua tarefa pode ser apoiar seus membros. Ou uma comunidade pode criar um bem público. Este é exatamente o caso da comunidade de desenvolvimento de software de código aberto. Além disso, se você deseja desenvolver algum tipo de software, é improvável que encontre pessoas com visões semelhantes, por exemplo, no seu pouso ou na próxima entrada. Existem tais projetos, mas geralmente como estudantes. E a comunidade online apaga as barreiras entre continentes e fusos horários, permitindo que você encontre mais entusiastas.
Fundação Apache
A história do Apache começou em 1999 com o servidor web HTTPD: um grupo de pessoas começou a desenvolver um servidor web, os usuários começaram a procurá-los, alguns dos quais começaram a enviar patches porque queriam melhorar algo neste produto ou corrigir bugs. Os desenvolvedores começaram gradualmente a alocar aos membros mais ativos dessa comunidade o direito de enviar ao repositório, que agora é chamado de confirmação de direitos.
Aplicando a mesma abordagem ao desenvolvimento de código aberto, o Apache agora se tornou a maior organização (fundação), que desenvolve software de código aberto. A organização está dividida em 319 (até agora) projetos diversificados, dos quais cerca de 200 são de nível superior. Não existe um processo único para todos os projetos, todos os participantes são voluntários, seu trabalho nunca é pago pela organização.
O Apache sem falha requer que todos os projetos tenham:
- Política jurídica;
- Políticas de uso da marca;
- Votação sobre a adoção de lançamentos;
- Uso de listas de discussão;
- Segurança da informação.
Incubadora Apache
Para construir uma comunidade, todos os projetos do Apache passam pelo Apache Incubator sem falhas. Este é um estágio intermediário no desenvolvimento, nem mesmo do projeto, mas da comunidade ao seu redor. Ninguém no Apache ditará qual tecnologia usar. Além disso, eles nem sequer perguntam qual decisão escolher. O objetivo do Apache Incubator é construir uma comunidade que tome decisões em conjunto. É muito importante que os participantes entendam como e quem toma a decisão, onde eles podem falar, onde sua voz será ouvida. Organizar um ASF ajuda anexando um mentor ao projeto.
Projeto Apache de nível superior
Se um projeto sair do Apache Incubator, ele poderá se tornar um projeto de nível superior. O Apache ajuda o projeto a participar de conferências, fornece toda a assistência possível na promoção da marca e oferece suporte à infraestrutura.
A comunidade do projeto de nível superior garante aos usuários que:
- O código pode ser usado legalmente;
- Código de alta qualidade;
- A segurança da informação é observada: por exemplo, todos os releases são assinados;
- O projeto estará sempre disponível para os usuários.
Código aberto e energia
Agora vamos falar sobre poder e dinheiro, e como as decisões são tomadas. Isso nem sempre é óbvio, mesmo para os membros da comunidade. Existem várias funções no projeto Apache e várias listas de correspondência correspondem a elas:
- Usuário (user@project.apache.org);
- Desenvolvedor (dev@project.apache.org);
- Committer (dev@project.apache.org);
- PMC (private@project.apache.org);
- Presidente do PMC (private@project.apache.org).
Além disso, você já pode crescer dentro da estrutura da Apache Software Foundation, tornar-se um mentor de um projeto, ajudar outros projetos a construir uma comunidade.
Quanto maior o papel, menos pessoas o desempenham, ou seja, forma-se uma pirâmide invertida: mais usuários, menos PMC. Geralmente todo mundo está interessado nos participantes crescendo e desempenhando um papel mais elevado.
Diferentemente das empresas comerciais, onde a equipe e o crescimento são limitados pelo orçamento, o código aberto não possui isso, nada limita o número de comissários ou PMCs. O grupo se regula de forma independente.
Usuário
Os usuários são todos nós. Certamente, cada um de vocês usa algum tipo de software de código aberto. É importante para a comunidade que o usuário não apenas use ou dê feedback na forma de relatórios de bugs ou solicitações de recursos, mas também ajude outras pessoas. Ou seja, do ponto de vista da comunidade, um participante se torna um usuário apenas quando se inscreve e responde à lista de usuários e ajuda outras pessoas a dominar o produto, compartilha seu conhecimento.
Desenvolvedor / Colaborador
Se o usuário estiver pronto para contribuir com o projeto, com a primeira contribuição ele se tornará automaticamente um colaborador ou desenvolvedor - esses são sinônimos. O colaborador participa de um boletim informativo para desenvolvedores que discute tudo relacionado às contribuições da comunidade. Todos os desenvolvedores influenciam a tomada de decisões da comunidade, todos criticam as decisões e oferecem alternativas.
Committer
Se a comunidade acredita que a pessoa fez uma contribuição suficiente, ela pode ter direito a enviar para o repositório, ou seja, o número mínimo de revisores de seu código é reduzido a zero (embora no Apache Ignite, às vezes, os committers ainda passem pela análise de código). Os assinantes assinam um ICLA (
Contrato de Licença de Colaborador Individual ). No entanto, também pode ser assinado antes de receber comissões. O comunicador recebe uma caixa de correio no apache.org e pode tomar decisões relacionadas a cada contribuição para o projeto.
Membro do PMC
Membro do PMC (Comitê de Gerenciamento de Projetos) - Membro do comitê de gerenciamento de projetos. Esse membro da comunidade já deu uma grande contribuição ao desenvolvimento do produto e tem o direito de tomar decisões de desenvolvimento a longo prazo, controla o projeto, monitora muitos aspectos, em particular a tomada de decisão em conjunto. Ajuda os membros da comunidade a alcançar consenso. O PMC tem muitas responsabilidades no Apache, por exemplo, pode votar para aceitar o lançamento. O comunicador e o colaborador também podem, mas, diferentemente deles, o PMC tem uma voz vinculativa. O PMC pode propor confirmadores ou novos PMCs.
Presidente do PMC
O Presidente do PMC é a ponte entre a Apache Software Foundation. Talvez o presidente do PMC não tenha muito poder em comparação com o membro do PMC. Mas ele deve resolver os problemas e informar ao Conselho Apache o status do projeto.
Tomada de Decisão: Duocracia
O Apache é dominado pelo princípio da duocracia (do-ocracy, de do - "do"). Quanto mais você faz, mais oportunidades você tem que fazer, mais você influencia o projeto.
Se uma decisão exigir uma posição coordenada de todos os participantes, será realizada uma votação. Dura pelo menos 72 horas para que todos votem.
Os eleitores colocaram:
+1: "para a decisão".
0: "Eu não ligo."
-1: "contra a decisão". Nesse caso, você precisa propor outra coisa e explicar em detalhes por que você vota contra.
Existem outros tipos de votos:
0: "Não gosto muito da ideia, mas combina comigo."
-0: "Não vou interferir, mas é melhor não fazer isso".
-0,5: "Não gosto da ideia, mas não consigo encontrar argumentos racionais contra ela".
++ 1: “Super, vamos lá!”
-0.9: "Eu não gosto, mas se todo mundo quiser, eu não vou colocar paus nas rodas, vá em frente."
+0,9: "A ideia é legal, eu gosto, mas não tenho tempo / conhecimento para ajudar."
Consenso preguiçoso
Existe uma política de tomada de decisão, como consenso preguiçoso ou aprovação através do silêncio. Este procedimento também dura pelo menos 72 horas. Se uma pessoa escreveu explicitamente: “Quero passar esta decisão por um consenso preguiçoso”, em três dias, mesmo que ninguém atenda, a decisão será considerada aceita pela comunidade.
Aprovação por maioria e aprovação por consenso
A votação para a liberação é mais ativa: nesse caso, é necessária a aprovação da maioria dos membros da comunidade: três votos obrigatórios (do PMC) "a favor" e mais votos "a favor" do que "contra".
O consenso é a melhor opção: todos são a favor, com pelo menos três PMCs.
Veto
Um colaborador qualificado, geralmente um membro do PMC, pode vetá-lo. Ele vota -1 na modificação do código e escreve uma explicação detalhada. Ninguém pode contornar essa solução de membro do PMC. Você não pode vetar uma liberação, mas se a edição for muito ruim, por exemplo, ela cria uma falha de segurança ou prejudica muito o desempenho, o PMC pode votar em -1. E até que ele retire o veto, é impossível aplicar a edição.
Meritocracia
Outro princípio que está próximo da duocracia. Literalmente, "meritocracia" significa "o poder dos dignos". Em código aberto, isso significa que, se o usuário, como o grupo acredita, fez bastante pela comunidade, ele é promovido a um colaborador. Você pode perguntar o quão justa é essa decisão, é sempre absolutamente honesta e equilibrada? Esta é uma decisão extremamente subjetiva por todos os PMCs nesta comunidade. Em grandes comunidades, como o Apache Ignite, essa política pode ser mais ou menos formalizada. Certas contribuições humanas são importantes, participe ativamente do boletim para desenvolvedores. Mas a “suficiência” é determinada individualmente por cada projeto.
Um ponto importante são as qualidades humanas do participante. A política do Apache afirma explicitamente que a interação da pessoa com outros participantes é avaliada, como ela se comporta se não concorda com sua opinião. Para que um membro seja promovido a um colaborador ou PMC, outros PMCs devem votar na lista privada e não deve haver votos de "não".
Código aberto e dinheiro
Este tópico importante aparece de uma maneira ou de outra: como ganhar dinheiro com os produtos Apache Software Foundation. A organização fornece a licença mais comercialmente amigável de tudo o que existe. Você pode vender produtos baseados em Apache ou suporte para produtos Apache; pode usá-los em produtos comerciais.
Um requisito importante: sempre deve haver uso gratuito dos produtos Apache. Eles são gerenciados independentemente de interesses comerciais. Isso está sendo monitorado pelo PMC.
O comissário pode receber dinheiro de uma organização de terceiros para contribuir com o projeto. O comissário pode ser contratado por terceiros. Recentemente, os membros da comunidade
disseram à Habr como eles trabalham com a comunidade de código aberto Apache Ignite na Sberbank Technologies. Mas a Fundação Apache nunca paga aos usuários. Esta é uma posição de princípios. Para o Apache, o colaborador é sempre um voluntário e um indivíduo. Ou seja, a empresa não pode participar de projetos Apache, apenas um desenvolvedor pode.
Por que e como ingressar em código aberto
Por que vale a pena começar a contribuir para projetos de código aberto?
Esta é uma boa oportunidade para atualizar suas habilidades e obter uma reputação profissional. As empresas comerciais gostam de participar de código aberto. Muitos desenvolvedores famosos participam de vários projetos, tornam-se comissários e PMC.
O que impede as pessoas de participar de código aberto?- "Você precisa ser olímpica ou sênior com 20 anos de experiência, caso contrário eu não posso fazer isso". De fato, não. O Apache Ignite é um projeto complexo, mas mesmo aqui você pode encontrar tarefas simples. Por exemplo, tickets e tarefas fáceis para escrever documentação projetada para melhor descrever o projeto. Em nenhum lugar do Apache diz que, para se tornar um committer, você precisa escrever um código.
- "Eu preciso de inglês fluente, caso contrário não posso lidar com isso". Aqueles que participam de listas de desenvolvedores confirmarão: lá você não precisa ser fluente em inglês. Além disso, a comunicação escrita não é em tempo real, há tempo para pensar e escrever uma resposta equilibrada.
- "Se eu enviar meu componente para código-fonte aberto, nunca mais poderei usá-lo." No Apache, isso não é verdade. Você pode continuar usando seu componente em um produto comercial, ele simplesmente existe sob a Apache Foundation sob a licença Apache.
- "Todo mundo vai ler o que eu escrevo na Internet." Mesmo na comunidade Apache Ignite, nem todo mundo lê o que escrevemos. É como uma piada sobre Joe indescritível: ninguém pode pegá-lo, porque ninguém precisa dele. Tenho certeza de que meus amigos e parentes não leem o que eu escrevo na lista de desenvolvedores, porque eles não se importam.
- "Vai levar todo o meu tempo livre." Isto é parcialmente verdade: a participação da comunidade é viciante. Se você começar a participar da discussão, levará algum tempo. E à medida que você cresce, é preciso mais. Quanto mais você souber, mais poderá saber, mais você participará de user e dev.list. Mas, novamente, não há obrigação para o Apache. Cada um regula seu próprio envolvimento. Se você pode fazer um patch, faça um patch. E, no entanto, ninguém irá forçá-lo. Mesmo quando uma pessoa é nomeada como comissário, a carta de proposta declara que não é necessário que ele se envolva mais do que está disposto a dar.
Como começar
Se você quiser participar de projetos Apache, precisará de uma conta no Github, uma caixa de correio, registro no
Apache JIRA e, possivelmente, no
Wiki . Qualquer comunidade tem um artigo
Como contribuir para iniciantes no Apache Ignite.
É uma boa forma de escrever uma carta de boas-vindas:
"Olá! Eu sou mais ou menos. Eu quero fazer esse ingresso, meu apelido no JIRA é tal e tal .
" Esta carta é importante em termos de atribuir ao usuário o papel de colaborador.
Listas de discussão
Para interagir com outros membros, o Apache requer o uso de listas de discussão. Às vezes ouço descontentamento: por que tão antiquado? Há um monte de chats, mensageiros instantâneos. Isso ocorre porque cada membro dos projetos Apache é voluntário. Ele pode ter sua própria família, trabalho que não está relacionado ao código aberto, seus hobbies. Ele não pode conversar online. Talvez ele possa verificar o correio a cada três dias. E nessas situações, as listas de discussão funcionam muito bem.
Além disso, não esqueça que os membros da comunidade estão espalhados pelo mundo. E cara
para quem você faz uma pergunta, pode estar em outro continente e responderá apenas amanhã.
Portanto, paciência e cortesia são aquelas qualidades que são muito importantes na correspondência nas listas de discussão. Por exemplo, na comunidade Apache Ignite, membros experientes nunca escreverão que discordam de você, eles escreverão que não têm certeza de que concordam.
Carta de exemplo:
Olá, □□□□□□□, não tenho certeza se concordo, porque ...A comunidade é mais importante que o código
Um dos princípios do Apache: a comunidade é mais importante que o código. Isso significa que a primeira coisa que o projeto Apache pretende criar é uma comunidade em torno de um projeto de código aberto. E então a mágica começa e um bom código aparece. Se você não concordar com nenhuma carta, adie-a por 4 horas, releia-a e adie-a novamente. Depois, há uma grande chance de você responder com restrição, sem pressionar os outros membros da comunidade com palavras descuidadas. Somos todos voluntários e, se as pessoas não se sentirem confortáveis, começarão a sair, e para um projeto de código aberto esse é um risco muito sério.
Recomendações por correspondência
Eles são mais ou menos semelhantes aos usados na correspondência comercial comum. Se qualquer sentença puder ser interpretada da maneira errada, será interpretada da maneira errada, especialmente considerando o tamanho da comunidade. Todas as recomendações se resumem a três princípios básicos: ser positivo, construtivo e respeitoso.
Um exemplo de uma carta não tão boa:
Olá, □□□□□.
Esta solução parece um pouco feia para mim.Um desejo meu como membro da lista de desenvolvedores: escreva letras curtas - três parágrafos ou 7 frases. Somos todos técnicos e queremos dar o máximo de detalhes possível. Mas se houver muitos deles, talvez seja uma ocasião para escrever um artigo separado.
O que contrabandear?
Cada comunidade tem uma lista do que precisa agora. O Ignite possui uma lista de tickets simples. Se você encontrou um bug durante o uso e o corrigiu no seu fork, é bem possível criar um problema no JIRA para essa empresa, fazer uma solicitação pull e escrever na lista de desenvolvedores.
Como passar pela revisão de código
Enquanto você é novo na comunidade, é improvável que você possa determinar qual ticket é uma prioridade. Pode fazer sentido entrar em contato com a pessoa que acompanha o componente; sua ajuda será muito importante para ele. Você também pode perguntar na lista de desenvolvedores quais tickets são mais importantes.
Se não houver resposta, lembramos novamente que todos são voluntários. Pode ser uma boa ideia lembrá-lo do que você propôs fazer em três dias.
Nos projetos Apache, incluindo o Ignite, não há função de um gerente de projeto que monitore o backlog, portanto, tickets irrelevantes também podem ser encontrados lá. É recomendável que você escreva primeiro na lista de desenvolvedores e esclareça.
Outra característica do Apache: em uma empresa comercial, pode haver uma política clara de que um funcionário de um determinado nível possa acessar e editar a documentação, mas um funcionário de um nível inferior não. Não existe tal coisa no Apache. Se houver algo para emprestar, não há problema. Eu acho que em qualquer projeto você não terá problemas com a obtenção de direitos de acesso, e não importa se a pessoa não é formalmente uma pessoa que confirma.
Fale sobre o projeto
A comunidade é amplamente assistida por artigos de produtos. A própria Apache Software Foundation ajuda nas conferências. Você também pode descrever sua experiência, não apenas com o Apache Ignite. Pode ser um caso de uso interessante, trabalho do aluno. Eles são sempre publicados na lista de desenvolvedores.