Desarrollo · Unos 6 min de lectura

Código abierto: compartir conocimiento y aun así ganar dinero.

Negocios de código abierto: licencias, colaboración y servicios remunerados. Aprende a separar derechos de uso, costes de mantenimiento y formas de cobrar.

Ilustración conceptual sobre negocios de código abierto: bazar marfil con toldos azules, figuras anónimas y bloques geométricos en sus puestos.

Los negocios de código abierto pueden compartir programas y cobrar por servicios relacionados. Para entender el acuerdo conviene separar los derechos que concede una licencia, el trabajo de mantener un proyecto y la ayuda que alguien está dispuesto a comprar. MEE propone examinar esas tres piezas antes de confundir colaboración con ingresos asegurados.

Ficha de lectura
Tema Definición de Economía Compartida
Nivel Desarrollo
Pregunta ¿Cómo compartir código y cobrar por trabajo?
Recurso Programa y derechos concedidos por su licencia
Servicio Instalación, integración, soporte o formación
Costes Tiempo, infraestructura y mantenimiento
Coordinación Revisión y aceptación de contribuciones
Límite Colaborar no asegura rentabilidad
Alcance Fuentes primarias y propuestas de MEE

Negocios de código abierto: qué se comparte y qué se cobra

La definición de la Open Source Initiative exige más que poder ver el código. Incluye derechos de redistribución y modificación, bajo las condiciones de la licencia, y no permite excluir un campo de actividad por ser comercial. La definición admite que se venda software; no establece que todo servicio relacionado tenga que ser gratuito.

Antes de ofrecer algo, MEE propone describirlo en una frase verificable: qué recibirá la persona, qué podrá hacer por sí misma y qué asistencia incluye el precio. Esa claridad permite comparar ofertas. Si alguien paga por una instalación, la factura debería expresar ese trabajo; si compra atención durante un periodo, necesitará conocer horarios, alcance y condiciones.

También conviene revisar la licencia concreta y las dependencias del proyecto. El permiso para usar una pieza no responde automáticamente qué avisos deben conservarse o cómo distribuir una modificación. Este artículo ofrece una distinción educativa; un producto real puede necesitar una revisión especializada de sus obligaciones.

Raymond: del ensayo de 1997 al libro de 1999

El ensayo de Raymond comenzó a circular en 1997 y dio nombre al libro publicado en 1999. La versión del ensayo consultada es posterior. Contrasta formas de desarrollar programas y examina experiencias como Linux y fetchmail. Su defensa de una colaboración abierta incluye requisitos: algo que pueda probarse, comunicación y capacidad para reconocer e integrar aportaciones.

MEE extrae una pregunta organizativa: ¿quién convierte las contribuciones en un producto que otra persona puede utilizar? Abrir un espacio para sugerencias puede aumentar el trabajo de revisión. Un proyecto necesita explicar dónde comunicar problemas, cómo proponer cambios y quién decide incorporarlos. La apertura de participación no hace que toda propuesta tenga que aceptarse.

Ejemplo hipotético 1. Una desarrolladora publica una herramienta para organizar reservas con una licencia abierta. Ofrece instalación y formación a negocios que prefieren contratar ayuda. Una persona con conocimientos podría instalarla por su cuenta. El servicio remunerado tendría valor por el trabajo entregado; la existencia del repositorio no probaría cuántos clientes conseguirá.

Maquetas marfil de un edificio con torres y un mercado abierto, con detalles azules y un cubo rojo.
Alusión conceptual al ensayo de Raymond; no es una comparación medida de productividad.

Linux y producción entre pares: reconocer la infraestructura

El informe de 2025 de Linux Foundation presenta organizaciones, formación y actividades de seguridad alrededor de su ecosistema. La sección del kernel permite observar trabajo coordinado entre participantes de distintas organizaciones. Es un informe de la propia fundación y abarca más proyectos que Linux; no demuestra que cualquier programa abierto sea seguro o viable.

En el capítulo 3 de The Wealth of Networks, Benkler analiza producción entre pares y motivaciones diversas. Puede haber aprendizaje, interés personal o actividad comercial complementaria. Sería una simplificación describir cada contribución como una venta encubierta. Compartir un recurso tampoco elimina las reglas para acceder a él y modificarlo.

La lectura de MEE pide distinguir papeles. Quien mantiene una biblioteca, quien integra un producto y quien presta soporte pueden ser personas diferentes. Un negocio debería saber de qué piezas depende y cómo responde cuando algo falla. Reconocer esa dependencia permite planificar trabajo y recursos, sin atribuir obligaciones comerciales a voluntarios que nunca las aceptaron.

Comparar servicios antes de elegir un modelo

  • Instalación: acordar configuración, pruebas y entrega.
  • Integración: definir qué sistemas deben comunicarse y quién mantiene esa conexión.
  • Soporte: precisar canales, tiempos de respuesta y situaciones cubiertas.
  • Formación: identificar quién aprende, con qué materiales y para realizar qué tareas.
  • Alojamiento gestionado: explicar operación, copias y condiciones de salida del servicio.

Son opciones ilustrativas de diseño comercial. MEE propone presupuestar el tiempo necesario y contrastar si alguien necesita esa ayuda. Un servicio puede tener demanda y seguir siendo inviable si exige atención que el equipo no puede sostener. Conviene probar un alcance pequeño y registrar qué se entrega, qué cuesta y qué queda pendiente.

Taller de puerta azul junto a una fuente marfil con agua azul y una vasija roja.
Metáfora de servicios complementarios; no implica que toda licencia o modelo asegure ingresos.

El mejor argumento en contra: otros pueden beneficiarse sin financiar

La objeción señala una dificultad real del acuerdo: quien utiliza un recurso puede obtener valor mientras el mantenimiento recae en otras personas. Una licencia abierta no implica por sí sola obligación de donar o enviar mejoras al proyecto original. Las obligaciones dependen de sus términos y de la actividad concreta, no del deseo del mantenedor.

Como propuesta, MEE invita a pactar financiación de mantenimiento, patrocinios o trabajo remunerado cuando el proyecto sea importante para un negocio. Cada acuerdo debe indicar qué aporta cada parte y qué obtiene. La posibilidad de que nadie acepte sigue existiendo. Si falta capacidad, reducir compromisos puede ser más responsable que ofrecer una atención indefinida.

Ejemplo hipotético 2. Dos talleres usan una herramienta abierta y necesitan una mejora. Podrían contratar conjuntamente su desarrollo y acordar cómo distribuir el resultado según la licencia. Antes revisarían alcance, pruebas, mantenimiento y pago. La colaboración no exige que todos los usuarios participen, ni autoriza a prometer trabajo futuro de terceros.

La lectura de MEE: compartir conocimiento con compromisos claros

MEE propone escribir por separado los derechos sobre el programa y los compromisos del servicio. Añade un plan para actualizarlo, una persona responsable de responder y una forma comprensible de terminar la relación. La salida de una red también importa cuando alguien decide cambiar de proveedor.

En esta lectura, la economía compartida de MEE puede incluir conocimiento reutilizable y servicios contratados voluntariamente. La utilidad debe comprobarse en el trabajo entregado. Compartir abre posibilidades de cooperación; convertir alguna de ellas en un negocio exige atender necesidades, costes y acuerdos concretos.

Preguntas frecuentes

¿Puedo cobrar si el programa tiene código abierto?

La definición de la OSI admite actividad comercial. El trabajo concreto debe respetar la licencia aplicable, incluidas sus condiciones de redistribución o modificación cuando correspondan. MEE propone explicar qué vendes y qué derechos conserva quien lo recibe. Cobrar por asistencia no significa que todas las personas necesiten contratarla.

¿Cada persona que utiliza el programa debe contribuir?

No existe una obligación universal de donar dinero o enviar cambios al proyecto original por utilizar código abierto. Deben revisarse la licencia y los acuerdos concretos. MEE recomienda reconocer dependencias y considerar apoyo voluntario cuando un recurso sostiene una actividad, sin presentar esa propuesta como una exigencia de todas las licencias.

¿Publicar un repositorio basta para crear una comunidad?

La publicación permite conocer y, según la licencia, utilizar el trabajo. No demuestra que haya personas dispuestas a mantenerlo. MEE propone ofrecer instrucciones, un proceso de revisión y compromisos asumibles. La coordinación descrita por Raymond ayuda a formular preguntas, pero no garantiza participación, seguridad o ingresos para cualquier proyecto.

Para seguir aprendiendo

Fuentes y alcance

Consulta: 30/10/2026. Ejemplos hipotéticos e ilustraciones conceptuales. Datos e investigaciones conservan periodo y método; las interpretaciones de MEE se identifican como tales.

  1. Eric S. Raymond, The Cathedral and the Bazaar, ensayo iniciado en 1997; versión 3.0 conservada en Stanford. Consultado el 30/10/2026.
  2. Open Source Initiative, The Open Source Definition. Consultado el 30/10/2026.
  3. Yochai Benkler, The Wealth of Networks, Yale University Press, 2006, capítulo 3. Consultado el 30/10/2026.
  4. Linux Foundation, Annual Report 2025. Consultado el 30/10/2026.

Esta idea forma parte de un mapa más grande.

Volver a su área