Este artículo sobre las dificultades de la adopción del softwarede código abierto en el Gobierno de los EE.UU. me ha parecido muy claro e inspirador sobre una situación que se repite país a país en todo el mundo. Por este motivo lo he traducido del inglés a nuestro idioma desde la fuente original http://ben.balter.com/2014/08/03/why-isnt-all-government-software-open-source/

Disculpen las incorrecciones que haya podido cometer en la traducción y espero que sea de su agrado.

El gobierno federal es el mayor comprador de código en el mundo. ¿Por qué es este código – financiado por los contribuyentes y parte integral para el trabajo del día a día de nuestra democracia – tan a menudo oculto a la vista del público? Hay dos cuestiones a tratar para responder a esta pregunta: ¿Por qué el gobierno desarrolla tan a menudo en plataformas cerradas, y una vez desarrollado, ¿por qué no es abierto el código al público?

El uso de código abierto

Es mucho más fácil contribuir al código abierto cuando estás construyendo sobre una plataforma abierta. Si bien es posible liberar el código fuente de un script VBA, probablemente tiene más impulso y recibe una recepción más cálida desde una plataforma con una comunidad en línea más vibrante como Ruby o Python. Sin embargo, la mayoría de las veces, en el Gobierno se mira por defecto a “nivel empresarial“, desde el inicio a las plataformas propietarias, que envían al Gobierno en la trayectoria del código cerrado.

La demanda de soluciones de “empresa”

Hay una buena cantidad de FUD – miedo, incertidumbre y duda – en las compras CIO del Gobierno acerca de que el código abierto es menos seguro, con errores, o es más costoso, y que vas a tener toda una vida de sufrimiento si no se invierte en una verdadera “solución empresarial“.

Por un lado, si un organismo emite un cheque a un proveedor de software, ya saben lo que van a obtener. El contrato detalla claramente las funciones, horarios de actualización, y asigna la responsabilidad en caso de que algo vaya mal. Más importante aún, el vendedor ofrece un número de teléfono al que desde el organismo puede llamar si necesitan ayuda. “Publica en los foros de soporte y alguien responderá” puede ser una propuesta que de miedo a un CIO.

Hay menos trajes detrás de código abierto

Antes de que la transacción se produzca, la plataforma de código cerrado es probable que tenga una página de publicidad llamativa y a un grupo de vendedores federales llamando al organismo y mostrando en las conferencias las cosas que las plataformas de código abierto tradicionalmente no hacen, evitar a Red Hat y algunas otras cosas. Y cuando la oficina del CIO pide características esariales” como registros de auditoría o el cumplimiento de ciertos requisitos de cumplimiento, se puede apostar a que la solución de código cerrado se asegurará de esas características estén en el siguiente ciclo de lanzamiento.

Contratistas de código cerrado

Por último, estas plataformas de código cerrado son sobre lo que los contratistas del Gobierno saben, porque es lo que se enseña en los programas de ciencias de la computación, y lo que siempre han pedido para el suministro. Si una empresa de desarrollo experimentado tiene un montón de desarrolladores de ColdFusion, cuando licitan en un contrato, van a recomendar que el producto se ​​construya en<ColdFusion. Por no hablar que el RFPdel Gobierno puede estar enfocado para favorecer la tecnología heredada que ya conocen. Todo esto significa que antes de que la primera línea de código se haya escrito, las probabilidades están en contra de que el proyecto vaya ver nunca el exterior del cortafuegos del organismo.Pero incluso si el organismo está usando una plataforma de código cerrado, no hay razón para que su código personalizado no pueda seguir siendo de código abierto.

Contribuir con el código abierto

Con la excepción del 18F, el CFPB y algunos otros, el Gobierno no escribe código. De hecho, rara vez disponen del conocimiento humano de cómo hacerlo si quisiera. En cambio, tradicionalmente el organismo desempeña el papel de un director de programa no técnico, proporcionando especificaciones para los requisitos funcionales, y la selección de un contratista que entregue la funcionalidad final. Los puntos de contacto en el organismo que supervisa el contrato rara vez participan con la comunidad de código abierto, y mucho menos son apasionados del código abierto. Como resultado, tradicionalmente el código abierto no es ni siquiera parte de la conversación. ¿Por qué debería serlo?

Los flujos de trabajo de código cerrado<

En cuanto a la mecánica real del desarrollo de software, el contrato suele estipular un flujo de trabajo de tipo “tíralo por encima de la valla“, donde el organismo ni siquiera ver el código hasta que ya está en producción, en todo caso, muy lejos del concepto de código abierto. Incluso si se les pregunta, los contratistas puede que no tengan experiencia con flujos de trabajo de código abierto, más modernos, o con la participación en la comunidad de código abierto, creando una mala experiencia para todos los involucrados y desalentando futuros intentos sobre código abierto en todo el Gobierno.

Reinventar la rueda como un modelo de negocio

También sospecho que los contratistas federales tienen un desincentivo para abrir el código de su trabajo, teniendo en cuenta que los requisitos técnicos probablemente no varían mucho de un organismo a otro. Una solicitud FOIA es una solicitud FOIA y un comunicado de prensa es un comunicado de prensa, sin importar si tiene el membrete de FAA o de la FDA. Liberar el código de estas soluciones por primera vez podría disminuir la demanda de volver a escribir ese mismo código por segunda vez a costa del contribuyente.

Una cultura de “no”

Una vez construido, se necesitan seres humanos para llevar ese código a la velocidad de escape necesaria para superar la inercia protectora del organismo. Los responsables de seguridad probablemente que va a decir que no. Los responsables de asuntos jurídicos probablemente que va a decir que no. Tendrá que conseguir la aprobación de la plataforma de alojamiento para el código. Va a tener que adquirir un contrato de mantenimiento continuo para revisar las solicitudes de aceptación de modificaciones. Va a tener que crear una política de compromiso para el desarrollador sobre cómo los acepta. En un mundo de prioridades en competencia, es probable que los empleados del Gobierno opten por pasar al próximo proyecto de cara al ciudadano, en lugar de gastar potencialmente meses combatiendo contra el sistema inmune al cambio de la burocracia.

Choque de culturas

Incluso si el organismo se las arregla para liberar el código fuente, la comunidad de código abierto sigue un conjunto de normas muy diferentes a los de la rígida jerarquía del Gobierno. Las agencias gubernamentales no siempre saben la mejor manera de involucrar a la comunidad de código abierto, o cómo integrar un flujo de trabajo de código abierto dentro de su propia cultura “orden y control“. Apoyar a una comunidad de código abierto requiere tiempo, algo de lo que los empleados del Gobierno tradicionalmente suelen estar escasos. Y cuando el organismo no sigue las normas tácitas de la comunidad del código de fuentes abiertas, los peores temores de los negativistas se convierten en una profecía autocomplaciente.

La transparencia como una debilidad

El código de fuente abierta expone al organismo a la posibilidad de críticas por parte de millones de ojos críticos altamente técnicos, con poco sentido de la percepción desde la perspectiva del organismo. El equipo no técnico del organismo puede no tener la capacidad de evaluar la artesanía del código interno, y es a menudo preferible barrer las cosas bajo la alfombra, en lugar de potencialmente airear sus trapos sucios a algunos de los trolls más hábiles de Internet. Por no hablar de los beneficios del código abierto que los defensores exponen a menudo no se consiguen, y por lo tanto no pueden servir como un contrapeso si el código construido es tan especifico de manera tal que lo hace inutilizable fuera del Gobierno, dejando de esta manera de atraer a colaboradores externos, o si el proyecto está mal gestionado, con el fin de ahuyentar a estos contribuyentes.

Mientras tanto, el código fuente no liberado plantea un escenario de responsabilidad absolutamente cero en el clima político actual. ¿Cuál elegirías?

¿Qué debe cambiar?

Para voltear el modelo por defecto, tres son las cosas que tienen que cambiar:

  • En primer lugar, los empleados públicos tienen que estar capacitados con una mejor comprensión y apreciación de las virtudes del código abierto. Aquellos organismos que tienen código abierto, lo hacen porque disponen de individuos entusiastas que encabezan la propuesta. Los proyectos exitosos están en el ámbito desde el primer día con la intención de ser de código abierto, y sirven para formar de nuevo la demanda del mercado. Iniciativas como 18F y el programa PIF pueden tratar de inspirar y educar a la próxima generación de defensores del código abierto dentro del Gobierno.
  • En segundo lugar, aun cuando el organismo no llama explícitamente para ello, como expertos en la materia, los contratistas del Gobierno tienen el deber de explorar alternativas de código abierto y de educar al mercado como a prácticas de desarrollo estándar de la industria moderna. Cualquier observador casual puede ver la dirección de la marcha del mercado, y las empresas inteligentes tienen la oportunidad de ponerse en frente de ella. Crear competencias internas en torno a tecnologías más populares del momento y hacer crecer la demanda del Gobierno. Que sea más práctico para que el Gobierno haga lo correcto, en lugar de lo que siempre ha hecho.
  • Por último, la comunidad de código abierto tiene que intensificar su juego, tanto en términos de lo que ofrece – cambiando la percepción de que el código abierto está escrito por aficionados – y el Gobierno de la recepción del código que recibe. Por el lado de la oferta, hay un modelo de negocio tremendo en ser los trajes detrás de cualquiera de los proyectos de código abierto más populares de Internet* – Automattic, GitHub, y Red Hat siendo algunos ejemplos – en la lucha contra el FUD y la prestación de soporte empresa“. Por el lado de la demanda, la comunidad necesita que sea un lastre no liberar el código ¿qué escondes?“), y hacer que el regreso de la inversión del organismo sea claro rompiendo la mentalidad del “nosotros contra ellos“, y apoyando, no criticando, los esfuerzos del Gobierno por aprender de código abierto.

¿Por qué no todo el software del Gobierno es de código abierto? Porque tienes una cadena de valor diseñada para producir software de código cerrado, un sistema en equilibrio, con pocos incentivos para reinventarse a si mismo. La tecnología ha hecho que colaborar en abierto sea más fácil en los últimos años, y como resultado, el ecosistema de código abierto se ha disparado. Sin embargo, como toda tecnología, el Gobierno tiene todavía un par de años de retraso en la adopción de la corriente principal.Esperemos que, con su ayuda, esto puede cambiar.

Notas al pie del traductor

  • del inglés Fear, Uncertainty and Doubt, en español miedo, incertidumbre y duda.
  • En el texto original utiliza la palabra agencia, pero la he traducido como organismo dado que es algo más cercano a nuestra cultura sobre las AA.PP.
  • Se refiere al equivalente en EE.UU. de la carrera española de Grado de Ingeniería en Informática.
  • del inglés Request For Proposal, traducido como Solicitud de Propuesta. Es un tipo de documento de adquisición que se utiliza para solicitar propuestas de posibles vendedores de productos o servicios para un proyecto.
  • 18F es una agencia de servicio digitales perteneciente a la Administración General de los EE.UU. Este grupo produce productor digitales para las organizaciones gubernamentales mediante el uso de metodologías LEAN, código libre y lenguajes de programación actuales. Su nombre proviene de su localización en Washintong DC entre las calles 18 y F.
  • Consumer Financial Protection Bureau, traducido como Oficina de Protección Financiera del Consumidor de los Estados Unidos. Es una agencia federal gubernamental responsable de la regulación de protección al consumidor en los EE.UU.
  • del ingles Freedom of Information Act, traducido como Ley por la Libertad de la Información. Es una ley que otorga a todos los ciudadanos de los EE.UU. el derecho de acceso a la información federal del Gobierno.
  • Federal Aviation Administration* traducido como Administración Federal de Aviación. Es la entidad gubernamental responsable de la regulación de todos los aspectos de la aviación civil en los EE.UU.
  • Food and Drug Administration, traducido como *Agencia de Alimentos y Medicamentos. Es la agencia del Gobierno de los EE.UU. responsable de la regulación de alimentos (tanto para personas como para animales), medicamentos (humanos y veterinarios), cosméticos, aparatos médicos (humanos y animales), productos biológicos y derivados sanguíneos.
  • Negativistas del código abierto. Personas que se encuentran en contra del uso de soluciones de código abierto.
  • Presidential Innovation Fellows. Se trata de un programa de becas competitivas en la que se que los une a los principales innovadores del sector privado, organizaciones sin animo de lucro y gente del mundo académico con los principales innovadores en el Gobierno de EE.UU. para colaborar en soluciones que tienen como objetivo ofrecer resultados significativos en seis meses.

Traducido de la fuente original: http://ben.balter.com/2014/08/03/why-isnt-all-government-software-open-source/