Um festival de TI será realizado em São Petersburgo esta semana . Um dos palestrantes será Richard Stallman. também participa do festival, e claro que não poderíamos ignorar o tema software livre. É por isso que um de nossos relatórios é chamado . Será dedicado à história do desenvolvimento do Embox como um projeto de código aberto. Neste artigo quero falar sobre as principais ideias que, na minha opinião, influenciam o desenvolvimento de projetos opensource. O artigo, assim como o relatório, é baseado em experiência pessoal.
Vamos começar com algo simples, com a definição do termo opensource. Obviamente, um projeto open source é aquele que possui uma das licenças que permite o acesso ao código-fonte do projeto. Além disso, um projeto aberto significa que desenvolvedores terceirizados podem fazer alterações. Ou seja, se alguma empresa ou desenvolvedor publica o código do seu produto, parcial ou totalmente, isso ainda não torna este produto um projeto opensource. E, finalmente, qualquer atividade de projeto deve levar a algum tipo de resultado, e a abertura do projeto implica que esse resultado não seja utilizado apenas pelos próprios desenvolvedores.
Não abordaremos os problemas das licenças abertas. Este é um tópico muito amplo e complexo que requer uma investigação aprofundada. Muitos artigos e materiais bons foram escritos sobre este tópico. Mas como eu próprio não sou especialista na área de direitos autorais, direi apenas que a licença deve atender aos objetivos do projeto. Por exemplo, para a Embox a escolha de uma licença BSD em vez de uma licença GPL não foi acidental.
O fato de um projeto de código aberto fornecer a capacidade de fazer alterações e influenciar o desenvolvimento do projeto de código aberto implica que o projeto seja distribuído. Gerenciá-lo, mantendo a integridade e o desempenho é muito mais difícil comparado a um projeto com gerenciamento centralizado. Surge uma pergunta razoável: por que abrir projetos? A resposta está na área de viabilidade comercial: para uma determinada classe de projetos, os benefícios desta abordagem superam os custos. Ou seja, não é adequado para todos os projetos e uma abordagem aberta é geralmente aceitável. Por exemplo, é difícil imaginar o desenvolvimento de um sistema de controle para uma usina ou aeronave baseado em um princípio aberto. Não, é claro, tais sistemas devem incluir módulos baseados em projetos abertos, porque isso proporcionará uma série de vantagens. Mas alguém deve ser responsável pelo produto final. Mesmo que o sistema seja totalmente baseado no código de projetos abertos, o desenvolvedor, tendo empacotado tudo em um sistema e feito compilações e configurações específicas, essencialmente o fecha. O código pode estar disponível publicamente.
Também há muitos benefícios para esses sistemas ao criar ou contribuir para projetos de código aberto. Como já disse, o código do sistema final pode permanecer disponível publicamente. Porque é óbvio que é improvável que alguém tenha a mesma aeronave para testar o sistema. Isso é verdade, mas pode haver alguém que queira verificar certas seções do código ou, por exemplo, alguém pode descobrir que a biblioteca usada não está configurada corretamente.
Um benefício ainda maior aparece se a empresa alocar alguma parte básica do sistema em um projeto separado. Por exemplo, uma biblioteca para suportar algum tipo de protocolo de troca de dados. Neste caso, mesmo que o protocolo seja específico para uma determinada área temática, você pode dividir os custos de manutenção desta parte do sistema com outras empresas desta área. Além disso, os especialistas que podem estudar esta parte do sistema de domínio público necessitam de muito menos tempo para utilizá-la de forma eficaz. E por fim, separar uma peça em uma entidade independente que os desenvolvedores terceirizados usam nos permite melhorar essa parte, pois precisamos oferecer APIs eficazes, criar documentação, e nem estou falando em melhorar a cobertura de testes.
Uma empresa pode receber benefícios comerciais sem criar projetos de código aberto, basta que seus especialistas participem de projetos de terceiros utilizados na empresa. Afinal, todos os benefícios permanecem: os funcionários conhecem melhor o projeto, portanto o utilizam de forma mais eficaz, a empresa pode influenciar o rumo do desenvolvimento do projeto e o uso de código pronto e depurado obviamente reduz os custos da empresa.
Os benefícios de criar projetos de código aberto não param por aí. Vejamos um componente tão importante dos negócios como o marketing. Para ele, esta é uma sandbox muito boa que lhe permite avaliar com eficácia as necessidades do mercado.
E claro, não devemos esquecer que um projeto opensource é uma forma eficaz de se declarar portador de qualquer especialização. Em alguns casos, esta é a única forma de entrar no mercado. Por exemplo, o Embox começou como um projeto para criar um RTOS. Provavelmente não há necessidade de explicar que existem muitos concorrentes. Sem criar uma comunidade, simplesmente não teríamos recursos suficientes para levar o projeto ao usuário final, ou seja, para que desenvolvedores terceirizados começassem a usar o projeto.
A comunidade é fundamental em um projeto de código aberto. Permite reduzir significativamente os custos de gerenciamento de projetos, desenvolver e apoiar o projeto. Podemos dizer que sem comunidade não existe projeto de código aberto.
Muito material foi escrito sobre como criar e gerenciar uma comunidade de projetos de código aberto. Para não recontar fatos já conhecidos, tentarei focar na experiência do Embox. Por exemplo, o processo de criação de uma comunidade é uma questão muito interessante. Ou seja, muitos contam como administrar uma comunidade existente, mas os momentos de sua criação às vezes são esquecidos, por se considerar isso um dado adquirido.
A regra principal ao criar uma comunidade de projetos de código aberto é que não existem regras. Quero dizer que não existem regras universais, assim como não existe solução mágica, até porque os projetos são muito diferentes. É improvável que você possa usar as mesmas regras ao criar uma comunidade para uma biblioteca de log js e algum driver altamente especializado. Além disso, em diferentes fases de desenvolvimento do projecto (e, portanto, da comunidade), as regras mudam.
O Embox começou como um projeto estudantil porque tinha acesso a alunos do departamento de programação de sistemas. Na verdade, estávamos entrando em alguma outra comunidade. Poderíamos interessar aos participantes desta comunidade, estudantes, boas práticas industriais na sua especialidade, trabalhos científicos na área de programação de sistemas, cursos e diplomas. Ou seja, seguimos uma das regras básicas de organização de uma comunidade: os membros da comunidade devem receber algo, e esse preço deve corresponder à contribuição do participante.
A próxima etapa do Embox foi a busca por usuários terceiros. É muito importante compreender que os usuários são participantes plenos da comunidade de código aberto. Geralmente há mais usuários do que desenvolvedores. E para quererem se tornar colaboradores de um projeto, primeiro eles começam a utilizá-lo de uma forma ou de outra.
Os primeiros usuários do Embox foram o Departamento de Cibernética Teórica. Eles sugeriram a criação de um firmware alternativo para Lego Mindstorm. E embora ainda fossem usuários locais (poderíamos encontrá-los pessoalmente e discutir o que queriam). Mas ainda assim foi uma experiência muito boa. Por exemplo, desenvolvemos demonstrações que poderiam ser mostradas a outras pessoas, porque os robôs são divertidos e chamam a atenção. Como resultado, obtivemos usuários verdadeiramente terceirizados que começaram a perguntar o que é o Embox e como usá-lo.
Nesta fase tivemos que pensar na documentação, nos meios de comunicação com os utilizadores. Não, claro, já pensamos nessas coisas importantes antes, mas foi prematuro e não deu efeito positivo. O efeito foi bastante negativo. Deixe-me dar alguns exemplos. Usamos o googlecode, cujo wiki suportava o multilinguismo. Criamos páginas em vários idiomas, não só inglês e russo, nos quais dificilmente conseguíamos nos comunicar, mas também alemão e espanhol. Como resultado, parece muito ridículo quando perguntado nestas línguas, mas não conseguimos responder de todo. Ou eles introduziram regras sobre como escrever documentação e comentários, mas como a API mudou com frequência e de forma significativa, descobriu-se que nossa documentação estava desatualizada e era mais enganosa do que ajudava.
Como resultado, todos os nossos esforços, mesmo os errados, levaram ao aparecimento de usuários externos. E apareceu até um cliente comercial que queria que seu próprio RTOS fosse desenvolvido para ele. E nós o desenvolvemos porque temos experiência e algum trabalho de base. Aqui você precisa falar sobre os bons e os maus momentos. Vou começar com os ruins. Como muitos desenvolvedores estiveram envolvidos neste projeto numa base comercial, a comunidade já estava bastante instável e dividida, o que obviamente não poderia deixar de afetar o desenvolvimento do projeto. Um factor adicional foi que a direcção do projecto foi definida por um cliente comercial e o seu objectivo não era o desenvolvimento adicional do projecto. Pelo menos este não era o objetivo principal.
Por outro lado, houve uma série de aspectos positivos. Temos usuários verdadeiramente terceirizados. Não foi só o cliente, mas também aqueles a quem este sistema se destinava. A motivação para participar no projeto aumentou. Afinal, se você também consegue ganhar dinheiro com um negócio interessante, é sempre bom. E o mais importante, ouvimos um desejo dos clientes, que na altura nos parecia uma loucura, mas que agora é a ideia principal da Embox, nomeadamente, utilizar código já desenvolvido no sistema. Agora a ideia principal do Embox é usar software Linux sem Linux. Ou seja, o principal aspecto positivo que contribuiu para o desenvolvimento do projeto foi a constatação de que o projeto é utilizado por usuários terceiros, devendo resolver alguns de seus problemas.
Naquela época, a Embox já havia ultrapassado o escopo de um projeto estudantil. O principal fator limitante no desenvolvimento do projeto segundo o modelo discente é a motivação dos participantes. Os alunos participam enquanto estudam e, quando se formam, deve haver uma motivação diferente. Se a motivação não aparecer, o aluno simplesmente deixa de participar do projeto. Se levarmos em conta que os alunos primeiro precisam ser treinados, verifica-se que eles se tornam bons especialistas ao se formarem, mas sua contribuição para o projeto, devido à inexperiência, não é muito grande.
Em geral, passamos suavemente ao ponto principal que nos permite falar sobre a criação de um projeto opensource - a criação de um produto que resolva os problemas de seus usuários. Como expliquei acima, a principal propriedade de um projeto opensource é a sua comunidade. Além disso, os membros da comunidade são principalmente usuários. Mas de onde eles vêm quando não há nada para usar? Acontece que, assim como acontece com um projeto não opensource, você precisa se concentrar na criação de um MVP (produto mínimo viável) e, se for do interesse dos usuários, uma comunidade aparecerá em torno do projeto. Se você está empenhado em criar uma comunidade apenas por meio de relações públicas da comunidade, escrevendo um wiki em todos os idiomas do mundo ou corrigindo o fluxo de trabalho do git no github, é improvável que isso tenha importância nos estágios iniciais do projeto. É claro que, nas fases apropriadas, estas coisas não são apenas importantes, mas também necessárias.
Para concluir gostaria de salientar , na minha opinião, refletindo as expectativas do usuário em relação a um projeto de código aberto:
Estou pensando seriamente em mudar para este sistema operacional (pelo menos tente. Eles estão ativamente perseguindo isso e fazendo coisas legais).
PS ativado Teremos até três relatórios. Um sobre código aberto e dois sobre incorporado (e um é prático). No estande realizaremos uma master class sobre programação de microcontroladores utilizando . Como sempre, traremos o hardware e deixaremos você programá-lo. Haverá também uma missão e outras atividades. Venha ao festival e ao nosso estande, será divertido.
Fonte: habr.com