10.12 Código abierto frente a código cerrado

Presentación y motivación

Casi todos los sistemas modernos son una mezcla de software que escribiste, software que compraste y software que tomaste gratis. Dos de esos tres vienen con una elección fundamental: ¿el software es de código abierto o de código cerrado? El software de código abierto (OSS) se distribuye bajo una licencia que otorga a todos el derecho de usar, estudiar, modificar y redistribuir el código fuente, las instrucciones legibles por humanos que definen el programa. El software de código cerrado, también llamado software propietario, se distribuye como un producto terminado cuyo código fuente el proveedor mantiene privado. Obtienes el derecho de ejecutarlo bajo una licencia, pero no de inspeccionar o cambiar cómo funciona. Una categoría intermedia, el software de fuente disponible, publica el código fuente para lectura pero restringe el uso, la modificación o la redistribución. Es visible pero no abierto según la definición estándar.

Dos aclaraciones importan antes de compararlos. Primero, “libre” es ambiguo. La comunidad distingue libre como en libertad (la libertad de modificar y compartir) de gratis como en precio (costo cero). El código abierto trata de libertad, no necesariamente de precio. Segundo, las licencias de código abierto se dividen en dos familias. Las licencias permisivas (como MIT, BSD y Apache 2.0) permiten hacer casi cualquier cosa, incluyendo incorporar el código en un producto cerrado. Las licencias copyleft (como la Licencia Pública General de GNU, GPL) exigen que las obras derivadas que distribuyas también se publiquen bajo los mismos términos abiertos, una regla de reciprocidad que a veces los críticos llaman “viral” y los defensores llaman “compartir por igual”.

Este capítulo examina la elección desde dos ángulos. Como consumidor, decides si adoptar un componente de código abierto o propietario. Como productor, decides si liberar como código abierto el software que construiste. Para las grandes empresas, y especialmente el gobierno, ambas decisiones pesan mucho más allá del archivo de licencia. Tocan las adquisiciones (capítulo 10.3), la soberanía digital (capítulo 10.11), la seguridad de la cadena de suministro (capítulo 4.2), la interoperabilidad (capítulo 3.8) y el cálculo de construir o comprar (capítulo 6.1).

Principios fundamentales

La licencia, no el precio, define “abierto”. Lee la licencia; gratuito y de código abierto son afirmaciones distintas.
Ningún modelo es inherentemente más seguro. Ambos pueden ser excelentes o negligentes; las prácticas alrededor del código importan más que su apertura.
La apertura es una palanca de reducción de dependencia. El acceso al código fuente es la protección máxima contra el bloqueo de proveedor.
Siempre posees la carga operativa. Gratis de adquirir nunca es gratis de operar; el costo total de propiedad cuenta la historia real.
Lo que te diferencia se mantiene cerrado; lo que es una mercancía puede abrirse. Libera como código abierto lo que no te distingue; protege lo que sí.
El copyleft tiene consecuencias. Comprende las obligaciones de reciprocidad antes de incorporar código copyleft en un producto que distribuyes.
Una comunidad viva es un activo; un repositorio abandonado es un pasivo. Juzga el proyecto, no solo la licencia.

Recomendaciones

Evalúa un componente por el proyecto, no solo por la licencia

Antes de adoptar cualquier dependencia, de código abierto o propietaria, evalúa su salud: la cadencia de lanzamientos, el número y la diversidad de mantenedores, la capacidad de respuesta a los reportes de seguridad y la amplitud de adopción. Una biblioteca de código abierto con un solo mantenedor y un pequeño proveedor propietario cargan el mismo riesgo de factor de autobús (el peligro de que un proyecto colapse si una o pocas personas clave se van). Favorece componentes con una base amplia de colaboradores o un proveedor financieramente sólido, y registra la evaluación como parte de la debida diligencia (capítulos 10.2, 4.2).

Lee y rastrea las licencias como una obligación de primera clase

Mantén un inventario de cada componente y su licencia, y aplica una política sobre qué familias de licencias son aceptables para qué usos. La distinción crítica es el copyleft. El código permisivo (MIT, Apache 2.0) generalmente puede incorporarse libremente en productos cerrados. El copyleft fuerte (GPL) puede obligarte a liberar tu propio derivado distribuido bajo los mismos términos. Usa el análisis de composición de software (SCA) automatizado, herramientas que escanean tus dependencias para identificar componentes, licencias y vulnerabilidades conocidas, y genera una lista de materiales de software (SBOM), un listado formal de cada componente de un producto (capítulos 10.3, 4.2).

Juzga la seguridad por la práctica, no por la apertura

No supongas que el código abierto es seguro por el argumento de “muchos ojos” (la ley de Linus: “con suficientes ojos, todos los errores son superficiales”). Y no supongas que el código propietario es seguro mediante la seguridad por oscuridad (la creencia errónea de que ocultar el código oculta los defectos). Muchos ojos solo ayudan si personas calificadas realmente miran, y muchos proyectos ampliamente usados están débilmente mantenidos. Ambos modelos cargan riesgo de cadena de suministro: el código abierto mediante dependencias comprometidas o abandonadas, el propietario mediante código opaco y canales de actualización que no puedes inspeccionar. Fija versiones, verifica la procedencia, escanea continuamente y monitorea los avisos sin importar el modelo (capítulo 4.2).

Diseña para la salida y la interoperabilidad

Prefiere componentes que hablen estándares abiertos y formatos de datos portables, para poder reemplazarlos después (capítulos 3.8, 10.11). Con el código abierto ganas la salida definitiva: si un proyecto se estanca, puedes bifurcarlo (crear y mantener tu propia copia). Con el software propietario, negocia protecciones por adelantado: exportación de datos en formatos abiertos, APIs documentadas y depósito de código fuente en garantía (un acuerdo legal donde el proveedor deposita el código fuente ante un tercero, que se libera si el proveedor falla). Diseña de modo que ningún componente, de ningún tipo, pueda tomar tu sistema como rehén.

Sopesa el costo total de propiedad, no el precio de etiqueta

Compara opciones por el costo total de propiedad (TCO), el costo completo de vida útil incluyendo adquisición, integración, operación, soporte, capacitación, actualizaciones y reemplazo eventual, en lugar de solo las tarifas de licencia. El código abierto a menudo cambia el costo de licenciamiento por mayor costo operativo y de personal. El software propietario a menudo cambia tarifas de suscripción predecibles por bloqueo y menos control. Incluye el costo del modelo mismo: el código abierto autosoportado necesita habilidad interna, mientras que el software propietario necesita capacidad de gestión de proveedores.

Como productor, libera como código abierto lo que no te diferencia

Clasifica tu propio software en lo que te da ventaja competitiva o de misión y lo que es infraestructura sin diferenciación. Mantén los diferenciadores propietarios. Considera liberar como código abierto la infraestructura de mercancía, donde una comunidad puede compartir el mantenimiento y la mejora. Para el gobierno, sopesa el principio de “dinero público, código público” (el principio de que el software financiado por los contribuyentes debe estar disponible públicamente por defecto) como impulsor de la transparencia, la reutilización y la soberanía (capítulos 10.5, 10.11). Elige la licencia deliberadamente: permisiva para maximizar la adopción, copyleft para mantener el ecosistema abierto.

Ventajas y desventajas

Dimensión	Código abierto	Cerrado / propietario
Costo de adquisición	Generalmente cero para adquirir	Tarifa de licencia o suscripción
Costo total de propiedad	El costo se traslada a operaciones y personal	Más predecible, pero con prima de bloqueo
Control y personalización	Completo: puedes leer y cambiar el código fuente	Limitado a lo que el proveedor expone
Soporte y responsabilidad	Comunidad o tercero pagado; sin un único responsable	Soporte contractual y una parte responsable clara
Postura de seguridad	Auditable; “muchos ojos” si está realmente mantenido	Gestionado por el proveedor; opaco; la oscuridad no es protección
Longevidad / abandono	Puede bifurcarse si está mantenido; puede marchitarse igual	Depende de la viabilidad y la hoja de ruta del proveedor
Bloqueo de proveedor	Bajo: el código fuente y los formatos abiertos permiten la salida	Alto salvo que se mitigue con estándares y depósito en garantía
Ecosistema	Comunidad abierta e interoperabilidad	Curado, integrado, a veces cerrado

La tensión recurrente es control frente a conveniencia y responsabilidad. El código abierto maximiza el control, la auditabilidad y la libertad frente al bloqueo, pero te pide suministrar la capacidad, la integración y el soporte tú mismo. El software propietario entrega un producto soportado, integrado y responsable con un contrato que hacer cumplir, pero cede control e invita al bloqueo. La resolución rara vez es todo o nada. La mayoría de los parques tecnológicos maduros mezclan bases de código abierto con sistemas propietarios donde el soporte, la responsabilidad o la capacidad especializada justifican el intercambio.

Preguntas para discutir con tu equipo

¿Aplicamos una política de licencias con SCA y SBOM automatizados en el pipeline, especialmente para detectar el copyleft fuerte antes de enviar el producto? Incorporar una biblioteca GPL en un producto propietario distribuido puede obligarte a liberar tu propio código fuente, y esa sorpresa suele surgir tarde, cuando es costosa de deshacer. Mantén un inventario de cada componente y su licencia, aplica qué familias de licencias son aceptables para qué usos, y ejecuta el análisis de composición de software automáticamente para que el pipeline bloquee las violaciones en lugar de que un abogado las detecte al momento de enviar. Genera un SBOM como cuestión de rutina. Para un parque tecnológico grande o gubernamental, esto también es higiene de cadena de suministro y a menudo un requisito de adquisición. Trae tu inventario actual de licencias, o el hecho de que no lo tienes, y decide quién posee la política.
Cuando adoptamos una dependencia, ¿evaluamos la salud del proyecto y el factor de autobús como debida diligencia? Una biblioteca de código abierto con un solo mantenedor y un pequeño proveedor propietario cargan el mismo riesgo: el proyecto colapsa si una o pocas personas clave se van. Antes de adoptar cualquier cosa, evalúa la cadencia de lanzamientos, el número y la diversidad de mantenedores, la capacidad de respuesta a los reportes de seguridad y la amplitud de adopción, y registra la evaluación. Ningún modelo es más seguro por defecto; “muchos ojos” solo ayuda si personas calificadas realmente miran, y muchos proyectos ampliamente usados están débilmente mantenidos. Trae las tres o cuatro dependencias de las que más depende tu producto y pregunta, para cada una, cuántas personas tendrían que irse antes de que se convirtiera en tu problema. Si no puedes responder, esa es la evaluación que te debes a ti mismo.
Cuando compramos propietario, ¿aseguramos protecciones de salida por adelantado? El software propietario ofrece responsabilidad y conveniencia a cambio de control, y el costo oculto es el bloqueo: costos de cambio que permiten a un proveedor subir precios o degradar el servicio con poco recurso. Negocia las protecciones antes de firmar, cuando aún tienes influencia: exportación de datos en formatos abiertos, APIs documentadas y depósito de código fuente en garantía que libera el código si el proveedor falla. Con código abierto tu salida es la capacidad de bifurcar; con propietario debes escribir la salida en el contrato. Trae tus sistemas propietarios más críticos y pregunta qué sucede realmente si el proveedor duplica el precio o quiebra. Si la respuesta es “estamos atrapados”, corrige el contrato en la renovación.
Para el software que construimos nosotros mismos, ¿cómo decidimos qué liberar como código abierto y qué mantener cerrado, y quién tiene la autoridad para tomar esa decisión? Equivócate en una dirección y regalas el código mismo que te diferencia; equivócate en la otra y acaparas infraestructura de mercancía cuyo mantenimiento una comunidad compartiría con gusto. Las presiones en competencia son reales: los ingenieros quieren el beneficio de reclutamiento y reputación de un repositorio público, mientras que producto y legal se preocupan por dar a los rivales una ventaja o exponer una heurística sensible a la seguridad. Trae una clasificación honesta de tus sistemas en diferenciadores de misión versus infraestructura sin diferenciación, y nombra a la persona o el comité que aprueba una liberación, porque una decisión improvisada tomada por quien empujó el repositorio es cómo se filtran las joyas de la corona. Para una gran empresa la pregunta es de estrategia de portafolio, y para el gobierno choca con “dinero público, código público”, el principio de que el software financiado por los contribuyentes debe ser público por defecto, así que decide de antemano qué excepciones (seguridad nacional, detección de fraude, datos personales) justifican mantener el código cerrado.
¿Nuestras comparaciones de construir o comprar capturan el costo total de propiedad completo, o todavía tratamos una tarifa de licencia cero como un costo cero? El error financiero más común con el código abierto es leer “gratis de adquirir” como “gratis de operar”, y luego descubrir que la integración, las operaciones, la respuesta de seguridad y el soporte pagado superan con creces cualquier licencia que se evitó. La tensión es que una suscripción propietaria se ve costosa en la factura mientras oculta una prima de bloqueo, y un componente abierto se ve gratis en la factura mientras traslada el costo a tu propio personal. Trae un modelo de TCO comparable para dos o tres decisiones reales: adquisición, integración, operación, soporte, capacitación, actualizaciones, respuesta de seguridad y reemplazo eventual, calculado sobre la vida útil completa en lugar del primer año. En un parque tecnológico empresarial o gubernamental, agrega el costo del modelo operativo mismo, ya que el código abierto autosoportado exige habilidad interna que debes reclutar y retener, y trata una comparación que omite esas líneas como evidencia, no como análisis.
¿Juzgamos la seguridad de un componente por sus prácticas, o nos apoyamos en la etiqueta de apertura, ya sea “muchos ojos” o el secreto del código cerrado? Ambos supuestos por defecto son trampas: “muchos ojos” solo te protege cuando personas calificadas realmente revisan el código, y muchos proyectos abiertos ampliamente usados funcionan con un solo mantenedor agotado, mientras que el código cerrado que confía en que los atacantes no lo vean es seguridad por oscuridad, no un control. El debate importa porque cambia dónde gastas el esfuerzo de seguridad escaso, y la respuesta honesta es que ambos modelos cargan riesgo de cadena de suministro, el código abierto mediante dependencias comprometidas o abandonadas y el propietario mediante canales de actualización opacos que no puedes inspeccionar. Trae evidencia de tus componentes más críticos: quién realmente los revisa, qué tan rápido se parchan los avisos, si las versiones están fijadas y la procedencia verificada, y si generas un SBOM. Para un parque tecnológico grande o gubernamental, vincula esto a las obligaciones de adquisición y escaneo continuo, porque un regulador preguntará qué inspeccionaste, no si el código era público.

Perspectiva sectorial

Startup. Con poco margen de tiempo construyes sobre bases de código abierto porque no puedes pagar tarifas de licencia y quieres la libertad de bifurcar si un proyecto se estanca. Ejecuta un escaneo de análisis de composición antes de enviar para que una biblioteca de copyleft fuerte no te obligue silenciosamente a publicar tu propio código, y mantén tu único diferenciador real estrictamente cerrado. Libera como código abierto una herramienta pequeña y no crítica si ayuda al reclutamiento, pero no asumas una carga de mantenimiento que no puedas sostener.

Pequeña empresa. Sin especialista legal o de plataforma interno, trata la licencia como un riesgo que no debes malinterpretar en lugar de un tema que puedes dominar. Prefiere herramientas propietarias soportadas o distribuciones comerciales de código abierto donde un proveedor posee los parches y la responsabilidad, porque autosoportar una pila que no puedes operar es una falsa economía. Cuando adoptes un componente gratuito, verifica que su licencia permita tu uso y que el proyecto esté realmente mantenido, no abandonado.

Empresa. A escala el problema es la consistencia entre muchos equipos: una política de licencias escrita, análisis de composición de software y generación de SBOM automatizados en cada pipeline, y decisiones de construir o comprar basadas en TCO en lugar de hábito por equipo. Gestiona el software abierto y propietario como un solo portafolio, estandariza protecciones de salida como formatos abiertos y depósito de código fuente en garantía en las adquisiciones, y rastrea la salud de las dependencias críticas para que un solo proyecto abandonado no se convierta en un incidente. Gobierna también el lado del productor, con una regla clara sobre qué libera la organización como código abierto frente a qué mantiene cerrado.

Gobierno. Las reglas de adquisición, los deberes de transparencia y la responsabilidad pública dan forma a cada elección. Sopesa “dinero público, código público”, el principio de que el software financiado por los contribuyentes debe ser público por defecto, para avanzar la reutilización entre agencias y la soberanía digital, mientras reservas excepciones estrechas para código sensible a la seguridad o a los datos personales. Exige a cualquier proveedor propietario que ofrezca exportación de datos en formatos abiertos y depósito de código fuente en garantía para que la falla de un proveedor no pueda dejar varado un servicio público, y publica el código no sensible para que los ciudadanos puedan auditar las reglas que los gobiernan.

Ejemplos

Startup. Una startup de tres fundadores construye todo su producto sobre bases de código abierto (Linux, una base de datos de código abierto, un framework web) porque no puede pagar tarifas de licencia y quiere la libertad de bifurcar si un proyecto se estanca. Antes de lanzar, uno de los fundadores ejecuta un escaneo de análisis de composición y detecta una biblioteca de copyleft fuerte que los habría obligado a publicar su algoritmo de emparejamiento propietario, así que la reemplazan por un equivalente con licencia permisiva. Mantienen ese algoritmo, su único diferenciador, estrictamente cerrado, y liberan como código abierto solo una pequeña herramienta interna de registro para generar buena voluntad y atraer ingenieros.

Empresa. Una gran aseguradora ejecuta su plataforma central sobre bases de código abierto: Linux, una base de datos de código abierto ampliamente usada y un orquestador de contenedores. Pero compra un conjunto propietario de modelado actuarial, porque la experiencia de dominio del proveedor, sus certificaciones regulatorias y su contrato de soporte valen la tarifa y no hay una alternativa abierta comparable. Paga una suscripción por código abierto comercial (distribuciones soportadas por proveedor de los componentes abiertos) para obtener responsabilidad y parches en la infraestructura, mientras mantiene el algoritmo de precios que la diferencia estrictamente propietario e interno. El análisis de TCO (capítulo 10.10) impulsa cada elección en lugar de la ideología.

Gobierno. Una agencia tributaria nacional, bajo una política de “dinero público, código público”, construye un nuevo servicio de elegibilidad de beneficios sobre componentes de código abierto y estándares abiertos (capítulo 3.8), para que otras agencias puedan reutilizarlo y los ciudadanos puedan auditar las reglas. Publica el código no sensible en un repositorio público, reteniendo solo las heurísticas de detección de fraude como cerradas por razones de seguridad. Esto reduce el bloqueo de proveedor y avanza la soberanía digital (capítulo 10.11). Las reglas de adquisición (capítulo 10.3) exigen que cualquier componente propietario ofrezca exportación de datos en formatos abiertos y depósito de código fuente en garantía, para garantizar la continuidad si el proveedor falla.

Caso de negocio: motivaciones, ROI y TCO

El atractivo financiero del código abierto, su ausencia de tarifa de licencia, es la parte menos confiable del caso, porque la adquisición es una fracción pequeña del TCO. Los retornos duraderos son estratégicos: libertad frente al bloqueo (la capacidad de cambiar o abandonar un proveedor sin rediseñar), auditabilidad para seguridad y cumplimiento, adopción más rápida porque los ingenieros pueden probar antes de comprometerse, y mantenimiento compartido de código de mercancía en toda una industria. Los costos compensatorios son reales. Debes suministrar integración, operaciones, respuesta de seguridad y a menudo soporte pagado, y un proyecto mal elegido y no mantenido puede costar más en incidentes de lo que cualquier licencia hubiera costado.

El caso de negocio del software propietario es responsabilidad y conveniencia: un único proveedor responsable del producto, un contrato de soporte que puedes hacer cumplir, características integradas y presupuesto predecible. Su costo oculto es el bloqueo, los costos de cambio que permiten a un proveedor subir precios o degradar el servicio con poco recurso, más la dependencia de la solvencia y la hoja de ruta del proveedor. Los modelos de negocio comunes difuminan la línea: núcleo abierto (una base abierta con complementos propietarios pagados), doble licenciamiento (el mismo código ofrecido tanto bajo una licencia copyleft como bajo una licencia comercial paga), software como servicio (SaaS) (el software se ejecuta como un servicio alojado que rentas, donde el código fuente puede ser irrelevante porque nunca posees el binario), y modelos de soporte/suscripción que venden servicio alrededor de código por lo demás gratuito.

Para un productor, el ROI de liberar como código abierto tu propio software sin diferenciación puede ser sustancial. Los colaboradores externos reducen tu carga de mantenimiento. El proyecto se convierte en un activo de reclutamiento y reputación. La adopción externa hace que tu estándar sea el de facto. Para el gobierno, entrega transparencia y reutilización en todo el sector público. La regla estratégica es simple: libera como código abierto la mercancía para compartir su costo y hacer crecer un ecosistema, y mantén cerrado el diferenciador para proteger la ventaja que financia todo lo demás.

Antipatrones y trampas

“Gratis significa gratis”: tratar el costo de adquisición cero como TCO cero, y luego subfinanciar la operación y el soporte.
Ceguera de licencias: incorporar código de copyleft fuerte en un producto propietario distribuido y desencadenar obligaciones que nunca planeaste.
Fe en “muchos ojos”: suponer que un proyecto abierto está auditado cuando tiene un solo mantenedor sobrecargado y ninguna revisión de seguridad.
Seguridad por oscuridad: creer que el código cerrado es seguro simplemente porque los atacantes no pueden leerlo.
Absolutismo ideológico: exigir “todo abierto” o “todo propietario” en lugar de elegir por componente según mérito y TCO.
Ignorar la procedencia: incorporar dependencias sin SBOM, fijación de versiones ni verificación de cadena de suministro (capítulo 4.2).
Liberar las joyas de la corona: publicar el código mismo que te diferencia, regalando tu ventaja.
Bifurcar y olvidar: bifurcar un proyecto abandonado sin la capacidad de realmente mantener la bifurcación.

Modelo de madurez

Nivel 1 (Iniciar). Los componentes de código abierto y propietario entran al parque tecnológico de manera improvisada. Las licencias no se leen, no hay inventario ni SBOM, y la elección entre modelos se hace por hábito o solo por precio. El abandono y el riesgo de licencia solo salen a la luz cuando algo se rompe, y cada equipo reacciona por su cuenta.

Nivel 2 (Desarrollar). Algunos equipos comienzan prácticas básicas: un inventario de componentes y licencias, una visión aproximada de las licencias aceptables, y análisis de composición de software ocasional. Las decisiones de construir o comprar y de abierto o cerrado se registran por escrito, pero la disciplina es irregular e inconsistente de un equipo a otro, así que una sorpresa de copyleft o de factor de autobús aún puede pasar donde el hábito no se ha arraigado.

Nivel 3 (Estandarizar). Un marco documentado gobierna tanto el consumo como la producción en toda la organización. Los componentes se eligen por TCO y salud del proyecto, las licencias se aplican automáticamente en el pipeline para que las violaciones bloqueen una construcción, los SBOM se generan como cuestión de rutina, y una política explícita establece qué libera la organización como código abierto frente a qué mantiene cerrado. Las protecciones de salida como formatos abiertos y depósito de código fuente en garantía son estándar en las adquisiciones, y cada equipo sigue las mismas reglas en lugar de las propias.

Nivel 4 (Gestionar). El programa se mide y se controla contra líneas base. La organización rastrea métricas como la cobertura de SBOM en todos los productos, la proporción de dependencias que violan la política, el tiempo medio para parchar una vulnerabilidad de dependencia divulgada, las puntuaciones de factor de autobús y salud para proyectos críticos, y el TCO realizado frente a la estimación que justificó cada elección. Los umbrales activan acciones: un componente cuyo mantenimiento se estanca o cuya latencia de parcheo se desvía más allá del objetivo se marca para reemplazo con base en evidencia, y las decisiones de abierto o cerrado y de construir o comprar se revisan contra los números en lugar de defenderse por hábito.

Nivel 5 (Orquestar). La estrategia de código abierto es una capacidad de negocio deliberada, integrada en toda la organización y mejorada continuamente. La organización contribuye a los proyectos de los que depende, y a veces los administra, libera como código abierto su software sin diferenciación como cuestión de rutina, y retroalimenta datos de salud de dependencias y de TCO hacia las adquisiciones, la seguridad y la planificación de productos. Reequilibra rutinariamente su portafolio de software abierto y propietario, adaptándose a cambios en el costo, el riesgo, la soberanía y la ventaja estratégica antes de que fuercen una crisis.

Ideas para el debate

¿Dónde en tu parque tecnológico sería existencial perder un solo proveedor o mantenedor, y cuál es tu plan de salida?
¿Cuáles de tus propios sistemas son mercancías que podrías liberar como código abierto, y cuáles son verdaderos diferenciadores que proteger?
¿Tu organización trata “muchos ojos” como un control de seguridad real o como una suposición no examinada?
Para los lectores del sector público: ¿qué cambiaría un valor por defecto de “dinero público, código público” en tu próxima adquisición?
¿Qué tan bien capturan tus comparaciones de TCO los costos operativos y de soporte que el código abierto traslada hacia ti?

Puntos clave

Abierto frente a cerrado se define por la licencia, no por el precio; conoce la diferencia entre libre como en libertad y gratis como en precio, y entre permisivo y copyleft.
Ningún modelo es inherentemente más seguro o más barato. Juzga las prácticas del proyecto y su TCO completo, no la etiqueta de apertura.
La apertura es el antídoto más fuerte contra el bloqueo, entregando auditabilidad, portabilidad y la capacidad de bifurcar; el software propietario ofrece responsabilidad y conveniencia a cambio de control.
Decide por componente según mérito, y mezcla modelos deliberadamente en lugar de por ideología.
Como productor, libera como código abierto la mercancía y mantén cerrado el diferenciador, y en el gobierno, sopesa “dinero público, código público” para la transparencia, la reutilización y la soberanía.

Referencias y lecturas adicionales

Eric S. Raymond, The Cathedral and the Bazaar
Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Adrian Cockcroft y otros, varios títulos de O’Reilly sobre estrategia y operaciones de código abierto
Free Software Foundation, The Free Software Definition (y los textos de la Licencia Pública General de GNU)
Open Source Initiative, The Open Source Definition y la lista de licencias aprobadas
Free Software Foundation Europe, materiales de la campaña Public Money, Public Code
Yochai Benkler, The Wealth of Networks