En serio, si habéis venido a una charla titulada “Actividades de la OSL de la UGR” tenéis mucho mérito. Merecéis un aplauso, o los créditos que vayáis a pedir, o lo que os den. Vamos a intentar, de todas formas, que no sea tan aburrido como parece a priori.
Por otro lado, también me parece irónico que me llamen a Cádiz, precisamente, que fueron unos de los pioneros, a que les cuente mis movidas... se van a dar cuenta que la mayoría de lo que hago es copy/paste de lo que hacen ellos, pero bueno, hay que arriesgarse.
Aunque se puede aprender mucho viendo a los demás. Hay un planet con todos los blogs de las OSLs de toda España, y por supuesto seguir a los pioneros, como la OSLUCA, pero en principio no hay algoritmos para montar oficinas.
Tampoco es que te ayuden desde la universidad. No hay tampoco un kit de iniciación del cargo universitario. Se aprende a palos.
Así que vamos a tratar de hacer en esta charla esa HowTo, cómo desarrollar una serie de habilidades que, eventualmente, resulten en la adopción y producción de SL por parte de la universidad.
Veamos las fases por la que pasa la adopción de software libre por parte de una organización
Tomado de aquí:
http://www.opencrowd.com/views/opensource.php
La creación de una OSL se sitúa precisamente en la fase de racionalización. Se establece una oficina que formalice y facilite la adopción de software libre dentro de una organización
Para ello, evidentemente, las otras dos fases son imprescindibles. En especial, si alguien no hubiera presionado a los candidatos a rector para la creación de una oficina, no habría habido manera.
El problema es que estamos a la mitad del camino. Tenemos que entrar en la fase de extender, y eventualmente llegar a la “norma”, y desaparición final de la oficina.
El problema es que, una vez establecida la oficina, ¿qué diablos es lo que hay que hacer?
Hasta el punto que estamos intentando desarrollar (con poco éxito) un programa para gestionar los saraos. Se llama, por supuesto, ASaraos.
La principal labor es la de agitación y propaganda, efectivamente. Lo principal es hacer llegar el mensaje a la gente, hacerla saber de la existencia del software libre, de la oficina, y de las aplicaciones libres. ¿Pero cómo lo hacemos?
Tienes que llegar a lo que la gente use. Las listas de correo están bastante generalizadas, pero lo cierto es que mucha gente pasa de ellas. Depende del colectivo, claro.
En el correo influye absolutamente todo. Cuándo lo mandas, qué título envías. Lo curioso es que averiguar qué título poner también te ilumina sobre cuál es el camino para la adopción de software libre dentro de la organización en la que estés.
Nada garantiza el éxito de una convocatoria
Vivimos en un mundo 2.0, y hay que estar atentos a todo: Twitter, Facebook, Tuenti... el problema es que nadie se va a hacer amigo de una oficina, porque las oficinas no son muy amistosas. Hay que hacerlo a través de las personas. Conviene buscar voluntarios, o hacerlo tú mismo, si ya tienes suficientes foyowers
No te olvides tampoco de que vives en comunidad: echa una mano a las otras oficinas de software libre, y a los eventos de software libre que sucedan en tu entorno
La oficina no es una torre de marfil, hay que ensuciarse las manos: conocer dónde se habla de SL, listas de correo, foros de facultades, foros de PAS delegaciones de alumnos... hay que estar ahí, echando una mano cuando haga falta.
El blog es imprescindible, pero más de cara al resto del mundo que a la propia comunidad. Incrementa la visibilidad de la Oficina, y por eso debe usarse no sólo como tablón de anuncios, sino también como un periódico (es decir, periódico) con anuncios relacionados con el SL, pequeños trucos, visibilización del software libre creado en comunidad, y, en general, como un blog personal de la gente que trabaje en la OSL.
Conviene, además, dejarlo abierto a la comunidad. Si alguien quiere postear, que lo haga.
También se debe contestar a las dudas, estar siempre atento, aprobar los comentarios... un blog está vivo, y hay que estar ahí todo el tiempo.
En la UGR hemos logrado varias portadas en Menéame, salido en Barrapunto, y tenemos 1500 visitas al día; la mayoría son en recursos que no van dirigidos exclusivamente a la comunidad universitaria: página sobre la fuente Ibarra, taller de virtualización
Una herramienta esencial de la agitación y propaganda es colocar carteles. En las encuestas que hemos hecho, una de las principales vías para saber qué se ha hecho es la cartelería.
Si es en tu propia facultad, es fácil, pero tienes que contar con delegaciones de alumnos y voluntarios que coloquen carteles en otros sitios. Recuerda que la OSL no es para Informática (aunque sea, principalmente, de informática), sino que es para todo el mundo.
No hace falta que diga que la cartelería tiene que ser llamativa, clara y dar una pista de qué va el tema. Si das un taller de OpenLaszlo igual se cree la gente que vas a vender un abrelatas, o si es de Django, igual piensa que es un método para aprender a tocar la guitarra. Ten en cuenta lo de antes: ¿A mi qué me importa? Siempre es lo esencial.
Lo cierto es que, hagas lo que hagas, hay un riesgo importante de que aparezcan sólo cuatro gatos en la charla. Lo que no sólo da mala impresión, es que hace perder el tiempo a la persona que se lo ha preparado con todo trabajo y cariño.
Es peor todavía si aparecen sólo cuatro gatos, y además siempre son los mismos.
Por eso, hay que tener cierto cuidado, y filtrar los eventos, teniendo cierto cuidado con ellos.
Lo importante no es tanto qué hacer, sino a qué llegar. No se puede dar lo mismo para los mismos: hay que buscar la novedad, y tocar las diferentes comunidades.
La universidad son muchas comunidades diferentes con intereses diversos y muchas veces contrapuestos. Hay que vigilar que las peticiones se hagan a un nivel determinado, sobre todo mirando a que se pueda garantizar un mínimo de asistencia.
Prestar siempre atención a los conductos oficiales, y confirmar cualquier petición individual que se haga.
En el mundo del software libre hay múltiples jugadores, y hay que prestar atención a todos ellos. Es más posible que tú los necesites a ellos, que el que ellos te necesiten a ti. Y esa red está formada por
Tenerlo en cuenta para no contraprogramar, tratar de cubrir campos que no se cubran, estar atentos a iniciativas que puedan afectar o beneficiar al SL, coordinar en lo posible las políticas de difusión con ellos, potenciar sus políticas en caso necesario, etc.
Máxima a aplicar: entre bomberos, no nos pisemos la manguera.
Pero siempre es cierto que hay gente que va totalmente a su bola.
Si al principio dela creación de la oficina te dan un teléfono y te sientas al lado esperando que te llamen para algo, estarías como en el cómic, con una telaraña entre tú, el teléfono y tux.
Al principio, hay que ser proactivo. Luego se va siendo paulatinamente cada vez más reactivo, porque te piden cosas, te consultan, y recibes llamadas de ¿Es ahí la oficina de software libre?
Buscar los temas que puedan ser interesantes, y proponer temas nuevos. Si hay quien pueda dar un tema, buscar la audiencia, si hay audiencia, buscar quien pueda dar un tema. Tratar de agrupar por temas similares, no saturar.
La proactividad te permite también organizarte mejor los recursos y el trabajo.
Ya sabéis como sigue... lo cierto es que es difícil lanzar iniciativas que interesen a los tres. Por lo pronto, de los saraos organizados, digamos que hay un 79% de estudiantes, 10% de posgrado y PAS, y el resto profesores. Sí, es uno de cada 100. Lo que es, hasta cierto punto, un fracaso.
Y mucho menos los argumentos habituales. Le importa hacer una tarea fácil y económicamente.
Como oiga otra vez el argumento del coche con el capó soldado, me paso a Windows 7. A mi, personalmente, como esté el coche me importa un comino. Valoro el hecho de que pueda llevarlo a diferentes talleres, no sólo al concesionario, pero tampoco es que me importe demasiado. A la gente le importa un bledo que si encuentras un error en OO puedas mandarle un parche para corregirlo. No quiere errores, y punto, aunque sean gratis (porque, de hecho, la alternativa propietaria también es gratis).
Del año anterior a este comenzamos a anunciar los talleres hablando de para qué sirve lo que explicamos. Nada de “Taller de Perl o de Gimp”. ¿Para qué sirve Perl o Gimp? ¿Qué hace mejor que otra alternativa? La asistencia se ha multiplicado por dos. Eso significa que de tener 5 personas hemos pasado a tener 10, pero ya es un logro.
Lo más curioso es que pasando encuestas, muchos de los que asisten a los talleres no conocen la OSL. Lo que me parece muy bien, siempre que a la salida del taller sepan instalar Linux o hacer un programa en Perl.
Que tampoco son una garantía de que se te llene. Siempre va a haber gente interesada, sobre todo si es gratis, pero tienes que buscar un tema atractivo. Es más, hasta cierto punto es peligroso porque hace que la gente vaya más interesada en los créditos que en el tema, y no fidelizan (si se siguen haciendo cosas con créditos, vienen, si no, pues no). Hay que buscar formatos atractivos para los eventos, como los siguientes
Un hackathon es un maratón de programación, asociado a un tema determinado, como por ejemplo el concurso universitario, o un lenguaje de programación, o un grupo de proyectos determinado. Se trata de movilizar a la comunidad que le guste programar para que eche una mano.
Hace poco hicimos el primero, asociado al CUSL, y tuvo bastante éxito, donde éxito significa que para ser el primero y con 4 proyectos algunos muy complicados, hubo unas 16 personas que llegaron al final. Por lo menos le dio un empujón grande a los proyectos, y los participantes salieron muy contentos. Por supuesto, también se daban créditos de libre configuración. De hecho, los cuatro proyectos estuvieron esa semana los primeros en la forja RedIris.
Y en cuanto al NoEsBarraLibreCamp, es decir, software libre como el sol cuando amanece, no como la barra libre, es un evento que vamos a realizar en junio, siguiendo el formato BarCamp, donde todos los participantes aportan algo (charla, apoyo, una pizza) y donde se da una organización mínima que emerge durante el propio barcamp. Estáis todos invitados, veremos a ver cómo sale.
Aunque algo no lo hayas organizado tú, apóyalo. La oficina del SL en la universidad (y, dentro de tus posibilidades, fuera de ella) debe al menos difundir, apoyar con material docente, con personal si hace falta, todo lo que se haga. Si es un curso de posgrado, un proyecto de innovación docente, lo que sea, hay que apoyarlo. Eso te permitirá coordinar mejor unos con otros (aconsejando a alugien que posponga, o le dé una determinada orientación a algo) y también que el apoyo sea mutuo: que de los eventos relacionados con el SL lleguen al SL en general, y de ahí a otros eventos y a la liberación de software.
Así que no hay que vallar el cortijo, y decir que aquí no se mete nadie, sino abrirse a todo el mundo. Al final, todo el mundo se beneficiará. Por lo mismo, tampoco conviene tocar mucho las narices: si alguien tiene montado un chiringuito enseñando esta o aquella aplicación de SL, déjalo a su aire, aunque pase de tí.
Lo más importante es extender la comunidad de usuarios y desarrolladores de software libre, no contentar a la que hay. Un taller de programación dirigida a Aspectos en Ruby puede interesarle a unos cuantos, y estará muy bien, pero no llegará a mucha gente. Es mejor un taller de “Python para dummies”
Un buen ejemplo que sirve para extender. Los que participan en el concurso universitario son, en su mayoría, gente que hace el proyecto fin de carrera, principalmente, y no ha desarrollado antes SL. Al participar en él atraen a amiguetes,compañeros de clase, director de proyecto... se extiende la comunicdad
También se crea el hábito de participación: este es el segundo año, y si se va participando todos los años, se organizan actos a su alrededor: presentación (jornadas), resolución del concurso (media jornada, al menos)...
En Granada han empezado este año 9 proyectos. Uno se lo llevó el software privativo y quedaron 8. De esos 8, de 4 de ellos no hemos sabido nada (y dos son gente a la que yo le dirijo el PFC), y de los otros dos sabemos que están en Finlandia. Pero los 4 que hay, participaron en el Hackathon y es muy posible que lleguen al final. Sólo 3 pueden tener premio, sin embargo...
El año pasado fue más o menos igual, pero hubo menos proyectos que llegaron al final; en realidad, sólo dos.
Al final, se trata también de que se desarrolle SL. O más bien que se libere el software desarrollado.
Todos los estamentos desarrollan SL: los alumnos (por kilos), el servicio de informática, y PDI (profesores y becarios).
Si uno no quiere liberar, no va a liberar. Si se ve que o ética o legamente lo que se está haciendo no está bien, hay que hacer todo lo posible por que lo haga. Pero incluso así, obligar a alguien a liberar es un contrasentido.
El principal esfuerzo hay que hacerlo en liberar lo que ya está con las fuentes abiertas, o tiene la intención de hacerlo, pero ni está en forja pública ni tiene licencia ni nada. Hay que buscarlos uno por uno, y hacer un seguimiento de en qué fase de la toma de decisión están. Finalmente, ayudarlos a escribir una nota de prensa comentando la liberación y su trascendencia.
Así hemos conseguido liberar media docena de cosas que andaban por ahí, y que no se habrían conseguido de otra forma. Algo es algo.
Frase típica: Vamos a organizar un curso o sarao de SL, o liberar este software. ¿Cuánto nos pagas?
La OSL no puede funcionar sin dinero, pero hay que tener mucho cuidado con él. Si se paga por algo (liberar software, dar clase, organizar un evento) corres el riesgo de que sólo se haga eso si se paga. Por ejemplo, si organizas premios para las aplicaciones liberadas una vez al año, no se liberan aplicaciones nada más que para el concurso, y luego se abandonan. El mensaje es que la creación de software libre es parte de la labor universitaria. Hay que hacerle llegar a la gente que si tienen la voluntad de liberar, se hará todo lo posible por ayudarles... salvo darles dinero.
Lo mismo ocurre con los cursos. Si organizas talleres y le pagas a los que lo dan, no vas a tener más gente que quiera darlos, pero sí te vas a encontrar con que muchos no quieren darlos si no se les paga.
Puede parecer raro que se hable de esto, pero muchas unidades de la universidad se autofinancian: enseñanzas virtuales, por ejemplo... la autofinanciación es una manera de no tener que pelearse por el presupuesto todos los años, asegurar continuidad de gente que trabaje y políticas, y tener siempre un colchón en caso de problemas.
Nuestra oferta de servicios es variada, pero ahora mismo lo único que nos ha proporcionado ingresos es el curso virtual de liberación de SL y el campus de SL para niños. El resto, todavía está por llegar.
El campus infantil en principio se hizo para los hijos de personal de la UGR, se basó en enseñarles Gimp, OpenOffice, Firefox y Scratch, un lenguaje de programación dirigido a ellos, precisamente. Se cubrió con creces, y en las primeras horas.
Este año posiblemente graduemos a los niños del año pasado y les enseñemos directamente python; además, el curso de Programación se dará con los portátiles de la Junta directamente.
Es complicado en un entorno protegido por la libertad de cátedra hacer políticas oficiales. Se trata de persuadir, no de obligar, dar ejemplo, y mostrar la utilidad del SL para muchas cosas.
Pero la adopción oficial puede venir por muchos sitios: por ejemplo, dejar de pagar licencias. Eso no implica que la OSL se lleve el dinero, pero sí que tiene que participar en la hoja de ruta, apoyar por todos lados, usando muchos menos recursos que los que debería usar.
Sin embargo, hay que echar el resto: apoyo al usuario, formación, material de transición, control de la transición... y esto desde la más pequeña transición (ordenadores de docencia con Ubuntu) hasta la mayor (dejar de pagar la licencia de Office).
Puede haber una política oficial de uso de formatos abiertos o de SL, resoluciones de departamento, lo que quieras que incluso así va a haber gente a la que no le dé la gana usar OO o R en vez de SPSS. Al menos, si así ocurre, que tengan que darte una repuesta oficial: hay que ofrecerle todas las opciones posibles para que lo hagan. También un punto de contacto claro a quien quiera chivarse de este tipo de cosas. Que está muy feo ser un chivato acusica, pero también obligar a alguien a usar un programa que no el apetece usar.
Una OSL debe ejercer de mosca o pingüino cojonero (que debe de molestar más, porque es más grande) siempre que pueda. Pero debe tocar las narices de forma eficaz, y siempre sabiendo retirarse cuando ya no haya nada que hacer.
Por otro lado, hay muchos callos por todos sitios, y algunos son muy grandes, así que tu mensaje va a llegar más eficazmente si haces las cosas muy diplomáticamente, respetando a todo el mundo, y haciendo siempre caso a los de arriba y a los de abajo (y a los de los lados, si los hubiere)
