¿Qué es el código abierto y cómo creció y gana dinero GitHub?

El código abierto no consiste simplemente en hacer público el código fuente. Es una forma de conceder a otras personas los derechos para usar, estudiar, modificar y redistribuir software bajo una licencia definida. GitHub creció hasta convertirse en una plataforma comercial al reunir este tipo de desarrollo colaborativo en un único flujo de trabajo para repositorios, control de versiones, revisión de código y automatización.

El modelo de negocio principal de GitHub no consiste en vender directamente proyectos públicos de código abierto. Atrae a una gran base de usuarios gratuitos y luego cobra por la colaboración privada, los controles de acceso, la seguridad, el cumplimiento normativo, la automatización, los entornos de desarrollo en la nube y las funciones de inteligencia artificial que necesitan las empresas.

Índice

• El significado preciso de código abierto
• El contexto que dio origen al movimiento de código abierto
• Cómo funciona el desarrollo de código abierto
• Las diferencias entre código abierto, Git y GitHub
• Los orígenes y el crecimiento de GitHub
• El modelo de ingresos de GitHub
• Por qué el código abierto gratuito genera valor económico
• Limitaciones y criterios de evaluación

¿Qué es exactamente el código abierto?

El software de código abierto es aquel cuyo titular de derechos de autor concede a los usuarios derechos mediante una licencia, incluidos los derechos de ejecutarlo, estudiarlo, modificarlo y redistribuirlo. La cuestión clave no es solo si el código puede verse, sino qué derechos están legalmente permitidos.

Según la definición de la Open Source Initiative (OSI), una licencia de código abierto debe permitir la redistribución gratuita, proporcionar el código fuente y permitir la distribución de modificaciones y obras derivadas. No debe discriminar a ninguna persona, grupo o ámbito de uso. Por ello, si se aplican restricciones como «solo para uso no comercial» o «no puede utilizarse en productos de la competencia», resulta difícil reconocer el software como código abierto en el sentido habitual, aunque su código fuente sea público. OSI의 Open Source Definition↗

Esta distinción es especialmente importante para los repositorios públicos en GitHub. Aunque un repositorio sea visible públicamente para todo el mundo, se aplica la legislación de derechos de autor por defecto si no tiene una licencia de código abierto. Otras personas pueden ver o hacer fork del repositorio dentro del servicio de GitHub, pero no obtienen automáticamente el derecho de copiar, modificar y distribuir libremente el código. GitHub también explica que un proyecto necesita una licencia que indique los permisos de uso para ser realmente de código abierto. GitHub의 저장소 라이선스 안내↗

Por tanto, las tres afirmaciones siguientes significan cosas diferentes:

• «Puedes ver el código» describe si el código fuente es público.
• «Puedes usarlo gratis» describe su precio.
• «Es de código abierto» describe los derechos concedidos por su licencia.

El software gratuito no es necesariamente de código abierto, y el software de código abierto también puede venderse.

¿Qué contexto dio origen al movimiento de código abierto?

La práctica de compartir código de software y mejorarlo de forma colaborativa existía en las primeras comunidades de investigación informática. Sin embargo, a medida que el software se convirtió en un producto comercial independiente y se reforzaron los derechos de autor y las restricciones de uso, también aumentó la preocupación por la capacidad de los usuarios para estudiar y corregir el software.

En la década de 1980, Richard Stallman puso en marcha el Proyecto GNU y el movimiento del software libre. En el software libre, «libre» no se refiere al precio, sino a la libertad de los usuarios de ejecutar, estudiar, modificar y redistribuir un programa, en su forma original o modificada. GNU의 자유 소프트웨어 정의↗

El nombre «código abierto» se creó en una reunión estratégica celebrada poco después de que Netscape anunciara planes para publicar el código fuente de su navegador en 1998. Ese mismo año, Eric Raymond, Bruce Perens y otras personas fundaron la OSI y organizaron la Open Source Definition basándose en las Debian Free Software Guidelines. El objetivo era explicar con mayor claridad a las empresas y al público las ventajas prácticas del desarrollo colaborativo. OSI 역사↗

El software libre y el código abierto coinciden en gran medida en las licencias que aceptan, pero difieren en su énfasis.

Esta diferencia no significa que una de las dos posturas sea siempre superior. Significa que el mismo programa puede explicarse desde una perspectiva centrada en los derechos de los usuarios y desde otra centrada en la eficiencia del desarrollo transparente y la colaboración distribuida.

¿Cómo funciona el desarrollo de código abierto?

El código abierto no significa que «cualquiera puede cambiar el código como quiera». La participación puede estar abierta, pero los mantenedores del proyecto y los procedimientos establecidos determinan qué se incorpora a una versión oficial.

Un proceso de desarrollo típico funciona así:

1. Un mantenedor publica el código fuente, la licencia, las instrucciones de uso y las reglas de contribución.
2. Un usuario clona o hace fork del repositorio para crear un espacio de trabajo independiente.
3. Las correcciones de errores o el desarrollo de funciones se realizan en una rama separada.
4. El colaborador envía un Pull Request con los cambios y su justificación.
5. Los mantenedores revisan el código, los resultados de las pruebas, la orientación del diseño y el impacto en la seguridad.
6. Solo los cambios que cumplen los criterios se integran en el repositorio oficial.
7. Se publica una nueva versión y los problemas detectados posteriormente vuelven a registrarse y seguirse.

En este proceso existen distintos roles. Los usuarios utilizan el software y comunican problemas. Los colaboradores envían código o documentación. Los mantenedores se ocupan de las revisiones y las versiones. Un comité directivo del proyecto o una fundación también puede gestionar las marcas, los presupuestos y las reglas de toma de decisiones.

En otras palabras, la «apertura» del código abierto no significa que no exista autoridad para tomar decisiones. Las oportunidades de participación y los derechos de uso del código están abiertos, mientras que los proyectos oficiales cuentan con estructuras de control para mantener la calidad.

¿En qué se diferencian las licencias de código abierto?

Las licencias de código abierto pueden entenderse, en términos generales, como licencias permisivas y licencias copyleft.

Licencias permisivas

MIT, BSD y Apache License 2.0 son ejemplos habituales. Siempre que se cumplan condiciones como conservar los avisos de derechos de autor y el texto de la licencia, estas licencias generalmente permiten incluir código modificado en software propietario.

Esto facilita que las empresas las integren en productos comerciales, pero no garantiza que el código mejorado vuelva a la comunidad original. Apache License 2.0 también incluye disposiciones explícitas relacionadas con patentes, por lo que sus condiciones legales no son idénticas a las de la licencia MIT.

Licencias copyleft

La GNU General Public License (GPL) es un ejemplo representativo. Cuando se distribuye código modificado, o se distribuye una obra derivada combinada con ese código, puede exigir que el código fuente se proporcione bajo la misma licencia.

El copyleft no prohíbe el uso comercial. El software puede venderse comercialmente, pero deben cumplirse las obligaciones de divulgación del código fuente dentro del alcance definido por la licencia. Variantes como LGPL y AGPL están diseñadas con condiciones diferentes para el enlace de bibliotecas y los servicios de red.

Al elegir una licencia, no debe seleccionarse simplemente porque la use un proyecto conocido. Deben examinarse el alcance de divulgación para las obras derivadas, las disposiciones sobre patentes, la prestación de servicios de red y la compatibilidad con otras licencias.

¿Cuál es la diferencia entre código abierto, Git y GitHub?

Estos tres conceptos suelen aparecer juntos, pero operan en capas distintas.

• Código abierto es un concepto que describe los derechos de uso del software y un método de desarrollo colaborativo.
• Git es un programa de control de versiones de código abierto que administra de forma distribuida el historial de cambios de archivos.
• GitHub es un servicio comercial que aloja repositorios Git en línea y ofrece revisión de código, gestión de incidencias, automatización, seguridad y funciones de colaboración.

Git se creó en 2005, después de que terminara la relación entre la comunidad de desarrollo del kernel de Linux y la herramienta propietaria de control de versiones distribuido BitKeeper. Se necesitaba una herramienta capaz de gestionar la velocidad, el trabajo distribuido y el gran número de ramas paralelas que requería un proyecto tan grande como Linux. Git 공식 역사↗

Con Git, cada desarrollador puede mantener un repositorio con el historial completo de cambios sin estar siempre conectado a un servidor central. Sin embargo, Git desde la línea de comandos hacía incómodo gestionar quién propuso un cambio, por qué era necesario, quién lo revisaría y cuándo se integraría. GitHub organizó precisamente este proceso colaborativo mediante una interfaz web.

Git puede utilizarse sin GitHub, y los repositorios pueden ejecutarse en GitLab, Bitbucket o servidores autohospedados. A la inversa, GitHub no solo contiene código abierto, sino también código corporativo privado y código público sin licencia. GitHub y el código abierto no son sinónimos.

¿Cómo comenzó GitHub?

GitHub fue desarrollado en torno a Tom Preston-Werner, Chris Wanstrath y PJ Hyett, y se lanzó como servicio público en 2008. Scott Chacon, experto en Git que más tarde se hizo conocido como autor de Pro Git, también se unió al equipo inicial.

El primer commit al repositorio interno de GitHub se realizó en octubre de 2007 y el servicio se lanzó en abril de 2008. Cerca de su primer aniversario, GitHub tenía más de 20.000 repositorios públicos y cuatro empleados a tiempo completo, sin haber recibido inversión externa. GitHub의 첫해 기록↗

El problema que GitHub buscaba resolver no era simplemente el almacenamiento de archivos. Pretendía crear un entorno colaborativo que visualizara los cambios entre repositorios Git distribuidos, ayudara a los desarrolladores a descubrir el trabajo de otros y facilitara la revisión de propuestas de cambio. El gráfico de red que GitHub publicó en 2008 también fue un intento de mostrar en una sola pantalla las relaciones entre las ramas y los commits de múltiples usuarios. 초기 Network Graph 소개↗

Este enfoque pasó a llamarse posteriormente «programación social». Los perfiles de los desarrolladores, los historiales de actividad, los seguimientos, los forks, las estrellas, las incidencias y los pull requests quedaron conectados a los repositorios de código, convirtiendo el propio proceso de desarrollo en una red que podía buscarse y observarse.

¿Por qué creció GitHub tan rápidamente?

El crecimiento de GitHub no puede explicarse solo por ofrecer almacenamiento gratuito para Git. La sincronización tecnológica, la experiencia de usuario, los efectos de red y un modelo de negocio empresarial actuaron conjuntamente.

Hizo comprensible en la web el complejo proceso de colaboración de Git

Las ramas, los commits y las fusiones son funciones potentes de Git, pero no son fáciles de entender para principiantes solo mediante comandos. GitHub reunió las diferencias de código, los debates, los resultados de revisión y el estado de las pruebas en la interfaz de pull requests.

En lugar de circular archivos de parches por correo electrónico, los desarrolladores podían compartir cambios mediante un único enlace. Los mantenedores de proyectos podían reducir los costes de revisión porque el código y el proceso de discusión quedaban registrados juntos.

Los repositorios públicos crearon una red de desarrolladores

Cuando un proyecto se incorpora a GitHub, es también más probable que sus usuarios y colaboradores creen cuentas. Después, esos usuarios crean otros proyectos o participan en proyectos existentes.

A medida que aumenta el número de repositorios, los desarrolladores visitan GitHub para buscar código. A medida que aumenta el número de desarrolladores, los mantenedores de proyectos eligen GitHub para atraer colaboradores. Este es un efecto de red de dos lados.

Los historiales públicos de actividad también sirvieron como portafolios de desarrolladores. Las empresas podían revisar el código real y la experiencia de colaboración de los candidatos, mientras que los desarrolladores tenían incentivos para crear historiales de actividad en busca de oportunidades laborales y reputación.

Hizo crecer simultáneamente el código abierto y los productos empresariales

GitHub redujo la barrera de entrada para los repositorios públicos de código abierto, al tiempo que cobraba por los repositorios privados desde sus primeros días. En 2011, lanzó GitHub Enterprise, que podía ejecutarse en servidores internos de empresas y atendía necesidades corporativas como autenticación, copias de seguridad y gestión de equipos. GitHub Enterprise 출시 기록↗

Esta estructura permitió a los desarrolladores individuales aprender a usar GitHub mediante proyectos de código abierto y luego emplear una versión empresarial del mismo flujo de trabajo al incorporarse a una empresa. Permitió una adopción ascendente, en la que los desarrolladores llevaban el producto a sus organizaciones sin esfuerzos de venta específicos dirigidos a particulares.

GitHub declaró que había alcanzado rentabilidad y crecimiento mediante servicios de pago sin inversión externa, y recibió su primera inversión externa en 2012. GitHub의 2012년 투자 발표↗

Amplió el nivel gratuito y redujo los motivos para migrar a servicios competidores

En 2019, GitHub empezó a ofrecer repositorios privados a cuentas personales gratuitas. En 2020, también eliminó los límites de colaboradores para repositorios privados gratuitos e hizo gratuitas las funciones principales para equipos. La gestión avanzada de permisos, la seguridad y las funciones de soporte que necesitan las empresas siguieron siendo ofertas de pago. GitHub Free 확대 발표↗

Ampliar el nivel gratuito supone renunciar a ciertos ingresos por suscripciones a corto plazo. Sin embargo, mantiene a más particulares y equipos pequeños en la plataforma y crea oportunidades para convertirlos a productos Team, Enterprise, de seguridad e IA a medida que sus organizaciones crecen.

¿Cómo afectó la adquisición por Microsoft al crecimiento de GitHub?

Microsoft acordó adquirir GitHub en 2018 por 7.500 millones de dólares en acciones de Microsoft. En ese momento, GitHub informó de más de 28 millones de usuarios. Microsoft declaró que GitHub mantendría operaciones independientes y su carácter centrado en los desarrolladores. Microsoft의 GitHub 인수 발표↗

La adquisición alineó necesidades estratégicas de ambas partes. GitHub podía utilizar infraestructura global de nube, una red de ventas empresariales y capacidades de seguridad y cumplimiento normativo. Microsoft podía superar su imagen anterior de empresa centrada en Windows y software propietario y establecer puntos de contacto con desarrolladores independientemente del sistema operativo o lenguaje de programación. También obtuvo oportunidades para conectar Azure, Visual Studio, VS Code y GitHub.

Tras la adquisición, GitHub se expandió más allá del alojamiento de repositorios hasta convertirse en una plataforma que cubre el ciclo de vida completo del desarrollo. GitHub Actions automatiza compilaciones, pruebas e implementaciones; Codespaces ofrece entornos de desarrollo en la nube; los productos Advanced Security analizan código, dependencias y secretos; y Copilot ofrece funciones de escritura y revisión de código basadas en IA.

En octubre de 2022, Microsoft anunció que GitHub había alcanzado 1.000 millones de dólares en ingresos recurrentes anuales (ARR) y había crecido hasta superar los 90 millones de usuarios, tres veces la cifra existente en el momento de la adquisición. Microsoft FY2023 1분기 실적 발표↗

GitHub anunció que más de 100 millones de desarrolladores utilizaron la plataforma en 2023 y más de 180 millones lo hicieron en 2025. En 2025, el total de proyectos llegó a 630 millones, y GitHub contabilizó que alrededor del 81,5 % de todas las contribuciones se produjeron en repositorios privados. Esto muestra que GitHub se ha convertido tanto en un espacio de código abierto como en infraestructura de desarrollo empresarial a gran escala. GitHub Octoverse 2025↗

Sin embargo, estas cifras son métricas de plataforma contabilizadas según los propios criterios de GitHub. El número de desarrolladores registrados no debe interpretarse como equivalente a usuarios activos mensuales o clientes de pago. Microsoft tampoco divulga cada año en detalle los ingresos actuales y el beneficio operativo de GitHub como unidad de negocio independiente, por lo que los 1.000 millones de dólares de ARR comunicados en 2022 deben considerarse una métrica representativa de tamaño divulgada entonces, no ingresos actuales.

En concreto, ¿de dónde obtiene ingresos GitHub?

El modelo de ingresos de GitHub puede resumirse como un modelo freemium: adquiere usuarios mediante una plataforma pública gratuita y cobra por el control y la productividad que las organizaciones necesitan para operar.

Suscripciones por usuario

El plan gratuito permite a particulares y equipos pequeños usar las funciones esenciales de repositorios. El plan Team proporciona funciones avanzadas de colaboración, mientras que el plan Enterprise ofrece seguridad, cumplimiento normativo, administración centralizada y opciones de implementación.

Según la página oficial de precios consultada en septiembre de 2026, Team comienza en 4 dólares por usuario al mes y Enterprise en 21 dólares por usuario al mes. Los importes reales pueden diferir según el plazo de contrato, la región, los impuestos y las condiciones de contratos grandes. GitHub 공식 가격표↗

La facturación por usuario tiene la ventaja de que los ingresos recurrentes pueden crecer a medida que aumenta la plantilla de una empresa. Una vez que el código y los procesos de trabajo se establecen en la plataforma, también aumentan los costes de cambio, lo que incrementa la probabilidad de mantener los contratos.

Suscripciones a productos de IA y facturación basada en el uso

GitHub Copilot dispone de planes de pago para particulares y organizaciones. Las empresas compran licencias para cada usuario, y pueden aplicarse cargos adicionales cuando se excede el uso de IA incluido en un plan. Por tanto, Copilot está evolucionando hacia un modelo que combina las suscripciones de software tradicionales con la facturación por uso de computación de IA. GitHub Copilot 조직 청구 안내↗

Copilot no solo añade una nueva fuente de ingresos para GitHub, sino que hace que la IA se consuma dentro de flujos de trabajo establecidos que incluyen repositorios, incidencias, pull requests y revisión de código. Esto facilita la venta cruzada de productos adicionales a clientes existentes de la plataforma en comparación con vender una herramienta de IA independiente.

Productos de seguridad y cumplimiento normativo

Las grandes empresas no pagan simplemente por un lugar donde almacenar código. Necesitan controles de cuentas, registros de auditoría, inicio de sesión único, detección de secretos, análisis de vulnerabilidades de código, gestión de la cadena de suministro y cumplimiento normativo.

A medida que aumenta la dependencia de componentes de código abierto, las organizaciones deben analizar continuamente paquetes vulnerables y credenciales filtradas. La expansión del ecosistema gratuito también incrementa paradójicamente la necesidad de productos de seguridad empresariales.

Uso de computación, almacenamiento y automatización

Servicios como GitHub Actions, Codespaces y Packages incluyen cierta cantidad de uso en un plan y cobran por los excedentes. Una factura empresarial puede incluir no solo licencias Enterprise, sino también uso excesivo de Actions o Codespaces y licencias adicionales para productos como Copilot y herramientas de seguridad. GitHub Enterprise 청구 구조↗

Este modelo permite que los ingresos de GitHub crezcan a medida que aumenta la actividad de desarrollo. Por otro lado, GitHub también asume los costes de servidores de ejecución, dispositivos de almacenamiento, redes y modelos de IA, por lo que no todos los ingresos por uso son beneficio.

Comisiones por transacciones de Marketplace

Los desarrolladores externos pueden vender aplicaciones de pago a través de GitHub Marketplace. GitHub proporciona gestión de pagos y suscripciones y retiene una parte del valor de la transacción como tarifa operativa. Según la documentación oficial, la parte retenida aplicada a las transacciones de aplicaciones desde 2021 es del 5 %. GitHub Marketplace 판매 대금 안내↗

Más allá de las comisiones directas de Marketplace, también es importante que las herramientas externas pasen a centrarse en GitHub. Cuantas más aplicaciones se utilizan, más herramientas de desarrollo deben sustituirse al abandonar GitHub, lo que refuerza la permanencia en la plataforma.

¿Por qué el código abierto gratuito tiene valor económico para GitHub?

Para GitHub, los repositorios públicos gratuitos no son simplemente una partida de coste. Son un activo fundamental para la adquisición de usuarios y la formación de un ecosistema.

En primer lugar, los proyectos de código abierto atraen nuevos usuarios. Los desarrolladores que quieren usar una biblioteca específica, informar de un problema o enviar un parche crean cuentas de GitHub. GitHub puede adquirir estos usuarios sin gastar en publicidad.

En segundo lugar, la actividad de código abierto convierte la forma de trabajar de GitHub en un estándar de facto del sector. Los desarrolladores aprenden forks, incidencias y pull requests en la escuela o mediante proyectos personales y después prefieren el mismo enfoque en el trabajo.

En tercer lugar, el ecosistema público y el desarrollo empresarial privado dependen mutuamente. Los productos privados de las empresas también utilizan innumerables bibliotecas y herramientas públicas. En los datos de GitHub de 2025, la mayor parte de la actividad de contribución ocurrió en repositorios privados, mientras que los proyectos públicos constituían la mayoría por número de repositorios. El ecosistema público gratuito proporciona la base para el trabajo empresarial de pago.

En cuarto lugar, los proyectos públicos más activos aumentan la demanda de seguridad y automatización. Se vuelven necesarias las actualizaciones de dependencias, la detección de paquetes maliciosos, la gestión de licencias y las pruebas e implementaciones a gran escala.

Por tanto, el apoyo de GitHub al código abierto gratuito es difícil de explicar como solo filantropía o solo actividad comercial. Aporta valor real a la comunidad de desarrolladores y, al mismo tiempo, funciona como una estrategia de distribución a largo plazo que conduce al mercado empresarial de pago.

¿Cómo ganan dinero generalmente las empresas de código abierto?

El modelo de negocio de GitHub es uno de varios modelos de ingresos que utilizan el código abierto. Las empresas de código abierto suelen cobrar no por el código reproducible en sí, sino por la facilidad operativa, la responsabilidad, la seguridad y la experiencia especializada.

• Soporte y consultoría: Ofrecen el software gratis y cobran por instalación, respuesta a incidentes, formación y soporte a largo plazo.
• Nube gestionada: Junto al código abierto que los clientes pueden instalar por sí mismos, venden SaaS que lo opera en nombre del cliente.
• Open core: Hacen públicas las funciones básicas y ofrecen funciones empresariales de gestión, seguridad y analítica bajo licencias propietarias.
• Licenciamiento dual: Ofrecen el mismo código bajo una licencia de código abierto y una licencia comercial, permitiendo a los usuarios elegir según sus circunstancias.
• Alojamiento y uso: Cobran según el uso de almacenamiento, red, computación y ejecución de automatizaciones.
• Patrocinios y donaciones: Particulares, empresas y fundaciones apoyan a mantenedores o la operación de proyectos.
• Certificación y formación: Obtienen ingresos mediante formación oficial, exámenes, certificaciones técnicas o programas de socios.

Estos modelos funcionan porque los costes del software no se limitan al precio de la licencia. Las empresas consideran el coste total de propiedad, incluido el tiempo de instalación, el riesgo de interrupciones, los incidentes de seguridad, las actualizaciones, el cumplimiento normativo y la escasez de personal especializado. Aunque puedan obtener el código gratis, pueden estar dispuestas a pagar por una responsabilidad operativa fiable.

¿Cuáles son las limitaciones del código abierto y GitHub?

El código abierto no se convierte automáticamente en software seguro y sostenible simplemente por contar con muchos participantes.

Las cargas de mantenimiento pueden concentrarse en pocas personas

Incluso una biblioteca muy utilizada puede depender de solo unos pocos mantenedores para las revisiones y publicaciones reales. A medida que aumenta el uso, crece la carga de informar incidencias y responder a problemas de seguridad, mientras que la remuneración de los mantenedores puede no crecer al mismo ritmo.

La revisión pública no garantiza la calidad

El hecho de que el código fuente sea público es distinto de que alguien lo haya revisado adecuadamente. Los riesgos de la cadena de suministro incluyen vulnerabilidades, contribuciones maliciosas, cuentas de mantenedores comprometidas y dependencias contaminadas.

Las obligaciones de licencia pueden pasarse por alto

El código abierto no es un bien público sin derechos de autor. Deben cumplirse las condiciones de cada licencia, incluidos conservar los avisos de derechos de autor, proporcionar el código fuente, indicar los cambios y aplicar la misma licencia. La compatibilidad de licencias debe revisarse especialmente en productos comerciales que combinan muchas dependencias.

La concentración en plataformas crea nuevas dependencias

Como Git es distribuido, los repositorios pueden trasladarse a otros servidores. Sin embargo, migrar completamente incidencias, debates de pull requests, flujos de trabajo de Actions, políticas de acceso, aplicaciones de Marketplace y registros de seguridad resulta mucho más difícil.

Cuanto más cómodo se vuelve GitHub, más pueden depender las comunidades de desarrollo de los precios, las políticas, la respuesta a incidentes y los cambios de funciones de una única empresa. Es necesario clonar el código localmente, hacer copias de seguridad de versiones y documentación, y comprender las dependencias respecto a funciones específicas de la plataforma.

¿Cuáles son los malentendidos habituales?

«Es público en GitHub, por lo tanto es de código abierto»

Sin una licencia, no surgen los derechos de uso habituales del código abierto. La visibilidad y la licencia son configuraciones separadas.

«Todo el código abierto es gratis»

Puede no haber coste de copia, pero las operaciones, el soporte, los servicios en la nube, la formación y las funciones de seguridad pueden tener costes. Las licencias de código abierto no prohíben las ventas de pago.

«Cualquiera puede cambiar el código oficial como quiera»

El derecho de cualquiera a modificar su propia copia es distinto de la autoridad para incorporar cambios al proyecto oficial. Los mantenedores y las reglas de gobernanza deciden si los cambios se incluyen oficialmente.

«GitHub en sí es de código abierto»

GitHub aloja proyectos de código abierto a gran escala y publica diversas herramientas de código abierto, pero el servicio completo de GitHub no es un único producto de código abierto. GitHub es una plataforma comercial propiedad de Microsoft.

«Como GitHub tiene muchos usuarios, la mayoría son usuarios de pago»

Los recuentos de desarrolladores comunicados por GitHub incluyen cuentas gratuitas. El total de desarrolladores registrados, los desarrolladores activos, los clientes empresariales y las licencias de pago son métricas diferentes.

«Microsoft opera GitHub gratis»

Aunque los repositorios gratuitos están ampliamente disponibles, GitHub genera ingresos mediante licencias empresariales, IA, seguridad, automatización, computación, almacenamiento y Marketplace. Los usuarios gratuitos aportan tanto una posible conversión a clientes de pago como valor de red.

¿Cómo se debe evaluar un proyecto de código abierto?

Al adoptar código abierto en un proyecto real, no se deben considerar solo los recuentos de estrellas o las clasificaciones de GitHub. Revise conjuntamente los siguientes elementos:

• El archivo LICENSE y la compatibilidad legal con el uso previsto
• La frecuencia de las versiones recientes y las actualizaciones de seguridad
• El número de mantenedores principales y la dependencia de personas concretas
• La velocidad de revisión de incidencias y pull requests
• La existencia de procedimientos de pruebas, automatización e informes de vulnerabilidades
• La integridad de la documentación y las guías de actualización
• El personal y los costes necesarios para el autoalojamiento
• La dependencia de GitHub o de un servicio de nube concreto
• Las alternativas disponibles y la viabilidad de migración si el proyecto se abandona

Los mismos principios se aplican al seleccionar GitHub como plataforma de trabajo. En lugar de comparar solo los precios gratuitos, evalúe conjuntamente la gestión de permisos requerida, la auditoría, la seguridad, el uso de automatización, el uso de IA, la ubicación de los datos, la respuesta a incidentes y los costes de migración.

¿Cómo debe entenderse la relación entre el código abierto y GitHub?

El código abierto es un conjunto de reglas que distribuye los derechos para usar y mejorar software de forma colaborativa. Git es una herramienta para administrar de forma distribuida el historial de esos cambios, y GitHub es una plataforma que intermedia la colaboración basada en Git a gran escala.

GitHub no inventó el código abierto. En cambio, simplificó en un flujo de trabajo web unificado los procesos de descubrimiento, copia, debate, revisión e integración que necesitan las comunidades de código abierto. Los proyectos públicos crearon una red de desarrolladores, y esa red también atrajo el desarrollo empresarial privado a GitHub.

Como resultado, en lugar de cobrar entrada por el código público, GitHub construyó un modelo que cobra por el control, la seguridad, la automatización, la computación y la IA que las empresas necesitan para colaborar a escala. Comenzó con un modelo inicial de «lo público es gratis y lo privado es de pago», pero ahora puede entenderse como un negocio de plataforma de desarrollo en el que «la colaboración básica es gratuita y las funciones que resuelven la complejidad organizativa son de pago».