Proyectos de código abierto: 7 cosas a tener en cuenta

10 noviembre
Denis Tsiplakov, Solutions Architect en DataArt
Proyectos de código abierto: 7 cosas a tener en cuenta
Si te interesa el software de código abierto, no te pierdas este artículo con algunos consejos que pueden resultar útiles para cualquier proyecto.

1. LOS PRODUCTOS PROPIOS DE CÓDIGO ABIERTO PROPIOS PUEDEN LLAMAR LA ATENCIÓN PERO REQUIEREN RECURSOS SIGNIFICATIVOS

Probablemente ya lo sepas pero, en base a mi experiencia personal, puedo asegurarte que incluso a los mejores desarrolladores no les será posible crear rápidamente algo notable basado en código abierto. Por lo tanto, es mejor no confiar en el software de código abierto como una herramienta para promover la empresa en el mercado.

Incluso si tu contribución al repositorio de código abierto convence a un cliente potencial para que firme un contrato, no termina todo ahí. Tal escenario funcionaría si se concentraran los esfuerzos en un nicho tecnológico relativamente estrecho. Para aquellos que, como DataArt, se enfocan en la gama más amplia posible de plataformas y trabajan con las más populares, la probabilidad de tal desarrollo es demasiado baja.

Los productos propios de código abierto pueden atraer la atención, pero requieren de muchos recursos y un cuidado constante. En otras palabras, necesitan de un gran esfuerzo para hacerse notar. 

2. EL CÓDIGO ABIERTO NO CONDUCIRÁ AL RECONOCIMIENTO INMEDIATO DE LOS PROGRAMADORES

Hace veinte años, mientras programaba con Delphi, pude escribir sobre una biblioteca de registro durante un fin de semana que la gente realmente usaba: Torry. Hoy, ya no es tan fácil llamar la atención de los demás.

Cada biblioteca propia requerirá un equipo permanente o, al menos, un producto owner. Hay que vigilar la coherencia, garantizar la transferencia de conocimientos, resolver un montón de problemas y encontrar formas de promover el desarrollo en la comunidad. Es posible que una sola persona pueda manejarla en menos de 40 horas a la semana, pero tendrá suficientes tareas. Esto significa que la dirección de la empresa tendrá que liberarla de otros compromisos y privarla de recursos humanos en su core business.

La experiencia de DataArt en la creación de sus propios productos de código abierto muestra que, en última instancia, su éxito depende del compromiso que uno asume con el producto. Debe haber una persona dedicada y enérgica que tenga absoluta confianza en el valor y el desarrollo del proyecto. Por lo general, las empresas de outsourcing no cuentan con muchas personas que solo quieran trabajar con código abierto y que consideren a un producto en sí como una parte importante de sus vidas.

Si se logra idear un proyecto único o una nueva funcionalidad para un framework bien conocido que no requiere grandes inversiones, ¡enhorabuena!

Toda contribución útil al software de código abierto contribuye a su desarrollo, pero al mismo tiempo es necesario averiguar por qué y si la empresa lo necesita. Esta es la única forma de determinar la dirección del esfuerzo y la cantidad de recursos que se dedicarán.

3. LOS PROYECTOS DE CÓDIGO ABIERTO TAMBIÉN IMPLICAN TAREAS PEQUEÑAS Y POCO DESAFIANTES

Cada proyecto conlleva una serie de tareas típicas, que no siempre son las más difíciles y emocionantes: desde comprobar la documentación hasta eliminar pequeños errores. Sin embargo, resolver estos problemas es importante para los futuros consumidores. 

Por ejemplo, en una biblioteca de código abierto, al crear una plantilla de proyecto hubo errores. Arreglamos esto rápidamente con la ayuda de dos desarrolladores jóvenes. Aunque no fue algo espectacular, la experiencia y los conocimientos adquiridos fueron importantes para ellos.

4. LA ELECCIÓN DEL ALMACENAMIENTO SE VUELVE FÁCIL

Está claro que la tecnología es el mejor punto de partida a la hora de elegir el almacenamiento. En nuestro caso, había más desarrolladores de JavaScript disponibles en ese momento y dos de ellos estaban interesados ​​en proyectos de código abierto. Otro enfoque es simplemente tomar los 100 proyectos principales en GitHub, filtrarlos por tecnología y seleccionar los que resulten más interesantes. Simplemente seleccioná los tickets marcados por los propios desarrolladores como importantes y analizá si contás con el suficiente tiempo para lidiar con los problemas que se describe en ellos.

Image for the article

Es importante cómo se organiza el proyecto en sí: ¿hay pautas y una elección lista de las tareas más importantes? ¿hay muchos problemas solucionados con el número de solicitudes de descarga? Si todo esto falta, parece que el repositorio relevante es poco probable.

Image for the article

En cambio, con un proyecto bien ajustado, un problema se puede resolver en dos horas. 

5. EXISTE UN UMBRAL PARA INGRESAR A UN PROYECTO DE CÓDIGO ABIERTO (PERO ES MUY BAJO)

Si el proyecto tiene un flujo de trabajo normal, se puede participar fácilmente en él. Sin embargo, todavía es un poco más difícil para las empresas que para los desarrolladores individuales. Angular, React y otros repositorios de escala similar están protegidos por un marco legal especial. Para participar en el proyecto en tu tiempo libre, simplemente tenés que marcar "Sí, estoy de acuerdo". Pero si querés participar como empleado de la empresa, vas a necesitar el consentimiento legal de la empresa para la que trabajás.

El acuerdo para utilizar software de código abierto y su desarrollo son dos cosas diferentes. Esto es lógico, ya que de esta forma los proyectos buscan protegerse de organizaciones desleales que podrían pretender ser parte de lo escrito a través del trabajo de sus empleados. Todo estará bien si estás seguro de que los abogados de tu empresa tienen una actitud positiva hacia las iniciativas de código abierto. En DataArt, por ejemplo, no hay obstáculos en tales situaciones.

Image for the article

Al mismo tiempo, existen proyectos de código abierto en cuyo desarrollo difícilmente será posible participar ya que están gestionados por equipos estables, dispuestos a aceptar solo propuestas verdaderamente ingeniosas. Aquí podrás ver por qué.

Si querés contribuir a un proyecto como Angular o React, esto es completamente posible, pero tenés que estar preparado para que tus cambios se verifiquen detenidamente, letra por letra (sin exagerar). Es una experiencia motivadora, pero no todo el mundo está preparado para ello. Si, en cambio, solo buscás hacer algo útil y evitar una revisión agotadora, podés optar por un repositorio más simple. Por ejemplo, en vez de React en sí, alguna biblioteca popular con componentes para él. Allí, el proceso será más sencillo e informal.

6. LOS PROYECTOS DE CÓDIGO ABIERTO SON BUENOS MAESTROS, ESPECIALMENTE PARA DESARROLLADORES PRINCIPIANTES

Los proyectos de código abierto pueden ser útiles para todos los programadores, pero para los desarrolladores principiantes resultan un gran maestro. El proceso en sí puede enseñarles muchas cosas, y el volumen y la complejidad se pueden elegir de acuerdo con el conocimiento de la persona. Todo lo que se necesita para participar es la capacidad de escribir el código lo suficientemente bien y los demás ayudarán: dirán, por ejemplo, si lo que ha escrito cumple con los estándares o no. Además, los grandes proyectos se realizan en base a las mejores prácticas para aprender.

El bajo umbral para ingresar a proyectos permite trabajar con diferentes repositorios en poco tiempo y obtener una experiencia muy diversa. Por eso, cuando se lanzó la iniciativa del proyecto de código abierto en DataArt, la consideramos educativa. 

7. NO HAY QUE APURARSE EN HACER PROMESAS

A veces sucede que las pequeñas empresas y los desarrolladores independientes asumen muchas tareas diferentes, y llega un punto en que se comprometen incluso a resolver un problema en unas pocas horas, cuando en verdad podrán hacerlo en un mes o incluso un año. 

Este es un ejemplo divertido:

Image for the article

No siempre está claro si casos como este son una estrategia deliberada, una coincidencia o el resultado de una mala planificación. En cualquier caso, son ejemplos que difícilmente deban seguirse.