Esta semana se llevará a cabo 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 código abierto. Por ello, una de nuestras presentaciones se titula . Estará dedicada a la historia del desarrollo de Embox como un proyecto de código abierto. En este artículo quiero compartir las ideas principales que, en mi opinión, influyen en el desarrollo de proyectos de código abierto. El artículo, al igual que la presentación, se basa en la experiencia personal.
Comencemos con lo básico, definiendo el término código abierto. Es obvio que un proyecto de código abierto es un proyecto que tiene una de las licencias que permiten acceder al código fuente del proyecto. Además, un proyecto abierto implica la posibilidad de que desarrolladores externos realicen modificaciones. Es decir, si alguna empresa o desarrollador publica el código de su producto, parcial o totalmente, eso no convierte automáticamente a ese producto en un proyecto de código abierto. Y finalmente, cualquier actividad de proyecto debe resultar en algún tipo de resultado, siendo la apertura del proyecto un indicativo de que este resultado es utilizado no solo por los propios desarrolladores.
No abordaremos los problemas de las licencias abiertas. Es un tema demasiado amplio y complicado que requiere un análisis profundo. Se han escrito muchos artículos y materiales de buena calidad sobre este tema. Pero dado que yo mismo no soy un especialista en derecho de autor, solo diré que la licencia debe cumplir con los objetivos del proyecto. Por ejemplo, para Embox, la elección de la licencia BSD en lugar de la GPL no fue casual.
El hecho de que un proyecto abierto deba permitir realizar cambios y afectar el desarrollo del proyecto abierto implica que el proyecto es distribuido. Gestionarlo, mantener su integridad y funcionalidad es mucho más complicado en comparación con un proyecto que tiene un control centralizado. Surge la pregunta razonable de por qué hacer proyectos abiertos en absoluto. La respuesta radica en la viabilidad comercial; para una cierta clase de proyectos, los beneficios de este enfoque superan los costos. Es decir, no todos los proyectos son adecuados y, en general, puede que el enfoque abierto no sea permisible. Por ejemplo, es difícil imaginar el desarrollo de un sistema de gestión de una planta de energía o de un avión basado en un principio abierto. Claro, en la composición de tales sistemas se deben incluir módulos basados en proyectos abiertos, ya que esto proporcionará una serie de ventajas. Pero alguien debe asumir la responsabilidad por el producto final. Incluso si el sistema se basa completamente en el código de proyectos abiertos, el desarrollador, al empaquetar todo en un solo sistema y hacer compilaciones y configuraciones específicas, en esencia lo cierra. El código puede estar en acceso público.
Para estos sistemas también existen numerosas ventajas al crear proyectos abiertos o participar en ellos. Como ya mencioné, el código del sistema final puede permanecer en acceso público. ¿Por qué? Porque es evidente que es poco probable que alguien tenga un avión igual para probar el sistema. Eso es cierto, pero ciertamente podría haber quienes deseen verificar secciones específicas del código, o, por ejemplo, alguien podría descubrir que la biblioteca utilizada no está configurada de manera del todo correcta.
Una ventaja aún mayor surge cuando una empresa asigna una parte básica del sistema a un proyecto separado. Por ejemplo, una biblioteca para el soporte de un protocolo de intercambio de datos. En este caso, incluso si el protocolo es específico para un determinado campo, los costos de mantenimiento de esta parte del sistema pueden compartirse con otras empresas de ese ámbito. Además, a los especialistas que pueden estudiar esta parte del sistema de forma abierta, les lleva mucho menos tiempo para utilizarla de manera efectiva. Y, por último, convertir esta parte en una entidad independiente, utilizada por desarrolladores externos, permite mejorar su calidad, ya que es necesario ofrecer APIs eficientes y crear documentación, sin mencionar la mejora de la cobertura de pruebas.
La empresa puede obtener beneficios comerciales sin necesidad de crear proyectos abiertos; es suficiente que sus especialistas participen en proyectos externos aplicados en la empresa. Así, todas las ventajas permanecen: los empleados conocen mejor el proyecto, por lo que 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 probado reduce evidentemente los costos de la empresa.
Pero las ventajas de crear proyectos de código abierto no terminan aquí. Tomemos como ejemplo un componente vital del negocio: el marketing. Para ello, representa un excelente entorno para evaluar efectivamente los requisitos del mercado.
Y, por supuesto, no debemos olvidar que un proyecto de código abierto es una forma efectiva de darse a conocer como portador de una especialización. En algunos casos, es prácticamente el único camino para ingresar al mercado. Por ejemplo, Embox comenzó como un proyecto para crear un sistema operativo embebido. Probablemente no sea necesario explicar que existen numerosos competidores. Sin la creación de una comunidad, simplemente no tendríamos los recursos para llevar el proyecto al usuario final, es decir, para que desarrolladores externos comenzaran a usar el proyecto.
La comunidad es clave en un proyecto de código abierto. Permite reducir significativamente los costos de gestión del proyecto, además de desarrollar y mantener la iniciativa. Se puede afirmar que sin comunidad, realmente no hay proyecto de código abierto.
Se han escrito muchos materiales sobre cómo crear y gestionar una comunidad de un proyecto de código abierto. Para no reiterar hechos ya conocidos, intentaré centrarme en la experiencia de Embox. Por ejemplo, un tema muy interesante es el proceso de creación de la comunidad. Es decir, muchos hablan sobre cómo gestionar una comunidad existente, pero a menudo se pasan por alto los momentos de su creación, considerándolo una obviedad.
La regla principal al crear una comunidad para un proyecto de código abierto es que no hay reglas. Me refiero a que no existen reglas universales, así como no hay una bala de plata, al menos porque los proyectos son muy diferentes entre sí. Difícilmente se pueden aplicar las mismas reglas al crear una comunidad para una biblioteca de logging en js y para algún controlador muy especializado. Además, en diferentes etapas de desarrollo del proyecto (y, por ende, de la comunidad), las reglas cambian.
Embox comenzó como un proyecto estudiantil, ya que teníamos acceso a estudiantes del departamento de programación de sistemas. En esencia, estábamos entrando en otra comunidad. Podíamos interesar a los participantes de esa comunidad, los estudiantes, ofreciéndoles buenas prácticas industriales según su especialidad, trabajos de investigación en el campo de la programación de sistemas, trabajos de curso y tesis. Es decir, cumplíamos con una de las reglas fundamentales de la organización de una comunidad: los participantes deben obtener algo, y este precio debe corresponder a la contribución del participante.
La siguiente etapa para Embox fue la búsqueda de usuarios externos. Es muy importante entender que los usuarios son participantes plenos de la comunidad de código abierto. Por lo general, hay más usuarios que desarrolladores. Y para que deseen convertirse en contribuyentes del proyecto, primero deben utilizarlo de alguna manera.
Los primeros usuarios de Embox fueron el departamento de Cibernética Teórica. Propusieron 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 deseaban), fue una experiencia muy valiosa. Por ejemplo, desarrollamos demostraciones que podíamos mostrar a otros, ya que los robots son divertidos y atraen la atención. Al final, obtuvimos verdaderos usuarios externos que empezaron a preguntar qué es Embox y cómo usarlo.
En esta etapa, tuvimos que reflexionar sobre la documentación y los medios de comunicación con los usuarios. Por supuesto, habíamos pensado en estas cosas importantes antes, pero era prematuro y no tenía un efecto positivo. El efecto era más bien negativo. Permítame dar un par de ejemplos. Utilizamos googlecode, cuya wiki soportaba multilingüismo. Creamos páginas en varios idiomas, no solo en inglés y ruso, con los que podíamos comunicarnos más o menos, sino también en alemán y español. Como resultado, era bastante ridículo cuando la gente preguntaba en esos idiomas y no podíamos responder. O establecíamos reglas sobre la redacción de la documentación y la comentación, pero dado que la API cambiaba con bastante frecuencia y de manera significativa, nuestra documentación se volvía obsoleta y generaba más confusión que ayuda.
Al final, todos nuestros esfuerzos, incluso los incorrectos, llevaron a que aparecieran usuarios externos. E incluso apareció un cliente comercial que quería que desarrolláramos un sistema operativo personalizado para él. Y lo hicimos, ya que tenemos experiencia y algunos desarrollos previos. Aquí hay que hablar tanto de los aspectos positivos como de los negativos. Comenzaré con lo malo. Dado que muchos desarrolladores fueron atraídos a este proyecto de forma comercial, la comunidad, que ya era bastante inestable, se dividió, lo que, por supuesto, afectó el desarrollo del proyecto. Un factor adicional fue que la dirección del proyecto estaba establecida por un cliente comercial, cuya meta no era el desarrollo futuro del proyecto. Al menos, este objetivo no era el principal.
Por otro lado, hubo una serie de aspectos positivos. Obtuvimos realmente usuarios externos. No solo eran clientes, sino también aquellos para quienes este sistema estaba destinado. La motivación para participar en el proyecto aumentó. Después de todo, si se puede ganar dinero haciendo algo interesante, siempre es agradable. Y lo más importante, escuchamos un deseo de los clientes que en ese momento nos parecía absurdo, pero que ahora es la idea principal de Embox, a saber, usar código ya desarrollado en el sistema. Actualmente, la idea principal de Embox es usar software Linux sin Linux. Es decir, el aspecto positivo principal que ha facilitado el desarrollo posterior del proyecto fue la comprensión de que lo utilizan usuarios externos y que debe resolver algunos de sus problemas.
En ese momento, Embox ya había trascendido su origen como proyecto estudiantil. El principal factor que limita el desarrollo del proyecto bajo el modelo estudiantil es la motivación de los participantes. Los estudiantes participan mientras están en la universidad, pero cuando se gradúan, debe surgir otra motivación. Si no aparece dicha motivación, el estudiante simplemente deja de participar en el proyecto. Si consideramos que primero hay que capacitar a los estudiantes, resulta que se convierten en buenos especialistas al momento de graduarse, pero su contribución al proyecto, debido a su inexperiencia, no es muy significativa.
En general, estamos pasando suavemente al punto principal que permite hablar sobre la creación de un proyecto de código abierto: la creación de un producto que resuelva los problemas de sus usuarios. Como ya mencioné antes, la característica principal de un proyecto de código abierto es su comunidad. Además, los miembros de la comunidad son, ante todo, usuarios. Pero, ¿de dónde provendrán si no hay nada que usar? Así que, al igual que con un proyecto que no es de código abierto, hay que centrarse en la creación de un MVP (producto mínimo viable), y si este despierta el interés de los usuarios, entonces surgirá una comunidad alrededor del proyecto. Sin embargo, si la creación de la comunidad se realiza únicamente a través de la promoción de la comunidad, la redacción de wikis en todos los idiomas del mundo o un flujo de trabajo Git correcto en GitHub, es poco probable que esto tenga importancia en las primeras etapas del proyecto. Por supuesto, en las etapas adecuadas, esto no solo es importante, sino que también es necesario.
En conclusión, quiero citar , en mi opinión, refleja las expectativas del usuario de un proyecto de código abierto:
Estoy considerando seriamente cambiarme a este sistema operativo (al menos, probarlo. Se están haciendo muchas mejoras y se crearon cosas increíbles).
P. S. En tendremos un total de tres presentaciones. Una sobre código abierto y dos sobre sistemas embebidos (y una será práctica). En nuestro stand, realizaremos un taller de programación de microcontroladores usando . Tradicionalmente, llevaremos hardware y permitiremos programarlo. También habrá un juego de búsqueda y otras actividades. Ven al festival y a nuestro stand, será divertido.
Fuente: habr.com
