| Siguiente: Posibles soluciones al problema Superior: La crisis del software Anterior: La crisis del software |
Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente excluyentes; de facto, es posible que la verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en común que son causadas por el método de valorar los avances científicos y el mecanismo actual de financiación de la actividad científica.
La ciencia en los últimos años se viene haciendo más competitiva. Por razones que quedan fuera del ámbito de este trabajo -quizás desempleo, quizás más valorización del científico- cada vez son más las personas que al terminar su graduación se deciden por cursar un curso de posgraduación, y que prestan concurso para la carrera docente en alguna universidad. El hecho de aumentar la competencia ha hecho que la competición se haga más difícil. Y, de entre los distintos factores que intervienen en un concurso -prueba didáctica, experiencia docente...- o que intervienen en la obtención de una beca de investigación -experiencia investigadora- aquel en que es más fácil marcar diferencia entre personas de la misma promoción es el número de artículos publicados en revistas indexadas.
Por otro lado, entre los grupos ya consolidados la situación es similar. Cada vez existen más grupos de investigación, y la financiación no ha crecido proporcionalmente, por lo que la competencia es cada vez mayor. En muchos países, no llega a manos del investigador una perra gorda si no presenta un rendimiento en publicaciones, via artículos publicados en revistas indexadas.
Este sistema ``publica o perece'' perjudica a los que desarrollan software libre, dado que no existen revistas indexadas específicas de software libre, por lo que es difícil conseguir una publicación de una nueva herramienta desarrollada en una revista indexada. El único método es publicar en una revista de informática teórica, lo que no siempre es posible. Además, esto hace que los que trabajan en informática teórica lo tengan más fácil, porque mientras que desarrollar una solución libre completa con un algoritmo nuevo involucra también un interface gráfico, un montón de pruebas y gran robustez, una comparativa entre dos algoritmos necesita menos tiempo para ser desarrollada. Por otro lado, si no implementa un algoritmo nuevo, no puede ser publicado; de nada vale decir: ``mi programa es el primer y único programa libre que hace tal cosa''. Si alguien ya planteó el problema, aunque no haya desarrollado la aplicación, él publicó y la aplicación completamente desarrollada, funcional, no generará ninguna publicación. Queda publicar en revistas de otra área; por ejemplo, publicar en revistas de biofísica los programas libres de biofísica. sin embargo, contamos con los mismos problemas que en las revistas de informática teórica, junto con los problemas de que tenemos que hacer un trabajo bien por encima de la media de los de la revista por estar fuera de area. Por si esto fuera poco handicap, además, muchas universidades y agencias de fomento de investigación ponderan negatívamente, o incluso ni valoran aquellos artículos indexados realizados en revistas de fuera del área -en nuestro caso, informática-.
Además, los mecanismos de avaliación de rendimiento son ahora a muy corto plazo. Por ejemplo, la agencia de becas que financia mi beca de doctorado exige un informe anual de rendimiento científico, con número de publicaciones en revistas indexadas. Si el rendimiento no es bueno, pierdo la beca.
Por otro lado, los proyectos de software científico que deben ser encarados actualmente en muchas áreas -física, química, medicina, entre otras- son de gran porte, necesitando años para su desarrollo.
Antiguamente era rentable a un grupo consolidado tener uno o varios científicos trabajando a tiempo completo desarrollando software libre. El placer de crear, de descubrir, suponía ya suficiente aliciente como para perder un poco de rentabilidad científica durante unos años, ya que parte del grupo estaba ``entretenida'' en tareas que no iban a suponer publicaciones -desarrollo de software científico-. Sin embargo, actualmente, cada vez se da menos este caso. La supervivencia del grupo y el mantenimiento de la beca de cada uno de los investigadores depende de las publicaciones con vista a un año. Esto supone que en los grupos muchas veces se prioriza la investigación con resultados inmediatos. Rob Pike, en su trabajo sobre por qué la investigación de informática de sistemas estaba muerta, ya daba la voz de alarma. En areas que no sean la informática, como es el caso de la ciencia base, la investigación en herramientas informáticas sufre más todavía de los problemas expuestos por Rob Pike.
La licencia GPL, aunque excelente, no ayuda tampoco a desarrollar software científico libre. Por un lado, es legal según la GPL cambiar el nombre del autor -aunque no sea ético-. La GPL no permite realizar restricciones adicionales a la licencia, cuando sería necesario establecer algún mecanismo para que se citen los trabajos del autor del programa. Por otro lado, a diferencia de otros áreas, no tiene sentido en muchas áreas de ciencia base abrir una empresa de servicios de valor añadido. Aunque esto funcione bien en algunos casos -como es el caso de HelixCode, o de cualquiera de las empresas de distribuciones- la masa crítica de posibles usuarios es lo suficientemente baja como para que no sea posible la supervivencia dando consultoría. Sí, existen universidades y algunas empresas con grandes paquetes de software cerrado. Pero esos paquetes llevan años desarrollándose -algunos más de 20 años-, con el principio que no tenían competencia; y cada dia que pasa, los paquetes son mejores y es más difícil que el software libre pueda presentar competencia real. Un ejemplo es el Whatif. Es un excelente paquete de ingeniería de proteínas, pero es propietario. Existen projectos intentando realizar sustitutos, como es el caso de Platon, que son lo suficientemente poco conocidos y lo suficientemente poco desarrollados como para no ser tenidos en cuenta. Y cada vez la distancia se hace más grande, y ahora que el Whatif se ejecuta maravillosamente en Linux, es probable que acabe con la competencia. Esto supone que en una cosa tan crítica como el diseño de medicinas a partir de proteínas sintéticas no contaremos con software libre plenamente desarrollado.
Por tanto, una primera causa para esta desaceleración del crecimiento del software científico es el sistema de valoración del rendimiento científico. Mas, aunque seamos lo suficientemente idealistas como para jugar a la ruleta rusa con nuestra beca, las cosas no suelen ser tan simples. Universidades y centros de investigación suelen estar rígidamente jerarquizados. A diferencia de estructuras como el ejercito, donde desde el principio está claro quien es el jefe, en los centros de investigación las relaciones de poder suelen ser delicadas, difusas y necesitan de una gran cantidad de diplomacia. Modificar la licencia de un proyecto científico para licencia libre supone, como mínimo, convencer al orientador y al jefe de grupo de investigación de la idoneidad de liberar un código a cambio de nada. También hay que convencer a los compañeros de grupo, que ayudan incorporando su conocimiento a nuestra aplicación. En caso de responsabilidades compartidas -varios jefes-, la cosa se complica. En el momento que uno ponga reticencias, todos se cerrarán en banda. Y si el viejo gurú del laboratorio dice que eso no sirve para nada, necesitaremos un milagro para continuar con el proyecto.