3 de Abril, 2009

Criterios para valoración de proyectos

Supongo que era inevitable que alguien me preguntara en qué consisten esos controles que comento en nuestra decepción con Alfresco. Dichos controles están muy relacionados con el sentido común, y tampoco es que sea algo complicado, pero visto lo visto, tener estas directrices presentes puede ser muy útil.

Es muy importante saber si podemos apostar por un proyecto Open Source: le vamos a dedicar tiempo, el trabajo de varias personas de la empresa pueden depender de él, y si sale mal... es más que probable que cueste dinero.

Hay varios puntos que tenemos claros cuando trabajamos con Software Libre:

  • Por definición de la licencia, no hay garantías.
  • El soporte de la comunidad es limitado.
  • No tiene porqué haber un control de calidad.

Así que se pueden proponer unos elementos a evaluar que nos pueden ayudar a decidir si un proyecto es adecuado para lo que buscamos (una vez cubiertas las necesidades funcionales, claro).

Los elementos que yo valoraría son, en orden de importancia:

  1. Hay comunidad de usuarios: el proyecto se usa, existen listas de corro, foros, etc. Si la comunidad nos tiene que dar soporte, contra más grande y sana se encuentre, mejor.
  2. Se propocionan correcciones a fallos: necesitamos un mantenimiento correctivo del software que utilizamos. Si una versión publicada tiene fallos importantes, nos deben dar correciones en un plazo razonable.
  3. El desarrollo es activo: esto solo aplica cuando no hablamos de una versión final, aunque sería un caso muy raro. Un proyecto en el que se desarrolla, es un proyecto vivo que nos garantizará un soporte. Dentro del desarrollo, el número de colaboradores es un dato interesante.
  4. Existen diferentes ramas: normalmente las nuevas características tardan en estabilizarse, así que es muy conveniente que haya una rama estable lista para producción (a la que se hace mantenimiento correctivo), y otra de desarrollo donde se hacen los cambios evolutivos del producto.

Son cuatro puntos bastante sencillos, ¿verdad? Podríamos quedarnos aquí, y ya tendríamos algunos argumentos para elegir o no un proyecto.

Pero además podemos tener en cuenta unos factores relacionados que nos pueden dar una visión más estratégica del producto:

  • Tecnologías o productos en los que se basa: la viabilidad del proyecto puede estar condicionada por terceros. Por ejemplo, una aplicación que usa un lenguaje de programación que está poco extendido.
  • Es interoperable con otros productos: tenemos que evitar el uso de protocolos y formatos que no sean estándares, para que nos permitan movilidad a otros productos del mismo estilo.
  • Es portable: un producto portable entre distintas arquitectruras y sistemas tiende a ser más robusto, a cambio de que perdamos puntos en especialización.
  • Cuenta con patrocinadores: una entidad propociona financiación, recursos y... quizás control sobre el producto. Este punto es más a medio/largo plazo.

Además de todo esto están las preferencias de cada uno, la excelencia técnica, etc; pero me parece que son buenos criterios para valorar objetivamente los proyectos o productos antes de empezar a utilizarlos.

Anotación por Juan J. Martínez, clasificada en: open source, software libre.

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.

Algunas anotaciones relacionadas: