Esta semana celebrarase un festival de informática en San Petersburgo . Un dos relatores será Richard Stallman. tamén participa no festival, e por suposto non podíamos obviar o tema do software libre. Por iso se chama un dos nosos informes . Estará adicado á historia do desenvolvemento de Embox como proxecto de código aberto. Neste artigo quero falar das principais ideas que, na miña opinión, inflúen no desenvolvemento de proxectos de código aberto. O artigo, como o informe, baséase na experiencia persoal.
Comecemos por algo sinxelo, coa definición do termo opensource. Obviamente, un proxecto de código aberto é un proxecto que ten unha das licenzas que permite acceder ao código fonte do proxecto. Ademais, un proxecto aberto significa que os desenvolvedores de terceiros poden facer cambios. É dicir, se algunha empresa ou desenvolvedor publica o código do seu produto, parcial ou totalmente, isto aínda non converte este produto nun proxecto de código aberto. E, finalmente, calquera actividade do proxecto debe levar a algún tipo de resultado, e a apertura do proxecto implica que este resultado é usado non só polos propios desenvolvedores.
Non imos tocar os problemas das licenzas abertas. Este é un tema demasiado grande e complexo que require unha investigación profunda. Escribiuse bastante artigos e materiais sobre este tema. Pero como eu mesmo non son un experto no campo dos dereitos de autor, só direi que a licenza debe cumprir os obxectivos do proxecto. Por exemplo, para Embox a elección dunha licenza BSD en lugar dunha licenza GPL non foi accidental.
O feito de que un proxecto de código aberto deba proporcionar a capacidade de facer cambios e influír no desenvolvemento do proxecto de código aberto implica que o proxecto estea distribuído. Xestionala, manter a integridade e o rendemento é moito máis difícil en comparación cun proxecto con xestión centralizada. Xorde unha pregunta razoable: por que abren proxectos? A resposta está na área de viabilidade comercial; para unha determinada clase de proxectos, os beneficios deste enfoque superan os custos. É dicir, non é apto para todos os proxectos e en xeral é aceptable un enfoque aberto. Por exemplo, é difícil imaxinar desenvolver un sistema de control para unha central eléctrica ou unha aeronave baseado nun principio aberto. Non, por suposto, estes sistemas deberían incluír módulos baseados en proxectos abertos, porque isto proporcionará unha serie de vantaxes. Pero alguén debe ser responsable do produto final. Aínda que o sistema se basee completamente no código de proxectos abertos, o desenvolvedor, tendo todo empaquetado nun só sistema e feito compilacións e configuracións específicas, esencialmente pechao. O código pode estar dispoñible publicamente.
Tamén hai moitos beneficios para estes sistemas ao crear ou contribuír a proxectos de código aberto. Como xa dixen, o código do sistema final pode permanecer dispoñible publicamente. Por que, porque é obvio que é pouco probable que alguén teña o mesmo avión para probar o sistema. Isto é certo, pero ben pode haber alguén que queira comprobar determinadas seccións do código ou, por exemplo, alguén pode descubrir que a biblioteca que se está a utilizar non está configurada correctamente.
Un beneficio aínda maior aparece se a empresa asigna algunha parte básica do sistema a un proxecto separado. Por exemplo, unha biblioteca para soportar algún tipo de protocolo de intercambio de datos. Neste caso, aínda que o protocolo sexa específico dunha determinada área temática, pode compartir os custos de mantemento desta peza do sistema con outras empresas desta área. Ademais, os especialistas que poden estudar esta peza do sistema no dominio público requiren moito menos tempo para usalo de forma eficaz. E, finalmente, separar unha peza nunha entidade independente que utilizan desenvolvedores de terceiros permítenos mellorar esta parte, porque necesitamos ofrecer API eficaces, crear documentación e nin sequera falo de mellorar a cobertura das probas.
Unha empresa pode recibir beneficios comerciais sen crear proxectos de código aberto; abonda con que os seus especialistas participen en proxectos de terceiros utilizados na empresa. Despois de todo, todos os beneficios permanecen: os empregados coñecen mellor o proxecto, polo tanto, úsano de forma máis eficaz, a empresa pode influír na dirección do desenvolvemento do proxecto e o uso de código preparado e depurado, obviamente, reduce os custos da empresa.
Os beneficios de crear proxectos de código aberto non rematan aí. Tomemos un compoñente tan importante dos negocios como o marketing. Para el, esta é unha moi boa caixa de area que lle permite avaliar eficazmente os requisitos do mercado.
E por suposto, non debemos esquecer que un proxecto de código aberto é unha forma eficaz de declararse portador de calquera especialización. Nalgúns casos, esta é a única forma de entrar no mercado. Por exemplo, Embox comezou como un proxecto para crear un RTOS. Probablemente non haxa que explicar que hai moitos competidores. Sen crear unha comunidade, simplemente non teriamos recursos suficientes para levar o proxecto ao usuario final, é dicir, para que os desenvolvedores de terceiros comezasen a usar o proxecto.
A comunidade é clave nun proxecto de código aberto. Permítelle reducir significativamente os custos de xestión de proxectos, desenvolver e apoiar o proxecto. Podemos dicir que sen comunidade non hai ningún proxecto de código aberto.
Escribiuse moito material sobre como crear e xestionar unha comunidade de proxectos de código aberto. Para non volver contar feitos xa coñecidos, intentarei centrarme na experiencia de Embox. Por exemplo, o proceso de creación dunha comunidade é un tema moi interesante. É dicir, moitos contan como xestionar unha comunidade existente, pero os momentos da súa creación ás veces pasan por alto, por considerar isto un feito.
A regra principal ao crear unha comunidade de proxectos de código aberto é que non hai regras. Quero dicir que non hai regras universais, igual que non hai unha bala de prata, aínda que só sexa porque os proxectos son moi diferentes. É pouco probable que poida usar as mesmas regras ao crear unha comunidade para unha biblioteca de rexistro js e algún controlador altamente especializado. Ademais, nas diferentes fases de desenvolvemento do proxecto (e, polo tanto, da comunidade), as regras cambian.
Embox comezou como un proxecto de estudantes porque tiña acceso aos estudantes do departamento de programación de sistemas. De feito, estabamos entrando noutra comunidade. Poderiamos interesar aos participantes desta comunidade, estudantes, en boas prácticas industriais na súa especialidade, traballos científicos no ámbito da programación de sistemas, cursos e diplomas. É dicir, seguimos unha das normas básicas para organizar unha comunidade: os membros da comunidade deben recibir algo, e este prezo debe corresponder coa achega do participante.
A seguinte etapa de Embbox foi a busca de usuarios de terceiros. É moi importante entender que os usuarios son participantes plenos na comunidade de código aberto. Normalmente hai máis usuarios que desenvolvedores. E para querer facerse colaborador dun proxecto, primeiro comezan a utilizalo dun xeito ou doutro.
Os primeiros usuarios de Embox foron o Departamento de Cibernética Teórica. Suxeriron crear un firmware alternativo para Lego Mindstorm. E aínda que seguían sendo usuarios locais (podemos reunirnos con eles persoalmente e discutir o que querían). Pero aínda así foi unha experiencia moi boa. Por exemplo, desenvolvemos demostracións que poderían ser mostradas a outros, porque os robots son divertidos e chaman a atención. Como resultado, conseguimos usuarios verdadeiramente de terceiros que comezaron a preguntar que é Embox e como usalo.
Nesta fase tivemos que pensar na documentación, nos medios de comunicación cos usuarios. Non, claro, pensabamos nestas cousas importantes antes, pero foi prematuro e non deu un efecto positivo. O efecto foi bastante negativo. Permíteme darche un par de exemplos. Usamos googlecode, cuxa wiki admitía o multilingüismo. Creamos páxinas en varios idiomas, non só inglés e ruso, nas que case non nos podíamos comunicar, senón tamén alemán e español. Como resultado, parece moi ridículo cando se lle pregunta nestes idiomas, pero non podemos responder en absoluto. Ou introduciron regras sobre escribir documentación e comentar, pero como a API cambiou con bastante frecuencia e de forma significativa, resultou que a nosa documentación estaba desfasada e era máis enganosa do que axudaba.
Como resultado, todos os nosos esforzos, incluso os equivocados, levaron á aparición de usuarios externos. E mesmo apareceu un cliente comercial que quería que o seu propio RTOS fose desenvolvido para el. E desenvolvémolo porque temos experiencia e unhas bases. Aquí hai que falar tanto dos bos como dos malos. Vou comezar polos malos. Dado que moitos desenvolvedores estaban implicados neste proxecto a título comercial, a comunidade xa era bastante inestable e dividida, o que por suposto non podía menos que afectar o desenvolvemento do proxecto. Un factor adicional foi que a dirección do proxecto foi establecida por un cliente comercial, e o seu obxectivo non era o desenvolvemento do proxecto. Polo menos este non era o obxectivo principal.
Por outra banda, houbo unha serie de aspectos positivos. Temos usuarios verdadeiramente de terceiros. Non era só o cliente, senón tamén aqueles aos que estaba destinado este sistema. A motivación para participar no proxecto aumentou. Despois de todo, se tamén podes gañar cartos cun negocio interesante, sempre é bo. E o máis importante, escoitamos un desexo dos clientes, que naquel momento nos parecía tolo, pero que agora é a idea principal de Embbox, é dicir, usar código xa desenvolvido no sistema. Agora a idea principal de Embbox é usar software Linux sen Linux. É dicir, o principal aspecto positivo que contribuíu ao desenvolvemento posterior do proxecto foi a constatación de que o proxecto é usado por usuarios de terceiros e que debería resolver algúns dos seus problemas.
Daquela, Embox xa fora do ámbito dun proxecto estudantil. O principal factor limitante no desenvolvemento do proxecto segundo o modelo do alumno é a motivación dos participantes. Os estudantes participan mentres estudan, e cando se gradúan debería haber unha motivación diferente. Se non aparece a motivación, o alumno simplemente deixa de participar no proxecto. Se temos en conta que primeiro hai que formar aos estudantes, resulta que cando se gradúan se converten en bos especialistas, pero a súa contribución ao proxecto, por falta de experiencia, non é moi grande.
En xeral, pasamos sen problemas ao punto principal que nos permite falar sobre a creación dun proxecto de código aberto: crear un produto que resolva os problemas dos seus usuarios. Como expliquei anteriormente, a principal propiedade dun proxecto de código aberto é a súa comunidade. Ademais, os membros da comunidade son principalmente usuarios. Pero de onde veñen cando non hai nada que usar? Polo tanto, resulta que, do mesmo xeito que cun proxecto non opensource, cómpre centrarse en crear un MVP (produto mínimo viable) e se interesa aos usuarios, aparecerá unha comunidade arredor do proxecto. Se estás comprometido a crear unha comunidade só a través da comunidade, escribindo unha wiki en todas as linguas do mundo ou corrixindo o fluxo de traballo de git en github, é improbable que isto importe nas primeiras etapas do proxecto. Por suposto, nas etapas adecuadas, estas non só son cousas importantes, senón tamén necesarias.
En conclusión gustaríame sinalar , na miña opinión, que reflicte as expectativas dos usuarios dun proxecto de código aberto:
Estou pensando seriamente en cambiar a este sistema operativo (polo menos tente. Están persiguíndoo activamente e facendo cousas interesantes).
PS activado Teremos ata tres informes. Un sobre código aberto e dous sobre embebido (e outro práctico). No stand levaremos a cabo unha clase maxistral sobre programación de microcontroladores utilizando . Como é habitual, levaremos o hardware e deixarémosvos programar. Tamén haberá unha misión e outras actividades. Ven ao festival e ao noso stand, será divertido.
Fonte: www.habr.com