Resistencia de código abierto: protejamos el open source durante el horario laboral

 (ossresistance.com)
6 puntos por GN⁺ 2026-05-15 | 2 comentarios | Compartir por WhatsApp
  • Open Source Resistance es un manifiesto de acción directa que propone que el mantenimiento del software de código abierto del que dependen las empresas se realice de forma discreta y profesional dentro del horario laboral
  • Aunque ninguna empresa puede operar sin open source, rechaza la estructura que obliga a los maintainers a mendigar permisos, un botón de donación o un rato el viernes por la tarde
  • Ya existían alternativas como Open Source Pledge (solicitar US$2,000 al año por desarrollador) u Open Source Friday (contribuir al menos 2 horas cada viernes), pero aquí se plantea una ejecución más directa
  • Ante la objeción de que esto sería “robo de tiempo”, se responde que las empresas ya han recibido subsidios gratuitos del OSS y que mantener el OSS del que dependen es trabajo de infraestructura compartida
  • Es indispensable revisar la cláusula de cesión de IP del contrato laboral y negociar por escrito una excepción para open source

Manifiesto: no pidas permiso para arreglar lo que ya hace falta

  • Open Source Resistance propone una acción directa: no empujar el mantenimiento del software de código abierto (OSS) del que depende la empresa a las noches o fines de semana como si fuera un hobby, sino hacerlo de forma discreta y profesional durante el horario laboral
  • El software de código abierto no es un “pasatiempo” del tiempo libre, y las empresas extraen valor del open source a cada hora mientras apenas ofrecen a los maintainers una tarde de viernes, un botón de donación o un agradecimiento en una reunión general
  • Los maintainers deben trabajar dentro de la empresa sobre el código OSS del que esta ya depende sin papeleo, programas internos ni aprobación gerencial
  • No es una idea nueva, sino decir en voz alta cómo se ha hecho siempre la mayor parte del open source
  • Los maintainers han sostenido internet sin esperar reuniones, sprints ni la aprobación de un product manager

Principios clave de acción

  • Protégete

    • Revisa tu contrato laboral, mantén la información confidencial dentro de la empresa y asegúrate de conservar la propiedad del IP open source que publiques

  • Haz el trabajo

    • Realiza revisiones de PR, actualizaciones de dependencias y correcciones de bugs en partes que ya son OSS

  • No seas imprudente

    • No dediques el 100% de tu horario laboral al OSS y luego culpes a otros si te despiden; la clave es el equilibrio

Alternativas existentes

  • Open Source Pledge: pide a las empresas que paguen a los maintainers (US$2,000 al año por desarrollador)
  • Open Source Friday: pide a las empresas donar tiempo (al menos 2 horas cada viernes)
  • También existe la ruta educada de convencer primero al empleador, y todas son iniciativas positivas que vale la pena apoyar
  • Open Source Resistance se presenta como el siguiente paso en esa línea y declara que mantener la cadena de dependencias ya es parte del trabajo, aunque la gerencia no lo nombre así
  • No puedes controlar cómo se asigna el presupuesto de la empresa, pero sí cómo usas tu tiempo de trabajo

Objeciones previsibles y respuestas

  • “Es robo de tiempo / es robarle a los accionistas”

    • Las empresas ya extraen valor todos los días de los maintainers de open source, y los accionistas han recibido durante décadas subsidios gratuitos del open source
    • Si el empleador depende del OSS, mantenerlo es trabajo de infraestructura como bien público, no robo

  • “Hay que pedir permiso”

    • Pedir permiso es una forma de mantener el desequilibrio de poder
    • No hace falta la bendición de la gerencia para mantener una infraestructura de la que el empleador ya depende

  • “Es como el quiet quitting”

    • El quiet quitting reduce la carga de trabajo; esto, en cambio, produce la infraestructura OSS sobre la que se construyó internet
    • El problema no es el trabajo en sí, sino que las empresas se niegan a clasificarlo como trabajo

  • “También perjudica a los buenos empleadores”

    • Los buenos empleadores evitan este problema permitiendo el mantenimiento open source dentro del horario laboral, financiando a maintainers o uniéndose a Open Source Pledge

La experiencia de Mike McQuaid

  • Cofundador de Open Source Friday y GitHub Sponsors, y líder del proyecto Homebrew (maintainer desde 2009)
  • En ningún trabajo le han pagado el trabajo en proyectos open source como Homebrew como parte principal de sus funciones
  • Aun así, lo hizo con todos sus empleadores, negoció sus contratos de IP para legalizarlo y también cumplió con sus compromisos laborales
  • Desde que tuvo hijos, más del 90% del trabajo open source lo realiza durante el horario laboral
  • Como plantea en Open Source Maintainers Owe You Nothing, nadie tiene derecho a exigir noches, fines de semana ni tiempo familiar no remunerado de un maintainer solo porque el modelo de negocio de una empresa dependa de su código

Precauciones y aviso legal

  • No es asesoría legal

    • Se aclara que esto no es asesoría legal ni consejo sobre contratos, empleadores, estatus migratorio, obligaciones de licencia o circunstancias individuales
    • Si el riesgo es alto, debes consultar a una persona calificada antes de actuar
    • Como la mayoría de las licencias open source, se ofrece “tal cual”, sin garantías de ningún tipo

  • Contratos, políticas y propiedad

    • El contrato laboral, las políticas del manual interno y las cláusulas de cesión de invenciones pueden reclamar derechos sobre el trabajo creado durante el empleo, el trabajo hecho con equipo del empleador o el trabajo dentro del alcance de tus funciones
    • En algunos estados, estas reclamaciones se limitan para trabajos hechos en tiempo personal y con equipo personal, pero los detalles importan
    • Antes de hacerlo, debes leer tu contrato laboral y confirmar que el empleador no sea dueño del IP open source que planeas publicar
    • Si el dispositivo, la red o la cuenta cambian el riesgo de propiedad, debes usar los tuyos

  • Negociar el contrato de IP

    • La cesión de IP suele ser negociable y se recomienda pedir por escrito una cláusula de excepción para open source al recibir una oferta laboral, antes de firmar
    • Primero debes leer Employee IP Agreements para saber a qué partes oponerte
    • Mike McQuaid afirma haber negociado con casi todos sus empleadores cambios fuera del contrato estándar, y que en la mayoría de los casos hubo mucha menos resistencia de la esperada
    • Puedes mostrar a posibles empleadores el Balanced Employee IP Agreement de GitHub
    • Este acuerdo fue liberado como open source bajo CC0, lo han usado empresas públicas grandes y está diseñado para que el empleador conserve aquello por lo que paga y el empleado conserve trabajo open source que no compita con el negocio

  • Confidencialidad y seguridad

    • No debes divulgar repositorios privados, credenciales, incidentes, datos de clientes, roadmaps, vulnerabilidades no publicadas ni discusiones internas
    • No debes evadir controles de seguridad ni usar accesos no autorizados
    • La acción directa no es una excusa para revelar información confidencial de la empresa, sino para mantener público el trabajo público y separarlo claramente de los secretos comerciales

  • Ser discreto no significa ser descuidado

    • Cuando las políticas, los contratos, las obligaciones con clientes o las normas de seguridad cambian el riesgo, hace falta criterio propio
    • Puede que necesites trabajar desde tus propios dispositivos, cuentas y red
    • No se trata de “robarle” a la empresa, sino de equilibrar lo que la empresa toma del open source y lo que tú puedes devolver
    • Puede que recibas una evaluación de desempeño más baja que la de tus colegas, pero un B sostenible es más sano que quemar tu vida por una A en una empresa que mañana podría despedirte

  • Límites de aplicación

    • Este argumento es más débil cuando el tiempo se factura a clientes específicos, subvenciones, organismos gubernamentales, proyectos de defensa o entornos regulados
    • También es más débil para ingenieros junior o en situación precaria que no tienen margen para absorber represalias
    • Es más fuerte para maintainers senior que corrigen dependencias públicas que el empleador ya usa
    • La forma más limpia no es “haz lo que quieras en horario laboral”, sino tratar el mantenimiento open source como parte del trabajo de ingeniería
    • Debes mantener los proyectos que ya mantienes, mejorar herramientas compartidas que tocan tu trabajo y evitar cosas no relacionadas, código privativo o acciones que te hagan incumplir compromisos reales

Fuente y proyecto

Lecturas relacionadas

2 comentarios

 
roxie 2026-05-22

En conjunto..., parece que la expresión "resistencia" es la adecuada.
 
GN⁺ 2026-05-15
Comentarios de Hacker News

  • En general, era bastante común que las empresas dieran un permiso amplio para contribuir a ciertos proyectos de código abierto.
    La forma de plantearlo importa. En vez de “¿puedo hacer un poco de caridad para sentirme bien?”, hay que decir: “¿podemos recibir revisión rigurosa gratis de expertos en esta área y además incorporar los cambios al proyecto open source upstream para eliminar futuros costos de mantenimiento de la empresa?”.
    Esa es, en realidad, la esencia del asunto, y nunca tuve un empleador que me dijera que no cuando lo planteé así. Está completamente alineado con el beneficio de la empresa; solo hay que ayudarles a verlo.

    • Una de las razones por las que todavía lamento que me despidieran de un trabajo anterior es que justo estábamos discutiendo si publicar como open source un cambio bastante grande que hice a la librería Kafka Streams.
      Reescribí bastante manteniendo la API mayormente compatible, con énfasis en E/S no bloqueante para poder usar semánticas de backpressure cuando hiciera falta. Permitía hacer cosas interesantes porque se podían mezclar state stores con E/S bloqueante y no bloqueante manteniendo un rendimiento bastante bueno, y estaba especialmente orgulloso porque exprimía rendimiento en varios puntos poco visibles.
      Presioné para que me dejaran publicarlo en GitHub o enviar un PR al proyecto upstream de Kafka Streams, pero antes hubo despidos y después ya no quedó ningún champion que impulsara ese trabajo, así que terminó atrapado como código privativo.
      Aún pienso en rehacerlo desde cero y publicarlo como software libre/open source. Ya pasó bastante tiempo, así que no creo que hubiera problema en reescribirlo y publicarlo, nunca hubo temas de patentes, y además hay cosas que me gustaría cambiar, como quitar la dependencia de Vert.x. Tal vez lo haga algún día si llego a tener una semana libre.
    • Extraño los tiempos en que trabajaba en lugares donde permitían esto.
      Hay empresas donde solo el proceso de revisión legal ya lo enreda todo.
      Una vez pedí permiso para mandar un parche a un proyecto y se armó una cadena de correos bastante interesante. Al final la pregunta era una sola: si el parche fue escrito para corregir un bug de un producto entregable, durante horas facturadas al cliente, y además la librería parchada debe recompilarse y entregarse junto con el código fuente, y el contrato dice que todo trabajo e IP relacionado con el producto se transfiere al cliente, ¿tenemos derecho a publicar ese parche como dominio público?
      El equipo legal no quería responder.
    • En general es un buen enfoque y un gran ejemplo de cómo enmarcar el trabajo de forma profesional. Pero no resuelve el problema de fondo. Especialmente en empresas lideradas por ingeniería, la dirección debería entender de inmediato estos beneficios; si no lo hace, ahí ya hay un problema.
      La forma en que se puede abordar esto también depende mucho de la suerte que tengas con tu empleador.
    • “Perfecto, voy a pasarlo por el equipo de compliance. Solo quiero verificar que no haya ninguna infracción de propiedad intelectual. ¿De qué repositorio e issue se trata exactamente?”

  • Sobre eso de “asegúrate de ser realmente dueño de la IP open source que publicas”, en las jurisdicciones donde yo he trabajado, el código escrito y publicado durante horario laboral pertenecía al empleador, no a mí.
    No podía decidir por mi cuenta contribuir durante horario de trabajo, y para trabajar en código open source hacía falta un acuerdo formal. Cada vez que lo pedía, se tardaban meses en pasar por legal, así que o lo dejaba, o para entonces otro contribuidor ya había mandado el PR y dejaba de insistir.

    • Probablemente lo que querían decir era “no intentes donar por tu cuenta trabajo que no es tuyo”. Hay una sección aparte sobre eso más abajo, pero viendo solo la viñeta de arriba sí resulta confuso.
      Para desarrolladores con experiencia es algo obvio, pero con algunos desarrolladores junior en ciertas empresas sí ha sido un problema real. Si la empresa está haciendo algo genial en un proyecto interno, pueden pensar que sería buena idea contribuirlo a algún proyecto open source sin considerar que eso puede llevar a enviar código sustancialmente similar usando conocimiento de código privado, o incluso a veces copiar y pegar directamente.
    • No lo he investigado directamente, pero tenía entendido que en Alemania, por defecto, todo el código fuente creado durante horario laboral pertenece al empleador.
      La mayoría de los empleadores que no son de perfil IT probablemente ni entienden qué es el open source ni cómo funciona. Así que conseguir permiso de mucha gente puede ser desesperante.
      El sitio enlazado quizá funcionaría mejor si primero explicara a los empleadores los beneficios del open source y se enfocara en promover lineamientos legales para empleadores.
    • Si una empresa no publica con una licencia permisiva, al menos todo lo que no sea parte de producción, yo no trabajaría ahí. Para mí eso mata la motivación y me llevaría mentalmente al límite. Preferiría ser más pobre.

  • Es una buena idea, incluso una gran idea, pero no sé si sea bueno posicionarlo como resistencia.
    El propósito de un puesto normalmente es alcanzar cierta meta. Cómo alcanzar esa meta debería poder decidirlo el desarrollador como profesional experto. Si esa decisión incluye software open source, entonces mantenerlo también debería ser parte de esa decisión.
    No es algo radical; es simplemente hacer tu trabajo cuidando la estabilidad futura y la mantenibilidad de las cosas de las que depende ese trabajo.

    • Esto además es simplemente buen sentido de negocio. Las empresas que fomentan colaborar con open source están cultivando el ecosistema que alimenta su propio negocio.
    • Estoy de acuerdo con todo lo dicho, pero la realidad de la mayoría de las empresas tecnológicas hoy, al menos por mi experiencia, es otra. Ni siquiera invierten tiempo en mantener su propia infraestructura y librerías salvo que se les obligue; con open source menos todavía.
      Se priorizan funciones inútiles para jugar con métricas, enshittification, dark patterns y modas de integración casi equivalentes a malware por encima de invertir en infraestructura base o librerías.
    • De acuerdo. Describirlo así hace que parezca que alguien solo quiere llamar más la atención en redes sociales. Es una lástima que hayamos llegado al punto donde todo tiene que ser exagerado.

  • En términos generales estoy totalmente de acuerdo, pero creo que llevarlo a la práctica sí es complicado. No soy abogado, pero según entiendo, en general el empleador es dueño de la propiedad intelectual, así que hace falta permiso explícito para publicarlo como open source.
    Y obtener ese permiso suele ser difícil, pasando por procesos interminables y por el departamento legal.
    “En Estados Unidos, Reino Unido y muchas otras jurisdicciones, si un empleado crea una obra como parte de su trabajo, el empleador es considerado el autor legal o el primer titular del copyright”.
    https://en.wikipedia.org/wiki/Work_for_hire
    Aun así, creo que el trabajo open source, es decir mantenimiento y desarrollo, debe hacerlo profesionales asalariados, no voluntarios mendigando donaciones. La pregunta clave es cómo hacer eso realidad, y cómo lograr que las empresas acepten contribuir a open source como práctica estándar en lugar de una excepción que haya que negociar caso por caso.

    • Los problemas que describes se parecen más a problemas teóricos que a “problemas prácticos”.
      En la práctica, simplemente se hace. No hay una subrutina dentro de la computadora que impida git push. En la práctica, los empleadores ponen de todo en los contratos de trabajo. Escriben tanto como pueden para evitar responsabilidad por todos lados. Si ellos pueden escribir lo que quieran, ¿por qué nosotros no podemos simplemente hacerlo? Nada importa.
      En la práctica, la cantidad de proyectos open source a los que realmente se les ha cuestionado la IP por este tipo de razones técnicas es casi cero.
    • Es cierto que si el trabajo está relacionado con tus funciones, entonces el empleador tiene la IP.
      Si no está relacionado con tus funciones, depende del estado. En muchos estados hay límites a lo que un empleador puede reclamar como su propiedad intelectual. Los contratos estándar intentan redactarse de forma amplia para reclamarlo todo, pero la ley a menudo dice que la empresa no puede quedarse también con trabajo hecho en tu tiempo libre que no tiene relación con ella.
      Si lo haces durante horario laboral o usando la laptop de la empresa, eso sí puede darle base para reclamar derechos. A la mayoría de las empresas no les importará, pero si quieres mantener todo limpio en caso de disputa, no hay que descuidarse.
      Hazlo en tiempo personal, con equipo personal, y sin que se traslape con tu trabajo contratado ni con cosas a las que hayas tenido acceso en la empresa.
    • No soy abogado, pero si le diste una copia a un colega para que la ejecutara, ¿eso no cuenta ya como usar una licencia open source? Ese colega tendría los derechos legales otorgados por la licencia y también el derecho de redistribuir los cambios, ¿no?
      Subir los cambios al upstream es la mejor forma de garantizar el mantenimiento, y todo esto se ve bastante ridículo. Lo mismo pasa con la incertidumbre legal de mantener forks privativos internos.
    • El artículo parece sugerir que sigas la ruta de menor resistencia. Trabaja en horario de la empresa y no hagas mucho ruido. Si te descubren, pides perdón. Desde la perspectiva de la empresa, perdonar es el camino fácil. Meter abogados sale carísimo y hasta podría convertirse en una pesadilla de relaciones públicas.
    • Si el estado actual de la programación nos ha mostrado algo, es que la propiedad intelectual y las leyes de copyright ya no existen.

  • Trabajo en una empresa bastante grande. La política de open source de nuestra empresa se resume más o menos en “pregúntale primero a tu manager, no lo hagas a nombre de la empresa y no reveles información confidencial”.
    Nunca ha sido problema y, en términos generales, me parece totalmente razonable.

  • Me parece bien contribuir durante horario laboral a proyectos open source de terceros, por ejemplo con correcciones de bugs, pero no sé cómo debería manejarse el caso del open source propio.
    Por ejemplo, digamos que tengo una librería pequeña hecha por mí en lo personal, la empresa empieza a usarla y descubro un bug durante horario laboral. Si contribuyo en ese mismo horario, parecería una zona gris.
    ¿Alguien ha negociado algo así durante entrevistas? Me interesa saber cómo lo han hecho.

    • Nunca he trabajado en una empresa a la que realmente le importara esto. Simplemente hacía lo que había que hacer. Incluso cuando pregunté cómo se suponía que debía hacerse “correctamente”, nunca recibí una respuesta.

  • Cuando trabajaba en una gran empresa, en general, cualquier solicitud para hacer algo que no fuera escribir código directamente en el codebase de la empresa, aunque presentara argumentos, recibía de mi manager directo la respuesta de “hazlo en tu tiempo libre”.
    En un entorno orientado a ganancias, solo se considera valioso lo que parece aportar valor inmediato. La actitud es bastante parasitaria, y la impulsan desde arriba una mayor presión por eficiencia y la competencia por métricas.

  • Definitivamente he hecho forks para corregir algo y resolver un problema de trabajo, y luego mandé el resultado como PR al upstream.
    Esa es una de las buenas partes de usar y tener acceso a open source. Esa es también la razón por la que git es casi una opción de primera clase en package.json y cargo.toml: puedes apuntar directamente a tu fork hasta que el cambio llegue al upstream.

  • Cuando ya eres senior, en la etapa de la entrevista donde preguntan “¿tienes alguna pregunta para nosotros?”, yo pregunto: “¿cuál es la postura de esta empresa respecto a que dedique parte de mi tiempo a contribuir a los proyectos open source de los que depende?”.
    Y ya decides si seguir adelante o no según la respuesta.