Dificultades encontradas al crear comunidades de software libre en el sector público Hoy en día, es un hito muy importante que haya Administraciones Públicas españolas liberando software y, aún más, creando y liderando comunidades en torno a ellas. A nivel internacional hay pocas experiencias parecidas a la que tenemos en nuestro país y es el […]
Dificultades encontradas al crear comunidades de software libre en el sector público
Hoy en día, es un hito muy importante que haya Administraciones Públicas españolas liberando software y, aún más, creando y liderando comunidades en torno a ellas. A nivel internacional hay pocas experiencias parecidas a la que tenemos en nuestro país y es el motivo por el que cada vez más entes de otros países nos solicitan asesoramiento (¿Marca España?). Definitivamente no es un camino sencillo; y es diferente a la creación de comunidades open source tradicionales.
Un poco de historia
Los concepto open source y software libre no son nada nuevo; pero tampoco son conceptos demasiado antiguos, al igual que la mayor parte de las áreas en las TIC (comparándola con otras disciplinas). Las experiencias relevantes en España en cuanto a software libre anteriores a una década se ubican principalmente fuera del ámbito de la industria y la Administración Pública; en comunidades de desarrolladores. Estos colectivos son (somos) los que desde hace años y basándonos en esa experiencia han solicitado de forma reiterada a la Administración Pública el uso de software libre en lugar de software privativo por motivos de coste, seguridad, apertura, etcétera.
No hace demasiados años, esas peticiones fueron calando de forma generalizada (Extremadura pionera en ello con la creación de LinEx) y paulatinamente se fueron sucediendo los casos de creación y adopción de distintos sabores de Linux: LinKat, Molinux, Guadalinex… cada una incorporando software propio de cada administración. Con planes de actualización como Abalar. Comenzaron a crearse entonces tímidamente productos libres como gvSIG.
Si bien esto fue un hito hace una década, lo cierto es que el uso y migración de software libre como sistema operativo, en la ofimática y en el puesto de trabajo en general o en el sector educativo, es ya prácticamente una realidad en todo el mundo, en mayor o menor medida; con casos de mayor o menor re levancia en algunos momentos. Con la creación de CENATIC, nos propusimos ir más allá e implicar a las Administraciones Públicas en la creación de comunidades. Comunidades que fueran sostenibles, que permitiesen poner en valor las ingentes cantidades de software desarrollado por entes públicos con fondos públicos, que beneficien a empresas, a instituciones de investigación, a la propia Administración; que posibilitaran ahorrar costes, generar empleo, generar tejido empresarial real, que permitiesen la participación de empresas pequeñas y autónomos en el juego… y no sólo TIC, sino empresas de formación, bufetes de abogados, editoriales… ¡Menuda tarea!
Pues bien, varios años después, habiendo superado algunas dificultades, tenemos comunidades de desarrollo de software público, en la Administración Pública, en España, con la participación de agentes públicos, privados y universidades. Ha habido que inspeccionar todas y cada unas de las experiencias parecidas en el ámbito internacional, realizar cientos de informes y análisis, equivocarse cientos de veces, mejorar los modelos, contrastar opiniones con cualquier persona del mundo que pudiese saber algo. Al principio de oyentes, posteriormente de aprendices y actualmente, de expertos. Formándonos en los entresijos del sector público, en leyes, en gestión del cambio, en técnicas de negociación, en modelos económicos y un sinfín de cosas más. Pero ahí están… las comunidades; nuestras «criaturas» (así las sentimos). Poco importan las horas dedicadas, en horario laboral y no laboral, en vacaciones o fuera de ellas, sabados y domingos. Se pueden hacer muchas más cosas, por supuesto, pero si a muchos de nosotros nos dicen hace 7-8 años que se iba a lograr que la Administración Pública liberase en comunidad el software público para beneficio de todos y que iban a participar en dichas comunidades, no hubiésemos dado crédito.
Las dificultades encontradas
Fruto de años de equivocaciones, hoy aprovecho este artículo para expresar las lecciones aprendidas, identificando los problemas más usuales que nos hemos encontrado y para los que hemos tenido que crear estrategias que están dado buenos resultados.
El contexto en el que se crean las comunidades de software libre público no tiene nada que ver con el propio desarrollo informático del producto en sí; o al menos no es lo más significativo. Nos encontramos generalmente con un producto enorme, ya finalizado, en muchas ocasiones con varias versiones, que han sido contratadas (que no desarrolladas) por un ente público a una empresa (generalmente enorme); que se encuentra en una situación difícil de mantener económicamente y donde nadie, salvo la empresa que lo creó tiene el conocimiento necesario para su actualización; donde las empresas pequeñas (el 99,88% en 2013) no tienen cabida por no poder dedicar recursos suficientes para entender la plataforma. Con un estado legal que en muchas ocasiones por desconocimiento, se ha obviado. Con una Administración Pública perpleja ante un modo de trabajo que se escapa de los procedimientos públicos habituales. Sujetos a leyes de la competencia, de la propiedad intelectual, de contratación pública… y se quiere poner el producto en comunidad. Sintetizando, se podrían clasificar los problemas que habitualmente aparecerán en este proceso de la siguiente forma:
Problemas técnicos
Son muchos y variados. En general, las personas que estamos acostumbradas al software libre o al open source, sabemos que la calidad del código aumenta cuando aumenta el número de ojos que pueden posarse sobre él. Hemos encontrado en ocasiones que las grandes plataformas desarrolladas por empresas para la Administración Pública, suelen acumular toda una serie de errores de programación, de documentación, de duplicidad de código, de optimización… suelen incluir versiones desfasadas de librerías porque el alcance de las sucesivas actualizaciones de las plataformas contemplaban sólo desarrollos evolutivos y no actualizaciones de lo existente, errores que se han ido propagando de una a otra versión por haber sido adjudicada cada una a una empresa distinta o a la misma empresa pero con equipo de trabajo distinto, que no tenían un conocimiento completo de lo que había previamente.
No hay que rasgarse las vestiduras por ello. Es lo habitual cuando la disponibilidad presupuestaria es año a año y es difícil planificar a medio plazo la evolución de los productos. Este tipo de problemas son normalmente los menos graves, pero que restan más tiempo para la creación de la comunidad. La barrera de entrada cuando el código no tiene calidad o no se entiende bien, es alta.
Problemas legales
Surgen de todo tipo. Proveedores que han incluido código libre de terceros en el producto desarrollado para la Administración Pública; cesiones de derechos incorrectamente realizadas o directamente obviadas; incorrecciones en los pliegos de condiciones de los concursos públicos, que impiden la liberación del código; el concepto de «activo» para los departamentos financieros de las Administraciones Públicas, cesiones de derechos sin tener la titularidad de los mismos; combinación de licencias libres con licencias no libres; incompatibilidad de licencias libres entre si en los componentes de la aplicación; subcontrataciones de las subcontrataciones, que dificultan saber a quién pertenece el código; aportación de código fuente resultante de proyectos de investigación, sujetos a una legislación particular; o código de universidades, cuya propiedad intelectual dista mucho de ser sencilla de dilucidar.
Un alto porcentaje de los análisis jurídicos preliminares realizados por CENATIC han resultado desfavorables y han requerido correciones legales de todo tipo por no estar familiarizados con los conceptos requeridos en el software libre. Y es algo necesario como paso previo a la creación de una comunidad. Y es grave pues puede traer consecuencias jurídicas si no se hace bien. No se puede liberar un código que no cumple los requisitos legales para ello.
Problemas procedimentales
Los procedimientos seguidos en la Administración Pública no son los más óptimos para la generación de comunidades de software líbre público: para decidir, para contar con presupuesto, para contratar, para bonificar o premiar contribuciones, para que una persona de la Administración Pública pueda dedicar horas de su trabajo a una comunidad.. en general son poco flexibles y poco ágiles para un entorno, como lo son las comundiades, que se mueve muy rápido. Hay razones por las cuales las Administraciones Públicas tienen estos mecanismos y no es otra que el control; gestionan los fondos públicos, de todos. Aunque se podrían aligerar los procesos, lo cierto es que siempre habrá una distancia entre lo deseable y lo que debe ser para seguridad de todos.
Pero lo cierto es que estos problemas surgen siempre. Y surgen en el peor momento; al iniciar la comunidad, cuando aún no hay una comunidad nutrida y hay que incentivar la creación de la misma de una forma dirigida desde la propia Administración Pública, como promotora de la comunidad en creación. Todo se ralentiza y los primeros miembros de las comunidades desesperan ante lo que parece un «inmovilismo» que no es más que el proceso habitual que lleva todo en las Administraciones.
Problemas económicos y de negocio
Algo que hemos aprendido en CENATIC es que todo el mundo quiere algo en las comunidades. Desde la diversión o la autosatisfacción personal (altruismo), hasta dinero. Todo es lícito siempre que las reglas del juego sean conocidas por todos y los intereses de unos no vayan en detrimento de los de otros. Los principales problemas económicos y de negocio que surgen en la creación de comunidades públicas son la falta de presupuesto tras la creación de la comunidad, en el momento de despegue, las aparentes (pero no reales) pérdidas que la participación en la comunidad por parte de los participantes, en cuanto al esfuerzo invertido, y la posibilidad de errores en el diseño de la comunidad al no haber analizado correctamente los posibles miembros y sus necesidades. Esto último hace que dichos miembros no encuentren su nicho de negocio en la comunidad y es un problema.
También es muy habitual y muy difícil de cambiar el hecho de que las Administraciones Públicas piensen que liberar un software en comunidad hará que no tengan que invertir presupuesto en ella. Eso dificulta la obtención de presupuesto destinado al diseño y arranque de la comunidad.
Sin el presupuesto adecuado, bien distribuido entre los participantes (no sólo en cash , sino también en especie y esfuerzo) y sin que la parcela de negocio para cada miembro esté correctamente equilibrada, no hay comunidad. Simplemente no existe interés en la misma.
Problemas de conocimiento
Son muy usuales, costosos de solucionar tanto en tiempo como en presupuesto y, en algunos casos, imposibles de solventar. Generan gran cantidad de problemas de los otros tipos de esta clasificación. En general, nadie sabe cómo debe funcionar una comunidad de software libre de la Administración Pública. Como he comentado en la introducción, en cenatic CENATIC hemos analizado prácticamente todas las experiencias a nivel internacional y nacional y mantenemos contacto habitual con sus artífices. Aún así no hay demasiadas experiencias y su reproducibilidad es escasa; aunque trabajamos a diario para identificar aquellos aspectos comunes en la mayor parte de comunidades, éstas son muy heterogéneas.
En general, las Administraciones Públicas no tienen conocimientos sobre el modo de trabajo en comunidad, por los problemas procedimentales que he comentado. Las empresas grandes tienen el mismo problema porque están habituadas a trabajar para las Administraciones Pública y por tanto tienen sus procesos productivos sincronizados con éstas. Las pequeñas empresas tienen más claro el trabajo en comunidad, pero no saben el modo de llevarlo a cabo dentro de una comunidad pública donde hay administraciones y empresas de calibre. Las personas a título individual que suelen trabajar en comunidades de software libre tradicionales no están demasiado acostumbradas a unas comunidades regidas por unas normas un poco menos flexibles y los usuarios finales, muchos de ellos clientes, se sienten desconcertados al no entender el modelo de soporte/ayuda en comunidad y en general, con lo cual, como paso previo al lanzamiento de una comunidad, hay que formar e informar a todos estos agentes en el modo de trabajo una y otra vez, hasta que lo asimilan. Persona a persona. Pero en muchas ocasiones, el tiempo y el presupuesto que esto conlleva es excesivo y sin una correcta planificación, el conocimiento llega cuando la comunidad se ha extinguido. En unos casos el desconocimiento genera rechazo, en otras desconfianza y en otras miedo. Hemos encontrado casos donde el pánico a lo desconocido ha paralizado la creación de alguna comunidad y sólo hasta que esos miedos han sido superados, ésta no ha podido arrancar (mi reconocimiento y agradecimiento personal desde estas líneas a la valentía de las pioneras en este proceso).
Otro problema es la transferencia de conocimiento sobre el producto. Son productos enormes, complejos, habitualmente desfasados tecnológicamente, con código elaborado prácticamente por una sola empresa que, en algunas ocasiones ha desaparecido y en otras es reacia a desprenderse de ese conocimiento en exclusiva ya que es uno de los activos para obtener otros negocios (aquí, tengo que decir, que genera más negocios liberar ese conocimiento). Sin ese conocimiento sobre el producto, la barrera de entrada a la comunidad es inmensa para cualquiera, por lo que hay que afrontar este problema cuanto antes para que la comunidad pueda comenzar a crecer.
Problemas de coordinación
Con la comunidad en marcha, compuesta por muchos y diversos miembros de todos los tipos, comienzan los problemas de comunicación: para tener reuniones periódicas, para que los órganos de gobierno de la comunidad hablen y discutan, para que empresas y clientes se encuentren, para que cualquier necesidad que pueda surgir en cuanto a la comunicación entre miembros, esté cubierta. Hay que tener en cuenta que las comunidades son deslocalizadas; en CENATIC contamos con más de 800 miembros en la comunidad, no sólo de toda la geografía nacional, sino incluso de otros países. Por tanto, hay que prever dichas necesidades de coordinación y proporcionar mecanismos que las cubran. Los problemas habituales suelen ser la realización de conferencias múltiples, la firma de documentos entre distintos miembros, la imposibilidad de realizar reuniones por no haber quorum suficiente y tener que intentarlo una y otra vez o la selección de momentos/lugares apropiados para tener reuniones presenciales entre los distintos miembros. No son problemas muy graves y suelen tener fácil solución, aunque suelen ser molestos y a veces desesperantes.
Problemas de influencia
Son peligrosos, ocurren menudo al inicio durante el primer año de vida de la comunidad y son difíciles de sortear. Pueden dar al traste con la comunidad. Siempre hay miembros de la comunidad que tienen la capacidad de acudir a «atajos» para conseguir por la vía rápida, en la comunidad, lo que no consiguen por su propia participación. Empresas poderosas, otras entidades públicas participantes distintas a las que promueven la comunidad o la propia entidad pública que promueve la comunidad, buscando un control sobre el proyecto que, tenía, pero que al estar en comunidad ya no le corresponde tener. Este tipo de problemas suele darse habitualmente como consecuencia de un problema de conocimiento, como se ha explicado un par de puntos más arriba. La falta de conocimiento sobre el trabajo en comunidad, principalmente, o la falta de conocimiento sobre las reglas y procedimientos de participación que se hayan definido para la comunidad en cuestión.
Problemas de dedicación
Es básico. La comunidad crece pero las plataformas liberadas por la Administración Pública requieren un esfuerzo importante que, si no tiene recompensas (recompensa no siempre es dinero), pueden no compensar la dedicación de una persona en ella. Existen todo tipo de soluciones en el mundo en las experiencias analizadas por CENATIC para facilitar la participación propiciando que la dedicación pueda ser menor (mayor productividad); aunque las soluciones son completamente heterogéneas, no repetibles y dependientes del contexto de cada comunidad. Son problemas a resolver en poco tiempo, porque pueden hacer que la ilusión y participación en la comunidad decrezca al requerir demasiado esfuerzo.
Problemas políticos o corporativos
Suelen ser problemas derivados de un problema de influencia. Este tipo de problemas provocará la extinción de la comunidad si aparecen en las primeras fases de la misma (siempre queda la posibilidad de un fork; el código es libre). Suelen ser cambios de estrategia política o corporativa empresarial que impliquen la prohibición a algunos de los miembros principales la participación en la comunidad: reestructuraciones departamentales que impidan a un miembro participar por ser necesario en otra parte de su organización, cambios políticos que desaconsejen la participación de un determinado ente público en la comunidad (elecciones cercanas, giro en la política a alto nivel…). Si los miembros afectados por estos problemas políticos, son el núcleo de la comunidad (cosa que ocurre siempre cuando la comunidad está en crecimiento), la comunidad tendrá pocas posibilidades so subsistir. No son, afortunadamente, problemas muy comunes.
Problemas de miedo escénico
Los problemas de miedos escénico son bastante habituales en las comunidades de software libre de la Administración Pública. Se da sobre todo en aquellas comunidades que tienen una gran cantidad de empresas involucradas. Todas quieren y pueden colaborar. Unas no colaboran por miedo a quedar mal delante de otras empresas con mayor conocimiento en la comunidad y que eso les lleve a perder imagen de cara a potenciales clientes. Otras, no colaboran por miedo a que su conocimiento sea utilizado por otras empresas, de la competencia pero participantes en la comunidad. Otras, tienen miedo a hacerlo mal, por su reducido tamaño. Esta situación genera el «efecto periferia». Todos los miembros de la comunidad intercambian conocimiento entre si, pero no en una relación todos a todos, sino por grupos reducidos. Se basan en la pertenencia a la comunidad para realizar contactos entre sí pero mantienen su colaboración en el límite externo de la comunidad justo el límite que separa las conversaciones semi-privadas de las conversaciones puramente públicas deseables en la comunidad. Hay actividad, pero no se ve ni se obtiene el máximo potencial de la misma.
Son problemas relativamente comunes y que hay que evitar a toda costa. Si el problema se estabiliza, será muy difícil atraer a los miembros de la comunidad a la participación en el corazón de la misma. Y puede llegar incluso a percibirse como la situación «habitual» y normal.
Hoy, 6 de Septiembre de 2013
Desde CENATIC hemos realizado decenas de análisis de plataformas para diversas Administraciones Públicas. Hemos creado comunidades de algunas y otras están en proceso de ser creadas. Con el paso del tiempo y con la práctica habitual por parte de estas Administraciones de consultarnos de forma anticipada a la contratación de un desarrollo, todos los problemas anteriores se van suavizando poco a poco. Por varios motivos: tenemos cada vez más conocimiento sobre cómo se debe hacer el proceso de creación de una comunidad de software libre público y las propias administraciones y empresas van asimilando los conceptos necesarios con cada comunidad creada. La siguiente cuesta algo menos que la anterior.
Decenas de empresas se benefician hoy en día de esos productos puestos en comunidad, los usuarios finales se benefician al poder contar con más empresas para que les den soporte o le desarrollen productos. Empresas de formación hacen negocio formando en los productos liberados y esa formación sirve a empresas para exportar las plataformas al extranjero. A la vez, los productos evolucionan y se enriquecen. Todos ganamos.
El mérito… de todos. Universidades, grandes empresas, pymes, autónomos y emprendedores, administraciones públicas y público en general. Desde CENATIC, orgullosos de transferir día a día este conocimiento y hacer que este modelo funcione y de haber hecho posible lo que parecía inalcanzable.
¿Compensa?
No es sencillo, no. Y en muchas ocasiones no es agradable. Pero no se me ocurre en este momento mejor forma de sacar partido a activos ya desarrollados (que ya han sido pagados) por la Administración Pública. No se me ocurre otro modelo que permita mejor que tantos y tan diversos actores se beneficien de esa comunidad. No es sencillo, no. Pero no se me ocurre una forma en que empresas y administraciones cooperen con beneficio para ambos. No se me ocurre mejor forma de crear alianzas entre empresas. Y entre usuarios. De todos los colores políticos y localizaciones. No se me ocurre mejor forma de destacar lo que nos une y no lo que nos separa. No se me ocurre mejor forma para que las Administraciones Públicas estén en contacto con la realidad, con los usuarios, con las universidades, con las empresas, grandes o pequeñas. Es un ejercicio de responsabilidad personal.
Pero no es sencillo… nunca.
Manuel Domínguez-Dorado es experto en creación de comunidades de software público y CPMO de CENATIC
@manolodd