Open Sourcing TIC

Greg Schott, CEO de Mulesoft, da una pequeña guia en ZDNet acerca de cómo deben cambiarse los patrones de compra para adoptar Software Libre
1. Establecer centros internos de excelencia en Software Libre. Que puede ser un centro de una sola persona, pero alguien tiene que dedicar tiempo a probar y evaluar opciones.
2. Entender las diferencias en los criterios de valoración. No se invita a IBM u Oracle junto con un proveedor de Software Libre a la vez al mismo proceso de compra y con los mismos criterios de valoración.
3. Establecer un criterio propio. Como corolario de lo anterior, en vez de confiar en la checklist de un analista externo, hacer una lista propia de necesidades particulares y determinar si el software (Libre o Privativo) las cumple.
4. Reconocer y recompensar el uso de Software Libre.
5. Deshacerse de las licencias corporativas. Las licencias corporativas son una de las tácticas anti Software Libre más eficaces, ya que tienden a dejar preso al cliente mediante una oferta a la totalidad, eliminando cualquier posibilidad de tomar decisiones tácticas favorables al Software Libre.
6. No creerse los FUDs ni dejarse asustar. Esta la he añadido yo mismo sobre las de Schott. Una de las maneras habituales de «ocuparse» de Linux es difundir rumores de que se producirán catastróficas consecuencias si se adopta Software Libre. Todos esos rumores ya se ha demostrado y más que demostrado que son absolutamente falsos.
7. Establecer un Criterio de Transparencia. Un añadido de José Luis Criterios que pueden cumplir o no proyectos de Software Libre o de Software Privativo. No todo proyecto de Software Libre puede responder a preguntas como ¿Cuál es el esfuerzo, el porcentaje de cambios en los últimos meses al proyecto? ¿Se estanca o evoluciona? ¿Tiene muchos bugs o pocos la última versión? ¿Se resuelven con diligencia? ¿Qué tecnologías aprovecha? ¿Esta adaptándose a los nuevos tiempos? ¿Existen clientes satisfechos o no a los que acceder desde fuera del entorno directo del proyecto? Hay datos fundamentales que en un caso estarán en la «Web» (repositorios de cambios y foros públicos y abiertos) o los puede suministrar la empresa propietaria. Estos datos sobre la evolución de líneas de código o el ratio de bugs resueltos por semana, prácticamente nunca son facilitados por los fabricantes de Software Privativo.
Post relacionados:
Incentivos a la toma de decisiones de compra
Cómpreme Software Libre Señor Presidente
Como venderle Software Libre a tu jefe
Los directores de TI apáticos con el Software Libre.