¿Debe abrirse o cerrarse la tecnología? Enfoques para maximizar el valor empresarial y la utilidad social

Introducción

Si se publica una tecnología desarrollada internamente, como en el caso del código abierto, es posible esperar una adopción generalizada en poco tiempo, pero por otro lado, se atrae a muchos competidores que ofrecen servicios similares. Si se toma una decisión adecuada, esto puede impulsar la expansión del servicio propio, pero ¿cómo deberíamos juzgar esta situación?

Desde la perspectiva de la sociedad, es beneficioso que las nuevas tecnologías se hagan públicas para muchos ingenieros e investigadores, pero si los inventores no pueden obtener ganancias de la divulgación de la tecnología, el incentivo para inventar se reduce y, como resultado, la innovación se vuelve menos probable.

En este artículo, organizamos la "apertura" de la tecnología en 9 niveles, desde "completamente abierta" hasta "completamente cerrada", y compilamos casos de éxito y fracaso para cada nivel. Luego, presentamos un enfoque para maximizar el valor empresarial y la utilidad social, basado en investigaciones académicas recientes y conocimientos de profesionales.

El grado de apertura de la tecnología se determina por dos ejes: "divulgación" y "licencia"

En primer lugar, como premisa, el grado de apertura de la tecnología en realidad no se compone de un solo eje, sino de dos.

Eje de divulgación: hasta qué punto revelar el contenido de la tecnología Es el grado de divulgación de información sobre si se publica el código fuente o las especificaciones técnicas, se muestra solo el comportamiento, o se mantiene completamente en secreto.

Eje de licencia: hasta qué punto permitir el uso Es el grado de derechos de uso: si se permite el uso comercial, la modificación, la redistribución y la conversión en servicios competidores, o si se limita al uso no comercial, o si solo la empresa propia puede ejecutarla.

Por ejemplo, una patente divulga completamente el contenido técnico (se publica 18 meses después de la solicitud), pero monopoliza los derechos de implementación durante aproximadamente 20 años. En otras palabras, es una combinación de "divulgación máxima, licencia mínima". Los siguientes 9 niveles se ordenan según el "grado de apertura" que combina estos dos ejes.

9 niveles de grado de apertura de tecnología

Nivel 1: Completamente abierto

Descripción: CC0, Unlicense (renuncia de derechos) y licencias permisivas como MIT, Apache 2.0 y BSD. Se publica el código fuente y se permite prácticamente sin condiciones el uso comercial, la modificación, la redistribución e incluso la incorporación en productos cerrados (solo se requiere la atribución). Apache 2.0 es adecuado para uso empresarial porque incluye la concesión explícita de derechos de patente.

Términos de uso: Principalmente atribución (conservación del aviso de derechos de autor). También es libre incorporar la versión modificada en un producto comercial sin hacer pública.

Propósito típico: Maximizar la adopción y establecer el estándar de facto. Se abre la tecnología periférica (SDK, formato de datos, conectores) que no importa si se incorpora, ampliando el ecosistema.

Casos de éxito: Android (AOSP) abrió el sistema operativo con Apache 2.0, expandió todo el mercado de teléfonos inteligentes y Google recuperó valor a través de capas cerradas (Play Store, publicidad, licencia GMS). React, VS Code y Kubernetes también se ampliaron con licencias permisivas, devolviendo valor a sus operaciones principales (nube, contratación, plataforma).

Casos de fracaso: 1. Docker publicó la tecnología de contenedores con una licencia permisiva y se convirtió en el estándar de la industria como tecnología. Sin embargo, debido a que la tecnología principal estaba completamente abierta, la mayor parte del valor fluyó hacia Kubernetes (liderado por Google) y los servicios administrados de proveedores de nube, lo que resultó en un fracaso en la monetización de Docker. En 2019, Docker vendió su negocio empresarial a Mirantis. Este es el caso más importante que demuestra que "el éxito técnico" y "el éxito empresarial" son cosas diferentes. 2. OpenSSL, del cual depende la mayor parte de la comunicación encriptada de Internet, operaba con una escasez extrema de recursos: solo 1 desarrollador a tiempo completo y aproximadamente 2,000 dólares en donaciones anuales en el momento del descubrimiento de la vulnerabilidad crítica "Heartbleed" en 2014. Un bien público que cualquiera puede usar sin costo es un ejemplo típico del problema del aprovechado, donde nadie asume el costo, lo que provocó que la investigación sobre sostenibilidad del software de código abierto se formalizara (Eghbal, 2020).

Nivel 2: Copyleft débil

Descripción: Una licencia intermedia que obliga a publicar los archivos o partes de biblioteca modificadas, pero permite que el producto combinado completo permanezca cerrado.

Términos de uso: Si se publica la modificación de la parte correspondiente, es posible incorporarla en un producto comercial cerrado.

Propósito típico: Solución intermedia cuando se desea "que se devuelvan las mejoras, pero no se desea impedir la incorporación comercial". Es adecuada para bibliotecas y componentes.

Casos de éxito: Firefox (MPL) estableció una opción para contrarrestar el monopolio en el mercado de navegadores. Varias bibliotecas LGPL (como glibc) se incorporan ampliamente en software comercial, convirtiéndose en una base común de facto.

Casos de fracaso: El sistema operativo para teléfonos inteligentes "Symbian" liderado por Nokia se abrió completamente con EPL (copyleft débil) en febrero de 2010 después de quedar rezagado frente a Android e iOS. Sin embargo, en noviembre del mismo año, Nokia anunció el cese de operaciones de Symbian Foundation, y en 2011, Nokia mismo terminó el suministro de código abierto. Esto demuestra que abrir después de perder competitividad no da razón a los participantes del ecosistema para invertir. La apertura es "una jugada ofensiva", no puede usarse como "medida de derrota".

Nivel 3: Copyleft fuerte

Descripción: Una licencia que obliga a publicar el código fuente de toda la obra derivada. Previene que los competidores incorporen mejoras en productos cerrados y las monopolicen.

Términos de uso: El uso comercial es libre, pero si se distribuye un producto que contiene código GPL, debe publicarse el código fuente completo.

Propósito típico: Prevenir el aprovechamiento gratuito y retornar las mejoras a la comunidad. Se utiliza como base para proyectos liderados por la comunidad y licencias duales (venta conjunta de versiones GPL y comerciales).

Casos de éxito: Linux (GPLv2) es el software de código abierto más exitoso de la historia y se ha convertido en la base de servidores, nube e integrados. Red Hat, que monetizó a través del soporte a distribuciones de Linux, fue adquirida por IBM por aproximadamente 34 mil millones de dólares en 2019, realizando el valor empresarial más grande como empresa de OSS. QGIS (GPL) también ha adquirido una cuota comparable a la de software comercial en el campo de sistemas de información geográfica.

Casos de fracaso: Después de la adquisición por Oracle, la comunidad OpenOffice.org bifurcó LibreOffice debido a la desconfianza en la política operativa (2010), y la mayoría de desarrolladores y usuarios migraron. Demuestra que incluso si la licencia es abierta, si una sola empresa monopoliza la gobernanza y pierde la confianza de la comunidad, perderá el control del proyecto en sí.

Nivel 4: Copyleft de red

Descripción: Una licencia que extiende la obligación de publicación de GPL a "provisión de servicios a través de la red (SaaS)". Previene que los proveedores de nube proporcionen versiones modificadas en secreto. Es la licencia de código abierto aprobada por OSI más defensiva.

Términos de uso: Si se proporciona un servicio usando código AGPL, es necesario publicar el código fuente incluida la parte modificada. Para las empresas que quieren evitar esto, se utiliza la estrategia de "licencia dual" vendiendo licencias comerciales.

Propósito típico: Mantener la transparencia del código mientras se suprime la reventa por parte de grandes nubes y se dirige a los ingresos de licencias comerciales.

Casos de éxito: Adoptado por Grafana, MongoDB (inicial) y Nextcloud. Redis regresó al código abierto con AGPLv3 en mayo de 2025 (Redis 8) después de críticas por no ser OSS en 2024. AGPL se reevalúa como una solución práctica de "abrirse mientras se defiende".

Casos de fracaso: MongoDB adoptó AGPL durante mucho tiempo, pero decidió que no podía suprimr suficientemente la provisión comercial por parte de proveedores de nube, y en 2018 pasó a SSPL más restrictivo. Sin embargo, al año siguiente en 2019, AWS presentó "DocumentDB", que implementaba de forma independiente un API compatible con MongoDB. Esto demuestra el límite estructural de la defensa de licencias: una licencia puede limitar la copia de código, pero no puede limitar la implementación de protocolo o API compatible (desarrollo de sala limpia).

Nivel 5: Publicación de código fuente con restricción de competencia

Descripción: El código fuente es legible, modificable y usable para muchos propósitos, pero se prohíbe explícitamente la "provisión como servicio competidor". No es software de código abierto según la definición de OSI. BSL (Business Source License) tiene una estructura de tiempo limitado que se convierte automáticamente en código abierto después de un cierto período (máximo 4 años).

Términos de uso: El uso interno y de desarrollo es ampliamente posible, pero proporcionar el software en sí como un servicio comercial a terceros está prohibido (o requiere un contrato de licencia comercial).

Propósito típico: Mantener la transparencia y la libertad de auto-hospedaje mientras se protegen los ingresos del "aprovechamiento y reventa gratuita" por parte de proveedores de nube.

Casos de éxito: Adoptado por MariaDB (inventor de BSL), Sentry y CockroachDB, manteniendo operaciones. MongoDB ha mantenido una alta evaluación en el mercado de valores incluso después de la transición a SSPL, demostrando cierto logro en la defensa de ingresos.

Casos de fracaso: HashiCorp cambió Terraform de MPL a BSL en agosto de 2023, pero solo 2 semanas después, la comunidad bifurcó OpenTofu, que creció rápidamente bajo Linux Foundation (38% de usuarios consultados consideraban alternativas). Redis también fue bifurcado por Valkey una semana después de la transición a SSPL en marzo de 2024, y después de críticas, regresó a AGPL en mayo de 2025. Además, SSPL no es aprobado por OSI, por lo que fue eliminado de distribuciones principales como Debian y Fedora, perdiendo los canales de distribución en sí. La investigación académica demuestra que estos forks formaron comunidades con mayor diversidad organizacional que las originales (arXiv:2411.04739, 2024), mostrando que cambiar "para cerrar lo que se abrió" es posible legalmente, pero es una decisión de alto riesgo que daña la comunidad como un activo.

Nivel 6: Publicación no comercial y con condiciones

Descripción: Se publica el código fuente o modelo, pero el uso está limitado a propósitos no comerciales o de investigación, o se adjuntan condiciones individuales sobre escala de uso u aplicación (CC BY-NC, licencias limitadas a investigación, "licencias comunitarias" propias de modelos de IA, etc.).

Términos de uso: Individuos e investigadores pueden usarlo libremente, pero el uso comercial requiere un contrato individual o cumplimiento de condiciones.

Propósito típico: Abrirse a investigadores y desarrolladores individuales para obtener reputación, retroalimentación y ecosistema, mientras se dirige todo uso comercial a la monetización.

Casos de éxito: La serie Llama de Meta utilizó la estrategia de "peso abierto" (publicación de pesos con uso condicional) para construir rápidamente un ecosistema que se opone al modelo de provisión de API cerrado. En software académico, la pista dual "investigación gratuita y comercial de pago" también funciona como una fuente de ingresos sostenible.

Caso de fracaso: El LLaMA original era una versión con acceso restringido ("solo investigadores" mediante solicitud), pero el modelo filtrado en 4chan apenas una semana después del lanzamiento, quedando disponible para cualquiera. Esto expuso que la distribución condicional era técnicamente inaplicable, lo que llevó a Meta a cambiar su estrategia: a partir de Llama 2 (julio de 2023), adoptaron una estrategia de distribución amplia desde el inicio bajo una "licencia comunitaria" que permite uso comercial. En otras palabras, la propia estrategia de pesos abiertos del Llama actual nació del fracaso de la operación estricta de nivel 6 (restricción a investigación). Incluso el propio Llama mantiene condiciones específicas como "las empresas con más de 700 millones de usuarios activos mensuales requieren un contrato separado", lo que hace que los departamentos legales corporativos eviten estas opciones y prefieran Mistral o Qwen bajo licencia Apache 2.0. La complejidad de las condiciones se ha convertido en una barrera para la adopción.

Nivel 7: Patentes

Explicación: Un régimen que otorga derechos de explotación exclusivos durante aproximadamente 20 años a cambio de divulgar completamente el contenido técnico. Después de que expire el período, cualquiera puede usarlo libremente, por lo que puede entenderse como una estructura con límite de tiempo que "se abre obligatoriamente después de un período determinado".

Condiciones de uso: Requiere autorización del titular de la patente (contrato de licencia). Las patentes esenciales para estándares tienen la obligación de otorgar licencias bajo términos FRAND (Justo, Razonable y No Discriminatorio).

Propósitos típicos: Protección de tecnologías que se revelan fácilmente mediante ingeniería inversa (mecanismos, procesos de fabricación o algoritmos visibles al análisis). El principio es "si será analizado de todas formas aunque se intente ocultarlo, es mejor hacerlo público y protegerlo legalmente". También se aplica en patentes defensivas, licencias cruzadas e ingresos por licencias.

Casos de éxito: Qualcomm hace de su negocio de licencias de patentes esenciales para estándares de comunicaciones uno de sus pilares de ingresos. La industria farmacéutica es el ejemplo típico de un modelo que recupera las inversiones colosales en investigación y desarrollo mediante el monopolio de períodos protegidos por patentes (Arora et al., 2001).

Caso de fracaso: Kodak tenía un portafolio de aproximadamente 1,100 patentes, incluyendo patentes fundamentales para cámaras digitales, que se evaluaban entre 2,200 a 2,600 millones de dólares antes de su quiebra. Sin embargo, tras su colapso empresarial en 2012, el precio de venta fue de solo 525 millones de dólares. Esto demostró que incluso si una tecnología se divulga y monopoliza mediante patentes, si se pierden los activos complementarios como manufactura, ventas y marca, así como el modelo de negocio, el valor de las propias patentes se desploma. Este es un ejemplo de la proposición teorizada por Teece (1986) de que "los beneficios de la innovación fluyen hacia quien posee los activos complementarios".

Nivel 8: Código cerrado + API

Explicación: El código fuente permanece cerrado, pero se proporciona la funcionalidad como producto, API o SaaS. La implementación interna no se muestra, pero el uso está ampliamente permitido.

Condiciones de uso: Uso dentro de los términos de servicio y contratos de API. No se permite acceso ni modificación de la implementación.

Propósitos típicos: Mantener la implementación y los datos en secreto mientras se maximizan los usuarios y los ingresos. La mayoría del software comercial y los modelos de IA basados en API adoptan esta forma.

Casos de éxito: Los modelos basados en API de OpenAI y Anthropic, SaaS como Salesforce, iOS de Apple (el núcleo es cerrado pero proporciona SDK a desarrolladores), etc. Este es el modelo dominante en los negocios de software de alto margen actuales.

Caso de fracaso: En la guerra de formatos de videograbadores domésticos, Sony fue reticente a otorgar licencias de Betamax, mientras que Victor Company of Japan (JVC) expandió ampliamente su grupo de partidarios al licenciar VHS, capturando el mercado (Cusumano et al., 1992). No fue la superioridad técnica sino la "diferencia en el grado de apertura" la que decidió el ganador en la competencia de estándares. Este es un caso clásico que demuestra que en mercados donde opera el efecto de red, el cierre puede ser el riesgo máximo.

Nivel 9: Completamente cerrado

Explicación: No se publica ni se solicita patente; se gestiona como secreto. Mientras se mantenga el secreto, el período de protección es ilimitado, lo que representa un tradeoff completamente opuesto al de las patentes.

Condiciones de uso: Solo la propia empresa puede implementarlo. La protección legal depende de sistemas de gestión de secretos como NDA y controles de acceso.

Propósitos típicos: Proteger indefinidamente cosas que son difíciles de revertir mediante ingeniería inversa (lógica del lado del servidor, datos de entrenamiento, secretos de fabricación, datos de clientes).

Casos de éxito: La fórmula secreta de la bebida de Coca-Cola (guardada en secreto durante más de 130 años) y el algoritmo de clasificación de búsqueda de Google son ejemplos representativos. Donde una patente expiraría en 20 años, se ha convertido en una ventaja indefinida como secreto comercial.

Caso de fracaso: Mientras que los secretos comerciales se protegen indefinidamente, son vulnerables a filtraciones. El caso judicial en el que se alegaba que un ex ejecutivo de Waymo llevó el secreto comercial de tecnología de conducción autónoma a Uber resultó en un acuerdo que alcanzó aproximadamente 245 millones de dólares en valores (2018). La estrategia de secreto comercial funciona solo si viene acompañada de inversión continua en el sistema de gestión de secretos en sí (retención de talentos, controles de acceso, contratos), no solo en la tecnología en sí.

Un marco de pensamiento para maximizar el valor del servicio y la empresa

Entonces, ¿qué partes deberían abrirse y cuáles cerrarse? El valor empresarial se determina aproximadamente por "crecimiento del mercado/ventas × capacidad defensible de ganancias (moat) × eficiencia de capital del crecimiento", y la estrategia de publicación afecta a estos tres aspectos.

Hay un único principio que sirve como punto de partida para la decisión: "Cierren lo que su empresa vende (bienes sustitutos) y abran lo que promueve su uso (bienes complementarios)". Cuanto más gratuito y económico sea un bien complementario, mayor será la demanda del producto principal (fuente de ingresos de la empresa), por lo que deliberadamente se abre la capa "contigua" a la fuente de ingresos para expandir el mercado general y recuperar los beneficios con el producto principal. Este pensamiento, que los profesionales llaman "comoditización de bienes complementarios" (Spolsky, 2002), es la lógica detrás de la estructura de Google que abre Android de forma gratuita pero recupera ingresos a través de publicidad y aplicaciones. A continuación, concretamos este principio en "qué abrir y qué cerrar".

Lo que debe abrirse

Lo que genera adopción y estandarización sin amenazar la fuente de ingresos de la empresa debe abrirse. Esto incluye lo siguiente:

• Funcionalidad central y motor: Partes que muchas personas usan y que tienen sentido cuando se convierten en estándar.

  • Chromium (Google): Se abre el motor del navegador en sí. Se ha convertido en la base común de Chrome, Edge y Brave, capturando el liderazgo en estándares web.

  • GitLab Community Edition: Un conjunto completo de gestión de Git y CI/CD se puede instalar de forma gratuita en el servidor propio de la empresa.

  • PostgreSQL / Elasticsearch / Docker Engine: "Motores estándar" para bases de datos, búsqueda y contenedores.

  • PyTorch (Meta): Se convierte en base común para aprendizaje automático, adquiriendo investigadores e ingenieros y retroalimentando la capacidad de desarrollo de IA de la propia empresa.

• Formatos de archivo, protocolos y especificaciones de API: Las herramientas de otros fabricantes vienen a conectarse a su empresa.

  • PDF (Adobe): La especificación se publicó e se estandarizó como ISO. Hacerlo un formato que todos pueden leer lo convirtió en el estándar de facto para documentos.

  • S3 API (Amazon): La especificación de la API de almacenamiento se convirtió en el estándar de facto, creando una situación donde las empresas competidoras se promocionan como "compatibles con S3".

  • Especificación de OpenAI API: Muchos LLM implementan "compatibilidad con OpenAI API" hasta el punto de estar estandarizado.

  • IFC: Estándar internacional de BIM.

• SDK, conectores y partes de integración: Bienes complementarios. Cuantos más haya, más se utiliza el producto principal.

  • SDK de Stripe: Bibliotecas en varios lenguajes que permiten integrar pagos con solo unas pocas líneas de código se publican de forma gratuita, adquiriendo desarrolladores de inmediato.

  • SDK y API de Slack / Twilio: Se amplía el ecosistema proporcionando bibliotecas oficiales que permiten conectar aplicaciones externas.

  • Proveedores de Terraform: Los conectores de conexión con cada nube se abren, y cuantas más opciones se soportan, mayor es el valor del producto principal.

• Funcionalidad básica para individuos y desarrolladores: Se amplía la base de usuarios gratuitamente como entrada.

  • Planes gratuitos de GitHub / Notion / Figma / Slack: Gratuito para individuos, se cobra por funcionalidad de equipos y empresas (freemium).

  • Docker Desktop: Gratuito para individuos y pequeñas empresas, de pago para empresas de cierto tamaño.

  • Versión académica gratuita de Gurobi: Las personas que se familiarizaron con ella como estudiantes se convierten en impulsores de adopción de licencias oficiales en sus empresas empleadoras.

Los beneficios incluyen lo siguiente:

• Reducción dramática del costo de adquisición de clientes: Como los desarrolladores implementan y propagan la solución sin intervención de ventas, el mismo crecimiento se logra a menor costo, mejorando la eficiencia de capital (la fuente de las altas valoraciones de acciones de empresas de núcleo abierto como GitLab, HashiCorp y Confluent).

• Construcción de moat mediante estandarización de facto y efectos de red: Un tipo de barrera de entrada que no se puede crear con código cerrado (Kubernetes, Linux).

• Eliminación de la preocupación por bloqueo de proveedor: La resolución de la preocupación de quedar bloqueado con un proveedor específico reduce la barrera de adopción para grandes empresas y el sector público.

• Marca de empleo y apalancamiento de I+D mediante contribución externa: La investigación empírica demuestra que las empresas que no solo "usan" OSS sino que también "contribuyen" a ellos extraen una mayor productividad del OSS (Nagle, 2018, 2019).

Lo que debe cerrarse

La fuente misma de los ingresos y el núcleo de la ventaja competitiva deben cerrarse. Esto incluye lo siguiente:

• La propia fuente de ingresos (versión de operación administrada/alojamiento): Si el negocio principal es vender la comodidad operativa, esta parte no se abre.

  • GitLab.com / MongoDB Atlas / Databricks: Aunque el software en sí está abierto, el "servicio que gestiona la operación" es completamente propiedad exclusiva de la empresa. El pilar de ingresos de MongoDB es Atlas, que no se permite que sea reproducido por nadie.

  • WordPress.com (Automattic): El cuerpo principal puede ser autoalojado gratuitamente por cualquiera, pero el negocio de alojamiento y mantenimiento está cerrado.

  • Suscripción a Red Hat Enterprise Linux: Aunque Linux en sí está bajo GPL, la empresa cobra por el "paquete operativo" de compilaciones certificadas, soporte a largo plazo y garantía.

• Funcionalidad orientada a organizaciones y empresas (SSO, gestión de permisos, registros de auditoría, cumplimiento, soporte/SLA): Aunque técnicamente es simple, estas son las características que buscan quienes "pueden pagar". Se cobra aquí.

  • GitLab Enterprise Edition: SAML/SSO, gestión de permisos detallada, registros de auditoría y funcionalidades de cumplimiento están limitados a la versión de pago. Este es el libro de texto de cómo hacer la "demarcación" en el modelo de núcleo abierto.

  • Mattermost / Sentry: El núcleo está abierto, SSO, permisos avanzados y funciones de auditoría son de versión empresarial. Esta práctica es tan común en la industria que se conoce como el "impuesto SSO" (incluso existe un sitio web llamado sso.tax que publica una lista de precios de SSO de empresas).

  • Grafana Enterprise: El cuerpo principal está abierto bajo AGPL, se cobra por conexiones de fuentes de datos orientadas a empresas, reportes y SLA de soporte.

• Lógica nuclear donde la ventaja competitiva se encuentra en el código mismo: Partes donde la publicación haría que la imitación fuera directamente posible.

  • Algoritmo de clasificación de búsqueda de Google: Aunque abre Chromium y Android, no publica nada sobre la lógica de decisión del ranking de búsqueda, que es el núcleo del negocio principal.

  • Motor de recomendación de Netflix: Ha convertido en OSS numerosas herramientas de infraestructura (Chaos Monkey, etc.), pero el núcleo de la recomendación de visualización no se publica.

  • Algoritmo de trading de empresas de comercio de alta frecuencia (HFT): La publicación significa la pérdida inmediata de la ventaja, por lo que se guarda en secreto completo.

• Datos propios, modelos entrenados, conocimientos operativos y base de clientes: "Activos complementarios" difíciles de imitar.

  • OpenAI / Anthropic de los modelos fronterizos los pesos y datos de entrenamiento: se abre el acceso mediante API, pero el modelo en sí y la canalización de aprendizaje permanecen confidenciales (combinación de niveles 8+9).

  • Datos de mapas y tráfico de Google Maps: la API se abre, pero el activo de datos acumulado durante 20 años nunca se entrega a nadie.

  • Datos de compra y base de reseñas de Amazon: activos complementarios más difíciles de imitar, reforzados por efectos de red.

  • Datos financieros de Bloomberg y red de usuarios de terminales: la combinación de datos + base de clientes no se alcanza por la imitación de funciones.

Lista de verificación de decisión abierto-cerrado

Por cada función individual, puede juzgarse aplicando las siguientes 5 preguntas.

1. Prueba de defensa: ¿Es la fuente de nuestra ventaja competitiva? → Cerrado

2. Prueba de difusión: ¿Se aumentan usuarios y socios con la publicación? → Abierto

3. Prueba de responsabilidad: ¿Crean errores responsabilidad legal o profesional? → Cerrado

4. Prueba del comprador: ¿Es una función que demanda quien paga (SSO, registros de auditoría, soporte, SLA)? → Cerrado

5. Prueba de reventa: ¿Si se publica, pueden competidores o gigantes de la nube revenderlo tal cual? → Cerrado (o proteger con licencias defensivas como AGPL/BSL)

El principio es: cerrar si corresponde a defensa, responsabilidad, comprador o reventa; abrir si corresponde solo a difusión.

¿Cuán óptimo es para la sociedad abrir la tecnología?

Hasta aquí hemos analizado cuánto debería abrirse la tecnología para maximizar el valor empresarial. Entonces, ¿debería la tecnología estar abierta o cerrada para el conjunto de la sociedad?

En conclusión, la solución óptima para la sociedad tampoco es completamente abierta ni completamente cerrada, sino una mezcla deliberadamente gestionada que reconoce el cierre temporal y finalmente regresa a la apertura. Cuando este marco funciona correctamente, la maximización de ganancias empresariales coincide con la maximización de beneficios sociales.

• El precio ideal del conocimiento es "cero", pero entonces nadie lo produce: el conocimiento y la tecnología tienen la naturaleza de "bien público" que puede ser utilizado por cualquier número de personas con costo marginal casi cero una vez creados (Arrow, 1962). Desde esta perspectiva, lo socialmente óptimo sería completamente abierto y gratuito para todos. Sin embargo, eso impide que los desarrolladores recuperen sus inversiones, lo que detiene la innovación en primer lugar. Existe un conflicto estructural entre "hacer que la tecnología creada se use al máximo (eficiencia estática)" y "preservar el incentivo para crear la próxima tecnología (eficiencia dinámica)" (Nordhaus, 1969).

• El sistema de patentes es un "intercambio" de la sociedad frente a este dilema: la sociedad resuelve este dilema mediante el acuerdo de que "se concede monopolio solo por un período limitado, a cambio de divulgar completamente el contenido técnico, de modo que cualquiera pueda usarlo después del vencimiento del período". Este es el sistema de patentes. El período de protección de aproximadamente 20 años fue diseñado como el punto de equilibrio entre los daños del monopolio y los incentivos para la innovación. La ley antimonopolio actúa como mecanismo corrector cuando este equilibrio se desvía demasiado hacia el "monopolio perpetuo de una sola empresa". En otras palabras, entre los 9 niveles sistematizados en este artículo, la sociedad ha establecido institucional el "Nivel 7 (divulgación con monopolio temporal)" como punto de compromiso fundamental.

• La "maximización de ganancias = óptimo social" no se cumple automáticamente: este mecanismo es solo una "solución de segundo orden", y sin intervención, las decisiones empresariales se desvían del óptimo social en dos direcciones. Primero, las empresas no abren suficientemente. Muchos de los beneficios de publicar tecnología (efectos de derrame del conocimiento) no son recuperables por la empresa que publica, por lo que la cantidad de apertura que las empresas eligen voluntariamente es sistemáticamente menor que el nivel deseable socialmente. Segundo, los monopolios no desaparecen. El supuesto clásico de que "la tecnología se vuelve obsoleta y las ganancias desaparecen por competencia" no se sostiene en mercados digitales donde funcionan efectos de red y bucles de auto-refuerzo de datos; en cambio, ocurre "ganador se lleva todo" donde la ventaja se refuerza con el tiempo.

• La propiedad intelectual no necesariamente es mejor cuanto más fuerte sea: si la protección es demasiado fuerte, produce el efecto contrario. La tecnología es acumulativa, construida sobre logros previos, así que otorgar derechos excesivamente fuertes al inventor inicial bloquea la innovación siguiente que se basa en eso (Scotchmer, 1991). La relación entre innovación y fortaleza de la propiedad intelectual no es monotónica sino que tiene un punto óptimo, cuya ubicación varía según la industria (el contraste entre la industria farmacéutica donde funcionan patentes fuertes y software donde las patentes pueden ser inhibidoras es típico).

• La sociedad diferencia el grado de apertura según el dominio: el diseño de la sociedad en su conjunto puede resumirse así: la investigación básica con grandes efectos de derrame del conocimiento y difícil de apropiar se suministra casi completamente abierta mediante financiamiento público y publicación de artículos. El desarrollo comercial que requiere inversión sin posibilidad de apropiación reconoce cierre temporal y parcial mediante patentes y secretos comerciales. Y cuando el monopolio tiende a fijarse, se tira hacia la apertura mediante ley antimonopolio, obligaciones de divulgación y límites de patentes, y promoción de estándares e interoperabilidad.

• La ganancia no es el único incentivo para la innovación: finalmente, no es cierto que "la ganancia del monopolio sea la única fuente de innovación". Como demuestran el software de código abierto y la ciencia abierta, tanto teoría como evidencia muestran que la contribución a bienes públicos y beneficios privados (aprendizaje, reputación, carrera, mejora de productos propios) pueden coexistir (von Hippel & von Krogh, 2003; Nagle, 2018), y bases como Linux y OpenSSL se han creado sin depender de ganancias de monopolio. La sociedad suministra innovación combinando "incentivos por ganancia" e "incentivos de otro tipo (deseo de usar, honor, reputación, misión, motivación de aprendizaje, etc.)".

Tendencias en la investigación académica más reciente

La investigación sobre estrategias de publicación de tecnología avanza en 4 direcciones principales.

Cuantificación del valor económico de OSS

• El valor del lado de la demanda se estimó en 8.8 billones de dólares: el equipo de investigación de Harvard Business School estimó el valor del lado de la oferta (costo de recreación) de OSS ampliamente usado en 4,150 millones de dólares, y el valor del lado de la demanda (gasto que las empresas requieren en desarrollo alternativo) en 8.8 billones de dólares. Sin OSS, el gasto de software empresarial requeriría 3.5 veces más que el actual. Además, el 96% del valor del lado de la demanda se genera por solo el 5% de los desarrolladores, revelando extrema asimetría en la creación de valor (Hoffmann et al., 2024).

• La sostenibilidad como bien público se convirtió en una cuestión de política: después de OpenSSL/Heartbleed, avanzó la investigación sobre "¿quién sostiene los OSS de base en los que depende toda industria?", y el diseño de mecanismos de financiamiento por empresas y gobiernos (como Sovereign Tech Fund) se discute en práctica y política (Eghbal, 2020).

Estrategias de ingresos y consecuencias de cambios de licencia

• Avanzó investigación empírica sobre cambios de licencia y bifurcaciones: en análisis de estructura comunitaria después de bifurcaciones (Terraform→OpenTofu, Redis→Valkey, Elasticsearch→OpenSearch) entre 2023-2025, la investigación mostró que bifurcaciones creadas bajo fundaciones neutrales (Linux Foundation, etc.) adquieren bases de contribuyentes con mayor diversidad organizativa que el proyecto original (arXiv:2411.04739, 2024). Esto es respaldo cuantitativo del riesgo de gobernanza de proyectos bajo control de una sola empresa.

• Polisemia de "abierto" y teoría de apertura parcial: West (2003) teorizó que empresas de plataforma adoptan estrategias híbridas "parcialmente abiertas" entre apertura total y monopolio completo, y Dahlander & Gann (2010) sistematizaron "apertura" en innovación abierta en 4 tipos según dirección (interna/externa) y monetariedad (pago/sin pago). La reciente aparición de BSL/SSPL puede entenderse como fenómeno en que el espacio de diseño de "apertura parcial" se subdivide aún más mediante invención de licencias.

Conducta contributiva de empresas y productividad

• Las empresas que "contribuyen" ganan más que las que solo "usan": Nagle (2019) demostró que entre empresas que utilizan OSS, aquellas que contribuyen código obtienen mayor mejora de productividad del mismo OSS que las que no contribuyen (learning by contributing). Este descubrimiento de que la contribución a un bien público sin costo produce retorno privado respalda a nivel empresarial el "modelo de innovación privada y colectiva" (von Hippel & von Krogh, 2003) que propone que la contribución a bienes públicos y la adquisición de beneficio privado son compatibles.

• Relación entre apertura de plataforma e innovación: Boudreau (2010) descompone apertura de plataforma en "otorgar acceso" y "delegar control", mostrando que la apertura de acceso aumenta mucho la innovación, pero el efecto cuando se delega control es limitado. No solo "cuánto abrir" sino "qué abrir (acceso o autoridad)" determina los resultados.

Nuevas cuestiones en la era de la IA

• Emergencia de nueva categoría: "open weight": en modelos de IA, surge "open weight" que mantiene código de entrenamiento y datos confidenciales pero publica condicionalmente los pesos del modelo, generando investigación rápida como forma intermedia que no encaja en la definición tradicional de OSS. La dicotomía de código fuente (abierto/cerrado) se reemplaza por diseño de apertura multinivel de datos, pesos, código y API.

• Uso de AI para entrenamiento está rediseñando licencias: las controversias de derechos de autor sobre uso de código y contenido públicos para entrenar IA se convirtieron en motivo nuevo de cambios de licencia desde 2024, y se debaten en derecho y economía la legitimidad del nuevo diseño de condiciones: "abierto para humanos, cerrado para aprendizaje de IA".

Conclusión

Sistematizamos abierto vs. cerrado en 9 niveles y aclaramos las formas de pensar apropiadas para empresas y sociedad. En conclusión, para maximizar el valor empresarial, la solución no es completamente abierta ni completamente cerrada, sino apertura selectiva (tipo open core): "abrir las capas que generan difusión y estándares, cerrar las fuentes de ingresos, y proteger las capas abiertas con licencias defensivas contra reventa".

La solución óptima para la sociedad tampoco es una ni otra, sino una mezcla deliberadamente gestionada que reconoce cierre temporal y finalmente regresa a la apertura. Cuando este marco funciona, la maximización de ganancias empresariales puede alinearse con la maximización de beneficios sociales.

Referencias

• Arora, A., Fosfuri, A., & Gambardella, A. (2001). Markets for technology: The economics of innovation and corporate strategy. MIT Press. (Obra que sistematiza las condiciones de establecimiento del "mercado de tecnología" mediante patentes y licencias, y el impacto de divulgación y transacción de tecnología en la estrategia corporativa)

• arXiv:2411.04739. (2024). The new dynamics of open source: Relicensing, forks, & community impact.（Estudio empírico dirigido a tres casos de Terraform/OpenTofu, Redis/Valkey y Elasticsearch/OpenSearch que demuestra que las bifurcaciones posteriores a los cambios de licencia forman comunidades con mayor diversidad organizativa que los proyectos originales）

• Boudreau, K. (2010). Open platform strategies and innovation: Granting access vs. devolving control. Management Science, 56(10), 1849-1872.（Documento que descompone la apertura de plataformas en "otorgamiento de acceso" y "transferencia de control", demostrando empíricamente las diferencias en sus efectos sobre la innovación）

• Casadesus-Masanell, R., & Ghemawat, P. (2006). Dynamic mixed duopoly: A model motivated by Linux vs. Windows. Management Science, 52(7), 1072-1084.（Investigación teórica que construye un modelo dinámico de mercado donde coexisten OSS sin costo y software comercial, analizando el equilibrio de la competencia mixta）

• Chesbrough, H. (2003). Open innovation: The new imperative for creating and profiting from technology. Harvard Business School Press.（Obra que propone el concepto de "innovación abierta", en la cual el conocimiento fluye hacia adentro y hacia afuera atravesando los límites de la empresa）

• Cusumano, M. A., Mylonadis, Y., & Rosenbloom, R. S. (1992). Strategic maneuvering and mass-market dynamics: The triumph of VHS over Beta. Business History Review, 66(1), 51-94.（Estudio de caso clásico que analiza la competencia de estándares entre VHS y Betamax, demostrando que la licencia abierta y la formación de alianzas, no la superioridad técnica, determinaron el ganador）

• Dahlander, L., & Gann, D. M. (2010). How open is innovation? Research Policy, 39(6), 699-709.（Documento que clasifica la "apertura" en innovación en cuatro tipos basándose en dos ejes: dirección y monetización, revisando las ventajas y costos de cada forma）

• Eghbal, N. (2020). Working in public: The making and maintenance of open source software. Stripe Press.（Investigación práctica que analiza la realidad de la creación y mantenimiento de OSS, identificando la dependencia de pocos mantenedores y los desafíos de sostenibilidad）

• Hoffmann, M., Nagle, F., & Zhou, Y. (2024). The value of open source software. Harvard Business School Working Paper 24-038.（Documento que estima el valor en el lado de la oferta del OSS ampliamente utilizado en $4.15 mil millones y el valor en el lado de la demanda en $8.8 billones, mostrando que el 96% del valor procede del 5% de los desarrolladores）

• Lerner, J., & Tirole, J. (2002). Some simple economics of open source. Journal of Industrial Economics, 50(2), 197-234.（Literatura fundamental que explica por qué los desarrolladores contribuyen sin costo a OSS mediante la economía de señalización y desarrollo de carrera）

• Nagle, F. (2018). Learning by contributing: Gaining competitive advantage through contribution to crowdsourced public goods. Organization Science, 29(4), 569-587.（Documento que demuestra empíricamente el mecanismo por el cual la contribución a bienes públicos (OSS) genera ventaja competitiva para la empresa contribuyente）

• Nagle, F. (2019). Open source software and firm productivity. Management Science, 65(3), 1191-1215.（Estudio empírico que relaciona el uso y la contribución a OSS con la productividad empresarial, mostrando que las empresas contribuyentes obtienen mayores retornos）

• Spolsky, J. (2002). Strategy letter V. Joel on Software.（Reflexión de un profesional que formula de manera clara la estrategia de bienes complementarios: "las empresas inteligentes commoditizan los bienes complementarios de sus productos"）

• Teece, D. J. (1986). Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy. Research Policy, 15(6), 285-305.（Una de las obras más importantes en teoría de estrategia tecnológica, que muestra las condiciones bajo las cuales los beneficios de la innovación fluyen hacia los poseedores de activos complementarios, no hacia los inventores）

• von Hippel, E., & von Krogh, G. (2003). Open source software and the "private-collective" innovation model: Issues for organization science. Organization Science, 14(2), 209-223.（Documento que presenta el "modelo de innovación privada-colectiva", en el cual la contribución a bienes públicos y la captura de beneficios privados pueden coexistir）

• West, J. (2003). How open is open enough? Melding proprietary and open source platform strategies. Research Policy, 32(7), 1259-1285.（Documento que analiza las condiciones bajo las cuales las empresas de plataforma adoptan estrategias híbridas de "apertura parcial" entre el monopolio y la apertura completa）