Software Libre y SCM: Drupal y gestión de la calidad de su cambio como software libre

Siempre hemos buscado cómo mejorar el proceso de producción de Software, y el Software Libre no es la excepción.
El asunto no es un tema menor ahora que el mundo del Software Libre es un mercado productivo y un sector económico. Y por lo mismo sujeto a ciertas reglas pero reglas surgidas del mundo del software libre.
Por eso un post que analiza un caso: DRUPAL, escrito en conjunto con Iván Campaña, RDI Director & Co-Founder de DOMO.
Deseamos aclarar que hablaremos de la Gestión de la Configuración del Software (Software Configuration Management, SCM), pero no como observadores ajenos a la comunidad de Software Libre sino como observadores que vivimos este proceso de madurez desde la propia comunidad DRUPAL.
Software Libre no significa hacer las cosas como se ocurren, sino cumplir un proceso de madurez propio de las comunidades. Esto es normal, y lo aclaramos.
Todas las comunidades humanas han ido superando estados de organización, conducentes hacia estados de trabajo organizados. Así es como siendo sociedad, hemos pasado de nuestros pequeños grupos de antepasados nómadas, luego los pueblos y los primeros asentamientos, conduciendo hacia los estado-ciudad medievales, y ya por último llegando una sociedad global que igualmente busca organizarse.

En paralelo hemos pasado de sociedades tribales, a reinados, imperios, países, más o menos burocráticos, más o menos liberales, más o menos cooperativos. Pero en suma, organizados y buscando medios que permiten la fraterna convivencia.
Gestión de la Configuración del Software o SCM -por sus siglas en inglés- permite el seguimiento y la mejora del desarrollo de software y de las versiones de los componentes y productos en producción. Como todo proceso productivo es apoyado por herramientas automatizadas, software de SCM.
Pero sobre este asunto del SCM, es un error asumir que si usamos una herramienta informática de control de versiones estoy cumpliendo con SCM. La verdad es que el control de versiones es apenas un componente del proceso, y usar un software es tener una visión acotada de la gestión de proyectos.
SCM es un proceso y una cultura organizacional de manufactura profesional y maduro ... No es usar un software, aunque eso ayude.
Aunque, si somos sinceros y recordamos nuestra época de estudiantes universitarios, el mantener un orden y seguir procesos, no es la norma.Albores del desarrollo compartido y el software libre.

Iván recuerda como experiencia, su primer contacto con la web fue por 1996, cuando su uso era aún incipiente y por prácticas como estudiante elaboró su primera página web (con la poca información que pudo conseguir y aprender).
De manera formal como profesional lo hizo posteriormente en el año 2003. Y por ese año, a medida que fueron cambiando las necesidades y los proyectos se comenzó a volver mucho más común el uso de componentes y/o paquetes completos de software para desarrollar.
Era un primer contacto con un CMS (Content Management System) como tal, y al momento pareció lo mejor que se podía obtener para reducir tiempos de desarrollo, aprovechar el conocimiento de otras personas con los mismos problemas y sobre todo conocer cómo lo habían resuelto.
Iván indica que se llegó a topar inclusive con casos de clientes que habían partido utilizando software libre implementado con un proveedor y literalmente habían canibalizado el proyecto, alterando a diestra y siniestra el código, haciéndolo virtualmente imposible de mantener.
Sin embargo, a medida que la complejidad aumentaba, las exigencias eran mayores y los errores y las limitaciones comenzaban a aparecer.
Christian comenzó su trabajo años antes, a mediados de los ochenta. Software libre y CMS no existían. El software era producido y no existía la idea de compartir como se conoce hoy. En las ayudantías universitarías se compartían experiencias y códigos y se aprendían tips. Se producía en máquinas de tiempo compartido y compartir era hablar con el compañero "de al lado".
Por los ochenta programábamos ventanas en X-Windows, "a mano" como la base de las aplicaciones que debían hacerse. O sea, debíamos incluso fabricar nuestras herramientas. Expresiones como framework, platform, API, etc. estaban partiendo. Todo era "hacer software". E internet en esos años de universidad era enviar un mensaje a alguien y esperar unos 10-15 minutos por la respuesta.
Ya en los noventa se trabaja produciendo la primera web. Se hizo hablando directo con el usuario, y en equipos de trabajo en incipientes redes. Como se hacían sistemas de toma de decisiones gráficos, el desarrollo requería alta interacción y por lo mismo se compartían algoritmos, no códigos fuente. Era en esencia un método de algoritmos libres. A fines de los noventa ya vino todo el boom de los CMS desarrollándolos desde cero y corrigiendo miles de líneas de código pues los programadores requerían cierta formalización. El caso Drupal como proceso de gestión de la configuración de software.

Volvamos a Drupal.

Aprender a utilizarlo va conectado con una curva de aprendizaje de pendiente bastante pronunciada. A propósito de esto, hay un gráfico que se mofa del proceso de aprendizaje usual con Drupal.
Como con cualquier software, con Drupal a medida que pasaba el tiempo, se aprende más, y se van descubriendo diferentes formas de hacer las cosas con esta herramienta. Esto es lo que se conoce como "The Drupal Way" que es un conjunto de buenas prácticas obtenidas de la comunidad para sacarle más provecho a la herramienta sin llegar a canibalizar Drupal, entender cómo funcionan algunos de los componentes que lo integran y poder obtener un mejor resultado.
¿Así que, Drupal es una herramienta sin errores? No, sin embargo tiene herramientas para hacer seguimiento de los errores, saber quien es el encargado de resolver un problema, el historial de cambios, el registro de la discusión que se está teniendo para saber como solucionarlo e inclusive la comunidad aporta con recomendaciones y parches para mejorar o corregir errores.
Cada módulo tiene uno o varios encargados de su mantenimiento, gestionar la cola de errores, hacer revisión de los parches y en caso de llegar a ser integrado, aplicarlo y subirlo a drupal.org (que funge como punto de encuentro para los creadores y consumidores de componentes del CMS).
Uno de los puntos de referencia en cuanto a la gestión del cambio, y la forma en la que aporta un miembro a la comunidad, nace desde la aprobación de un módulo nuevo para ser publicado en drupal.org, donde cada uno necesita "ganarse" la reputación suficiente para que su módulo sea aprobado (un proceso que se realiza una sola vez), y esto se gana justamente siguiendo las normativas definidas por la comunidad sobre cómo escribir código seguro, haciendo revisión manual de calidad de al menos 3 módulos, y llenar la solicitud de revisión para el módulo también sea revisado y aprobado, dentro del cual puede ser enviado nuevamente para que sea mejorado, ya sea por errores encontrados, por duplicar una funcionalidad ya existente en otro módulo (lo cual no aportaría al ecosistema), no seguir los estándares de codificación o simplemente por errores de seguridad.
En el caso de lo que se conoce como el core (núcleo) de Drupal, el proceso es similar, pero mucho más estricto, por obvias razones, ya que la idea es que sólo las mejores contribuciones formen parte de la distribución oficial.
Para poder entender esto de mejor manera Iván participó en al menos 2 sprints de código durante dos DrupalCon (encuentro de los diferentes actores que formamos parte de la comunidad). Lo hizo desde abajo, como principiante por completo, a pesar de tener suficiente experiencia a nivel de desarrollo y proyectos, se quería saber cómo funcionaba el proceso en su totalidad y entender la manera correcta de hacerlo.
Dentro de ese proceso se recibió una corta capacitación sobre las herramientas de comunicación utilizadas para encontrar errores y realizar revisiones, cómo moverse a través de los tableros de reporte de errores, la nomenclatura utilizada para describir los problemas, cómo y cuando se puede solicitar una revisión, de qué manera se debe describir el problema o la necesidad, la automatización de pruebas de código y si se decidía aportar con código, cómo debía hacerlo.
Desde nuestra experiencia, esto va mucho más conectado al proceso de SCM en software, donde se registran peticiones de cambio, con solicitantes (clientes), responsables (personal operativo), revisión por pares y observaciones (QAS), control de versiones y un flujo de aprobación claramente identificado.
En otros proyectos de Software Libre en los que trabajamos, aportamos y buscamos conectarnos con la comunidad no encontramos un proceso que nos dé la certeza que estábamos trabajando con un equipo de gente que compartía nuestro interés por tener software que cubriera nuestras expectativas.
Tanto Joomla, como Wordpress (2 de los CMS más utilizados al día de hoy y que evaluamos durante nuestro proceso) tienen millares de componentes, más de uno realizando la misma función, todos asegurando que uno lo hace mejor que otro (con lo cual el esfuerzo se diluye) y con niveles de calidad que dependen realmente de la persona o la empresa que lo realizó, de forma que pueden haber componentes excelentes y otros catastróficos.
Vale la pena recalcar lo que dijimos antes. Todo lo anterior no garantiza que el proceso en Drupal esté libre de errores o que no se pueda escapar algo, pero permite resolver problemas mucho más rápido y genera un alto nivel de apoyo en la comunidad que se ve retribuido como soluciones que todos podemos aprovechar.Drupal: software libre de origen privado y de voluntarios.

Esta capacidad de unir actores empresariales y voluntarios es una de las líneas motivacionales más utilizadas en la comunidad, es lo que permite converger tanto actores de comunidad, como actores de negocios, en los que quizá la motivación es diferente para cada uno, pero marca una línea sobre la cual seguir adelante.
Esto deja claro que el componente empresarial o corporativo tiene un peso importante, ya que existen múltiples aportes que han sido patrocinados por empresas y liberados a la comunidad como software libre.
El caso más reciente, en donde se junta el esfuerzo de la comunidad y empresa ha sido en el aceleramiento para la salida de la versión 8 de Drupal, donde se contó con un plan de incentivos (Drupal 8 Accelerate) para corregir los errores críticos y realizar mejoras al software.
Esto fue canalizado a través de la Drupal Association, un organismo sin fines de lucro que se encarga de ser el catalizador de la comunidad, ampliando el uso de Drupal a través de eventos, capacitaciones, becas y programas de entrenamiento.
Recordando una conversación durante el último Drupal Summit Latino en Cusco-Perú donde conversábamos al respecto, el factor en común es que independiente si somos miembros por la parte empresarial o de la parte comunitaria, todos mantenemos un perfil profesional que queremos desarrollar y con el cual trabajar.
Esto se confirma al ver que no necesariamente la ingeniería de software debe estar divorciada de un proceso creativo, ni tampoco del software libre, las reglas son diferentes, pero el resultado final debe ser el mismo, herramientas que permitan crear soluciones de negocio, obtener resultados palpables y medibles.SCM y software libre.

El SCM es un concepto asociado directamente con la ingeniería de software, y define en términos sencillos o se puede tratar de explicar como la gestión del cambio, de forma que el desarrollo de software pueda ser trazable, evaluado y valorado en términos de calidad y responsabilidad (en el caso de un equipo de desarrollo).

¿De qué manera se maneja esto en el software libre? Nos gustaría decir que todos los proyectos siguen un proceso estructurado, pero la verdad es que existe un gran porcentaje de estos que tienen su origen en el tiempo libre de algún neófito o aparecen como resultado del proyecto universitario de algún estudiante.

Sin embargo, existe una parte de proyectos que nacen amparados bajo el paraguas de una empresa, o en el caso que vamos a abordar, sirven como punto de partida para crear una, en la cual se utiliza el concepto de “Dictador Benévolo”.
En la comunidad de software libre Dictador Benévolo se utiliza para referenciar al líder de proyecto, quien probablemente sea quien dio partida al mismo y define las directrices bajo las cuales se va a manejar el desarrollo de un producto.

Algunos de los líderes de proyecto más conocidos (por nombrar algunos) son: Mark Shuttleworth (Ubuntu), Linus Torvalds (Kernel de Linux), Guidovan Rossum (Python) y Dries Buytaert (Drupal). Podemos dejar alguien fuera, pero vale el ejemplo.

Para este post nos enfocaremos en el último personaje de la lista de líderes, Dries Buytaert, quien es al día de hoy el CTO y co-fundador de la empresa Acquia, la cual según datos de febrero del 2015 maneja cerca de 600 empleados y tiene ingresos sobre los 100 millones de dólares. Acquia fue creada para dar servicios sobre Drupal, un software que creó Dries como proyecto universitario para gestionar contenido.

¿Quiere decir ésto que Drupal es más comercial que software libre? Todo lo contrario, es una de las herramientas web que se ha mantenido fuertemente amparada y apoyada en su comunidad de software libre y es esto lo que le ha permitido crecer y fortalecerse como CMS (Content Management System).

Producir software es trabajar con dos factores clave en la producción de software: la falta de control de calidad y la inflexibilidad del software que se había utilizado.

En nuestro caso y experiencia, comenzamos la búsqueda de alternativas de CMS para poder tener una base sobre la cual montar nuestros proyectos, que nos permitiera ser flexibles, pero al mismo tiempo mantener la ventaja de poder acoplarnos a diferentes escenarios.

Cerca del año 2010, tal era la demanda de proyectos con mayor envergadura (clientes que pedían poder manejar sitios web con necesidades muy específicas y con la capacidad de soportar miles de usuarios de forma concurrente), que se llegó inclusive a considerar la opción de desarrollar nuestra propia herramienta.

Finalmente se optó por utilizar Drupal (luego de evaluar más de 10 herramientas web diferentes, no había sido el ganador, de hecho ni siquiera había quedado en la lista), pero apareció por exigencia de un cliente de EEUU.
Así llegamos a DRUPAL, del cual se conocía poco, pero que a lo largo de los años desarrolló un proceso que se consolida, no solamente por responder a criterios de ingeniería propios del software, sino por mantener la flexibilidad y "frescura" creativa de una comunidad internacional y de voluntarios.
Esta última aclaración es vital en el mundo del software libre. ¿Porqué?
Las comunidades de software libre se crean para dar vida a los software o un tipo de software, lo cual dar lugar a una organización sostenible si el software comienza a masificarse y a ser popular.
Software libre como manufactura, no como ideología, fabrica dispositivos de uso social casi al 100% y deben ayudar a sostener esos procesos sociales en los cuales se inserta.
La calidad del software es inmanente a cualquier dispositivo de ingeniería.
La comentada mejor calidad de los software libre debe compartirse de lo contrario perderá el sentido originario de su esencia.
Queremos cerrar este post con una idea de Drupal:
"Come for the software, stay for the community"
"Ven por el software, quédate por la comunidad"
y unas reflexiones:
Software libre se define por ciertas reglas.
Software libre se valida por su uso.
Pero ¿cómo gestionar la calidad de su cambio?