Forks – El bueno, el feo y el malo

Esta semana me ha tocado un poco la moral enterarme que todavía hay programadores, arquitectos o llámalos como te dé la gana que no saben hacer forks o peor aún no saben lo que es un fork. Pensando un poco en el tema se me ha ocurrido dividir los forks del código fuente de un proyecto en 3 tipos: el bueno, el feo y el malo (en honor a la película). Al menos, para que cualquiera que lea esto sepa cuánto la está cagando (o no) con el simple hecho de bifurcar el código de un proyecto.

Si no sabes lo que es un fork, lee esto y lo que viene 🙂

El fork bueno

El fork bueno por poner un ejemplo es el que haces desde Github.

En los sistemas de gestión de código distribuido (git, mercurial, etc.) un fork es la manera natural de contribuir a un proyecto. Haces un fork, modificas/corriges/añades lo que te dé la gana y “vuelcas” tus modificaciones sobre la rama principal. Fácil.

Este flujo al final resulta beneficioso para los proyectos, ya que hace sencillo el hecho de contribuir e incluso sirve de métrica del éxito de un proyecto. A más forks, normalmente más contribuciones, mayor éxito.

El fork feo

El fork feo (para mí) es la bifurcación de un proyecto por problemas en la gestión del mismo. Hay casos muy sonados, como el de OpenOffice/LibreOffice, NodeJS/io.js y muchísimos más. No siempre, pero la mayoría de las veces este tipo de forks tiene más que ver con temas “políticos” que meramente técnicos. Conflictos en las políticas de contribución, exceso de “soberanía” del núcleo de desarrolladores del proyecto, exceso de control, etc.

El caso se suele repetir:

Algún desarrollador o grupo de desarrolladores quiere hacer algo con el proyecto, contribuir de cierta manera o hacer que el proyecto evolucione en cierta dirección. Hay opiniones opuestas por parte del núcleo del proyecto. No se llega a ningún acuerdo y los primeros deciden crear su “versión” del proyecto con otro nombre.

Este tipo de casos suelen desencadenar discusiones públicas entre programadores que no le interesan a nadie por cierto…

Al final, se tienen versiones diferentes del mismo proyecto que evolucionan de manera distinta, en la que contribuyen programadores diferentes y con políticas de gestión diferentes. De cara al usuario final es un jaleo porque: ¿Cuál es mejor peor OpenOffice o LibreOffice? ¿Qué prefieres Node o io.js?

El fork malo

Este es el que “me gusta” y el que me ha motivado a escribir esto. Lo describo así:

Tengo un proyecto monolítico, del que tengo que hacer una versión para un tercero que comparte el 95% de funcionalidad o quiero utilizar un 5% de su funcionalidad para otro proyecto diferente. Como no tengo ni puta idea de gestionar proyectos (a nivel técnico), decido copiar todo el código a otro repositorio y listo.

Las consecuencias:

• Gran parte de código duplicado
• Los bugs que se corrigen en un proyecto no acaban repercutiendo en el otro o hay que duplicar esfuerzos
• No hay funcionalidad compartida, lo que se desarrolla en un proyecto no repercute en el otro o hay que duplicar esfuerzos
• Cualquier programador “normal” va a pensar que el que ha tomado esa decisión es un incompetente
• Cualquier programador “normal” que tenga que desarrollar alguno de esos proyectos va a pensar que hay alguien que no tiene ni guarra

Lo digo siempre, lo malo no es hacer las cosas mal (que también), sino no saber que lo estás haciendo MAL. Incluso, en algún caso este tipo de fork me puede parecer una solución aceptable, el problema está cuando se convierte en la norma.

En fin, es lo que hay, para mí este tipo de forks es uno de los casos más graves de deuda técnica y que se podría evitar con muy poco esfuerzo previo con algo tan básico como gestionar dependencias entre proyectos, reutilizar código, aplicar principios básicos de programación orientada a objetos o diseñar arquitecturas basadas en micro-servicios.