Hola a todos,
Pensé en aportar algunas perspectivas adicionales (basadas en mi
propia experiencia) a la discusión. Sigo pensando que es un ejercicio
importante evidenciar los aspectos involucrados en este tipo de
decisiones.
Hasta donde pude experimentarlo (puede que las cosas hayan cambiado),
la contratación de este tipo de cosas se ha realizado de manera anual,
debido a que está enmarcada en los presupuestos (anuales) asignados a
proyectos específicos. Si bien existe la figura de apropiación de
vigencias futuras, esta se utiliza para cosas mucho más macro, no para
la adquisición de este tipo de licencias, que por otro lado no son más
que un apoyo al desarrollo de proyectos específicos (para este caso
específico, no es parte de la responsabilidad de la Oficina de
Tecnología del MEN). En ese sentido, podría incluso no adquirirse
ninguna herramienta.
Uno podría decir que tal esquema es desgastante y desventajoso por
muchas razones. Sin duda lo es. Pero son las reglas desde las que se
mueven las entidades públicas...
En ese sentido, es complicado (hasta donde entiendo, de nuevo puedo
estar equivocado) prever una compra de una licencia de alguna cosa
para cinco años. Eso significa que el margen que tenemos es de
14.200.000. Ahora, para agregarle complejidad al ejercicio, tomemos
como referencia la cifra de 36 millones que menciona Rafael. Eso
equivale (en términos gruesos) a un salario de 2.000.000 (más
prestaciones) durante un año para un único ingeniero (que podría
convertirse en 1.000.000 para dos personas).
Como no tengo un conocimiento tan cercano de la realidad actual de la
industria del software nacional, me pregunto ahora cuál sería el
alcance de lo que podría realizar una única persona durante un año.
Obviamente, depende de la habilidad y capacidad de la persona (pues
sería ingenuo suponer que todo desarrollador tiene la misma
capacidad). Es obvio que tal persona tendría como respaldo a una
comunidad mayor (pues estaríamos hablando de una herramienta de
software libre, que es sobre la que se podría hacer desarrollo nuevo),
pero también es obvio que el esfuerzo de desarrollo es alto. Mi duda
sería qué podemos obtener por 36 millones en un año.
Pero, siendo ingeniero y habiendo sido desarrollador durante varios
años, es claro que esa es una pregunta ilógica. Por eso sigo pensando
que el factor de decisión aquí está en la funcionalidad, no en el
costo. Solamente si existe claridad sobre cuáles son las
características del sistema que un cliente requiere, es posible hacer
estimación de esfuerzo y costo. Hacerlo de otro modo (aunque ocurra
con frecuencia) es algo que, en mi opinión, es irresponsable de parte
del cliente e injusto de parte del desarrollador, pero esa es otra
historia (En este sentido, los contratos de alcance limitado -como los
que se usan en ocasiones en XP- pueden ser una buena alternativa, pero
eso es apartarnos de la discusión..).
Lo anterior no quiere decir que no tenga sentido hacer desarrollo
local. Tan solo que no existe una receta única para hacerlo, y que al
analizar el panorama completo en un momento dado del tiempo la
respuesta puede ser positiva, o negativa. Y que tenemos que estar
abiertos a tal posibilidad (digo yo)... ¿Cuáles serían otros factores
de contexto que tendríamos que tener en cuenta para avanzar en este
análisis? ¿El proyecto termina al final de un año, o se convierte en
un gato recurrente? ¿Cuánto cuestan la actualización y el
mantenimiento? ¿Qué es en realidad factible desde la realidad que
tenemos?
Héctor tiene razón en que a menudo podemos observar desperdicio de
recursos. Afortunadamente, creo que este no es el caso. A lo largo
del año de vigencia de la licencia, el proyecto de acompañamiento a la
formulación de planes estratégicos de TIC en las IES realizó diversas
reuniones con líderes de todo el país a través de la herramienta que
se licenció. La Red Virtual de Tutores también realizó diversos
eventos en línea, y ha llegado a convocar a 60 personas en una misma
sesión (este es un número importante, pues es similar al que se
observa en sesiones similares de esta área en inglés, que tienen un
público potencial mucho mayor). En el caso de los talleres EduCamp,
también realizamos diversas actividades a través de la herramienta,
las cuales fueron grabadas, exportadas a diversos formatos y luego
publicadas en línea. Por eso me atrevería a decir que este es un caso
en donde, en realidad, lo que se logró fue un ahorro sustancial de
recursos.
Por supuesto, eso no significa que no tengamos mucho que aprender al
respecto. Todavía estamos descubriendo el potencial de estas
herramientas de conferencia, y tal vez podría argumentarse que, frente
a la funcionalidad disponible, las subutilizamos. Pero eso no es
distinto a lo que, al menos yo, hago con la mayoría de las utilidades
de mi procesador de texto... :D Hace parte del aprendizaje...
Pienso que esa es una perspectiva importante a tener en cuenta. Como
dije en algún momento, sin duda es deseable que el costo se acerque a
cero (en los casos en los que sea posible), pero tal deseo no debería
ocultar que en el último año hicimos cosas que antes no podíamos
hacer, de manera más eficiente. Si en este momento encontramos que
una nueva herramienta nos ofrece la funcionalidad que ya hemos estado
disfrutando por un mejor precio, es claro que tendrá que estar
incluida en el análisis que una entidad como el MEN haga.
En esa línea, sigo pensando que un análisis independiente (más allá de
los departamentos de relaciones públicas de cada empresa) de
comparación funcional entre las diversas herramientas existentes sería
un aporte excelente a esta discusión.
Como dije antes, lo más interesante de esta discusión para mi ha sido
empezar a aclarar un montón de preconceptos y supuestos sobre la
diferencia entre software propietario y software abierto. Una lección
muy importante para mi es que definitivamente no es un asunto binario
(blanco o negro) sino que hay muchos factores que afectan una decisión
de este tipo, y que es crucial tenerlos en cuenta.