¿por qué es mala idea obligar al estado ecuatoriano comprar software libre?
El artículo 136 del Código Ingenios crea más problemas que pretende resolver.
En su artículo 136 del Código Ingenios, legislación creada con el declarado fin de generar más innovación en industrias de conocimiento en Ecuador, se estipula la compra obligatoria y exclusiva de software libre por entidades del estado.
La idea de limitar toda compra de software exclusivamente a software libre es mala. Ningún país de la región, salvo Venezuela, impone tantas restricciones sobre la compra de software por razones obvias: en un organismo tan complejo y diverso en necesidades de software como el estado, limitarnos al uso de software libre simplemente no es práctico, y terminará haciendo más daño que bien. En lo que sigue explicaré por qué.
Para evitar entrar en un debate prolongado sobre los méritos de software libre comparado con software propietario, me limito a explicar que, en su esencia, con software libre (SL) el código fuente, o la receta de software, es abierto: es decir cualquier persona puede acceder al código fuente (la receta de software), copiarlo, auditarlo, crear su propia versión, y usarlo básicamente sin restricción. Con Software Propietario (SP), el código fuente no es accesible: es propiedad de su autor.
Hay diferencias entre software libre y código abierto, y también hay muchos tipos de licencias. Para algunos software libre es una ideología, una manera de ver el mundo. Para otros, es una manera colaborativa de desarrollar software. La guerra entre los dos se dio y se terminó en los años 90, porque pueden coexist fácilmente. Revivir esos debates supera el objetivo de este artículo cuyo fin es discutir la obligatoriedad del uso de SL en el sector público.
Y para ser claros sobre la propuesta del Código Ingenios, el artículo 136 en su forma actual dice así:
Artículo 136.- Obligatoriedad de uso de software libre y estándares abiertos.- El sector público y las instituciones del Sistema Nacional de Educación y del Sistema de Educación Superior en todos sus niveles de formación, deberán usar obligatoria y exclusivamente software libre y estándares abiertos.
En el caso de que no sea pertinente el uso de dicho software libre o estándares abiertos, o ambos, las entidades públicas obligadas en este artículo, deberán solicitar motivadamente y conforme el reglamento expedido para el efecto, la autorización de adquisición de otro tipo de software.
Las instituciones privadas del Sistema Nacional de Educación y del Sistema de Educación Superior, podrán prescindir del software libre o estándares abiertos, o ambos, en los casos establecidos en el reglamento respectivo.
En cualquier caso, la autorización para adquisición de otro tipo de software impondrá la obligación de migrar o desarrollar software libre, en un plazo razonable definido por la autoridad competente.
Quedará excluida de la autorización prevista en los incisos anteriores, la contratación de actualizaciones de software adquirido previamente a la entrada en vigencia de este Código; y, los sistemas que por razones técnicas o comerciales no puedan ser reemplazados por software libre. Estas adquisiciones serán debidamente motivadas por parte de la autoridad contratante e informado a la entidad rectora del sistema de contratación pública, para su control ex post.
Las instituciones obligadas por esta norma deberán poner a disposición del público bajo estándares de documentación a través del Sistema de Información de Ciencia, Tecnología, Innovación y Saberes Ancestrales, el código fuente del software libre desarrollado o contratado. Se exceptúan de esta disposición el software desarrollado o contratado por instituciones públicas que por razones de seguridad deba mantener reservados el código fuente. La instancia que establezca el Presidente de la República mediante reglamento, autorizará la reserva de dicho código fuente.
La contratación de software como servicio de las entidades obligadas en este artículo, deberá realizarse con proveedores que garanticen que los datos se encuentren localizados en el Ecuador.
Para resumir, si se aprueba el artículo 136, las contrataciones públicas de software se limitarán a SL, y eso cambia la prioridad del sector público en contratar software. El estado contrata software cuando tiene un problema que resolver. Con 136 ya no se prioriza la compra en base a la mejor solución que resuelve el problema, sino se prioriza la compra en base a la manera en qué un software fue producido. Vemos aquí una agenda ideológica: el objetivo de la contratación pública deja de ser, “contratemos el software que mejor servirá a los ecuatorianos”, y se vuelve, “contratemos el servicio que cumpla con nuestra visión ideológica de cómo se debería desarrollar software.” Con 136, imponemos una visión ideológica sobre el proceso de contratación pública.
Por limitar la compra de software propietario, se limita la competencia entre servicios, algo que bajo ninguna lógica ayuda a los ecuatorianos que buscan un buen servicio por parte del aparato estatal, pero para los defensores del 136, la calidad de servicio es menos importante que la pureza de la ideología detrás de la creación del software. Sus argumentos en favor de aquella pureza puedes encontrar aquí.
Este cambio tendrá implicaciones para la industria de software nacional. Por ejemplo, en su defensa del artículo 136, el ex-colaborador de la SENESCYT Andrés Delgado dice, “el Estado está migrando su demanda, no eliminándola. Las empresas están en capacidad de migrar su modelo de negocios, y esa es la tendencia mundial.”
Hay varios problemas con esta frase. Primero, cuando dice, “las empresas están en capacidad de migrar su modelo de negocios,” lo dice como que fuera fácil, sin reconocer las dificultades y riesgos que ya existen en el sector para sobrevivir, sobre todo en este momento en nuestra historia económica.
Hay miles de personas (Según la Superintendencia de Compañías eran 14200 en 2011) en Ecuador dentro de cientos de empresas que se dedican al desarrollo de software. Según Delgado, aquellas empresas simplemente deberían cambiar su modelo de negocio de SP a SL, como si fuera fácil y sin riesgos, no para satisfacer demanda orgánica por parte de los clientes de software al nivel nacional y internacional, sino porque un cliente gigantesco, el gobierno ecuatoriano, cuya influencia en el sector nacional es desproporcionada gracias al papel inflado que juega el estado en la economía, lo dicta.
Tal transición no nace como parte de la tendencia orgánica de la industria de software de querer más SL, sino corresponde a planificación económica centralizada dictada por una ley. Delgado, sin mayor preocupación, nos invita a participar en un experimento económico cuya base teórica es académica y no basada en la experiencia real ecuatoriana de creadores de software: si fuese tanta demanda para SL en Ecuador las empresas migrarían orgánicamente y no habría resistencia, pero no es así. Es posible que el entusiasmo que tiene la comunidad de SL les hace sobrestimar la demanda para SL, y están dispuestos a poner en riesgo miles de empleos reales con la esperanza de que nazcan empresas hipotéticas en el futuro para reemplazarlos. Obligar a cientos de empresas cambiar su modelo de negocio para satisfacer una agenda ideológica estatal es ingenua y peligrosa, demostrando poca sensibilidad por lo difícil que es armar y sostener un negocio de software en Ecuador y competir en un mercado global.
Continuando, el problema con la palabra “migrar” es que no es una migración orgánica, sino forzada, y por ser una migración forzada, genera desplazados y refugiados. Por limitar competencia, el 136 representa un subsidio al sector de software libre, porque les da acceso privilegiado a la contratación pública, sin tener que producir productos superiores a la oferta SP. Actualmente, no hay ningún obstáculo para que una empresa dedicada a SL pueda participar en contrataciones públicas. Repito: no hay ningún obstáculo para que una empresa dedicada a SL pueda participar en contrataciones públicas. Si un producto realizado con software libre es superior a las alternativas de software propietario y lleva mejor precio, puede prosperar. Si un producto de SL representa ahorros para el estado, también puede prosperar. En adición, por tratar de crear demanda falsa al limitar competencia, 136 subestima la capacidad de las empresas de SL: las empresas exitosas nacionales de SL, como Elastix, no lograron su éxito por ser favorecidos en contratación pública, sino porque llegaron al mercado con una oferta superior. Decir que necesitamos limitar competencia para poder prosperar es igual a decir que Independiente del Valle va a prosperar al nivel internacional por no tener que jugar contra equipos de Guayaquil. Es un sinsentido.
Ademas, si eliminamos la competencia con SP, estamos en efecto ofreciendo un subsidio a los productores de SL no porque sus productos sean mejores o porque lleva más mano de obra local, sino porque su ideología se alinea con la ideología de los autores de la ley. El 136 no busca mejor servicio: busca que el sistema de contratación pública sea otro campo en una batalla ideológica en una guerra ya concluida. Si eliminamos competencia, no podemos garantizar mejores precios, ni más mano de obra local, ni mejor servicio. Por reducir competencia, simplemente aseguramos que el software viene con un sello ideológico que complace a los defensores, y los que más prosperen económicamente de nuevas restricciones son los que adhieren a ésta tendencia ideológica.
En adición, la obligatoriedad de la compra de SL atenta contra la eficiencia del aparto estatal por limitar las opciones de software que puede usar el sector público en buscar atender bien a su clientela, los ciudadanos ecuatorianos. Si existen opciones en el mercado que resuelven con eficiencia los problemas que tiene un departamento del estado, nuestra capacidad de aprovechar de la existencia de aquella tecnología depende de si fue hecha como SL o SP. El criterio que más debe dirigir compras públicas es cumplir con los requisitos, pero en el artículo 136 cumplir con requisitos toma un segundo grado de importancia.
Las consecuencias para éste tipo de artículo son graves, y dudo que los autores del artículo hayan pensado en todos los problemas que 136 puede generar.
Si los arquitectos del Ministerio de Obras Públicas quieren usar AUTOCAD para la reconstrucción de la costa, ¡qué pena! tendrán que encontrar una alternativa de SL, sin importar que sea inferior a AUTOCAD. Si los analistas del ministerio de finanzas quieren usar Microsoft Excel para hacer cálculos avanzados, tampoco pueden. Si los programadores de SL del estado quieren compartir su código en GitHub tampoco van a poder:aunque el protocolo GIT es SL, GitHub, el principal depositario de código SL en el mundo, es SP. Como ejemplo personal, una vez hice una consultoría pequeña con una entidad del estado que se financia con la venta de publicidad. Para mejorar su desempeño y mejorar la experiencia del usuario recomendamos varios productos de software, de los cuales ninguno existe como SL. Los escenarios no pensados superan la imaginación de los defensores de 136.
El problema con 136 es conceptual. El artículo trata al software como si fuera medicina. Si existe algo SP de marca, debería de existir el mismo producto genérico pero en SL. La verdad es distinta: si habría un producto equivalente o superior de SL para cada producto SP, aquellos productos tendrían más participación en el mercado y harían competencia. Si los productos de SL son igual de buenos, no necesitan subsidios ni trato especial. Con 136, los productores de SL simplemente evitan el trabajo duro de tener que convencer del mérito de su productos.
Los defensores del artículo 136 dirán que el artículo permite excepciones, pero tener excepciones contradice las palabras “obligatoria y exclusivamente”, poniendo en entredicho la necesidad de decir “obligatoria y exclusivamente.” Si vamos a decir “obligatoria y exclusivamente,” y luego vamos a decir “pero hay excepciones”, ¿por qué tener 136? El proceso de buscar que una contratación pública sea tenga excepciones simplemente agrega nuevos trámites y obstáculos burocráticos que des-acelera el proceso de contratación pública que ya es lenta, ineficiente, y fácilmente manipulada.
También dirán que el decreto presidencial 1014, aprobado en 2008, dice básicamente la misma cosa que el artículo 136. Si no ha habido consecuencias negativas para el sector hasta ahora, ¿por qué creer que 136 causará problemas? La respuesta genera otra pregunta: si después de 8 años pocas entidades del gobierno hayan cambiado a SL (salvo la asamblea, que es un cuerpo político que necesariamente sigue agendas políticas), es porque el 1014 no es práctico, y si no es práctico, no hay necesidad de más legislación. El fracaso del decreto 1014 niega la necesidad del artículo 136.
Tal vez lo más grave del artículo 136 es que limita las instituciones educativas al uso de Software Libre, lo cuál niega a estudiantes la oportunidad de dominar software que será necesario para ejercer su profesión. Cada año la SENESCYT gasta millones en mandar estudiantes al exterior porque se supone que aquellas instituciones educativas son superiores. Pero ninguna universidad que recibe estudiantes con becas de la SENESCYT limita a sus estudiantes al uso de SL porque eso innecesariamente limitaría su experiencia educativa. Otra vez la agenda ideológica supera el bienestar de los usuarios del software, en este caso los estudiantes.
Los que van a beneficiarse del Artículo 136 es el gremio de Software Libre que encuentra en la ley una manera de conseguir favoritismo en contrataciones públicas sin tener que competir con SP. No quiero insinuar que su apoyo al 136 es meramente económico: he gastado horas debatiendo con miembros de la comunidad SL en Twitter (btw, Twitter es SP, pero no les importa), y veo que son convencidos que 136 está alineado con su visión ideológica y creen que buscan el bienestar común. No obstante, tampoco debemos ignorar que un sector de software se verá inmensamente beneficiado por una decisión que obviamente les favorece. No son actores neutrales.
Si la rigidez del artículo 136 fuese una buena idea, habrían modelos que seguir o países líderes en innovación que habrían adoptado modelos parecidos, pero los ejemplos son pocos. O somos pioneros y vamos a liderar el mundo en un movimiento nuevo, o somos profundamente equivocados. Delgado nota que el país vasco ha tenido éxito en desarrollar una cultura de SL y con ella nacieron varias empresas rentables. Lo que Delgado falla en reconocer es que el movimiento orgánico de SL en España no se debe a una imposición del gobierno, sino la convicción y compromiso de una comunidad de programadores. Tampoco reconoce que los programadores en España tienen el gran lujo de poder vender en todos los países de la unión europea, una escala y oportunidad económica que no nos corresponde a la industria ecuatoriana. Los movimientos sociales que se sostienen en el tiempo no nacen de leyes; nacen de comunidades orgánicas comprometidas y convencidas. Es difícil imaginar cómo vamos a crear un movimiento de SL con leyes y palos y no con comunidades y zanahorias.
Y aquí llegamos a la contradicción final del artículo 136 que los militantes locales no quieren reconocer. El movimiento de software libre depende de inteligencia colectiva y consenso. Es un movimiento profundamente democrático, que detesta la imposiciones de autoridades centrales. Bitcoin, unos de los proyectos de SL más grande en el mundo, está estancado y dividido justamente porque la comunidad que lo apoya no puede llegar a una decisión clave sobre cómo avanzar con el desarrollo de la plataforma. Mientras la toma de decisiones en colectivo es el corazón del movimiento SL en el mundo, en Ecuador la comunidad de SL quiere imponer su voluntad a través de una autoridad central, el estado. Me rompe la cabeza entender cómo un movimiento tan democrático en espíritu justifica el uso de una autoridad central para lograr sus objetivos. Como dice el emprendedor y programador Fernando Rivera,
“No creo que a Richard Stallman, ideólogo del software libre, se le haya cruzado por su mente que su filosofía se implementaría algún día a través de una ley draconiana en una “Banana Republic” que, no solo que no hace nada por promover la libertad del individuo, sino que ata de manos al estado ecuatoriano de por vida (hasta que alguien cambie la ley) a una única forma de comprar y consumir “software” en un mundo que innova constantemente.”
Al final, 136 contradice el propósito declarado del Código Ingenios: en lugar de promocionar un mercado nacional de software, limita la compra y venta de software nacional por favorecer un modelo de creación sobre productos hechos aquí. En lugar de crear un mercado más grande para el software, 136 reduce las oportunidades para las empresas nacionales que no hacen SL. Aunque los militantes más convencidos lo nieguen, para la mayoría del mundo SP y SL son dos piernas de un mismo cuerpo. Los dos benefician de su éxito mutuo, porque la fomentación de un ecosistema vibrante de software no se da gracias a la imposición de limitaciones sino gracias a la creación de incentivos. Crear limitaciones es el opuesto a crear incentivos. Por algo Silicon Valley es la fuente principal de SP y SL: mientras los ideólogos insisten en su diferencia, en la zona más innovadora del mundo hay empresas de SP que dependen de SL y hay empresas de SL que también dependen de SP, lo cuál provoca la pregunta: ¿alguien honestamente cree que el éxito de Silicon Valley se daría por crear restricciones a la compra y venta de SP?
Si la respuesta es no, es posible que el artículo 136 no logra el objetivo de crear más ingenio, y que potencialmente confunde el medio, software libre, con el fin, más innovación. Con 136 Priorizamos el SL sobre el deseo de generar más innovación.
Esperamos que en el segundo debate del Código Ingenios hay mayor sensibilidad a los peligros de la ley y más mecanismos para promocionar el software libre sin necesidad de restricciones, limitaciones, e imposiciones dañosas de una autoridad central. Personalmente, creo que el gobierno debería fomentar el uso de SL en el estado: estoy de acuerdo con muchos de los beneficios que subrayan los promotores de la ley, pero creo no se ha tomado en cuenta los problemas que puede crear, y tampoco creo que una ley draconiana es el camino. Que la prioridad del estado sea primero contratar el mejor software que cumpla con los requisitos de atender bien a los ecuatorianos, y que la segunda prioridad sea contratar software nacional, sin importar la filosofía de su fabricación.
Antes de acusarme de querer defender intereses económicos, no hago SW, y tampoco me dedico a la venta de licencias, y tampoco fui remunerado como me han acusado por participar en el debate. Defiendo el principio de la libre elección. Invito a todos enriquecer el debate por dejar sus comentarios aquí.
