Nesta semana, ocorrerá um festival de TI em São Petersburgo . Um dos palestrantes será Richard Stallman. também está participando do festival, e, é claro, não poderíamos deixar de lado o tema de Software Livre. Portanto, uma das nossas palestras se chama . Ela será dedicada à história do desenvolvimento da Embox como um projeto de código aberto. Neste artigo, quero compartilhar as ideias principais que, em minha opinião, influenciam o desenvolvimento de projetos opensource. O artigo, assim como a palestra, é baseado em experiências pessoais.
Comecemos pelo básico, definindo o termo opensource. É evidente que um projeto de código aberto é um projeto que possui uma das licenças que permitem o acesso ao código-fonte do projeto. Além disso, um projeto aberto implica a possibilidade de modificações por desenvolvedores externos. Ou seja, se uma empresa ou desenvolvedor publica o código de seu produto, parcial ou totalmente, isso não o torna automaticamente um projeto opensource. Por fim, qualquer atividade de projeto deve resultar em algum resultado, sendo que a abertura do projeto implica que esse resultado não é utilizado apenas pelos próprios desenvolvedores.
Não vamos abordar as questões das licenças abertas. Esse é um tema grande e complexo que exige uma análise aprofundada. Há uma boa quantidade de artigos e materiais sobre o assunto. Mas, como não sou especialista em direitos autorais, direi apenas que a licença deve atender aos objetivos do projeto. Por exemplo, para a Embox, a escolha da licença BSD, em vez da GPL, não foi aleatória.
O fato de que um projeto aberto deve permitir a introdução de mudanças e influenciar o desenvolvimento do projeto implica que o projeto é distribuído. Gerenciá-lo, mantendo sua integridade e funcionalidade, é muito mais difícil em comparação com um projeto que possui uma gestão centralizada. Surge a pergunta legítima: por que fazer projetos abertos? A resposta reside na área da viabilidade comercial, para uma determinada classe de projetos, os benefícios desse approach superam os custos. Portanto, nem todos os projetos são adequados, e o enfoque aberto não é sempre permitido. Por exemplo, é difícil imaginar o desenvolvimento de um sistema de controle de uma usina elétrica ou de um avião baseado em princípios abertos. Claro que, dentro de tais sistemas, módulos baseados em projetos abertos devem ser incluídos, pois isso traz uma série de vantagens. Mas alguém deve assumir a responsabilidade pelo produto final. Mesmo que o sistema seja totalmente baseado em código de projetos abertos, o desenvolvedor, ao embalar tudo em um único sistema e fazer compilações e configurações específicas, de certa forma, fecha o sistema. O código pode, no entanto, estar em acesso público.
Para esses sistemas, há também uma série de vantagens em criar projetos abertos ou participar deles. Como já mencionei, o código do sistema final pode permanecer em acesso público. Por que, já que é óbvio que é improvável que alguém tenha um avião semelhante para testar o sistema? Isso é verdade, mas pode haver quem deseje verificar partes específicas do código, ou por exemplo, alguém pode descobrir que a biblioteca utilizada não está configurada corretamente.
Uma maior vantagem aparece quando a empresa aloca uma parte básica do sistema em um projeto separado. Por exemplo, uma biblioteca para suporte a um determinado protocolo de troca de dados. Nesse caso, mesmo que o protocolo seja específico para um determinado domínio, é possível compartilhar os custos de manutenção dessa parte do sistema com outras empresas desse setor. Além disso, os especialistas que podem estudar essa parte do sistema de forma aberta precisam de muito menos tempo para utilizá-la de maneira eficaz. E, finalmente, alocar uma parte como uma entidade independente, que é utilizada por desenvolvedores externos, possibilita que essa parte seja de melhor qualidade, uma vez que é necessário oferecer APIs eficazes, criar documentação, e nem menciono a melhora da cobertura de testes.
A empresa pode obter benefícios comerciais mesmo sem criar projetos abertos; basta que seus especialistas participem de projetos de terceiros utilizados na empresa. Afinal, todas as vantagens permanecem: os funcionários conhecem melhor o projeto, portanto, o utilizam de forma mais eficiente; a empresa pode influenciar a direção do desenvolvimento do projeto, e, o uso de código já testado evidentemente reduz os custos da empresa.
As vantagens da criação de projetos open source não terminam aqui. Vamos considerar um aspecto importante dos negócios como o marketing. Para isso, é uma excelente arena que permite avaliar efetivamente as exigências do mercado.
E claro, não podemos esquecer que um projeto open source é um caminho eficaz para se afirmar como um portador de alguma especialização. Em alguns casos, é até o único caminho para entrar no mercado. Por exemplo, o Embox começou como um projeto para criar um sistema operacional de tempo real. Provavelmente não é necessário explicar que existem vários concorrentes. Sem a criação de uma comunidade, simplesmente não teríamos recursos suficientes para levar o projeto ao usuário final, ou seja, para que desenvolvedores externos utilizassem o projeto.
A comunidade é fundamental em um projeto open source. Ela permite reduzir significativamente os custos de gerenciamento do projeto, desenvolve e mantém o projeto. Pode-se dizer que sem a comunidade, não existe um projeto open source.
Há muitos materiais sobre como criar e gerenciar uma comunidade de um projeto de código aberto. Para não repetir fatos já conhecidos, vou me concentrar na experiência da Embox. Por exemplo, uma questão muito interessante é o processo de criação da comunidade. Muitas pessoas falam sobre como gerenciar uma comunidade existente, mas muitas vezes esquecem dos momentos de sua criação, tratando isso como uma suposição.
A principal regra ao criar uma comunidade de projeto opensource é que não existem regras. Quero dizer, não existem regras universais, assim como não existe uma bala de prata, principalmente porque os projetos são bastante diferentes. É improvável que se possa usar as mesmas regras ao criar uma comunidade para uma biblioteca de log de js e algum driver altamente especializado. Além disso, em diferentes estágios de desenvolvimento do projeto (e, portanto, da comunidade), as regras mudam.
A Embox começou como um projeto estudantil, já que tínhamos acesso a alunos do departamento de programação de sistemas. Na verdade, estávamos ingressando em outra comunidade. Podemos interessar os participantes dessa comunidade, os alunos, com boas práticas industriais em suas especializações, trabalhos acadêmicos na área de programação de sistemas, trabalhos de curso e teses. Ou seja, estávamos cumprindo uma das principais regras para organizar uma comunidade: os participantes devem receber algo, e esse valor deve corresponder à contribuição do participante.
A próxima fase para a Embox foi a busca por usuários externos. É muito importante entender que os usuários são participantes plenos da comunidade opensource. Geralmente, há mais usuários do que desenvolvedores. E para que queiram se tornar contribuidores do projeto, primeiro começam a usá-lo de alguma forma.
Os primeiros usuários do Embox foram do Departamento de Cibernética Teórica. Eles propuseram criar um firmware alternativo para o Lego Mindstorm. Embora ainda fossem usuários locais (podíamos nos encontrar pessoalmente e discutir o que eles desejavam), foi uma experiência muito boa. Por exemplo, desenvolvemos demos que podíamos mostrar a outros, pois robôs são divertidos e atraem atenção. No final, tivemos verdadeiros usuários externos que começaram a perguntar o que era o Embox e como utilizá-lo.
Nesta fase, tivemos que pensar na documentação e nos meios de comunicação com os usuários. Claro, já havíamos considerado essas questões importantes antes, mas era prematuro e não trouxe resultados positivos. O efeito foi mais negativo. Vou dar alguns exemplos. Usamos o googlecode, cujo wiki suportava multilíngue. Criamos páginas em vários idiomas, não apenas em inglês e russo, que eram os idiomas básicos para nossa comunicação, mas também em alemão e espanhol. Como resultado, era bastante ridículo quando nos questionavam nesses idiomas, mas não podíamos responder. Também estabelecemos regras para a escrita da documentação e comentários, mas como a API mudava com frequência e significamente, a nossa documentação se tornava obsoleta, causando mais confusão do que ajudando.
No final, todos os nossos esforços, mesmo os incorretos, resultaram na aparição de usuários externos. E até mesmo um cliente comercial surgiu, que queria que desenvolvêssemos um sistema operacional personalizado para ele. E nós fizemos, pois temos experiência e alguns desenvolvimentos anteriores. É necessário falar tanto sobre os aspectos positivos quanto negativos. Começarei pelos negativos. Como muitos desenvolvedores foram atraídos para este projeto de forma comercial, a comunidade, já de per se instável, se dividiu, o que, naturalmente, não poderia deixar de impactar o desenvolvimento do projeto. Um fator adicional foi que a direção do projeto era determinada por um único cliente comercial, cuja meta não era o desenvolvimento contínuo do projeto. Pelo menos, esse objetivo não era o principal.
Por outro lado, houve uma série de pontos positivos. Recebemos realmente usuários externos. Não eram apenas os clientes, mas também aqueles para quem o sistema foi projetado. A motivação para participar do projeto cresceu. Afinal, se é possível ganhar dinheiro com algo interessante, isso é sempre agradável. E o principal, ouvimos um desejo dos clientes que naquele momento parecia irreal, mas que agora é a ideia central do Embox, ou seja, utilizar código já desenvolvido no sistema. Atualmente, a ideia principal do Embox é usar software Linux sem o Linux. Isso significa que um dos principais pontos positivos que contribuiu para o desenvolvimento futuro do projeto foi a conscientização de que o projeto é utilizado por usuários externos e que ele deve resolver algumas de suas questões.
Naquele momento, o Embox já tinha ultrapassado os limites de um projeto estudantil. O principal fator limitante para o desenvolvimento do projeto sob a perspectiva estudantil é a motivação dos participantes. Os estudantes participam enquanto estão estudando, e quando se formam, deve surgir outra motivação. Se essa motivação não aparece, o estudante simplesmente para de participar do projeto. Considerando que os estudantes precisam ser treinados primeiro, isso significa que eles se tornam bons especialistas no momento da formatura, mas sua contribuição para o projeto, devido à inexperiência, não é muito grande.
Em geral, estamos gradualmente chegando ao ponto principal que permite falar sobre a criação de um projeto open source: a criação de um produto que resolva os problemas de seus usuários. Como já expliquei acima, a principal característica de um projeto open source é a sua comunidade. E os participantes da comunidade são, antes de tudo, os usuários. Mas como eles podem surgir se não têm nada para usar? Assim, como em um projeto não open source, é necessário focar na criação de um MVP (produto minimamente viável), e se ele interessar aos usuários, uma comunidade surgirá ao redor do projeto. No entanto, se ficar apenas na criação da comunidade por meio da divulgação, escrevendo wikis em todos os idiomas do mundo ou seguindo um fluxo de trabalho adequado no GitHub, isso provavelmente não terá relevância nas primeiras etapas do projeto. Claro, em estágios apropriados, isso não é apenas importante, mas também necessário.
Para concluir, quero apresentar , na minha opinião, reflete as expectativas do usuário em relação a um projeto de código aberto:
Estou seriamente considerando a migração para este SO (pelo menos para experimentar. Está sendo muito desenvolvido e estão criando coisas incríveis).
P. S. Em teremos nada menos que três palestras. Uma sobre código aberto e duas sobre embedded (sendo que uma será prática). Em nosso estande, realizaremos um workshop de programação de microcontroladores usando . Tradicionalmente, traremos equipamentos e permitiremos que todos programem. Haverá também um quiz e outras atividades. Venha para o festival e para o nosso estande, será divertido.
Fonte: habr.com
