Gestión de componentes

Aquí entendemos contribuciones en un sentido amplio: commits en el repositorio de código, bug reports, traducciones, etcétera.

Es más importante la diversidad (personas y entidades diferentes que participan) que la cantidad de las contribuciones (por ejemplo, número de commits por mes).

Si el componente presenta contribuciones por parte de organizaciones importantes (empresas de un cierto tamaño, universidades, instituciones), es más probable que, aunque alguno de los contribuyentes falle, el proyecto continúe. Pero también puede ser muy buena señal que muchas personas a título individual hagan contribuciones y que se tengan en cuenta.

La cantidad de notificaciones de deficiencias. No nos tiene que alarmar que haya muchas notificaciones abiertas y no resueltas, el número de incidencias tiende a crecer linealmente con el número de usuarios, pero, en cambio, el número de desarrolladores suele crecer más lentamente.

Que los desarrolladores estén respondiendo a las incidencias. Insistimos: si el número de usuarios es elevado, habrá siempre muchas incidencias abiertas, pero es importante observar que los desarrolladores participan habitualmente en el bug tracker, que no lo hayan abandonado.

Después hay que mirar la actividad pública del proyecto, teniendo en cuenta lo siguiente:

En productos con licencia libre, siempre será posible contratar a alguien a fin de que los modifique y mantenga o resuelva problemas. No obstante, obtenemos una mayor garantía de éxito si ya existen empresas o personas que ofrecen soporte profesional sobre el componente en cuestión, y que, por lo tanto, se puede asumir que lo conocen bien.

Es mejor que haya diferentes empresas ofreciendo servicios comerciales sobre el producto que solo una, ya que en este segundo caso incurriríamos en una mayor dependencia hacia esta empresa. Es habitual un modelo de negocio en el que la misma empresa que desarrolla el producto (quizás sin mucho soporte comunitario externo) ofrezca también soporte comercial sobre este. No se tiene que descartar de entrada, pero es mejor que el soporte profesional se encuentre diversificado.

La existencia de empresas que ya inicialmente ofrecen servicios profesionales sobre un producto puede facilitar también realizar una evaluación tentativa del coste que supondrá adaptarlo o mantenerlo.

La transparencia es un pilar básico de los proyectos de software libre, sin ella es muy difícil que todo el resto funcione bien.

Que un componente ofrezca instrucciones detalladas y precisas sobre cómo instalarlo facilita que se pueda hacer una evaluación técnica independiente de este.

El hecho de que tanto el código como las herramientas de gestión de proyectos (bug-trackers, listas de correo, foros) sean públicas implica que, sobre los proyectos de software libre, sea posible extraer algunas métricas objetivas muy difíciles de conseguir en el caso de software privativo.

Algunas métricas que se pueden obtener para ciertos proyectos son las siguientes:

Cuando necesitamos adaptar un componente de software libre ya existente, conocer de antemano el proyecto y la comunidad que lo sustenta presenta muchas ventajas:

Puede ser que el IMI tenga ya identificadas personas clave dentro de la comunidad.

Se puede hacer una estimación más realista del coste en tiempo y en dinero de las modificaciones que se pretende hacer, y de las posibilidades de que sean integradas en el producto original.

Esta información la ofrece la Free Software Foundation (FSF) en su listado de licencias: https://www.gnu.org/licenses/license-list.es.html.

Las licencias de la familia de la General Public License (GPL) son unas de las más comunes. Para evitar conflictos de licencia con otros componentes que posiblemente necesitaremos, conviene que todos nuestros componentes sean compatibles con GPL.

Todo componente de la solución que esté incluido en la distribución estable de Debian en el momento de diseñar el proyecto, o que se pueda ejecutar sobre Debian Estable sin necesidad de adaptación, y que sea multiarquitectura, se considera un componente duradero y fiable.

Cuando menos, hay que favorecer componentes que puedan ejecutarse, en su versión estándar descargable en la web del proyecto, sobre plataformas libres, preferiblemente GNU/Linux y sin que existan restricciones en cuanto a lo siguiente:

Requerir una distribución particular de GNU/Linux (por ejemplo, un software que solo se ejecute en entornos CentOS y no sobre Debian).

Versiones demasiado específicas de los elementos principales de la plataforma, sobre todo si se trata de versiones demasiado antiguas o fuera de su periodo de mantenimiento estándar (por ejemplo, un software que requiera un kernel de Linux en una versión 3.*, o unas librerías básicas del sistema desfasadas).

Requerir una arquitectura de hardware específica (por ejemplo, soluciones que solo se ejecuten en máquinas Intel).

Por ejemplo:

Se puede establecer por contrato y puede ser cualquier tarea relacionada con el desarrollo:

El objetivo es tener personal propio familiarizado con un software que se seguirá utilizando en el futuro, una vez se acabe el contrato de desarrollo actual. Se trata de profundizar en la soberanía y evitar al máximo la dependencia de proveedores únicos.