Imagine esto: a su compañía le va bien, ésta hace uso de una parte de software confiable y bien estructurado para respaldar algunos procesos importantes del negocio, cuando repentinamente se vuelve aparente que no todo anda bien en la comunidad de desarrolladores del proyecto. Se produce una división y el futuro mismo del proyecto depende de ese balance. Antes de que lleguemos a las preguntas cruciales respecto a qué tan mala podría ser una división y qué debería hacer un CIO cuando se enfrenta a una, primero debemos entender claramente de qué estamos hablando.

En su estudio de separaciones de software, los investigadores Gregorio Robles y Jesús M. González‐Barahona de la Universidad Rey Juan Carlos en España definen la separación de la siguiente manera:

La división ocurre cuando una parte de la comunidad de desarrolladores ﴾o terceros que no se relacionan al proyecto﴿ inicia una línea completamente independiente de desarrollo fundada en la base del código fuente de un proyecto. Para ser considerada una división, un proyecto debería tener:

1. Un nuevo nombre de proyecto
2. Una rama del software.
3. Una infraestructura paralela (sitio web, sistema de versiones, listas de mailing, etcétera)
4. Y una nueva comunidad de desarrolladores (separada de la original).

Y para poner las cosas en perspectiva, vale la pena recordar que la división no es tan común. Aunque las divisiones se han vuelto más frecuentes en los últimos años, los investigadores encontraron que el número de éstas no ha crecido en proporción al número de proyectos de software gratuitos.

Ver las separaciones desde ambos lados las divisiones podrían no ser tan comunes, pero eso no evita que pensar en una de ellas sea menos enervante si su compañía depende del proyecto en cuestión. Así que ¿cómo deberían pensar los CIOs respecto de las divisiones?

“En un extremo, las divisiones son uno de los derechos fundamentales que tiene con el código abierto, y estamos hablando de lo genial que es tener la libertad de separarse ‐puede ser una buena manera de revivir un proyecto moribundo”, afirmó Allison Randal, presidenta de Open Source Initiative.

Como un ejemplo, Randal señaló que antes de la separación de LibreOffice, OpenOffice.org estaba sufriendo de “problemas humanos” que evitaban que el código avanzara. La separación de LibreOffice fue exitosa y ahora ha sobrepasado a OpenOffice.org.

Desafortunadamente, la división no siempre produce un resultado tan positivo. “He visto casos donde la separación del proyecto divide a la comunidad, trae tensión, corta los recursos y termina por matar ambos proyectos”, indicó Randal. “Si un proyecto se divide y usted tiene solo la mitad de las personas trabajando en cada lado, se tiene una situación donde cada lado está compitiendo por los mismos usuarios, y éstos no reciben una masa crítica. Entonces se encuentra en problemas”.

Pero existen cosas que usted puede hacer para asegurarse de terminar en el lado correcto de la división.

Si una división es anunciada, “debería tratarla como un ejercicio estándar de evaluación del riesgo”, es el consejo de Randal. “Necesita evaluar ambas partes y ver si una está obteniendo una masa crítica de desarrolladores ‐esa es la clave. También tiene que ver si una de ellas está obteniendo una masa crítica de usuarios. Sí es así, apueste por esa, porque será la ganadora ‐inclusive si no hay una compañía detrás. Si una parte de la separación tiene éxito, las compañías vendrán a proveerle soporte”.

La vida real puede ser caótica
Algunas veces no será muy claro si es que una división será exitosa, y ninguno de los lados obtendrá rápidamente una masa crítica de desarrolladores y usuarios. “En ese caso, debería adoptar el enfoque de observar y esperar a ver qué pasa, o le podría servir un proyecto distinto ‐o al menos busque una alternativa”, indicó Randal.

Cuando Nextcloud se separó de ownCloud a comienzos de año, fue el cofundador de ownCloud, Frank Karlitschek, quien estuvo detrás de la división, y fue él quien fundó Nextcloud. A pesar de esto, él dijo que las divisiones deben evitarse siempre que sea posible. “En general, la separación no es algo bueno. Viene con desventajas significativas y debería ser el último recurso. Sacude y daña a la comunidad, y en el peor de los casos puede partir por la mitad a la comunidad”, anotó.

Karlitschek añadió que, cuando fundo Nextcloud, él estaba bastante consciente que para un CIO cuya compañía hace uso de un proyecto, y que podría estar pagando por una suscripción o paquete de soporte, instigar una división causa problemas que necesitan minimizarse de ser posible. “Si una compañía (como ownCloud) tiene clientes, tiene una responsabilidad con ellos, y algo que siempre querrá hacer en una situación de división es mantenerlos felices. Necesita cerciorarse de que a los usuarios les sea posible hacer una transición fluida ﴾hacia la separación﴿ sin tener pérdidas financieras ‐y eso es bastante complicado.

Él afirmó que con Nextcloud fue importante asegurar que el lanzamiento inicial fuese una “gota de reemplazo” de ownCloud, que era 100% compatible, y Nextcloud también ofreció respetar los contratos de respaldo existentes que tenían los clientes de ownCloud.

Un problema potencial para los CIOs, cuando éstos intentan decidir a cuál rama de la división respaldar, es que la parte que ganará eventualmente no siempre es obvia por razones que no se relacionan al ámbito técnico, de acuerdo Michael Meeks, miembro clave del proyecto LibreOffice.

“El branding es un problema cuando se realiza una separación”. Los ingenieros creen que una separación solo se trata de funciones, y LibreOffice está llena de éstas. Pero aun así le tomó mucho tiempo despegar sin importar que LibreOffice y OpenOffice no tienen costo, y usted puede moverse libremente de uno al otro. Construir una marca es costoso, y no tener los recursos para construir una marca puede ser frustrante en una separación”.

¿Los CIO deberían temer a las divisiones?
La mejor forma de contestar esta pregunta puede ser buscar datos históricos respecto a lo que pasa cuando ocurre una separación.

En su investigación, Robles y Gonzales‐Barahona se propusieron “documentar todas las divisiones significativas”. Desde agosto del 2011, ellos han identificado 220 proyectos que experimentaron divisiones. En menos del 9% de estos casos, tanto el proyecto original como su separación fueron descontinuados. Y cuando quita el caso donde un proyecto es separado debido a la ﴾posible o real﴿ descontinuación del original, el proyecto original es descontinuado cerca del 10% de las veces, y las divisiones son descontinuadas con una frecuencia ligeramente más frecuente (14% de las veces).

Eso significa que, en 9 de 10 veces, el proyecto original o la división que provino de éste, continuarán existiendo para proporcionarle el software del que ha estado dependiendo. Es por esto que Karlitschek de Nextcloud dijo que lo mejor que puede hacerse cuando uno se enfrenta a una separación es mantener la calma. “Mi consejo para los CIO es que se relajen, que vean cómo se desarrollan los proyectos y noten cuál de estos termina con mejores funciones. Después de unos pocos meses decidan a cuál de los proyectos respaldará. No es algo que tengan que hacer inmediatamente”.

-Paul Rubens, CIO.com