10 criterios para elegir un proyecto libre

Recientemente se puso en marcha la iniciativa Business Readiness Rating, patrocinada por Carnegie Mellon West Center, O’Reilly, SpikeSource e Intel, para crear una metodología formal de evaluación de madurez de los proyectos de código abierto. Actualmente este proyecto se encuentra en fase de definición.
Independientemente de que se utilice una métrica de comparación, existen algunos criterios informales sencillos para evaluar la idoneidad y madurez de un proyecto de software libre:
1º) Plataforma y estándares
Determinar en qué plataforma está basado el producto y cuales son sus dependencias.
La elección de la plataforma puede afectar especialmente a los proyectos LAMP (Linux+Apache+MySQL+PHP) ya que LAMP es muy popular pero no ha conseguido una gran penetración en las empresas debido a que no cuenta con el apoyo directo de ningún gran fabricante.
Por otra parte, algunos proyectos utilizan formatos de archivo o mecanismos de persistencia poco comunes. Conviene revisar que la información y los protocolos utilizados cumplan con los estándares más extendidos.
2º) Tipo de licencia
No todas las licencias son iguales. La GPL, por ejemplo, no es una licencia nada amigable para los negocios que pretenden modificar el software base y revenderlo, dado que su naturaleza viral obliga a distribuir los derivados también como GPL.
3º) Estabilidad
La estabilidad de un producto es una función del tiempo que lleva en el mercado y de su base de usuarios: basicamente, estabilidad = tiempo x usuarios
4º) Actividad del desarrollo
Cuanto más activo esté el grupo de desarrollo, mejor, ya que esto es un indicador de la velocidad a la que irán incorporando mejoras e innovaciones. El ranking de SourceForge es el rey en la medida de actividad, ya que la utilizan para incentivar el uso de su propio servicio por parte de los desarrolladores.
5º) Comunidad de usuarios
Cuanto más grande y activa mejor.
6º) Calidad del código fuente
Hay que revisar siempre la calidad del código fuente antes de adoptar un proyecto libre, especialmente los componentes más pequeños. Muchos proyectos están inacabados o fueron desarrollados por estudiantes con poco experiencia en implementación. Un componente troyano Open Source mal elegido puede converirse en un auténtico cáncer dentro de un proyecto.
7º) Documentación
Este suele ser un punto débil de muchos proyectos Open Source.
8º) Soporte y certificaciones
En proyectos de misión crítica es fundamental determinar la calidad y el coste del soporte ofrecido por el fabricante o el distribuidor, así como las certificaciones de funcionamiento reconocidas.
9º) Idoneidad
No tiene sentido adoptar un software libre porque es libre, sin tener en cuenta las necesidades reales de la empresa. Es el valor que aporta y no su coste monetario lo que debe tenerse en cuenta a la hora de elegir un producto de software.
10º) Usabilidad
La usabilidad suele ser otro punto flaco de los proyectos libres. Es conveniente realizar unas pruebas previas con los usuarios.
Post relacionado: Enterprise Open Source Alternatives (Roberto Gallopini)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Esta entrada fue publicada en Adoptando Sw Libre en una Organización. Guarda el enlace permanente.