Já esta semana em São Petersburgo, sediará o
festival de TI
TechTrain . Um dos oradores será Richard Stallman.
A Embox também participa do festival e, é claro, não podemos ignorar o tópico do software de código aberto. Portanto, um de nossos relatórios é chamado
“Do artesanato do aluno ao projeto de código-fonte aberto. Experiência Embox .
” Será dedicado à história da Embox como um projeto de código aberto. Neste artigo, quero falar sobre as principais idéias que, na minha opinião, afetam o desenvolvimento de projetos de código aberto. O artigo, como o relatório, é baseado na experiência pessoal.
Vamos começar com uma definição simples do termo código-fonte aberto. Obviamente, um projeto de código aberto é um projeto que possui uma das licenças que permite acessar o código-fonte do projeto. Além disso, um projeto aberto implica a possibilidade de alterações por desenvolvedores de terceiros. Ou seja, se alguma empresa ou desenvolvedor publicar o código de seu produto, parcial ou completamente, isso não fará deste produto um projeto de código aberto. E, finalmente, qualquer atividade do projeto deve levar à aparência de algum tipo de resultado, e a abertura do projeto implica que não apenas os próprios desenvolvedores usem esse resultado.
Não tocaremos nos problemas das licenças abertas. Este é um tópico muito grande e complicado que requer uma investigação profunda. Muitos bons artigos e materiais foram escritos sobre esse tópico. Mas como eu próprio não sou especialista na área de direitos autorais, só posso dizer que a licença deve atender aos objetivos do projeto. Para a Embox, por exemplo, escolher uma licença BSD em vez de uma licença GPL não foi aleatória.
O fato de um projeto aberto tornar possível fazer alterações e influenciar o desenvolvimento de um projeto aberto implica que o projeto seja distribuído. Gerenciar, manter a integridade e a eficiência é muito mais difícil se comparado a um projeto com gerenciamento centralizado. Uma pergunta razoável surge: por que os projetos de código aberto? A resposta está no campo da viabilidade comercial; para uma determinada classe de projetos, os benefícios dessa abordagem superam os custos. Ou seja, não para todos os projetos, uma abordagem aberta é geralmente aceitável. Por exemplo, é difícil imaginar o desenvolvimento de uma usina ou sistema de controle de aeronaves com base em um princípio aberto. Não, é claro, vale a pena incluir módulos baseados em projetos abertos na composição de tais sistemas, porque isso fornecerá várias vantagens. Mas alguém deve responder pelo produto final. Mesmo que o sistema seja completamente baseado no código-fonte aberto, o desenvolvedor, agrupando tudo em um sistema e fazendo montagens e configurações específicas, basicamente o fecha. O código pode estar disponível ao público.
Para esses sistemas, também há muitos benefícios na criação de projetos de código aberto ou na participação deles. Como eu disse, o código do sistema final pode permanecer em domínio público. Por que, 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 seções individuais do código ou, por exemplo, alguém pode achar que a biblioteca usada não está configurada corretamente.
Um benefício ainda maior aparece se a empresa alocar uma parte básica do sistema em um projeto separado. Por exemplo, uma biblioteca para suportar algum tipo de protocolo de troca de dados. Nesse caso, mesmo que o protocolo seja específico para uma determinada área, é possível compartilhar os custos de manutenção dessa parte do sistema com outras empresas dessa área. Além disso, os especialistas que podem estudar essa parte do sistema em domínio público precisam de muito menos tempo para usá-la efetivamente. E, finalmente, destacar uma peça como uma entidade independente, usada por desenvolvedores de terceiros, permite que você melhore essa parte, porque você precisa oferecer APIs eficazes, criar documentação, nem estou falando em melhorar a cobertura dos testes.
Uma empresa pode obter benefícios comerciais sem criar projetos abertos; basta que seus especialistas participem de projetos de terceiros usados pela empresa. Afinal, todos os benefícios permanecem: os funcionários conhecem melhor o projeto, portanto, usam-no com mais eficiência, a empresa pode influenciar a direção do desenvolvimento do projeto, bem, o uso de código depurado pronto reduz obviamente os custos da empresa.
Os benefícios da criação de projetos de código aberto não terminam aí. Vamos considerar um componente tão importante do negócio como marketing. Para ele, essa é uma caixa de areia muito boa, que permite avaliar efetivamente os requisitos do mercado.
E, é claro, não devemos esquecer que o projeto de código-fonte aberto é uma maneira eficaz de se declarar portador de qualquer especialização. Em alguns casos, essa é geralmente a única maneira de entrar no mercado. Por exemplo, a 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 desenvolvedores terceirizados usarem o projeto.
A comunidade é fundamental no projeto de código-fonte aberto. Permite reduzir significativamente os custos de gerenciamento de projetos, desenvolver e dar suporte ao projeto. Podemos dizer que sem uma comunidade não há projeto de código aberto.
Muitos materiais foram escritos sobre como criar e gerenciar uma comunidade de projeto de código aberto. Para não recontar fatos já conhecidos, tentarei me concentrar na experiência da Embox. Por exemplo, uma questão muito interessante é o processo de criação de uma comunidade. Ou seja, muitos dizem como gerenciar a comunidade existente, mas os momentos de sua criação às vezes são ignorados, considerando-a um dado.
A regra principal ao criar o projeto de código-fonte da comunidade - não há regras. Quero dizer, não existem regras universais, como uma bala de prata, mesmo que os projetos sejam muito diferentes. Dificilmente é possível usar as mesmas regras ao criar uma comunidade para uma biblioteca de log js e algum driver altamente especializado. Além disso, em diferentes estágios do desenvolvimento do projeto (e, portanto, da comunidade), as regras mudam.
A Embox começou como um projeto de estudante, pois havia acesso a estudantes no Departamento de Programação de Sistemas. De fato, entramos em outra comunidade. Participantes desta comunidade, estudantes, poderíamos estar interessados em boas práticas industriais em sua especialidade, trabalhos científicos no campo da programação de sistemas, trabalhos e diplomas. Ou seja, cumprimos uma das regras básicas da organização da comunidade, os membros da comunidade devem obter algo e esse preço deve corresponder à contribuição do participante.
O próximo estágio para a Embox foi a busca por usuários de terceiros. É muito importante entender que os usuários são membros de pleno direito da comunidade de código aberto. Geralmente, existem mais usuários que desenvolvedores. E, para querer se tornar um colaborador do projeto, eles primeiro começam a usá-lo de uma maneira ou de outra.
Os primeiros usuários da Embox foram o Departamento de Cibernética Teórica. Eles sugeriram a criação de um firmware alternativo para o Lego Mindstorm. E apesar de ainda serem usuários locais (poderíamos nos encontrar pessoalmente e discutir o que eles querem). Mas ainda assim foi uma experiência muito boa. Por exemplo, desenvolvemos demos que podem ser exibidas para outras pessoas, porque os robôs são divertidos e atraem atenção. Como resultado, tivemos usuários realmente terceirizados que começaram a perguntar o que era a Embox e como usá-la.
Nesta fase, tivemos que pensar em documentação, em meios de comunicação com os usuários. Não, é claro, pensamos sobre essas coisas importantes antes, mas foi prematuro e não produziu um 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 apenas inglês e russo, que mal conseguiam se comunicar, mas também alemão e espanhol. Como resultado, parecia muito ridículo quando solicitado nesses idiomas, mas não podemos responder. Ou eles introduziram regras para escrever documentação e comentar, mas como a API mudou com bastante frequência e de forma significativa, nossa documentação estava desatualizada e enganosa mais do que ajudava.
Como resultado, todos os nossos esforços, mesmo que não corretos, levaram ao surgimento de usuários externos. E até apareceu um cliente comercial que queria que ele desenvolvesse seu próprio RTOS. E nós o desenvolvemos porque temos experiência e alguns desenvolvimentos. Aqui você precisa falar sobre os pontos positivos e negativos. Vou começar com os ruins. Como muitos desenvolvedores estavam envolvidos nesse projeto em uma base comercial, a comunidade e, de certa forma, instáveis, se separaram, o que obviamente não poderia deixar de afetar o desenvolvimento do projeto. Um fator adicional foi que a direção do projeto foi definida por um cliente comercial e seu objetivo não era o desenvolvimento adicional do projeto. Pelo menos esse objetivo não era o principal.
Por outro lado, houve vários pontos positivos. Temos realmente usuários de terceiros. Não era apenas o cliente, mas também aqueles a quem esse sistema se destinava. A motivação para participar do projeto aumentou. Afinal, se você também pode ganhar dinheiro com um assunto interessante, é sempre bom. E o mais importante, ouvimos um desejo dos clientes, que na época pareciam loucos para nós, mas que agora é a principal idéia da Embox, a saber, usar o código já desenvolvido no sistema. A principal idéia da Embox agora é usar o software Linux sem o Linux. Ou seja, o principal fator positivo que contribuiu para o desenvolvimento adicional do projeto foi a constatação de que o projeto foi usado por usuários terceiros e deve resolver alguns de seus problemas.
Naquela época, a Embox já estava além do escopo do projeto do aluno. A principal restrição ao desenvolvimento do projeto de acordo com o modelo do aluno é a motivação dos participantes. Os alunos participam enquanto estudam e, quando se formam, uma motivação diferente deve aparecer. Se a motivação não aparecer, o aluno simplesmente deixa de participar do projeto. Se levarmos em conta que os alunos devem ser treinados primeiro, acontece que eles se tornam bons especialistas na época da graduação, mas a contribuição para o projeto, devido à inexperiência, não é muito grande.
Em geral, estamos nos movendo suavemente para o ponto principal, que nos permite falar sobre a criação de um projeto de código-fonte aberto - a criação de um produto que resolveria os problemas de seus usuários. Como expliquei acima, a principal propriedade do projeto de código-fonte aberto é sua comunidade. Além disso, os membros da comunidade são principalmente usuários. Mas de onde eles vêm até o que usar? Acontece que, assim como em um projeto não de código aberto, você precisa se concentrar na criação de um MVP (produto mínimo viável) e, se interessar aos usuários, uma comunidade aparecerá em torno do projeto. Se você está envolvido apenas na criação de uma comunidade por meio do PR da comunidade, escrevendo um wiki em todos os idiomas do mundo ou no fluxo de trabalho adequado do git no github, é improvável que isso importe nos estágios iniciais do projeto. Obviamente, nos estágios apropriados, essas são não apenas importantes, mas também necessárias.
Concluindo, quero
comentar , refletindo as expectativas do usuário em relação ao projeto de código-fonte aberto:
Penso seriamente em mudar para este sistema operacional (pelo menos tente. Eles são muito ativos em serrar e fazer coisas legais).
PS No
TechTrain , 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 usando a
Embox . Tradicionalmente, vamos trazer as glândulas e deixá-las programar. Também haverá uma busca e outras atividades. Venha para o festival e nosso estande, será divertido.