10.18 Oficina de programa de código abierto (OSPO) y contribución ascendente

Presentación y motivación

Tu organización ya funciona con software de código abierto: los sistemas operativos, lenguajes, bases de datos, y bibliotecas que cargan tu producto están mayormente escritos por gente que no trabaja para ti. El capítulo 10.3 cubre la adquisición y el cumplimiento de licencias, y el capítulo 10.12 cubre la decisión de abierto frente a cerrado. Este capítulo trata de la función que hace coherente todo eso: una oficina de programa de código abierto (OSPO), el equipo que posee cómo la empresa consume, contribuye a, y libera código abierto. Una OSPO es el centro de gravedad para una relación que de otro modo está dispersa a través de cada ingeniero que escribe import.

La mayoría de las organizaciones llegan al código abierto una dependencia a la vez, y luego descubren la exposición acumulada toda de golpe: una pregunta de licencia durante la debida diligencia de una adquisición, una biblioteca crítica con un mantenedor agotado, un aviso de seguridad en código que nadie sabía que enviaba. Una OSPO convierte esa carrera en una capacidad gestionada. Establece la política de consumo que habilita en lugar de bloquear, decide cuándo contribuir hacia arriba sirve al negocio, administra los proyectos que liberas, y aplica la colaboración abierta dentro de la empresa a través de InnerSource. Esta es una función estratégica, conectada a tus valores de ingeniería de software (capítulo 1.1), no una casilla de cumplimiento.

Para las empresas el impulsor es la escala: miles de dependencias, obligaciones de exportación y licencia a través de jurisdicciones, y cientos de ingenieros que cada uno toma pequeñas decisiones de código abierto diariamente. Una sola oficina le da a esa expansión una columna vertebral. Para el gobierno el impulsor es la política y la confianza pública. “Código abierto por defecto” y “dinero público, código público” son cada vez más ley, así que los organismos públicos necesitan a alguien que pueda publicar código de manera segura, reutilizar entre agencias, y sostener a los proveedores a estándares abiertos. En ambos entornos la OSPO se paga a sí misma convirtiendo el riesgo invisible y sin precio en trabajo deliberado y presupuestado.

Principios fundamentales

El código abierto es una relación de doble vía, no un almacén gratuito. Consumes, contribuyes, y liberas, y una OSPO posee las tres.
La contribución es estrategia, no caridad. Contribuir hacia arriba reduce el costo de cargar parches privados y te compra influencia.
Habilita el camino rápido, no vigiles la puerta. Una política más lenta que copiar código será ignorada, así que haz que el camino conforme sea el más rápido.
Financia a los mantenedores de los que dependes. El patrimonio común no se autosostiene, y tu biblioteca más crítica puede tener un solo autor sin pagar.
Administra lo que liberas, o no lo liberes. Un proyecto abandonado daña tu reputación más de lo que ningún proyecto lo haría.
Mide el compromiso para poder mejorarlo. Cuenta contribuciones, salud de dependencias, y tiempo de aprobación, no comunicados de prensa.
En el gobierno, por defecto abierto y publica por defecto. La apertura es la norma; el cierre es la excepción documentada.

Recomendaciones

Levanta una OSPO dimensionada a tu realidad

No necesitas un equipo grande para empezar. En una startup una OSPO puede ser un ingeniero con un mandato escrito y unas cuantas horas a la semana. En una empresa es un pequeño grupo central más una red federada de campeones incrustados en equipos de producto. Cualquiera que sea el tamaño, dale una carta clara cubriendo cuatro responsabilidades: política de consumo y cumplimiento, contribución ascendente, liberar y administrar tus propios proyectos, y relaciones de comunidad y financiamiento. Colócala donde pueda ver tanto la ingeniería como lo legal, a menudo reportando al CTO o a un VP de ingeniería con una línea punteada a legal y seguridad. El modo de fallo es una OSPO que vive completamente dentro de legal y se convierte en un freno; la solución es dotarla de ingenieros que entregan, para que su guía lleve credibilidad en los equipos a los que sirve.

Consume responsablemente, y haz que el camino seguro sea el camino fácil

El consumo es donde entra la mayor parte del riesgo, así que haz que el buen comportamiento sea sin esfuerzo. Provee un catálogo interno curado de componentes previamente verificados, escaneo automatizado de licencias y vulnerabilidades en el pipeline, y valores predeterminados claros que un desarrollador puede seguir sin abrir un ticket. Apóyate en la disciplina de licencias del capítulo 10.3 y las prácticas de cadena de suministro y salud de dependencias del capítulo 2.18: fija versiones, genera una lista de materiales de software, vigila la cadena de suministro de software por paquetes comprometidos o abandonados, y rastrea el fin de vida antes de que fuerce una migración. El trabajo de la OSPO no es aprobar cada dependencia a mano. Es construir las barandas para que el noventa y cinco por ciento de las elecciones sean seguras automáticamente y solo los casos genuinamente inusuales lleguen a un humano.

Contribuye hacia arriba porque paga, no porque es agradable

Trata la contribución ascendente como una decisión económica. Cada parche privado que cargas contra una dependencia es un impuesto que pagas en cada actualización, para siempre, hasta que el cambio aterrice río arriba o la bifurcación diverja tanto que la poseas por completo. Contribuir la corrección de vuelta elimina ese impuesto. Contribuir hacia arriba también compra influencia sobre la dirección, así que la hoja de ruta de un componente del que dependes se dobla hacia tus necesidades, y señala competencia a los ingenieros que quieres contratar. Dale a tus desarrolladores un camino rápido y documentado: un acuerdo de licencia de colaborador o certificado de origen del desarrollador previamente aprobado, una aprobación ligera que confirme que el cambio es seguro de compartir, y tiempo de gestión presupuestado para el trabajo. Cuando la alternativa es mantener una bifurcación permanente de un proyecto que no controlas, contribuir de vuelta casi siempre es más barato.

Libera tus propios proyectos con gobernanza real

Cuando liberas como código abierto software que construiste, hazlo deliberadamente o no lo hagas en absoluto. Decide primero si el código es una mercancía que vale la pena compartir o un diferenciador que vale la pena mantener cerrado, usando el razonamiento del capítulo 10.12. Si liberas, elige una licencia que coincida con tu intención (permisiva para maximizar la adopción, copyleft para mantener el ecosistema recíproco), documenta quién decide qué mediante un modelo de gobernanza escrito, y registra la marca en el nombre del proyecto para poder protegerlo del mal uso mientras mantienes el código libre. Comprométete con una administración real: un rastreador de incidencias público, una guía de contribución, un código de conducta, y una política de seguridad con divulgación coordinada para que los reportadores sepan cómo contactarte (capítulo 4.2). Nombra a un mantenedor y presupuesta su tiempo. Un proyecto que lanzas con fanfarria y abandonas en un año hace más daño a tu reputación que uno que nunca enviaste.

Aplica InnerSource para colaborar dentro de la empresa

Los hábitos que hacen funcionar el código abierto (repositorios públicos, guías de contribución claras, revisión por mérito, barreras bajas para un primer parche) funcionan igual de bien detrás del cortafuegos. InnerSource significa que cualquier ingeniero puede encontrar, usar, y mejorar cualquier proyecto interno, enviando una solicitud de extracción a través de los límites de equipo en lugar de abrir un ticket y esperar. Esto rompe los silos, propaga la reutilización de código, y entrena a tu gente en el flujo de trabajo exacto que usarán cuando contribuyan externamente. La OSPO es el hogar natural para InnerSource porque ya posee las herramientas y el manual cultural. Empieza con unas cuantas bibliotecas compartidas de alto valor, publica sus guías de contribución internamente, y premia a los equipos que aceptan parches externos con gracia.

Financia y sostén a los mantenedores de los que dependes

Tu sistema de producción puede descansar en una biblioteca mantenida por una persona en su tiempo libre. Eso es un riesgo de cadena de suministro, y la respuesta honesta es ayudar a cargar el peso. Identifica tus dependencias más críticas a partir de tu lista de materiales, encuentra las que tienen una base de mantenedores delgada, y elige una respuesta para cada una: patrocina directamente al mantenedor, contribuye tiempo de ingeniería, únete a una fundación que financie el proyecto, o, como último recurso, prepárate para bifurcar o reemplazar. Financiar el patrimonio común es más barato que la emergencia que sigue a su colapso, y mantiene sanos los componentes de los que dependes y moviéndose en una dirección que puedes influenciar.

Establece una política de contribución que aprueba rápido

Una política de contribución existe para decir sí rápidamente, no para decir no lentamente. Especifica qué puede contribuir un ingeniero sin preguntar (correcciones de errores, documentación, características pequeñas a proyectos que ya usas), qué necesita una verificación ligera (cualquier cosa que toque un diferenciador o una patente), y cómo se manejan la propiedad intelectual y los acuerdos de colaborador una vez, centralmente, en lugar de por contribución. Automatiza las partes aburridas: verificaciones de licencia, un acuerdo de colaborador corporativo pre-firmado, y un bot que marca la rara presentación que necesita ojos humanos. Mide el tiempo de aprobación y trata una cola lenta como un error en la política.

Ventajas y desventajas

Enfoque	Ventajas	Desventajas
OSPO central	Política consistente, experiencia profunda, propiedad clara	Puede convertirse en un cuello de botella si solo vigila y nunca habilita
OSPO federada (campeones en equipos)	Escala, mantiene las decisiones cerca de los ingenieros	Necesita coordinación fuerte o la política se desvía
Contribuir hacia arriba	Elimina el impuesto de parches privados, compra influencia, ayuda al reclutamiento	Esfuerzo continuo, revisión de propiedad intelectual, trabajo en el calendario de alguien más
Cargar bifurcaciones privadas	Control total, entrega en tu propio calendario	Impuesto de mantenimiento permanente, se desvía de las correcciones de seguridad río arriba
Liberar tu propio proyecto	Ecosistema, reputación, mantenimiento compartido	Costo real de administración; el abandono daña la reputación
Financiar mantenedores	Protege dependencias críticas, compra buena voluntad	Costo directo, y elegir a quién financiar es político
Sin OSPO (improvisado)	Costo de configuración cero	Deuda legal, de seguridad, y de sostenibilidad invisible

La tensión central es entre control y habilitación. Una OSPO que revisa cada dependencia y cada contribución a mano se siente segura, pero se convierte en lo que los ingenieros rodean, lo que produce las dependencias fantasma invisibles que intentabas prevenir. Una OSPO que solo publica guías alegres sin ninguna aplicación automatizada se ignora en el momento en que se acerca una fecha límite. La resolución es la misma que recorre el capítulo 10.3: automatiza el caso común para que el camino conforme sea el camino más rápido, y reserva el juicio humano para lo genuinamente novedoso. Acierta ese equilibrio y la oficina es un multiplicador de fuerza; falla en cualquier dirección y es o un freno o una decoración.

Preguntas para discutir con tu equipo

¿Quién posee tu relación con el código abierto hoy, y podría responder una pregunta difícil mañana? Si los abogados de un posible adquirente pidieran tu inventario de licencias, o un reportero preguntara qué biblioteca no mantenida está en tu camino de pagos, ¿hay un nombre adjunto a la respuesta? Para la mayoría de las organizaciones la respuesta honesta es “nadie”, lo que significa que cada ingeniero está haciendo política silenciosamente y nadie es responsable de la suma. Trae la evidencia a la reunión: intenta producir la lista de licencias aprobadas, la lista de materiales de software, y la persona que respondería una pregunta de copyleft durante la debida diligencia. Si esos artefactos no existen o apuntan a nadie, has encontrado tu primera tarea de OSPO. La decisión a tomar no es si tener la función sino quién la posee y qué mandato lleva, incluso si la oficina es una persona por un día a la semana.
¿Estás cargando parches privados que podrías contribuir hacia arriba, y qué te está costando eso? Muchos equipos mantienen una pila silenciosa de modificaciones locales contra sus dependencias, reaplicándolas a mano en cada actualización y absorbiendo el dolor de fusión como si fuera una ley de la naturaleza. Cada uno de esos parches es un impuesto recurrente, y cada uno es candidato a contribuirse de vuelta para que el impuesto desaparezca. Trae los detalles: lista las bifurcaciones y parches locales que tu construcción realmente carga, estima las horas de ingeniería que cada una cuesta al año, y anota qué proyectos río arriba probablemente aceptarían el cambio. La consideración en competencia es real, ya que contribuir hacia arriba toma esfuerzo ahora y funciona en el calendario del mantenedor, pero la comparación es contra pagar el impuesto del parche para siempre. La respuesta debería convertir “siempre simplemente lo reaplicamos” en una elección deliberada, con un camino de contribución lo suficientemente rápido para que los ingenieros lo usen.
¿Qué dependencia dolería más si su mantenedor se fuera, y qué harás al respecto? En algún lugar de tu pila hay un componente que detendría un servicio crítico para los ingresos o la misión si se rompiera, mantenido por una persona o un puñado de personas a las que nunca has financiado o agradecido. El patrimonio común se siente gratis hasta el momento en que no lo es, y la versión costosa de esa lección es una carrera después del abandono o una vulnerabilidad sin parchear. Trae tu lista de materiales y clasifica las dependencias por radio de explosión, luego anota el número de mantenedores y el estado de financiamiento de las principales. Para cada una crítica y con poco personal, decide de antemano si patrocinarás, contribuirás tiempo, te unirás a una fundación, o te prepararás para reemplazar. Eso convierte un punto único de fallo latente en una relación gestionada, sostenida al mismo estándar que cualquier otro riesgo operativo (capítulo 2.18).
Antes de liberar como código abierto la próxima herramienta interna, ¿estás listo para administrarla durante años, o estás enviando un lanzamiento y una eventual disculpa? Una liberación pública es un compromiso permanente: un rastreador de incidencias que alguien debe clasificar, una bandeja de seguridad que alguien debe vigilar, y un nombre que alguien debe defender. Los equipos recurren a liberar código abierto para ayudar al reclutamiento o la buena voluntad, y luego descubren que un proyecto abandonado con incidencias obsoletas daña la reputación que esperaban construir, más de lo que lo haría no enviar nada. Trae la evidencia: lista los proyectos que ya has liberado, y para cada uno muestra la antigüedad de sus incidencias abiertas, si un mantenedor nombrado tiene horas presupuestadas, si tiene un modelo de gobernanza, una marca registrada, y una política de divulgación coordinada, y si el código es una mercancía que vale la pena compartir o un diferenciador que deberías mantener cerrado (capítulo 10.12). La consideración en competencia es que la administración real cuesta tiempo de ingeniería que podrías gastar en el producto, así que la elección honesta a menudo es liberar menos cosas y administrarlas apropiadamente. Para una empresa esto significa revisión legal y de marca antes del lanzamiento; para el gobierno significa que la marca, el canal de divulgación, y el proceso de excepción de publicar-por-defecto se resuelvan antes de que el repositorio se haga público.
¿Cuánto tiempo realmente toma que a un ingeniero se le apruebe una dependencia o se le libere una contribución, y eso es más lento que rodearte? Una política de código abierto compite directamente con el camino de solución más rápido que un ingeniero pueda encontrar, y cualquier proceso más lento que copiar el código se evade, produciendo las dependencias fantasma invisibles que la oficina pretendía prevenir. La tensión es control contra habilitación: cada revisión manual agrega un rastro de auditoría y captura el raro problema genuino, pero también agrega latencia que empuja el caso mediano fuera del camino conforme. Trae los números a la reunión: el tiempo de aprobación medido para una dependencia estándar y una contribución estándar, la proporción de decisiones manejadas automáticamente frente a por un humano, y el conteo de excepciones que genuinamente necesitaron juicio el trimestre pasado. En una empresa con cientos de ingenieros cada uno tomando pequeñas decisiones diariamente, una cola de dos días silenciosamente se convierte en miles de revisiones evadidas; en el gobierno, la misma latencia choca con las obligaciones de adquisición y auditoría que requieren el rastro documental que la solución alternativa se salta, así que la solución es automatizar el caso común en lugar de dotar de personal a una puerta más grande.
¿Qué proyectos internos se beneficiarían más de InnerSource, y qué le impide a otro equipo enviarte una solicitud de extracción hoy? Las prácticas que hacen funcionar el código abierto (repositorios públicos, guías de contribución, revisión por mérito, una barrera baja para un primer parche) rinden frutos detrás del cortafuegos rompiendo silos, propagando la reutilización, y entrenando a la gente en el flujo de trabajo exacto que usarán para contribuir externamente. La consideración en competencia es que abrir un proyecto interno exige una guía de contribución, capacidad de revisión de sobra, y una decisión sobre qué código debe permanecer restringido por razones de seguridad o regulatorias. Trae los detalles: nombra las bibliotecas compartidas de alto valor, anota cuáles ya publican una guía de contribución interna, y describe cómo se maneja hoy una solicitud de extracción entre equipos, si es bienvenida o se pierde en una cola. Para una empresa el beneficio se mide en construcciones internas duplicadas evitadas a través de muchos equipos; para el gobierno, el mismo hábito se extiende a través de los límites de agencia como reutilización entre agencias, para que publicar-por-defecto y los componentes compartidos reduzcan el gasto público duplicado en lugar de multiplicarlo.

Perspectiva sectorial

Startup. Dale la oficina a un ingeniero nombrado por unas cuantas horas a la semana con una carta de una página, no un comité. Por defecto usa licencias permisivas con un escáner en el pipeline, contribuye hacia arriba solo el puñado de parches privados que realmente duelen en cada actualización, y establece un pequeño patrocinio mensual para la biblioteca mantenida en solitario de la que genuinamente no puedes prescindir. La velocidad importa más que la cobertura aquí: un camino conforme más rápido que copiar código vence a una política exhaustiva que nadie sigue.

Pequeña empresa. No dotarás de personal a una OSPO dedicada, así que compra la capacidad incrustada en herramientas que ya usas: un escáner que marca problemas de licencia y vulnerabilidad, y un catálogo curado de componentes previamente verificados. Enmarca el trabajo como higiene de cumplimiento de licencias y salud de dependencias en lugar de un programa: conoce qué hay en tu lista de materiales de software, conoce qué obliga cada licencia, y conoce qué dependencia de un solo mantenedor dolería si desapareciera. Prefiere comprar el escaneo y catalogación en lugar de construir el tuyo.

Empresa. Ejecuta una pequeña oficina central más una red federada de campeones incrustados en equipos de producto, para que la política se mantenga consistente mientras las decisiones se mantienen cerca de los ingenieros. Automatiza el escaneo de licencia, vulnerabilidad, y exportación, cubre a cada ingeniero con un acuerdo de colaborador previamente aprobado, y rastrea el tiempo de aprobación como una métrica reportada. Financia las fundaciones detrás de tus dependencias críticas, ejecuta InnerSource a través de muchos repositorios, y gestiona todo el parque tecnológico como un portafolio con métricas de salud y compromiso en lugar de una dispersión de decisiones individuales.

Gobierno. Opera bajo código-abierto-por-defecto y dinero-público-código-público: publica servicios nuevos en un repositorio público a menos que aplique una excepción documentada de seguridad o privacidad. Ejecuta un catálogo entre agencias para que los equipos reutilicen antes de construir, escribe requisitos de código abierto y estándares abiertos en la adquisición para que los proveedores entreguen código reutilizable con derechos retenidos, y maneja la divulgación coordinada de lo que publicas. Financia el mantenimiento de bibliotecas compartidas de las que dependen varias agencias, para que ningún equipo individual posea silenciosamente infraestructura de la que depende todo el gobierno.

Ejemplos

Startup. Una startup de veinte personas hace que su ingeniero de plataforma líder sea el dueño a tiempo parcial de la OSPO con una carta de una página. Ella establece una política de consumo simple (licencias permisivas preaprobadas, copyleft revisado, escáner en el pipeline), y nota que el equipo carga tres parches privados contra una biblioteca de colas de código abierto, reaplicados dolorosamente en cada actualización. Los contribuye hacia arriba los tres; dos son aceptados dentro de un mes, eliminando el impuesto de actualización para siempre. Libera como código abierto una pequeña herramienta interna con un README real, una licencia, y un contacto de seguridad, principalmente para atraer ingenieros, y establece un patrocinio mensual para el analizador mantenido en solitario del que depende el producto. Nada de esto necesita personal adicional, solo un dueño nombrado y un mandato claro.

Empresa. Un banco global ejecuta una OSPO central de seis personas más una red federada de campeones de código abierto incrustados en cada grupo de producto. El equipo central posee la política, el escaneo automatizado de licencia y cumplimiento de exportación, y el acuerdo de licencia de colaborador que cubre a cada ingeniero desde el primer día. Los campeones manejan la revisión local y entrenan a sus equipos en la contribución. El banco financia varias fundaciones cuyos proyectos sustentan sus sistemas de negociación, contribuye correcciones río arriba a un marco de datos ampliamente usado para dejar de mantener una bifurcación, y ejecuta InnerSource a través de doscientos repositorios internos para que cualquier equipo pueda enviar una solicitud de extracción a cualquier otro. El tiempo de aprobación para una contribución estándar es menos de dos días, rastreado como una métrica que la OSPO reporta trimestralmente.

Gobierno. Una agencia digital nacional opera bajo un mandato de “código abierto por defecto” y dinero-público-código-público. Su OSPO publica servicios nuevos en un repositorio público a menos que aplique una excepción documentada por seguridad o privacidad, ejecuta un catálogo entre gobiernos para que las agencias reutilicen código antes de construirlo, y escribe requisitos de código abierto y estándares abiertos en la adquisición para que los proveedores entreguen código reutilizable y bien documentado con el gobierno reteniendo los derechos. La oficina también maneja la divulgación coordinada de seguridad para el código que publica y financia el mantenimiento de una biblioteca de identidad compartida de la que ahora dependen varias agencias, para que ningún equipo individual posea silenciosamente un componente del que depende todo el gobierno.

Caso de negocio: motivaciones, ROI y TCO

El retorno más claro es la eliminación de sorpresas evitables y costosas. El código abierto sin gestionar produce crisis que llegan en su propio calendario: una violación de copyleft que sale a la superficie durante la debida diligencia de una adquisición, una migración de emergencia fuera de un componente muerto, una brecha rastreada a una dependencia que ningún inventario listaba. Una OSPO convierte esos eventos de baja probabilidad y alto costo en trabajo constante y presupuestado. Agrega los ahorros recurrentes de contribuir hacia arriba: cada parche privado que retiras deja de gravar cada actualización futura, y a través de un parque tecnológico grande eso se compone en capacidad de ingeniería real devuelta al trabajo de producto.

En el libro mayor del costo total de propiedad, la oficina es barata en relación con lo que protege. Su costo es un equipo pequeño, algo de herramientas de escaneo y catalogación, y financiamiento modesto de mantenedores. Compara eso contra el costo de no tenerla: responsabilidad legal, debida diligencia fallida o retrasada, incidentes de seguridad, construcciones internas duplicadas de cosas que ya existen como código abierto, y el lento sangrado de bifurcaciones que nadie eligió mantener. También hay retornos al alza que son más difíciles de cotizar pero reales: influencia sobre la dirección de los componentes de los que dependes, una ventaja de reclutamiento y reputación de una presencia creíble de código abierto, y entrega más rápida porque los ingenieros reutilizan en lugar de reconstruir. Cuando hagas el caso al liderazgo, enmarca la OSPO como gestión de cadena de suministro para la mayoría de tu base de código, con un dividendo estratégico encima. En el gobierno, agrega la dimensión de cumplimiento, ya que la apertura a menudo es obligatoria y hacerla bien evita tanto el incumplimiento como el gasto público duplicado.

Antipatrones y trampas

La OSPO como puerta. Una oficina que solo revisa y bloquea, nunca habilita, se rodea, produciendo las dependencias fantasma que pretendía prevenir.
Teatro de contribución. Anunciar una estrategia de código abierto mientras se hace el proceso de aprobación tan lento que nadie realmente contribuye.
La liberación abandonada. Publicar un proyecto con una entrada de blog de lanzamiento, y luego nunca clasificar una incidencia, dañando tu reputación más de lo que lo haría el silencio.
Bifurcar y olvidar. Bifurcar una dependencia para una sola corrección y luego cargarla para siempre, desviándose de los parches de seguridad río arriba.
Vivir del esfuerzo de mantenedores frágiles. Depender de una biblioteca crítica de un solo mantenedor y nunca financiar, agradecer, o ayudar a la persona detrás de ella.
Negligencia de marca. Liberar un proyecto sin proteger su nombre, y luego ver a una bifurcación o proveedor comerciar con tu reputación.
Propiedad solo legal. Alojar la OSPO completamente en legal para que su guía no lleve credibilidad de ingeniería y los equipos la desconecten.
Métricas de vanidad. Contar estrellas y menciones de prensa en lugar de salud de dependencias, tiempo de aprobación, y parches privados retirados.

Modelo de madurez

Nivel 1 (Iniciar). Los ingenieros agregan, parchean, y ocasionalmente publican código abierto sin política y sin dueño. El consumo, la contribución, y la liberación son reactivos e improvisados, impulsados por la iniciativa individual. Las bifurcaciones privadas se acumulan sin ser notadas, nadie financia ningún proyecto río arriba, y nadie podría responder una pregunta de licencia durante la debida diligencia.

Nivel 2 (Desarrollar). Aparecen prácticas básicas pero varían por equipo. Existe una política de consumo aproximada y una lista de licencias aprobadas, y alguien es vagamente responsable, sin embargo la contribución es lenta y caso por caso y algunos grupos hacen mucho más que otros. Se conocen algunas dependencias críticas, pero la sostenibilidad, las liberaciones, y la administración siguen siendo inconsistentes.

Nivel 3 (Estandarizar). Una OSPO con carta posee el consumo, la contribución, la liberación, y la comunidad, y las prácticas están documentadas y se aplican en toda la organización. El escaneo y una lista de materiales de software están automatizados, existe un acuerdo de colaborador previamente aprobado y un camino de aprobación rápido, los proyectos liberados llevan gobernanza real, marcas, y políticas de seguridad, e InnerSource se está extendiendo. Los equipos gubernamentales publican por defecto.

Nivel 4 (Gestionar). La función de código abierto se mide y controla contra líneas base. El tiempo de aprobación se rastrea contra un objetivo, el volumen de contribución y la tasa de aceptación río arriba se reportan, los tableros de salud de dependencias y conteo de mantenedores marcan puntos únicos de fallo, la cobertura de mantenedores financiados de las dependencias de mayor riesgo se monitorea, y el inventario de parches privados y bifurcaciones tiende a la baja trimestre tras trimestre. Los proyectos liberados tienen tiempos de respuesta a incidencias medidos, las excepciones se revisan en una cadencia, y las métricas de vanidad como las estrellas se abandonan a favor de estas.

Nivel 5 (Orquestar). El código abierto es una capacidad estratégica gestionada, integrada con la planificación de ingeniería, legal, seguridad, y adquisiciones y adaptada continuamente. La contribución es rutinaria, los mantenedores y fundaciones críticos están financiados, la organización administra proyectos bien gestionados y dirige los ecosistemas de los que depende, e InnerSource es la norma. Las métricas de compromiso y salud alimentan la mejora continua, y el portafolio se reequilibra conforme cambian las dependencias, los riesgos, y los mandatos.

Ideas para el debate

¿Dónde está la línea entre una OSPO que habilita y una que vigila, y cómo sabrías desde afuera cuál has construido?
¿Cuáles de tus parches o bifurcaciones privadas estás cargando por hábito en lugar de necesidad, y qué se necesitaría para contribuir hacia arriba las tres principales?
¿Cómo deberías decidir qué mantenedores y fundaciones financiar cuando la lista de dependencias críticas es más larga que el presupuesto?
¿Qué cambiaría genuinamente en tu próxima liberación si tuvieras que publicarla con gobernanza real, una marca, y una política de divulgación coordinada desde el primer día?
Para los lectores del sector público, ¿cuál es un proceso defendible para exentar código de publicar-por-defecto sin erosionar silenciosamente el principio?
¿Qué bibliotecas internas se beneficiarían más de InnerSource, y qué le impide a otro equipo enviarte una solicitud de extracción hoy?

Puntos clave

Una OSPO posee toda la relación con el código abierto: consumir responsablemente, contribuir hacia arriba, liberar tus propios proyectos, y sostener a los mantenedores de los que dependes.
Contribuir hacia arriba es estrategia, no caridad; elimina el impuesto recurrente de los parches privados, compra influencia sobre la dirección, y ayuda a reclutar.
Haz que el camino conforme sea el camino más rápido mediante la automatización y la curación, para que la oficina habilite a los ingenieros en lugar de vigilarlos.
Libera tus propios proyectos solo con gobernanza real, una licencia elegida, una marca protegida, y divulgación de seguridad coordinada, o no los liberes en absoluto.
Financia y ayuda a los mantenedores críticos sobre los que descansa tu sistema de producción, porque el patrimonio común no se autosostiene.
Aplica InnerSource para traer la colaboración de código abierto dentro de la empresa, y en el gobierno, por defecto abierto, publica por defecto, y reutiliza antes de construir.

Referencias y lecturas adicionales

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper y Klaas-Jan Stol (editores), Adopting InnerSource: Principles and Case Studies
The Linux Foundation y TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation y TODO Group, State of OSPOs and Open Source Management (serie de encuestas anuales)
Heather Meeker, Open (Source) for Business
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
U.S. Federal Source Code Policy y la guía de Code.gov