Concurso Universitario de Software Libre (6ª edición)

Por cuarto año consecutivo he participado como miembro del Comité de Evaluación del Concurso Universitario de Software Libre. Como ediciones anteriores, 5 han sido los proyectos que he tenido que evaluar. Los proyectos los elijo basándome en dos criterios:

  1. El stack tecnológico es próximo a mis conocimientos
  2. El tema sobre el que versa el proyecto es de interés para mi.

Aun no cumpliéndose el punto 1º, puedo elegir proyectos que cumplan sólo el punto 2º si el tema me interesa mucho. En este caso simplemente tengo que dedicar mucho más tiempo para evaluarlo. Básicamente porque configurar un entorno de desarrollo por primera vez para un stack tecnológico desconocido, no es sencillo. Este año sí he tenido un proyecto así, relacionado con Digital Signage.

El resumen de mi evaluación no es positivo. Con independencia del nivel de acabado de los proyectos, deduzco que hay poca intención de ganar el concurso por parte de los participantes. O al menos competir. Particularmente que un proyecto tenga una versión “vendible” o no  (lo que en klicap llamamos cerrar el circulo) es sólo un aspecto más de la evaluación, pero hay otros muchos que sí demuestran intención (actitud).

Los aspectos que más valoro en los proyectos son:

  1. La descripción. Hay proyectos que ni se molestan en redactar una descripción que haga atractivo el proyecto. Estás en un concurso, debes saber vender tu idea. Este ejercicio te resultará útil de cara a la defensa de tu proyecto fin de carrera.
  2. Blog. Poner en marcha un blog para escribir 3 o 4 entradas en 4 meses de concurso es perder el tiempo. Usa el blog para compartir tus ideas, decisiones, obstáculos, expectativas o como marketing de tu proyecto. Escribir este tipo de cosas sobre tu proyecto sólo pueden ser positivas porque constantemente te hacen pensar “en voz alta” y reflexionar sobre lo que estás haciendo.
  3. Uso de la forja. Si desde la organización del concurso se os anima a que uséis las herramientas no es porque de cara a la evaluación resulte más cómodo, que también, sino para que tengáis vuestro primer acercamiento a herramientas que formarán parte de vuestro futuro ecosistema de desarrollo software. Quizás en la organización del concurso se debiera dar una pensada al uso de Gforge.
  4. Documentación básica. ¿Guía de usuario? ¿Guía de desarrollo? Cómo quieres que compile tu proyecto si todo lo tengo que averiguar. Si algunos se empleasen herramientas de construcción conocidas todo resultaría un poco más sencillo y además incluiría a su perfil una herramienta que quizás se valore positivamente en un entrevista de trabajo.
  5. Originalidad. ¿Antes de comenzar el proyecto has analizado soluciones similares? Si las hay y decides poner en marcha otra, justifica muy bien qué aportarás frente a las otras.

Los proyectos que tienen un tutor implicado, se nota. Quizás sea precipitado, pero os invito a reflexionar sobre la implicación y dedicación del profesorado en la asignatura del proyecto fin de carrera. Lo curioso es que en el 2009 ya escribí unas notas sobre la evaluación, y veo que pocas cosas han cambiado. Creo que el concurso debe parar y coger aire.

Leave a Reply

Your email address will not be published. Required fields are marked *