Esta semana se celebrará un festival de TI en San Petersburgo . Uno de los ponentes será Richard Stallman. También participa en el festival, y por supuesto no podíamos dejar de lado el tema del software libre. Por eso uno de nuestros informes se llama . Estará dedicado a la historia del desarrollo de Embox como proyecto de código abierto. En este artículo quiero hablar de las principales ideas que, en mi opinión, influyen en el desarrollo de proyectos opensource. El artículo, al igual que el informe, se basa en una experiencia personal.
Empecemos por algo sencillo, con la definición del término opensource. Obviamente, un proyecto de código abierto es un proyecto que tiene una de las licencias que permite acceder al código fuente del proyecto. Además, un proyecto abierto significa que los desarrolladores externos pueden realizar cambios. Es decir, si alguna empresa o desarrollador publica el código de su producto, parcial o totalmente, esto aún no convierte a ese producto en un proyecto de código abierto. Y finalmente, cualquier actividad del proyecto debe conducir a algún tipo de resultado, y la apertura del proyecto implica que este resultado no solo lo utilizan los propios desarrolladores.
No tocaremos los problemas de las licencias abiertas. Este es un tema demasiado amplio y complejo que requiere una investigación en profundidad. Se han escrito bastantes buenos artículos y materiales sobre este tema. Pero como yo mismo no soy un experto en el campo de los derechos de autor, solo diré que la licencia debe cumplir con los objetivos del proyecto. Por ejemplo, para Embox la elección de una licencia BSD en lugar de una licencia GPL no fue accidental.
El hecho de que un proyecto de código abierto proporcione la capacidad de realizar cambios e influir en el desarrollo del proyecto de código abierto implica que el proyecto está distribuido. Gestionarlo, mantener la integridad y el rendimiento es mucho más difícil en comparación con un proyecto con gestión centralizada. Surge una pregunta razonable: ¿por qué abrir proyectos? La respuesta está en el área de la viabilidad comercial; para una determinada clase de proyectos, los beneficios de este enfoque superan los costos. Es decir, no es adecuado para todos los proyectos y un enfoque abierto es generalmente aceptable. Por ejemplo, es difícil imaginar el desarrollo de un sistema de control para una central eléctrica o un avión basado en un principio abierto. No, por supuesto, estos sistemas deberían incluir módulos basados en proyectos abiertos, porque esto proporcionará una serie de ventajas. Pero alguien debe ser responsable del producto final. Incluso si el sistema se basa completamente en el código de proyectos abiertos, el desarrollador, después de empaquetar todo en un solo sistema y realizar compilaciones y configuraciones específicas, esencialmente lo cierra. El código puede estar disponible públicamente.
También existen muchos beneficios para estos sistemas al crear o contribuir a proyectos de código abierto. Como ya dije, el código del sistema final puede permanecer disponible públicamente. Porque es obvio que es poco probable que alguien tenga el mismo avión para probar el sistema. Esto es cierto, pero es posible que alguien quiera comprobar determinadas secciones del código o, por ejemplo, que alguien descubra que la biblioteca que se está utilizando no está configurada del todo correctamente.
Aparece un beneficio aún mayor si la empresa asigna alguna parte básica del sistema a un proyecto separado. Por ejemplo, una biblioteca que admita algún tipo de protocolo de intercambio de datos. En este caso, incluso si el protocolo es específico de un área temática determinada, puede compartir los costos de mantenimiento de esta parte del sistema con otras empresas de esa área. Además, los especialistas que pueden estudiar esta parte del sistema en el dominio público necesitan mucho menos tiempo para utilizarla de forma eficaz. Y, finalmente, separar una pieza en una entidad independiente que utilizan los desarrolladores externos nos permite mejorar esta parte, porque necesitamos ofrecer API efectivas, crear documentación y ni siquiera estoy hablando de mejorar la cobertura de las pruebas.
Una empresa puede recibir beneficios comerciales sin crear proyectos de código abierto, basta con que sus especialistas participen en proyectos de terceros utilizados en la empresa. Después de todo, todos los beneficios permanecen: los empleados conocen mejor el proyecto, por lo tanto lo utilizan de manera más efectiva, la empresa puede influir en la dirección del desarrollo del proyecto y el uso de código ya preparado y depurado obviamente reduce los costos de la empresa.
Los beneficios de crear proyectos de código abierto no terminan ahí. Tomemos un componente tan importante del negocio como el marketing. Para él, se trata de un entorno de pruebas muy bueno que le permite evaluar eficazmente las necesidades del mercado.
Y, por supuesto, no debemos olvidar que un proyecto de código abierto es una forma eficaz de declararse portador de cualquier especialización. En algunos casos, ésta es la única forma de ingresar al mercado. Por ejemplo, Embox comenzó como un proyecto para crear un RTOS. Probablemente no sea necesario explicar que hay muchos competidores. Sin crear una comunidad, simplemente no habríamos tenido suficientes recursos para llevar el proyecto al usuario final, es decir, para que desarrolladores externos comenzaran a utilizar el proyecto.
La comunidad es clave en un proyecto de código abierto. Le permite reducir significativamente los costos de gestión de proyectos, desarrollar y respaldar el proyecto. Podemos decir que sin una comunidad no hay ningún proyecto de código abierto.
Se ha escrito mucho material sobre cómo crear y gestionar una comunidad de proyectos de código abierto. Para no volver a contar hechos ya conocidos, intentaré centrarme en la experiencia de Embox. Por ejemplo, el proceso de creación de una comunidad es un tema muy interesante. Es decir, muchos dicen cómo gestionar una comunidad existente, pero a veces se pasan por alto los momentos de su creación, considerándolo un hecho.
La regla principal al crear una comunidad de proyectos de código abierto es que no existen reglas. Quiero decir que no existen reglas universales, al igual que no existe una solución milagrosa, aunque sólo sea porque los proyectos son muy diferentes. Es poco probable que pueda utilizar las mismas reglas al crear una comunidad para una biblioteca de registro js y algún controlador altamente especializado. Además, en las diferentes etapas de desarrollo del proyecto (y por tanto de la comunidad), las reglas cambian.
Embox comenzó como un proyecto estudiantil porque tenía acceso a estudiantes del departamento de programación de sistemas. De hecho, estábamos entrando en alguna otra comunidad. Podríamos interesar a los participantes de esta comunidad, estudiantes, en buenas prácticas industriales en su especialidad, trabajos científicos en el campo de la programación de sistemas, trabajos de curso y diplomas. Es decir, seguimos una de las reglas básicas para organizar una comunidad: los miembros de la comunidad deben recibir algo y este precio debe corresponder a la contribución del participante.
La siguiente etapa de Embox fue la búsqueda de usuarios externos. Es muy importante comprender que los usuarios participan plenamente en la comunidad de código abierto. Suele haber más usuarios que desarrolladores. Y para querer convertirse en colaborador de un proyecto, primero empieza a utilizarlo de una forma u otra.
Los primeros usuarios de Embox fueron el Departamento de Cibernética Teórica. Sugirieron crear un firmware alternativo para Lego Mindstorm. Y aunque todavía eran usuarios locales (podíamos reunirnos con ellos en persona y discutir lo que querían). Pero aun así fue una muy buena experiencia. Por ejemplo, desarrollamos demostraciones que podrían mostrarse a otros, porque los robots son divertidos y llaman la atención. Como resultado, obtuvimos verdaderos usuarios externos que comenzaron a preguntar qué es Embox y cómo usarlo.
En esta etapa tuvimos que pensar en la documentación, en los medios de comunicación con los usuarios. No, por supuesto, pensamos en estas cosas importantes antes, pero fue prematuro y no dio un efecto positivo. El efecto fue bastante negativo. Dejame darte un par de ejemplos. Usamos googlecode, cuyo wiki apoyaba el multilingüismo. Creamos páginas en varios idiomas, no sólo inglés y ruso, en los que apenas podíamos comunicarnos, sino también alemán y español. Por eso, cuando se nos pregunta en estos idiomas, parece muy ridículo, pero no podemos responder en absoluto. O introdujeron reglas sobre la redacción de documentación y los comentarios, pero como la API cambiaba con bastante frecuencia y de manera significativa, resultó que nuestra documentación estaba desactualizada y era más engañosa de lo que ayudaba.
Como resultado, todos nuestros esfuerzos, incluso los equivocados, condujeron a la aparición de usuarios externos. E incluso apareció un cliente comercial que quería que le desarrollaran su propio RTOS. Y lo desarrollamos porque tenemos experiencia y algo de trabajo preliminar. Aquí hay que hablar tanto de los buenos como de los malos momentos. Empezaré por los malos. Dado que muchos desarrolladores participaron en este proyecto a nivel comercial, la comunidad ya estaba bastante inestable y dividida, lo que por supuesto no podía dejar de afectar el desarrollo del proyecto. Un factor adicional fue que la dirección del proyecto la marcó un cliente comercial y su objetivo no era el desarrollo posterior del proyecto. Al menos éste no era el objetivo principal.
Por otro lado, hubo una serie de aspectos positivos. Tenemos verdaderos usuarios de terceros. No se trataba sólo del cliente, sino también de aquellos a quienes estaba destinado este sistema. La motivación para participar en el proyecto ha aumentado. Después de todo, si además puedes ganar dinero con un negocio interesante, siempre es bueno. Y lo más importante, escuchamos un deseo de los clientes, que en ese momento nos parecía una locura, pero que ahora es la idea principal de Embox: utilizar código ya desarrollado en el sistema. Ahora la idea principal de Embox es utilizar software Linux sin Linux. Es decir, el principal aspecto positivo que contribuyó al desarrollo posterior del proyecto fue la comprensión de que el proyecto es utilizado por usuarios externos y debería resolver algunos de sus problemas.
En aquel momento, Embox ya había superado el ámbito de un proyecto estudiantil. El principal factor limitante en el desarrollo del proyecto según el modelo estudiantil es la motivación de los participantes. Los estudiantes participan mientras estudian y cuando se gradúan debe haber una motivación diferente. Si no aparece la motivación, el alumno simplemente deja de participar en el proyecto. Si tenemos en cuenta que los estudiantes primero necesitan capacitarse, resulta que cuando se gradúan se convierten en buenos especialistas, pero su contribución al proyecto, debido a la inexperiencia, no es muy grande.
En general, pasamos sin problemas al punto principal que nos permite hablar sobre la creación de un proyecto de código abierto: crear un producto que resuelva los problemas de sus usuarios. Como expliqué anteriormente, la propiedad principal de un proyecto de código abierto es su comunidad. Además, los miembros de la comunidad son principalmente usuarios. ¿Pero de dónde vienen cuando no hay nada que utilizar? Entonces resulta que, al igual que con un proyecto que no es de código abierto, debes concentrarte en crear un MVP (producto mínimo viable) y, si interesa a los usuarios, aparecerá una comunidad alrededor del proyecto. Si está involucrado en la creación de una comunidad solo a través de relaciones públicas comunitarias, escribiendo una wiki en todos los idiomas del mundo o corrigiendo el flujo de trabajo de git en github, es poco probable que esto importe en las primeras etapas del proyecto. Por supuesto, en las etapas apropiadas esto no sólo es importante, sino también necesario.
Para concluir me gustaría señalar , en mi opinión, refleja las expectativas de los usuarios de un proyecto de código abierto:
Estoy pensando seriamente en cambiar a este sistema operativo (al menos inténtalo. Lo están buscando activamente y haciendo cosas interesantes).
PD activado Tendremos hasta tres informes. Uno sobre código abierto y dos sobre integrado (y uno es práctico). En el stand realizaremos una clase magistral sobre programación de microcontroladores utilizando . Como siempre, traeremos el hardware y te dejaremos programarlo. También habrá una misión y otras actividades. Ven al festival y a nuestro stand, será divertido.
Fuente: habr.com