Ya esta semana en San Petersburgo se
realizará el festival
TechTrain IT. Uno de los oradores será Richard Stallman.
Embox también participa en el festival y, por supuesto, no podríamos ignorar el tema del software de código abierto. Por lo tanto, uno de nuestros informes se llama
"De las manualidades de los estudiantes al proyecto de código abierto. Experiencia Embox " . Se dedicará a la historia de Embox como un proyecto de código abierto. En este artículo quiero hablar sobre las ideas principales que, en mi opinión, afectan el desarrollo de proyectos de código abierto. El artículo, como el informe, se basa en la experiencia personal.
Comencemos con una definición simple del término código abierto. Obviamente, un proyecto de código abierto es un proyecto que tiene una de las licencias que le permite acceder al código fuente del proyecto. Además, un proyecto abierto implica la posibilidad de cambios por parte de desarrolladores externos. Es decir, si alguna empresa o desarrollador publica el código de su producto, parcial o completamente, esto no convierte a este producto en un proyecto de código abierto. Y, por último, cualquier actividad del proyecto debe dar lugar a la aparición de algún tipo de resultado, y la apertura del proyecto implica que no solo los propios desarrolladores utilizan este resultado.
No tocaremos los problemas de las licencias abiertas. Este es un tema demasiado grande y complicado que requiere una investigación profunda. Se han escrito muchos buenos artículos y materiales sobre este tema. Pero como yo no soy especialista en el campo de los derechos de autor, solo puedo decir que la licencia debe cumplir con los objetivos del proyecto. Para Embox, por ejemplo, elegir una licencia BSD en lugar de una licencia GPL no fue aleatorio.
El hecho de que un proyecto abierto permita hacer cambios e influir en el desarrollo de un proyecto abierto implica que el proyecto está distribuido. Administrarlo, mantener la integridad y la eficiencia es mucho más difícil en comparación con un proyecto con administración centralizada. Surge una pregunta razonable: ¿por qué los proyectos de código abierto en absoluto? La respuesta se encuentra en el campo de la viabilidad comercial; para una cierta clase de proyectos, los beneficios de este enfoque superan los costos. Es decir, no para todos los proyectos, un enfoque abierto es generalmente aceptable. Por ejemplo, es difícil imaginar el desarrollo de una planta de energía o un sistema de control de aeronaves basado en un principio abierto. No, por supuesto, vale la pena incluir módulos basados en proyectos abiertos en la composición de dichos sistemas, ya que esto proporcionará una serie de ventajas. Pero alguien debe responder por el producto final. Incluso si el sistema está completamente basado en código fuente abierto, el desarrollador, que empaqueta todo en un sistema y realiza ensamblajes y configuraciones específicas, esencialmente lo cierra. El código puede estar disponible públicamente.
Para estos sistemas, también hay muchos beneficios al crear proyectos de código abierto o participar en ellos. Como dije, el código del sistema final puede permanecer en el dominio público. Por qué, porque es obvio que es poco probable que alguien tenga el mismo avión para probar el sistema. Esto es cierto, pero puede haber alguien que quiera verificar secciones individuales del código, o por ejemplo, alguien puede encontrar que la biblioteca utilizada no está configurada correctamente.
Un beneficio aún mayor aparece si la compañía asigna alguna parte básica del sistema a un proyecto separado. Por ejemplo, una biblioteca para admitir algún tipo de protocolo de intercambio de datos. En este caso, incluso si el protocolo es específico para un área temática determinada, es posible compartir los costos de mantener esta parte del sistema con otras compañías de esta área. Además, los especialistas que pueden estudiar esta parte del sistema en el dominio público necesitan mucho menos tiempo para usarlo de manera efectiva. Y finalmente, resaltar una pieza como una entidad independiente, que es utilizada por desarrolladores externos, le permite mejorar esta parte, porque necesita ofrecer API efectivas, hacer documentación, ni siquiera estoy hablando de mejorar la cobertura de la prueba.
Una empresa puede obtener beneficios comerciales sin crear proyectos abiertos, es suficiente que sus especialistas participen en proyectos de terceros utilizados por la empresa. Después de todo, todos los beneficios permanecen: los empleados conocen mejor el proyecto, por lo tanto, lo usan de manera más eficiente, la compañía puede influir en la dirección del desarrollo del proyecto, bueno, el uso de código depurado listo obviamente reduce los costos de la compañía.
Los beneficios de crear proyectos de código abierto no terminan ahí. Tomemos un componente tan importante del negocio como el marketing. Para él, este es un sandbox muy bueno, que le permite evaluar de manera efectiva los requisitos del mercado.
Y, por supuesto, no debemos olvidar que el proyecto de código abierto es una forma efectiva de declararse como el portador de cualquier especialización. En algunos casos, esta es generalmente 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 tendríamos suficientes recursos para llevar el proyecto al usuario final, es decir, para que los desarrolladores externos lo utilicen.
La comunidad es clave en el proyecto de código abierto. Le permite reducir significativamente los costos de gestión de proyectos, desarrolla y apoya el proyecto. Podemos decir que sin una comunidad no hay ningún proyecto de código abierto.
Se han escrito muchos materiales sobre cómo crear y administrar 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, un tema muy interesante es el proceso de creación de una comunidad. Es decir, muchos dicen cómo administrar la comunidad existente, pero los momentos de su creación a veces se pasan por alto, considerándolo un hecho.
La regla principal al crear el proyecto de código abierto de la comunidad: no hay reglas. Quiero decir, no hay reglas universales, como una bala de plata, aunque solo sea porque los proyectos son muy diferentes. Es casi imposible usar las mismas reglas al crear una comunidad para una biblioteca de registro js y algún controlador altamente especializado. Además, en diferentes etapas del desarrollo del proyecto (y, por lo tanto, de la comunidad), las reglas cambian.
Embox comenzó como un proyecto estudiantil, ya que había acceso a los estudiantes en el Departamento de Programación del Sistema. De hecho, fuimos a otra comunidad. Los participantes de esta comunidad, estudiantes, podrían estar interesados en buenas prácticas industriales en su especialidad, trabajos científicos en el campo de la programación de sistemas, trabajos y diplomas. Es decir, cumplimos con una de las reglas básicas de organización comunitaria, los miembros de la comunidad deben obtener algo, y este precio debe corresponder a la contribución del miembro.
La siguiente etapa para Embox fue la búsqueda de usuarios de terceros. Es muy importante comprender que los usuarios son miembros de pleno derecho de la comunidad de código abierto. Por lo general, hay más usuarios que desarrolladores. Y para querer convertirse en un contribuyente al proyecto, primero comienzan a usarlo 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 en persona y discutir lo que querían). Pero aún 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, tuvimos usuarios realmente externos que comenzaron a preguntar qué era 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. Déjame darte un par de ejemplos. Usamos googlecode, la wiki que soportaba multilingüismo. Hicimos páginas en varios idiomas, no solo inglés y ruso, que no podían comunicarse mal, sino también alemán y español. Como resultado, parecía muy ridículo cuando se le preguntó en estos idiomas, pero no podemos responder en absoluto. O introdujeron reglas para escribir documentación y comentar, pero dado que la API cambió con bastante frecuencia y de manera significativa, resultó que nuestra documentación estaba desactualizada y era más engañosa de lo que ayudó.
Como resultado, todos nuestros esfuerzos, incluso los no correctos, llevaron a la aparición de usuarios externos. E incluso apareció un cliente comercial que quería que él desarrollara su propio RTOS. Y lo desarrollamos porque tenemos experiencia y algunos desarrollos. Aquí debes hablar sobre los puntos buenos y los malos. Comenzaré con los malos. Dado que muchos desarrolladores estuvieron involucrados en este proyecto sobre una base comercial, la comunidad, y por lo tanto bastante inestable, se separó, lo que por supuesto no pudo sino afectar el desarrollo del proyecto. Un factor adicional fue que la dirección del proyecto fue establecida por un cliente comercial, y su propósito no era el desarrollo posterior del proyecto. Al menos este objetivo no era el principal.
Por otro lado, hubo una serie de puntos positivos. Tenemos realmente usuarios de terceros. No era solo el cliente, sino también aquellos a quienes estaba destinado este sistema. La motivación para participar en el proyecto ha crecido. Después de todo, si también puede ganar dinero en un asunto 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, a saber, utilizar el código ya desarrollado en el sistema. La idea principal de Embox ahora es usar software de Linux sin Linux. Es decir, el principal factor positivo que contribuyó al desarrollo posterior del proyecto fue darse cuenta de que el proyecto fue utilizado por usuarios externos, y que debería resolver algunos de sus problemas.
En ese momento, Embox ya estaba fuera del alcance del proyecto del estudiante. La principal limitación para el desarrollo del proyecto según el modelo del alumno es la motivación de los participantes. Los estudiantes participan mientras estudian, y cuando se gradúan, debe aparecer una motivación diferente. Si no aparece la motivación, el estudiante simplemente deja de participar en el proyecto. Si tenemos en cuenta que los estudiantes primero deben ser entrenados, resulta que se convierten en buenos especialistas al momento de la graduación, pero la contribución al proyecto, debido a la inexperiencia, no es muy grande.
En general, nos estamos moviendo sin problemas al punto principal, lo 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 del proyecto de código abierto es su comunidad. Además, los miembros de la comunidad son principalmente usuarios. ¿Pero de dónde vienen hasta qué usar? Resulta que, al igual que con un proyecto que no es de código abierto, debe centrarse en crear un MVP (producto mínimo viable) y, si interesa a los usuarios, aparecerá una comunidad alrededor del proyecto. Si solo está involucrado en la creación de una comunidad a través de relaciones públicas de la comunidad, escribiendo un wiki en todos los idiomas del mundo o un flujo de trabajo git adecuado en github, entonces es poco probable que esto importe en las primeras etapas del proyecto. Por supuesto, en las etapas apropiadas, no solo son cosas importantes, sino también necesarias.
En conclusión, quiero hacer un
comentario , en mi opinión, reflejando las expectativas del usuario del proyecto de código abierto:
Pienso seriamente en cambiar a este sistema operativo (al menos pruébalo. Son muy activos en serrarlo y hacer cosas geniales).
PD: En
TechTrain tendremos hasta tres informes. Uno sobre código abierto y dos sobre incrustado (y uno práctico). En el stand, realizaremos una clase magistral sobre programación de microcontroladores utilizando
Embox . Tradicionalmente, traeremos las glándulas y les dejaremos programar. También habrá una búsqueda y otras actividades. Ven al festival y a nuestro stand, será divertido.