Si te detienes un momento a mirar la pantalla de tu móvil o ese portátil que ya empieza a pedir un cambio de batería, lo más probable es que estés viendo el resultado de miles de horas de trabajo regalado. Bueno, «regalado» es una forma de hablar, pero ya me entiendes. La verdad es que si hoy podemos pedir una pizza desde una app o consultar el tiempo para ver si va a llover en el Puerto de Cartagena, es porque hace décadas unos cuantos locos decidieron que el código fuente no debía ser un secreto guardado bajo siete llaves.
A veces me pongo a pensar en cómo ha cambiado el cuento. Antes, hacer software era como construir una catedral: necesitabas un plano maestro, un arquitecto jefe con ínfulas de divinidad y un ejército de picapedreros que no tenían ni voz ni voto. Hoy, la cosa se parece más a un mercadillo de domingo, pero uno donde la gente se intercambia piezas de motor de Ferrari de forma gratuita. Es lo que Eric S. Raymond llamó «El Bazar», y vaya si ha funcionado.
Para entender cómo se hace el software hoy, hay que viajar un poco atrás, pero no te preocupes, que no me voy a poner en plan profesor de instituto pesado. Todo empezó con un tipo llamado Richard Stallman y una impresora que no funcionaba. Stallman, que por aquel entonces andaba por el MIT, se pilló un rebote monumental porque no podía arreglar el software de una impresora láser. La empresa se negaba a darle el código. «Es nuestro secreto», le dijeron. Y claro, a un tipo que cree en la colaboración, eso le sentó como una patada.
De ahí nació el concepto de Software Libre. No se trata de que sea gratis (que a veces lo es, y eso nos encanta), sino de libertad. Stallman definió cuatro libertades que son como los diez mandamientos para los que nos movemos en este mundillo:
- Libertad 0: Usar el programa para lo que te dé la gana.
- Libertad 1: Estudiar cómo funciona y cambiarlo. Si quieres que el botón sea verde fosforito, pues lo pones verde fosforito.
- Libertad 2: Distribuir copias. Ayudar al prójimo, que dirían algunos.
- Libertad 3: Mejorar el programa y publicar esas mejoras.
La verdad es que, al principio, esto sonaba a utopía de cuatro barbudos. Pero entonces llegó un chaval finlandés, Linus Torvalds, y dijo: «Oye, que estoy haciendo un sistema operativo por pura diversión, nada profesional». Y así, casi sin querer, nació Linux. Hoy, ese «juguete» mueve internet, los servidores de la NASA y probablemente tu televisión inteligente.
¿Cómo se cocina el código en la era de GitHub?
Si te asomas a la ventana de cualquier oficina técnica en Madrid, Barcelona o aquí mismo, en el Polígono de Santa Ana, verás a gente con cascos escribiendo líneas de texto que parecen jeroglíficos. Pero lo interesante no es lo que escriben, sino cómo lo comparten. La herramienta mágica aquí se llama Git.
Git es, básicamente, una máquina del tiempo para el código. Inventada también por Torvalds (el tío no para), permite que cientos de personas trabajen en el mismo archivo sin que aquello termine en una pelea de bar. Antes, si dos personas tocaban lo mismo, el archivo explotaba. Ahora, Git te dice: «Oye, que Juan ha cambiado la línea 10 y tú también, ¿qué hacemos?».
Y luego está GitHub (o GitLab, para los más puristas). Imagina una red social, pero en lugar de fotos de postureo con un café de especialidad, la gente sube sus proyectos. Es el epicentro de la creación actual. Si quieres saber cómo se hace el software hoy, la respuesta corta es: a base de Pull Requests.
El ritual de la Pull Request
Para que nos entendamos, una Pull Request (PR) es como si yo escribo un capítulo de un libro y se lo envío al autor original diciéndole: «Oye, creo que esto mejora tu historia, échale un ojo y si te gusta, mételo».
- El Fork: Haces una copia del proyecto en tu cuenta. Es tu patio de recreo.
- El Commit: Haces tus cambios. «He arreglado el error que hacía que la web se viera mal en el móvil de mi abuela».
- La PR: Pides permiso para fusionar tus cambios con el proyecto principal.
- La Revisión: Aquí es donde empieza lo bueno. Otros programadores revisan tu código. A veces son majos, otras veces te sacan hasta los colores. «Esto es poco eficiente», «Usa una variable más descriptiva», «Vaya chapuza has hecho aquí».
Este proceso de revisión por pares es lo que hace que el software libre sea, a menudo, mucho más robusto que el software propietario de grandes corporaciones que todos conocemos. Hay miles de ojos mirando, y como dice la Ley de Linus: «Con suficientes ojos, todos los errores son superficiales».
El modelo de negocio: ¿De qué vive esta gente?
Esta es la pregunta del millón. «Si el código es libre y cualquiera lo puede copiar, ¿cómo pagan las facturas?». Pues mira, la respuesta es variada y, a veces, un poco sorprendente. No todo es amor al arte, aunque haya mucho de eso.
La mayoría de las grandes empresas tecnológicas (Google, Meta, Microsoft) pagan a ingenieros para que trabajen en proyectos de software libre. ¿Por qué? Porque les sale más a cuenta que mantener ellos solos una infraestructura gigantesca. Si todos usamos el mismo motor de base de datos, los costes de mantenimiento se reparten. Es puro pragmatismo.
Luego tenemos el modelo de «Soporte y Servicios». Es lo que hace Red Hat, por ejemplo. Te dan el software gratis, pero si eres una empresa con miles de servidores y algo falla a las tres de la mañana, les pagas una pasta para que alguien te coja el teléfono y lo arregle. Es como si te regalan un coche, pero te cobran por el mantenimiento oficial y la garantía.
Y no nos olvidemos del Open Core. Te dan la versión básica gratis, pero si quieres las funciones «pro» (esas que suelen necesitar los bancos o las grandes telecos), ahí es donde sacan la cartera. Es un equilibrio delicado, porque si limitas demasiado la versión gratuita, la comunidad se enfada y te hace un «fork» (una bifurcación), llevándose el proyecto hacia otro lado. Ya ha pasado mil veces.
Un pequeño ejemplo práctico (con un toque de ironía)
Para que veas que esto no es física cuántica, vamos a imaginar que queremos hacer un pequeño script en Python para automatizar algo muy de aquí: avisarnos de cuándo hay cruceros en el puerto de Cartagena para evitar las colas en los bares del centro.
# El script definitivo para el cartagenero que odia las colas
import requests
def hay_cruceros_hoy():
# Simulamos una llamada a una API de la autoridad portuaria
# En un mundo ideal, esto sería un estándar abierto
url = "https://api.puertocartagena.es/v1/cruceros"
try:
respuesta = requests.get(url)
datos = respuesta.json()
if len(datos['barcos']) > 0:
print("¡Ojo! Hay guiris. Evita la calle Mayor si quieres un café tranquilo.")
else:
print("Todo despejado. Puedes ir a por tus marineras sin miedo.")
except Exception as e:
# Si falla, probablemente es que el servidor está caído
# o que alguien ha pisado un cable en el Arsenal.
print(f"Vaya, algo ha petado: {e}")
# Ejecutamos la función
hay_cruceros_hoy()
Este trozo de código tan tonto usa una librería llamada requests. Esa librería es software libre. La usan millones de personas. Si yo encuentro un fallo en ella mientras intento saber si hay cruceros, puedo arreglarlo y enviarlo a los mantenedores. Así es como se construye el mundo hoy: pieza a pieza, entre todos.
La Inteligencia Artificial: ¿El nuevo invitado o el que se va a comer todo el catering?
No puedo escribir esto sin hablar de la IA. Es el tema de conversación en todas las cañas de después del trabajo. Herramientas como Copilot o ChatGPT están cambiando la forma en que escribimos código. Ya no empezamos con una página en blanco; le pedimos a la máquina que nos haga un esqueleto y nosotros lo vamos puliendo.
Pero aquí hay un debate ético y legal que tela marinera. Estas IAs se han entrenado con código de GitHub. Código que tú, yo y el vecino de arriba escribimos bajo ciertas licencias. ¿Es lícito que una empresa use mi código libre para entrenar un modelo que luego me vende por 20 pavos al mes? La verdad es que estamos en territorio inexplorado. Es como si usaran todas las recetas de las abuelas de Cartagena para crear un robot cocina-calderos y luego nos cobraran por usarlo.
Aun así, el software libre está respondiendo. Ya hay modelos de lenguaje (LLM) abiertos, como Llama de Meta (bueno, «abierto» con matices) o Mistral, que permiten que cualquiera pueda montar su propia IA en casa sin depender de los gigantes de Silicon Valley. Es la misma lucha de siempre, pero con esteroides.
El factor humano: No todo son ceros y unos
A veces nos olvidamos de que detrás de cada línea de código hay una persona que quizás no ha dormido bien, que tiene que llevar a los niños al cole o que simplemente está harta de que le pidan cosas gratis con exigencias de cliente VIP. El «burnout» o agotamiento es un problema real en las comunidades de software libre.
Hay proyectos críticos para la seguridad de todo internet que mantienen dos tíos en su tiempo libre desde un garaje en algún lugar perdido. Es lo que se llama el «Bus Factor» (Factor Autobús): ¿cuántas personas tendría que atropellar un autobús para que este proyecto muera? En muchos casos, la respuesta es uno. Y eso da un poco de miedo, la verdad.
Por eso, la tendencia actual es crear fundaciones (como la Apache Foundation o la Linux Foundation) que den estructura y apoyo legal y financiero a estos proyectos. No se trata solo de escribir código, sino de cuidar a la gente que lo escribe. Al final del día, el software es un producto social.
¿Y qué pasa en España?
Pues mira, en España tenemos un talento brutal, aunque a veces nos falte creérnoslo un poco más. Hay empresas españolas que son referentes en el mundo del código abierto. Por ejemplo, en el ámbito de la ciberseguridad o de las bases de datos, hay gente de aquí dando lecciones fuera.
Incluso a nivel institucional, ha habido intentos de fomentar el software libre. Hace años se hablaba mucho de las distribuciones de Linux autonómicas (¿te acuerdas de Linex en Extremadura?). Aunque algunas no cuajaron como se esperaba, sembraron una semilla. Hoy, muchas administraciones públicas se han dado cuenta de que no pueden depender de licencias cerradas que cuestan un ojo de la cara y que no permiten auditar qué se hace con los datos de los ciudadanos.
En Cartagena, sin ir más lejos, tenemos una universidad politécnica (la UPCT) que saca hornadas de ingenieros que ya vienen con el chip del software libre de serie. No es raro ver a chavales de aquí colaborando en proyectos internacionales mientras se toman un asiático en una terraza.
La conclusión que saco de todo esto…
Hacer software hoy es un acto de equilibrio constante entre la generosidad y el negocio, entre la automatización de la IA y el toque artesano del programador. Ya no se trata de quién tiene el secreto mejor guardado, sino de quién es capaz de construir la comunidad más fuerte y vibrante.
Si eres de los que solo usa el ordenador para mirar el correo, que sepas que cada vez que haces clic, hay una montaña de software libre sosteniéndote para que no te caigas. Y si eres programador, pues qué te voy a decir que no sepas: sigue haciendo esos commits, sigue peleándote con las PRs y, sobre todo, no te olvides de comentar el código, que luego los que venimos detrás nos volvemos locos intentando entender qué querías hacer a las tres de la mañana con ese bucle infinito.
Vaya, que el software libre no es solo una forma de programar; es una forma de entender el mundo donde compartir no te hace más pobre, sino que nos hace a todos un poco más listos. O al menos, nos permite arreglar la impresora sin tener que pedir permiso a nadie.
Unas notas finales para los más curiosos:
- Si quieres empezar en esto, no hace falta ser un genio. Empieza arreglando una errata en una documentación. Eso también es contribuir.
- Ojo con las licencias. No es lo mismo una MIT (haz lo que quieras) que una GPL (si usas mi código, el tuyo también tiene que ser libre). Lee la letra pequeña.
- Apoya a los mantenedores. Si usas una herramienta que te ahorra horas de trabajo, mira si tienen un botón de «Sponsor» en GitHub. Un café al mes no te saca de pobre y a ellos les da la vida.
Y con esto y un bizcocho (o un crespillo, que estamos donde estamos), ya tienes una idea de cómo se cocina la tecnología que mueve nuestras vidas. No es magia, es colaboración pura y dura.
Deja una respuesta