En los últimos años, GitHub se ha consolidado como la plataforma predominante para alojar proyectos de código abierto y privado. Sin embargo, algunos desarrolladores, incluyendo a quienes disfrutan del código libre y de la colaboración abierta, están comenzando a cuestionar si esta concentración de poder en una única plataforma propietaria es beneficiosa para la comunidad y el ecosistema del software. A finales de 2022, decidí migrar mis proyectos fuera de GitHub hacia plataformas alternativas que se alinean mejor con mis principios y necesidades laborales. Quiero compartir este camino personal, no con la intención de dictar qué plataforma es superior, sino para que quienes sienten inquietudes similares puedan reflexionar sobre su propia relación con estas herramientas y valorar opciones distintas. Uno de los motivos principales que me llevó a salir de GitHub tiene que ver con GitHub Copilot, la herramienta de inteligencia artificial que sugiere fragmentos de código para acelerar el desarrollo.
Aunque Copilot es una innovación impresionante, existe preocupación sustancial en la comunidad respecto a cómo entrena sus modelos. Se ha demostrado que Copilot reproduce fragmentos de código abierto eliminando sus licencias originales, lo que plantea dilemas legales y éticos sobre propiedad intelectual y atribución. Este fenómeno no solo genera inseguridad en los desarrolladores que aportan sus aportes al ecosistema libre, sino que también dificulta la comprensión clara de qué prácticas son legales y cuáles no. Mientras la legislación sigue definiendo estos límites, la postura de Microsoft y GitHub ha sido, en esencia, desentenderse diciendo que son los usuarios quienes deben garantizar que su código no sea reproducido sin permiso, lo que resulta, como poco, una solución insuficiente. Más allá de Copilot, existen motivos filosóficos que apoyan la migración.
Por ejemplo, resulta paradójico que la plataforma más utilizada para alojar código abierto sea, en gran parte, un producto propietario. Esta concentración del control y la gestión de proyectos open source en manos de un gigante tecnológico puede atentar contra la diversidad, independencia y transparencia que definen a la comunidad del software libre. La centralización conlleva riesgos inherentes y, desde mi perspectiva, es fundamental diversificar para preservar la autonomía y evitar que una sola empresa determine el rumbo y las reglas del panorama. Otro aspecto que influye en mi decisión tiene que ver con la experiencia de usuario y cómo las plataformas moldean comportamientos. GitHub, en particular, está diseñado con principios que buscan maximizar el compromiso y la interacción, lo cual se refleja en elementos que generan pequeñas recompensas psicológicas, como los famosos cuadrados verdes de actividad o la visibilidad pública de seguidores y estrellas.
Aunque estas funciones pueden parecer inofensivas, fomentan una dinámica donde el desarrollador modifica sus hábitos y prioridades para aumentar esas señales visibles de popularidad, muchas veces en detrimento de la eficiencia real o la calidad del trabajo. Esta manipulación del comportamiento, enfocada más en incrementar métricas y beneficios para la empresa que en ayudar verdaderamente al usuario, no se alinea con mi concepto de herramientas de trabajo. Un punto relacionado y que creo es importante destacar es la cuestión económica y los incentivos que detonan las plataformas gratuitas. Personalmente, opto por pagar por mis herramientas para asegurar que los intereses estén alineados conmigo como usuario. Por ejemplo, pago por mi servicio de correo electrónico en Fastmail para evitar la explotación de mis datos con fines publicitarios.
De ahí que sospeche que los productos gratuitos, en especial gigantes como GitHub usados masivamente y con un enorme volumen de datos, sirvan para crear enormes bases de información destinadas a potenciar sistemas como Copilot o futuras innovaciones de inteligencia artificial. Cuando no pagas, eres el producto, y este es un modelo que prefiero evitar. Después de esta reflexión, el siguiente paso fue encontrar una plataforma alternativa que cumpliera con criterios claros y no negociables: debía ser un entorno open source, ofrecer transparencia en su dirección, y estar diseñada para respetar la salud mental y el flujo natural de trabajo, liberando al usuario de mecanismos que exploten los mecanismos de recompensa neuroquímica. En este sentido, Sourcehut se posicionó como la opción más atractiva para mí. Sourcehut es un proyecto financiado colectivamente que se distribuye bajo la licencia AGPL y permite incluso la autohospedaje si así se desea.
Lo que más valoro de esta plataforma es que no integra funcionalidades destinadas exclusivamente a captar la atención a través de recompensas inmediatas. Su creador, Drew DeVault, mantiene una postura clara, fuerte y transparente, lo que facilita entender hacia dónde dirigen el proyecto y qué prácticas se rechazan. Esto contrasta con plataformas como GitHub, donde las decisiones se toman dentro de contextos corporativos mucho más opacos y en función de métricas empresariales que no son susceptibles a discusión pública o transparencia. Otro factor significativo es la ligereza y rapidez de Sourcehut. Usando un diseño sin JavaScript, los tiempos de carga son considerablemente menores que en GitHub, lo que se traduce en menor consumo de recursos y una navegación más fluida, aspectos que no debo subestimar dada la frecuencia con que interactúo con estos sistemas.
Para ponerlo en perspectiva, un repositorio que en GitHub puede tardar cerca de un segundo en cargar y descargar varios megabytes, en Sourcehut demora una fracción del tiempo y descarga menos de doscientos kilobytes, una diferencia muy notable. Una de las funcionalidades críticas para muchos proyectos es la integración de CI/CD (Integración continua y despliegue continuo). A pesar de que opciones como Gitea existen —que también es rápido y ligero—, carecen o tienen sistemas menos robustos para integración de compilaciones y pruebas automatizadas. Sourcehut sobresale al ofrecer un modelo sencillo pero poderoso para construir, probar y desplegar código. Su esquema utiliza archivos YAML simples que configuran entornos virtuales donde se ejecutan scripts definidos, además de permitir correr compilaciones ad hoc y conectarse mediante SSH a máquinas virtuales para depurar errores.
En comparación, plataformas populares como GitHub Actions son ampliamente reconocidas como complejas y difíciles de dominar, implicando largas cadenas de commits experimentales para ajustar workflows. Un aspecto peculiar y que puede ser una barrera inicial para muchos es el flujo de contribución basado en git-send-email en Sourcehut. Esta metodología se basa en correos electrónicos para enviar, discutir y aceptar parches, un enfoque que puede parecer obsoleto frente a la omnipresente interfaz de solicitudes de merge (PR) de GitHub. Requiere cierto esfuerzo para aprender y adoptar, pero personalmente encuentro que facilita mantener el foco y reduce la dependencia del navegador, evitando distracciones y mejoras claras en mi concentración al gestionar aportes. Además, esta manera respeta y promueve el principio de no exigir al colaborador la creación de cuentas adicionales, lo cual es crucial para fomentar contribuciones en términos prácticos.
Naturalmente, mantener una cuenta en GitHub sigue siendo relevante para mí, dado que es la plataforma corporativa utilizada en mi trabajo diario y también porque ocasionalmente contribuyo a proyectos hospedados allí. No considero que sea necesario abandonar GitHub completamente, sino más bien diversificar y adaptar la plataforma a cada escenario y necesidad. La separación consciente de proyectos activos y antiguos me permite administrar recursos y atención de manera equilibrada. Si estás pensando en migrar, no es obligatorio hacerlo de forma drástica. Puedes explorar alternativas y poco a poco integrar diferentes foros y plataformas para reducir la centralización y mitigar los riesgos asociados a depender exclusivamente de un proveedor estableciendo el estándar global.
