Cuando el Open Source no significa consultoría ilimitada

El código está abierto

Cuando publico un proyecto Open Source, mi intención es compartir:

• Código.
• Arquitectura.
• Documentación.
• Conocimiento.

Eso significa que cualquier persona puede estudiar el proyecto y, de acuerdo con su licencia, adaptarlo o reutilizarlo.

Una situación que no esperaba

Con el tiempo comenzaron a aparecer solicitudes diferentes.

No se trataba de integrar la API.

No se trataba de utilizar el proyecto.

La solicitud era otra.

"¿Puedes ayudarnos a reimplementar toda la lógica en otro lenguaje?"

Por ejemplo:

• Node.js
• C#
• Python
• Go

Ahí comprendí que existe un límite

Una cosa es explicar cómo funciona un proyecto.

Otra muy distinta es dedicar semanas o meses a transferir años de conocimiento para que otra organización reconstruya exactamente la misma solución utilizando otra tecnología.

En una oportunidad acepté hacerlo.

La experiencia me enseñó que ese tipo de trabajo consumía una enorme cantidad de tiempo.

Desde mi punto de vista profesional, no fue una buena utilización de ese tiempo.

Lo que decidí

A partir de esa experiencia tomé una decisión muy simple.

El proyecto seguirá siendo Open Source.

La documentación seguirá siendo pública.

La arquitectura seguirá siendo abierta.

Pero ya no participo en procesos de reimplementación completa del proyecto en otros lenguajes.

Quien desee hacerlo es libre de estudiar el código y construir su propia implementación.

Sin embargo, mi tiempo hoy está dedicado a mantener y evolucionar AppDTE Community.

Una diferencia importante

Muchas veces se confunden dos conceptos.

Transferencia de conocimiento

• Explicar la arquitectura.
• Publicar documentación.
• Compartir ejemplos.
• Escribir artículos.

Desarrollo profesional

• Reimplementar toda la lógica.
• Adaptar el proyecto a otra plataforma.
• Acompañar una migración completa.
• Desarrollar una versión equivalente.

Para mí son actividades completamente distintas.

Conclusión

El Open Source abre el conocimiento.

No implica que el autor deba asumir cualquier trabajo derivado de ese conocimiento.

Aprendí que también es importante definir los límites de los servicios que estoy dispuesto a ofrecer.

Esos límites no restringen la libertad del software.

Simplemente permiten que el proyecto siga evolucionando sin perder su foco.