Recientemente estaba en las IV Jornadas de SIG Libre de Girona hablando con la gente de Sextante, cuando un conocido se dirigió a ellos. La conversación fue más o menos en estos términos:
– “¡Os he hecho un fork!“
– “¡Por fin! ¡No hay proyecto open-source serio sin su fork!“
– “¡Ahora ya somos un proyecto de verdad!“
– “Ahora cuéntanos, ¿qué ha pasado?“
– “Vereis es que necesitaba …“
Bromas aparte, la proliferación de forks y similares parece que estos días está de moda. En el caso de Sextante, el tema se debía, según creo recordar, a versiones de bibliotecas; nada que no resuelva una siguiente release de Sextante.
Ha coincidido que esta semana ha habido bastante revuelo en las listas de correo internacionales de gvSIG, tras el anuncio de una distribución paralela no oficial de gvSIG, que soluciona varios problemas existentes en la versión oficial 1.9.
El asunto no habría pasado de ahí si no fuera porque ha habido intentos de comunicación con la organización responsable de la nueva distribución (“quasi-fork”), sin respuesta. Confío en que, dejando a un lado intereses de vender una imagen a través de una nueva distribución, se trabaje en común, con repositorio de código fuente común, aplicaciones y cadenas de L10Ncomunes, bugtracking común, etc. Parece que va a ser así.
Pensando en las razones que motivan a alguien aventurarse a hacer un fork, se me ocurren varias:
- Motivos técnicos. El proyecto original presenta limitaciones técnicas que para alguien son tan insalvables que fuerzan a hacer un fork. Un ejemplo de este caso podría ser GeoToolkit, fork de GeoTools (con aditivos de motivos estratégicos).
- Motivos personales. Problemas de comunicación, inter-personales o ansias de portagonismo personal motivan que alguien decida no seguir colaborando en un proyecto y lance un fork.
- Motivos estratégicos. La dirección del proyecto diverge de los intereses estretégicos de un desarrollador o grupo, forzando a realizar una rama del proyecto, creando uno nuevo.
Habitualmente, suele darse una mezcla de motivos. Mi opinión personal, es que muchas veces las divergencias surgen de problemas de comunicación que derivan en posiciones forzadamente inamovibles. En ocasiones es beneficioso, ya que la “forkabilidad” implica un consenso tácito en la dirección del proyecto; consenso que se hace explícito cuando aparece un fork y la comunidad debe decidir el camino a seguir. La posibilidad de que se pueda hacer un fork es intrínsecamente buena y sana, característica única de los proyectos open source.
Sin embargo, lanzar forks alegremente es en general una manera horrible e ineficiente de solucionar los problemas que puede tener un proyecto. ¡Comunicación, por favor! Una mejor comunicación solucionaría muchos de los problemas que motivan un fork.
Así, que a fin de cuentas, la aparición de forks es, en cierta manera, una consecuencia del éxito de un proyecto. No se producen forks de proyectos en vía muerta, simplemente se extinguen (como sucedió con el proyecto Community MapBuilder).
Así, que puede afirmarse que gvSIG ya es un proyecto maduro, con su propio fork. Seguiremos la vida de este “pseudo-fork” nacido para morir con la publicación de la versión 2.0 de gvSIG. ¿Extraño? No, además de los motivos técnicos concretos que puedan existir, la publicidad que está recibiendo la organización que lo ha lanzado, probablemente le valga la pena.
