La relación de Microsoft con el software libre y el código abierto constituye uno de los cambios más significativos en la historia de la industria tecnológica. Durante décadas, la compañía representó el modelo de negocio basado en el software propietario, en el que el código fuente permanecía bajo el control de sus desarrolladores y los usuarios debían adquirir licencias para utilizar sus productos. Sin embargo, con el paso del tiempo, Microsoft pasó de considerar el código abierto una amenaza para su negocio a convertirlo en una pieza fundamental de su estrategia tecnológica, especialmente en ámbitos como la computación en la nube, el desarrollo de aplicaciones, la inteligencia artificial y la infraestructura empresarial.

Esta transformación no se produjo de un día para otro ni respondió exclusivamente a un cambio ideológico, fue el resultado de una combinación de factores tecnológicos, económicos y estratégicos. La expansión de Linux en los servidores, el crecimiento de las comunidades de desarrolladores, la consolidación de herramientas abiertas y el auge de los servicios en la nube obligaron a Microsoft a replantearse una filosofía empresarial que durante años había estado estrechamente vinculada a Windows y a sus aplicaciones comerciales. Para comprender la magnitud de este cambio, es necesario recorrer las distintas etapas de una relación marcada inicialmente por la confrontación, seguida de una aproximación pragmática y, finalmente, por una integración cada vez más profunda.

Durante los años noventa y buena parte de la década de los 2000, Microsoft mantuvo una posición claramente defensiva frente al software libre. Bajo el liderazgo de Bill Gates, la empresa construyó un ecosistema comercial alrededor de Windows y Microsoft Office, dos productos que se convirtieron en referencias del mercado informático. Su éxito se apoyaba, entre otros elementos, en la venta de licencias, la compatibilidad entre aplicaciones y sistemas operativos, y la amplia presencia de sus productos en empresas, administraciones públicas y hogares. En ese contexto, el desarrollo de alternativas abiertas como Linux representaba un desafío importante, ya que ofrecía a organizaciones y desarrolladores la posibilidad de utilizar, modificar y distribuir software sin depender de un único proveedor.

La diferencia entre ambos modelos iba mucho más allá del precio. Mientras que Microsoft mantenía el control del código fuente de sus principales productos, el software libre defendía la libertad de los usuarios para estudiar cómo funcionaban los programas, adaptarlos a sus necesidades y compartir sus modificaciones. Esta filosofía, impulsada por comunidades de desarrolladores y organizaciones como la Free Software Foundation, cuestionaba la idea de que el control exclusivo sobre el software debía ser la base de su desarrollo y comercialización. Conviene distinguir, además, entre software libre y código abierto, porque, aunque ambos conceptos se solapan ampliamente, el primero pone el acento en las libertades de los usuarios, mientras que el segundo suele destacar también las ventajas prácticas del acceso al código y del desarrollo colaborativo.

Uno de los episodios más reveladores de aquella época fueron los conocidos como Halloween Documents, una serie de memorandos internos de Microsoft que salieron a la luz en 1998. Estos documentos analizaban la expansión del software libre y reconocían que determinados proyectos, especialmente Linux, presentaban ventajas competitivas relevantes. Entre ellas figuraban la capacidad de colaboración de las comunidades de desarrollo, la rapidez con la que podían mejorarse ciertos componentes y la posibilidad de distribuir software a gran escala sin los costes asociados al modelo tradicional de licencias.

Los documentos también reflejaban la preocupación de Microsoft por el impacto que estas características podían tener sobre su negocio. En lugar de considerar Linux simplemente una alternativa minoritaria, la empresa comenzaba a reconocer que el desarrollo abierto podía convertirse en una fuerza capaz de competir con sus productos. Los memorandos estudiaban diferentes formas de responder a esa amenaza, entre ellas el aprovechamiento de las ventajas de los productos propietarios y el uso de estrategias técnicas y comerciales que dificultaran la adopción de soluciones rivales. Su publicación se convirtió en un hito porque permitió conocer, desde dentro, cómo interpretaba Microsoft el crecimiento del software libre.

La tensión alcanzó una de sus expresiones más conocidas durante la etapa de Steve Ballmer como consejero delegado. En 2001, Ballmer calificó Linux de «cáncer» en una declaración relacionada con la licencia GPL y sus posibles implicaciones para la propiedad intelectual. La preocupación de Microsoft se centraba en las condiciones bajo las cuales se distribuía y modificaba el software amparado por esta licencia, especialmente en las obligaciones que podían aplicarse a la redistribución de determinadas obras derivadas.

La GPL establece que quienes distribuyen versiones modificadas de un programa cubierto por ella deben respetar determinadas condiciones de libertad y disponibilidad del código fuente. Para una empresa acostumbrada a proteger sus desarrollos mediante licencias propietarias, este modelo podía parecer incompatible con algunas de sus prácticas comerciales. No obstante, la interpretación de las obligaciones de la GPL depende de las circunstancias concretas y no significa que cualquier programa que interactúe con Linux deba convertirse automáticamente en software libre. La declaración de Ballmer reflejaba, en cualquier caso, una confrontación entre dos formas distintas de entender el desarrollo y la distribución del software.

Durante aquellos años, Microsoft no solo defendía públicamente su modelo, sino que también competía con Linux en ámbitos estratégicos como los servidores empresariales y los sistemas operativos. Linux ofrecía estabilidad, flexibilidad y una gran capacidad de adaptación, características que lo hacían especialmente atractivo para infraestructuras técnicas. Además, permitía a las organizaciones reducir su dependencia de un proveedor concreto y disponer de un mayor control sobre sus sistemas. A medida que estas ventajas se hicieron evidentes, la compañía de Redmond empezó a enfrentarse a una realidad que resultaba cada vez más difícil de ignorar: el software libre no era una moda pasajera, sino una alternativa con capacidad para transformar el mercado.

A mediados de la década de los 2000 comenzó una etapa de acercamiento gradual. Microsoft todavía no había abandonado su preferencia por el software propietario, pero las necesidades de sus clientes estaban modificando sus prioridades. Las grandes empresas ya no utilizaban necesariamente una única plataforma tecnológica. Era habitual encontrar servidores Windows junto a máquinas Linux, bases de datos de diferentes proveedores, aplicaciones desarrolladas con herramientas heterogéneas y sistemas virtualizados que debían funcionar de manera coordinada. En ese entorno, la interoperabilidad se convirtió en una necesidad empresarial.

Un ejemplo significativo fue el acuerdo anunciado en noviembre de 2006 entre Microsoft y Novell, la empresa vinculada entonces a la distribución SUSE Linux. El pacto pretendía mejorar la compatibilidad entre Windows y SUSE Linux Enterprise, facilitar el trabajo conjunto de ambas plataformas y ofrecer garantías comerciales relacionadas con determinadas reclamaciones de patentes. También contemplaba iniciativas de colaboración técnica y comercial destinadas a los clientes que utilizaban sistemas mixtos. El acuerdo provocó reacciones diversas dentro de la comunidad del software libre; algunos consideraron que constituía un avance práctico hacia una mayor compatibilidad entre plataformas, mientras que otros criticaron las disposiciones relacionadas con las patentes y temieron que pudieran introducir divisiones dentro del ecosistema abierto. La controversia puso de manifiesto que colaborar con Microsoft no era una cuestión puramente técnica, también planteaba interrogantes sobre la independencia de los proyectos, la protección de las libertades del software y las consecuencias de los acuerdos comerciales.

A pesar de las críticas, el pacto evidenció que Microsoft estaba dispuesta a establecer relaciones con empresas del entorno Linux cuando existían ventajas comerciales claras. La compañía comenzaba a reconocer que muchos de sus clientes no querían elegir necesariamente entre Windows y Linux, sino utilizar ambos sistemas de forma conjunta. En lugar de intentar eliminar esa diversidad, resultaba más útil desarrollar mecanismos que permitieran administrarla.

Otro momento importante llegó en 2009, cuando Microsoft aportó código al núcleo de Linux para mejorar su funcionamiento como sistema invitado en Hyper-V, su plataforma de virtualización. Las contribuciones incluían controladores y componentes destinados a facilitar la comunicación entre Linux y el hipervisor de Microsoft, mejorando aspectos como el rendimiento y la integración con el hardware virtualizado. El episodio tuvo un valor simbólico considerable, pues una empresa que durante años había presentado Linux como un competidor amenazante estaba contribuyendo ahora directamente a su desarrollo. Sin embargo, también respondía a una lógica empresarial evidente: si los clientes ejecutaban Linux en máquinas virtuales gestionadas mediante Hyper-V, mejorar su rendimiento beneficiaba tanto a los usuarios como al negocio de virtualización de Microsoft. La colaboración con el código abierto comenzaba así a demostrar que podía ser una herramienta competitiva, y no necesariamente una renuncia al modelo comercial de la compañía.

Durante los años siguientes, la relación continuó evolucionando. Microsoft amplió sus esfuerzos para mejorar la documentación de sus protocolos, facilitar la integración entre plataformas y ofrecer herramientas capaces de trabajar con tecnologías distintas de las propias. La compañía todavía mantenía un fuerte compromiso con Windows, pero empezaba a comprender que la fidelidad de los desarrolladores no dependía únicamente del sistema operativo que utilizaran. También era necesario proporcionarles herramientas eficaces, lenguajes modernos, servicios fiables y entornos de trabajo compatibles con sus preferencias.

El cambio decisivo llegó en 2014 con la llegada de Satya Nadella a la dirección ejecutiva de Microsoft. Su nombramiento coincidió con una transformación más amplia del sector tecnológico, en la que la computación en la nube, los dispositivos móviles y los servicios digitales estaban adquiriendo un protagonismo creciente. Windows seguía siendo un producto esencial, pero ya no podía constituir por sí solo el centro de la estrategia de una empresa que aspiraba a competir en todos los ámbitos de la infraestructura informática.

Nadella impulsó una orientación más abierta y centrada en los servicios, resumida en una idea que se hizo especialmente conocida: Microsoft loves Linux, es decir, «Microsoft ama a Linux». La frase simbolizó una ruptura con el discurso predominante de etapas anteriores y expresó la voluntad de colaborar con tecnologías que, hasta entonces, se habían considerado rivales. No significaba que Microsoft abandonara Windows ni que renunciara a proteger sus productos comerciales. Significaba que la compañía estaba dispuesta a aceptar que sus clientes y desarrolladores utilizaran distintas plataformas, siempre que sus servicios pudieran aportar valor dentro de ese ecosistema.

El principal motor de este cambio fue el crecimiento de Microsoft Azure. La computación en la nube modificó profundamente la forma en que las empresas compraban y utilizaban tecnología. En lugar de adquirir y mantener toda su infraestructura física, podían contratar capacidad de procesamiento, almacenamiento y otros servicios a través de plataformas gestionadas por proveedores especializados. En ese nuevo mercado, Linux tenía una presencia destacada gracias a su flexibilidad, su eficiencia y su amplia adopción en servidores, contenedores y herramientas de desarrollo.

Para competir en la nube, Microsoft necesitaba ofrecer un entorno en el que pudieran ejecutarse las tecnologías elegidas por sus clientes, incluso cuando no pertenecieran a su propio ecosistema. Si una empresa desarrollaba sus aplicaciones sobre Linux, utilizaba contenedores o dependía de herramientas abiertas, Azure debía ser capaz de alojar esas cargas de trabajo de forma eficiente. La estrategia dejó de consistir exclusivamente en convencer a los usuarios de que adoptaran Windows y pasó a centrarse también en proporcionarles una plataforma desde la que pudieran ejecutar múltiples tipos de software.

Esta nueva orientación se reflejó en la apertura progresiva de tecnologías que antes estaban estrechamente ligadas al ecosistema propietario de Microsoft. Uno de los ejemplos más importantes fue .NET. Tradicionalmente asociado al desarrollo de aplicaciones para Windows, el entorno evolucionó hacia una plataforma capaz de funcionar en distintos sistemas operativos. Con el lanzamiento de .NET Core en 2016, Microsoft impulsó una implementación modular y multiplataforma que permitía a los desarrolladores crear aplicaciones para Windows, Linux y macOS. Posteriormente, la evolución del proyecto desembocó en la plataforma unificada .NET, cuyo desarrollo público y abierto ha facilitado la participación de una comunidad más amplia.

La importancia de esta decisión radica en que permitió a Microsoft ampliar el alcance de sus tecnologías de desarrollo. Los programadores ya no tenían que elegir necesariamente entre utilizar herramientas de Microsoft y trabajar en sistemas distintos de Windows y podían construir aplicaciones con .NET y desplegarlas en infraestructuras Linux, incluidos servidores en la nube. Para la empresa, esta apertura significaba que el valor de sus herramientas podía extenderse mucho más allá de su sistema operativo.

PowerShell experimentó una evolución similar. Concebido originalmente como un entorno de automatización estrechamente vinculado a Windows, se convirtió en una herramienta multiplataforma que también podía utilizarse en Linux y macOS. Esta decisión fue especialmente relevante para administradores de sistemas y profesionales de DevOps, responsables de automatizar procesos, gestionar servidores y coordinar infraestructuras complejas. Al permitir que PowerShell funcionara en diferentes plataformas, Microsoft facilitó su adopción en organizaciones que utilizaban entornos heterogéneos y reforzó su posición en el mercado de la administración informática.

Otro caso fundamental fue Visual Studio Code, el editor de código que Microsoft presentó en 2015. Su popularidad se explica por una combinación de factores: es relativamente ligero, admite numerosos lenguajes de programación, dispone de un amplio catálogo de extensiones y ofrece integración con sistemas de control de versiones, depuración y herramientas de desarrollo modernas. Además, funciona en Windows, Linux y macOS, lo que permite a los programadores mantener un entorno de trabajo similar independientemente del sistema operativo que utilicen.

Visual Studio Code se distribuye bajo una licencia de código abierto, aunque es importante distinguirlo de la distribución oficial de Microsoft, que incorpora determinados elementos y condiciones adicionales. El proyecto abierto del que deriva se conoce como Code – OSS. Esta distinción ilustra una característica importante de la estrategia de Microsoft, que es que la apertura del código puede coexistir con servicios, extensiones y productos comerciales que añaden funcionalidades o mantienen condiciones de distribución específicas. El resultado es un modelo híbrido en el que la colaboración comunitaria y el negocio empresarial no tienen por qué excluirse mutuamente.

La compra de GitHub en 2018 constituyó otro acontecimiento decisivo. Microsoft anunció la adquisición de esta plataforma por 7500 millones de dólares en acciones, en una operación que situó a la empresa propietaria de Windows al frente de uno de los principales centros mundiales de colaboración y alojamiento de código. GitHub era utilizado por millones de desarrolladores y empresas para almacenar proyectos, revisar cambios, gestionar versiones, coordinar equipos y publicar software, incluidos innumerables proyectos libres y de código abierto. Esta operación generó inquietud entre algunos usuarios, que temían que una plataforma tan importante para el desarrollo abierto pudiera quedar subordinada a los intereses comerciales de Microsoft. La empresa respondió prometiendo mantener GitHub como una plataforma abierta a diferentes lenguajes, herramientas y sistemas operativos. Desde entonces, GitHub ha seguido desempeñando un papel central en el desarrollo colaborativo, mientras Microsoft ha integrado la plataforma en su estrategia de herramientas para programadores y empresas.

La adquisición también reflejó un cambio en la manera de entender el valor del software. En lugar de limitarse a vender programas terminados, Microsoft reconocía la importancia de las plataformas donde los desarrolladores crean, comparten y mantienen sus proyectos. GitHub no es simplemente un repositorio de archivos, sino que facilita la colaboración entre personas y organizaciones, permite revisar el historial de los cambios y ofrece mecanismos para automatizar pruebas y despliegues. Controlar una infraestructura de este tipo proporciona a Microsoft una presencia importante en el proceso de desarrollo, incluso cuando el código que se crea pertenece a proyectos independientes.

Esta evolución también ha estado acompañada por una mayor participación de Microsoft en proyectos abiertos de infraestructura, seguridad, lenguajes de programación y herramientas de desarrollo. La empresa contribuye a proyectos comunitarios, publica bibliotecas bajo licencias abiertas y desarrolla parte de sus tecnologías de forma pública. Además, mantiene iniciativas destinadas a facilitar la creación y distribución de aplicaciones en entornos Linux y de contenedores. Estas contribuciones no implican que todos los productos de Microsoft sean abiertos, pero sí muestran que el código abierto ha pasado a formar parte habitual de sus procesos de ingeniería.

En la actualidad, Linux ocupa un lugar esencial en la estrategia de infraestructura de Microsoft, particularmente en Azure. La plataforma permite ejecutar numerosas distribuciones Linux y ofrece servicios diseñados para cargas de trabajo basadas en este sistema. Para muchas organizaciones, Linux constituye la base de servidores web, bases de datos, sistemas de análisis, aplicaciones empresariales y entornos de contenedores. Su presencia en la nube ha crecido gracias a la expansión de tecnologías como Kubernetes y Docker, así como a la adopción de arquitecturas de microservicios y modelos de despliegue automatizado.

La relación entre Linux y Azure demuestra que la competencia tecnológica ya no siempre se organiza en torno a sistemas operativos enfrentados. Una empresa puede utilizar Windows en sus equipos de escritorio, Linux en sus servidores y herramientas abiertas para desarrollar aplicaciones, mientras contrata servicios de infraestructura a Microsoft. Desde el punto de vista del proveedor de nube, lo importante es ofrecer rendimiento, seguridad, disponibilidad y facilidad de administración. El sistema operativo que se ejecuta sobre la infraestructura es una decisión que puede depender de las necesidades técnicas del cliente.

Las cifras concretas sobre el porcentaje de máquinas virtuales Linux en Azure varían según el año, la métrica utilizada y el tipo de carga de trabajo. Por ello, más que atribuir una proporción invariable al conjunto de la plataforma, lo relevante es que Linux representa una parte sustancial de su infraestructura y que Microsoft ha invertido de forma continuada en soportarlo. La presencia de este sistema ya no constituye una excepción tolerada, sino una característica estructural de la oferta de Azure.

Una de las expresiones más visibles de esta integración es el Subsistema de Windows para Linux, conocido como WSL. Esta tecnología permite ejecutar entornos Linux directamente en Windows, de manera que los desarrolladores pueden utilizar herramientas, intérpretes de comandos y aplicaciones habituales de Linux sin tener que abandonar su sistema principal ni configurar necesariamente una máquina virtual tradicional por separado. La primera versión de WSL apareció en 2016 y proporcionaba una capa de compatibilidad para ejecutar determinadas herramientas Linux. Con WSL 2, presentado posteriormente, Microsoft introdujo una arquitectura basada en un núcleo Linux real que funciona en un entorno de máquina virtual ligera y se integra con Windows. Este cambio mejoró la compatibilidad con las llamadas del sistema Linux y permitió ejecutar una gama más amplia de aplicaciones y herramientas.

Gracias a WSL 2, un desarrollador puede utilizar distribuciones como Ubuntu, instalar paquetes mediante los gestores habituales de Linux, trabajar con Bash y ejecutar herramientas como Git, Python o compiladores compatibles. También puede desarrollar aplicaciones en un entorno Linux y utilizar simultáneamente editores gráficos, navegadores y otras aplicaciones de Windows. Esta integración resulta especialmente útil para quienes necesitan reproducir en su ordenador el entorno donde se ejecutarán posteriormente sus aplicaciones, como ocurre con muchos servidores de producción basados en Linux.

WSL no convierte Windows en una distribución Linux ni elimina todas las diferencias entre ambos sistemas. Se trata de una tecnología de integración que permite aprovechar las herramientas de los dos entornos. Su existencia es, sin embargo, un ejemplo muy claro de hasta qué punto ha cambiado la relación de Microsoft con Linux. En lugar de obligar a los desarrolladores a escoger entre un entorno Windows y uno Linux, la empresa ofrece una solución que permite combinar ambos según las necesidades de cada proyecto.

Otro ejemplo significativo es Azure Linux, la distribución que Microsoft desarrolla para determinados usos de su infraestructura. El proyecto se conocía anteriormente como CBL-Mariner y fue presentado como una distribución Linux orientada a las necesidades de la propia empresa. Su diseño prioriza aspectos como la seguridad, la eficiencia, la previsibilidad de las actualizaciones y la adaptación a cargas de trabajo específicas, especialmente en entornos de nube y contenedores. Azure Linux demuestra que Microsoft no solo admite distribuciones creadas por otras organizaciones, sino que también desarrolla y mantiene su propia base tecnológica sobre Linux. Esto no significa que pretenda sustituir a todas las distribuciones existentes ni que sea necesariamente la mejor opción para cualquier servidor. Su propósito responde a necesidades concretas de infraestructura y operación. En una plataforma de gran escala, disponer de una distribución adaptada a los requisitos internos puede facilitar la gestión de actualizaciones, la reducción de componentes innecesarios y la aplicación de políticas de seguridad coherentes.

La expansión de los contenedores y de las arquitecturas de nube también ha reforzado esta relación. Muchas aplicaciones modernas se empaquetan en contenedores que incluyen sus dependencias y pueden desplegarse en diferentes entornos. Linux desempeña un papel destacado en este ecosistema y constituye la base de numerosas infraestructuras de contenedores. Por ello, el soporte de Microsoft para tecnologías abiertas como Kubernetes y herramientas asociadas resulta importante para atraer a empresas que buscan desplegar sus aplicaciones de forma flexible, sin depender exclusivamente de un sistema operativo o de una infraestructura determinada.

El ámbito de la inteligencia artificial añade una nueva dimensión a esta estrategia. Una parte considerable de las herramientas utilizadas para entrenar, ejecutar y desplegar modelos de aprendizaje automático se desarrolla sobre tecnologías abiertas y entornos Linux. Los frameworks, bibliotecas, herramientas de automatización y sistemas de orquestación forman un ecosistema en el que la colaboración entre empresas y comunidades de desarrolladores tiene un peso considerable. Para competir en este mercado, Microsoft necesita ofrecer infraestructura y herramientas compatibles con las tecnologías que utilizan investigadores, programadores y empresas, independientemente de que hayan sido creadas dentro o fuera de la propia compañía.

Sin embargo, sería incorrecto concluir que Microsoft se ha convertido en una empresa completamente abierta o que ha renunciado a su modelo comercial tradicional. Windows continúa siendo un producto propietario, y buena parte de sus aplicaciones, servicios y plataformas comerciales siguen distribuyéndose bajo licencias y condiciones específicas. La empresa mantiene también intereses económicos en suscripciones, servicios en la nube, soluciones empresariales y herramientas de productividad. La diferencia es que ahora puede combinar esos productos con componentes abiertos, comunidades de desarrollo y tecnologías mantenidas por terceros.

Esta convivencia entre apertura y negocio constituye uno de los aspectos más interesantes de la transformación de Microsoft. El código abierto puede reducir las barreras de entrada para los desarrolladores, favorecer la adopción de una tecnología y acelerar la identificación de errores. Al mismo tiempo, una empresa puede obtener ingresos ofreciendo alojamiento, soporte técnico, servicios gestionados, herramientas adicionales o versiones comerciales de una solución. El hecho de que un proyecto sea abierto no implica que todos los servicios relacionados con él deban ser gratuitos, del mismo modo que la existencia de un modelo comercial no impide que el código pueda desarrollarse públicamente.

También es importante distinguir entre software libre y servicios abiertos en sentido amplio. Publicar el código fuente de una aplicación no garantiza por sí solo todas las libertades asociadas al software libre: la licencia, las restricciones de uso y las condiciones de redistribución son determinantes. Del mismo modo, una plataforma puede incorporar tecnologías abiertas sin que toda su infraestructura o todos sus componentes estén disponibles para la comunidad. En el caso de Microsoft, conviven proyectos con licencias libres, herramientas de código abierto, productos propietarios y servicios comerciales. Por ello, cada iniciativa debe analizarse de acuerdo con sus características concretas.

La transformación tampoco elimina las tensiones entre los intereses de una gran empresa tecnológica y los de las comunidades independientes. El control de plataformas de desarrollo, la dependencia de servicios alojados por proveedores comerciales, las condiciones de las licencias y la dirección de los proyectos siguen siendo asuntos relevantes para quienes defienden la autonomía tecnológica. GitHub, por ejemplo, facilita enormemente la colaboración, pero también plantea preguntas sobre la concentración de infraestructuras esenciales en manos de una compañía privada. De forma similar, el uso de tecnologías abiertas dentro de una nube comercial puede ofrecer flexibilidad y, al mismo tiempo, generar dependencias respecto a los servicios específicos de ese proveedor.

Por tanto, la historia de Microsoft y el software libre no debe interpretarse simplemente como el triunfo de una ideología sobre otra. Es, sobre todo, el relato de una industria que ha cambiado sus prioridades y en la que las fronteras entre competencia y colaboración son cada vez más complejas. Durante los años noventa, Microsoft veía en Linux una amenaza para el control de su ecosistema. A mediados de los 2000 empezó a colaborar con tecnologías abiertas para responder a las necesidades de interoperabilidad de sus clientes. A partir de 2014, bajo el liderazgo de Satya Nadella, convirtió esa colaboración en una parte esencial de su estrategia de nube, herramientas de desarrollo e infraestructura.

El resultado es una situación que habría sido difícil de imaginar durante los años de mayor confrontación. Hoy es posible desarrollar una aplicación con Visual Studio Code, utilizar GitHub para coordinar su código, ejecutar herramientas Linux mediante WSL 2, desplegar la aplicación en contenedores y alojarla en Azure, combinando tecnologías abiertas con servicios comerciales de Microsoft. Este escenario no implica que las diferencias entre ambos modelos hayan desaparecido, pero sí que la empresa ha aprendido a competir en un entorno donde el software libre y el código abierto son elementos centrales de la innovación tecnológica.

En definitiva, la evolución de Microsoft refleja un cambio profundo en la manera de entender el valor del software. En sus primeras décadas de expansión, la compañía construyó gran parte de su éxito sobre el control de sus productos y la distribución de licencias propietarias. En la actualidad, ese modelo convive con otro en el que las plataformas, la interoperabilidad, los servicios en la nube y la participación en comunidades abiertas desempeñan un papel fundamental. La empresa no ha dejado de proteger sus intereses comerciales, pero ha pasado a reconocer que colaborar con el software libre puede ser una forma de ampliar su mercado, atraer desarrolladores y fortalecer su posición tecnológica.

La paradoja es evidente: una compañía que llegó a describir Linux como una amenaza existencial terminó desarrollando tecnologías basadas en él, contribuyendo a su núcleo, facilitando su ejecución en Windows y construyendo servicios de nube capaces de alojar millones de cargas de trabajo heterogéneas. Más que una reconciliación definitiva entre dos filosofías, se trata de una adaptación a una realidad tecnológica en la que el éxito depende cada vez más de la capacidad para integrarse con otros sistemas y responder a las necesidades de los usuarios. Comprender esta transformación también ayuda a entender el funcionamiento de la informática actual. El software libre ya no ocupa un espacio marginal reservado a entusiastas o administradores de sistemas, forma parte de las infraestructuras empresariales, las plataformas de desarrollo y los servicios digitales utilizados a diario por millones de personas.

Microsoft es uno de los ejemplos más claros de cómo incluso una empresa históricamente vinculada al software propietario ha tenido que incorporar esta realidad a su estrategia. La relación entre ambos mundos sigue evolucionando y probablemente continuará condicionando la manera en que se desarrollan, distribuyen y utilizan las tecnologías del futuro.

Si utilizaste un PC durante los años ochenta o principios de los noventa, probablemente recuerdes el sonido característico del PC Speaker, aquel pequeño altavoz interno que tenía fama de producir únicamente pitidos; pitidos al arrancar, pitidos de error, pitidos en los videojuegos y, en general, pitidos para cualquier cosa que el ordenador quisiera comunicar al usuario. Comparado con una Sound Blaster o una AdLib, era poco más que una broma tecnológica.

Lo sorprendente es que, técnicamente, aquel insignificante altavoz era capaz de hacer bastante más de lo que parecía. De hecho, algunos programadores consiguieron reproducir voces digitalizadas, efectos de sonido complejos e incluso fragmentos musicales que parecían completamente imposibles para un dispositivo tan rudimentario. Y lo hicieron sin añadir hardware adicional.

Para entender el truco hay que comprender primero cómo funcionaba realmente el PC Speaker. A diferencia de una tarjeta de sonido moderna, no podía generar muestras digitales de audio ni reproducir varios canales simultáneamente. Estaba conectado a un temporizador programable Intel 8253 o 8254 presente en la placa base del PC, el cual generaba una onda cuadrada que encendía y apagaba el altavoz a una frecuencia determinada. Si configurabas una frecuencia de 440 Hz obtenías una nota La; si seleccionabas otra frecuencia distinta obtenías otra nota diferente.

Por eso los primeros juegos de PC sonaban como sonaban, porque el ordenador simplemente ordenaba al temporizador generar una frecuencia concreta y el altavoz vibraba siguiendo ese patrón. El resultado, pues, era esa onda cuadrada de la que hablamos, muy simple, rica en armónicos y bastante desagradable para los estándares actuales. Sin embargo, para una máquina de principios de los ochenta era una solución extraordinariamente barata y eficaz.

La limitación más importante era evidente, y es que el PC Speaker sólo conocía dos estados: encendido o apagado. No existían niveles de volumen, ni mezcla de sonidos, ni tonalidades complejas. A primera vista parecía imposible reproducir voz humana utilizando un dispositivo tan binario. Pero ahí entró en juego la creatividad de los programadores.

Algunos desarrolladores descubrieron que el cono del altavoz no respondía instantáneamente a los cambios eléctricos, sino que, como cualquier sistema mecánico, poseía una cierta inercia física. Si se activaba y desactivaba lo suficientemente rápido, el cono no llegaba a completar todo su recorrido y adoptaba posiciones intermedias, en otras palabras, aunque electrónicamente sólo existieran dos estados, mecánicamente podían obtenerse desplazamientos parciales. La técnica consistía en controlar aquel temporizador miles de veces por segundo y, en lugar de generar una simple nota musical, el programa modificaba constantemente la duración de los impulsos enviados al altavoz, cambiando con enorme rapidez el tiempo durante el cual permanecía activado o desactivado y haciendo posible simular diferentes amplitudes de señal. Este principio es muy parecido al que utilizan ciertas técnicas modernas de modulación por ancho de pulsos o PWM.

Desde el punto de vista matemático, lo que se hacía era aproximar una onda analógica mediante una sucesión extremadamente rápida de impulsos digitales. Cuanto mayor era la frecuencia de actualización, más convincente resultaba la ilusión acústica y, además, el oído humano actuaba como un filtro natural, integrando todas esas pequeñas variaciones en una forma de onda aparentemente continua. Por supuesto, aquello tenía un precio, y es que reproducir audio digitalizado mediante el PC Speaker consumía una cantidad enorme de tiempo de CPU. Mientras una Sound Blaster disponía de hardware específico para manejar el sonido, aquí era el propio procesador quien debía alimentar constantemente el flujo de datos y, por ejemplo, durante la reproducción de voz, una parte importante de la potencia de cálculo del ordenador quedaba dedicada exclusivamente a producir sonido.

¿Y por qué consumía tantos recursos? Pues básicamente por dos aspectos. El primero era la generación de interrupciones masivas (high overhead), pues para simular diferentes niveles de voltaje, la CPU tenía que cambiar el estado del altavoz (encendido/apagado) a frecuencias extremadamente altas (por ejemplo, a 8 kHz o a 11 kHz para audio digital de baja calidad). Esto significaba que el procesador debía interrumpir lo que estaba haciendo miles de veces por segundo solo para actualizar un bit del puerto. El segundo aspecto, se refería a los ciclos de reloj desperdiciados, ya que los procesadores de la época (como el Intel 8088 a 4,77 MHz del IBM PC original) no tenían potencia suficiente para procesar los gráficos de un juego y, al mismo tiempo, calcular los tiempos exactos de la onda de sonido. La CPU se veía obligada a entrar en bucles de espera (busy-waiting) midiendo los pulsos de máquina exactos para que el audio no se distorsionara, y los desarrolladores tenían que entrelazar el código del juego con el código de sonido de forma milimétrica, haciendo que cada instrucción de renderizado gráfico se calculara para que durara exactamente los ciclos de reloj idóneos entre pulso y pulso del altavoz.

Todo ello se traducía en congelaciones de juegos y ralentizaciones extremas la mayoría de las veces. Muchos usuarios descubrieron estas capacidades y sufrieron sus consecuencias gracias a juegos y demostraciones técnicas de la época en títulos como Castle Wolfenstein (versión de PC, en 1984), Space Quest III: The Pirates of Pestulon (1989), Pinball Dreams (1992), algunas conversiones de Prince of Persia (1989) o Street Fighter II para PC (1992). También diversas demos de la escena PC y numerosos programas shareware lograron reproducir voces sorprendentemente reconocibles utilizando únicamente el altavoz interno; escuchar una frase hablada salir de aquel pequeño transductor era casi magia para quien entendía las limitaciones del sistema. En España, el ejemplo más notable fue el de La abadía del crimen (1987), con su canto religioso del Ave María durante los rezos o aquel «Pirata, pirata…» enlatado cuando el juego detectaba que estabas ejecutando una copia ilegal o alterada.

Lo más fascinante es que el truco no explotaba una característica diseñada expresamente para ello, pues los ingenieros de IBM nunca imaginaron que aquel humilde altavoz destinado a emitir códigos de error terminaría reproduciendo frases digitalizadas, sino que fue una consecuencia inesperada de combinar física, electrónica y una alta cantidad de ingenio. Los desarrolladores observaron las limitaciones del hardware, comprendieron cómo vibraba realmente el altavoz y encontraron una manera de engañar tanto al dispositivo como al oído humano.

Hoy, cualquier teléfono móvil barato incorpora circuitería de audio millones de veces más sofisticada. Sin embargo, resulta difícil no sentir cierta admiración por aquellos programadores capaces de arrancar voces humanas a un componente diseñado básicamente para hacer «bip». Porque la historia del PC Speaker es, en el fondo, una de las historias más representativas de la informática clásica, aquella que dice que cuando el hardware era insuficiente, alguien siempre encontraba una forma ingeniosa de hacer lo imposible.

Eran aquel momento en el que los usuarios de PC querían interfaces gráficas, ventanas, cuadros de diálogo y menús desplegables, pero el ordenador les respondía con un simple cursor parpadeando sobre una pantalla negra. Windows existía, sí, pero durante buena parte de los años ochenta y principios de los noventa el auténtico campo de batalla seguía siendo MS-DOS. Y fue precisamente en ese entorno hostil donde surgió una de las disciplinas más peculiares de la informática clásica: construir falsas interfaces gráficas utilizando únicamente caracteres de texto.

Para entender el fenómeno hay que recordar cómo era una sesión típica de DOS. La pantalla estaba formada por una cuadrícula de caracteres de 80 columnas por 25 filas. Cada posición almacenaba un código ASCII y unos atributos de color, y aquello, en teoría, sólo servía para mostrar texto. Sin embargo, los programadores pronto descubrieron que podían hacer bastante más con ello, porque el juego de caracteres de IBM incluía líneas horizontales, verticales, esquinas, bloques sombreados y otros símbolos semigráficos que permitían dibujar recuadros y estructuras sorprendentemente complejas.

La llegada de ANSI.SYS elevó la situación a otro nivel. Este controlador permitía interpretar secuencias ANSI enviadas por los programas o por archivos de texto y, gracias a ellas, era posible mover el cursor a cualquier posición de la pantalla, cambiar colores, borrar zonas concretas o modificar atributos visuales sin necesidad de acceder directamente al hardware. Para un usuario actual puede parecer algo trivial, pero en aquel momento era como descubrir superpoderes.

De repente comenzaron a aparecer programas cuya pantalla principal parecía una extraña imitación de un entorno gráfico. Había barras de menús, ventanas superpuestas, cuadros de ayuda y zonas coloreadas que daban la impresión de estar ante algo mucho más avanzado que una simple consola. Todo era mentira, por supuesto, no existían ventanas reales ni botones auténticos, tan solo había caracteres colocados cuidadosamente en posiciones concretas para crear una ilusión.

Lo fascinante es que esta técnica no se limitó a utilidades profesionales, los grupos de la escena warez y demoscene la adoptaron con entusiasmo. Muchas introducciones de cracks, por ejemplo, mostraban logotipos animados, textos desplazándose, degradados de color y marcos extremadamente elaborados. El usuario ejecutaba un programa y, antes de aparecer el juego, era recibido por una demostración técnica que parecía imposible para una simple pantalla de texto. En realidad, detrás de la magia sólo había secuencias ANSI, mucha imaginación y una paciencia infinita.

Técnicamente, ANSI.SYS era un controlador de dispositivo cargado desde al archivo de configuración CONFIG.SYS que interceptaba la salida de texto enviada a la consola de MS-DOS y analizaba las secuencias de escape ANSI que aparecían embebidas en el flujo de caracteres. Cuando un programa escribía una cadena que comenzaba por el carácter de escape ESC (ASCII 27), ANSI.SYS la interpretaba como una orden en lugar de mostrarla en pantalla. Estas órdenes permitían establecer el cursor en unas coordenadas concretas, cambiar colores de primer plano y fondo, eliminar líneas o regiones de pantalla, definir reasignaciones de teclado e incluso crear efectos de animación sin acceder directamente a la memoria de vídeo.

Internamente actuaba como una capa de traducción entre los programas y el controlador de consola de DOS, proporcionando una funcionalidad similar a la de los terminales profesionales compatibles con ANSI, pero con una penalización de rendimiento apreciable, ya que cada carácter enviado debía ser inspeccionado e interpretado antes de llegar a la pantalla. Por este motivo muchos programas profesionales, como gestores de archivos o BBS, acabaron utilizando bibliotecas propias que escribían directamente en la memoria de vídeo de las tarjetas CGA, EGA o VGA, obteniendo una velocidad muy superior a la que podía proporcionar ANSI.SYS.

Los más obsesivos llegaron a convertirlo en una disciplina artística, y se llegaron a diseñar auténticas ilustraciones formadas exclusivamente por caracteres ASCII y ANSI. Las sombras se construían mediante bloques semillenos, los reflejos se emulaban utilizando distintos colores de primer plano y las texturas eran combinaciones de símbolos aparentemente absurdos. Algunas composiciones ocupaban cientos de líneas y requerían terminales compatibles para renderizarse correctamente. Eran imágenes digitales, pero creadas con las mismas herramientas que se utilizaban para escribir un documento de texto.

La situación adquiría tintes casi cómicos cuando los desarrolladores intentaban competir visualmente con los primeros entornos gráficos. Aparecieron gestores de archivos, programas de comunicaciones y aplicaciones empresariales que simulaban cuadros de diálogo muy similares a los de Windows. Muchas personas pasaban horas trabajando dentro de aplicaciones DOS que, visualmente, intentaban convencerlas de que estaban utilizando una interfaz moderna, aunque por debajo siguiera existiendo exactamente la misma pantalla de texto de siempre.

Desde el punto de vista técnico, tampoco era una tarea sencilla. Había que considerar tarjetas gráficas diferentes, terminales incompatibles y sistemas que no siempre interpretaban las secuencias ANSI de la misma forma. Un efecto visual impresionante en un PC podía mostrarse completamente roto en otro. Por eso, muchos desarrolladores acabaron incluyendo detección automática de hardware, bibliotecas propias de control de pantalla e incluso sistemas alternativos cuando ANSI.SYS no estaba cargado.

Quizá lo más sorprendente es que todo este esfuerzo nacía de una limitación. Nadie habría dedicado tantas horas a dibujar botones con caracteres si hubiera tenido acceso a herramientas gráficas modernas. Sin embargo, precisamente porque existían restricciones técnicas, los programadores encontraron formas inesperadas de superarlas y, lo que debía ser un simple terminal de texto, acabó convirtiéndose en una plataforma para la creatividad visual.

Mirado con perspectiva, ANSI.SYS representa una de esas historias que definen perfectamente la informática clásica, donde un controlador diseñado para gestionar secuencias de terminal terminó alimentando una pequeña guerra entre la funcionalidad y el buen gusto. Algunos creaban interfaces elegantes y sorprendentemente profesionales, otros producían monstruos visuales llenos de colores fosforescentes, marcos imposibles y logotipos gigantescos que parecían diseñados después de una noche especialmente intensa de cafeína y ensamblador.

Y, siendo sinceros, ahí residía buena parte de su encanto, porque antes de los temas visuales, de las librerías gráficas y de los motores de interfaz, hubo una generación de programadores empeñada en demostrar que una pantalla de texto podía parecer cualquier cosa, incluso una interfaz gráfica. Aunque para lograrlo hubiera que declarar una guerra abierta al sentido estético.

Hay una escena que el cine lleva décadas repitiendo mal: aparece un gran ordenador de los años cincuenta o sesenta, lleno de luces parpadeantes, y algún técnico con bata blanca pulsando interruptores de vez en cuando. La realidad era bastante más interesante, pues aquellos interruptores no estaban allí para decorar ni para impresionar a las visitas, y no se pulsaban cada media hora cuando el operario de turno hacía la ronda con una carpeta de pinza en la mano. En la mayoría de los casos eran literalmente «el teclado» de la máquina.

Las primeras computadoras electrónicas carecían de los sistemas de entrada que hoy damos por supuestos. No existían teclados ni ratones, no había interfaces gráficas ni terminales conectados permanentemente. Incluso antes de que una máquina pudiera leer una cinta de papel o una tarjeta perforada, había que cargar en memoria un pequeño programa inicial, y para introducir ese software se hacía necesario enviarlo bit a bit mediante los interruptores del panel frontal.

Imaginemos una máquina con un bus de 16 bits. En el frontal encontrábamos normalmente dieciséis palancas alineadas horizontalmente, cada una de ellas representando un bit. Interruptor hacia arriba significaba 1; interruptor hacia abajo significaba 0. Si el operador quería introducir el valor binario 0001001000110100, debía colocar exactamente cada interruptor en la posición correcta y, después, pulsar una tecla o palanca de carga para escribir ese valor en memoria. Luego cambiaba la combinación y repetía el proceso para la siguiente instrucción.

En máquinas como el IBM 1130, aquellos interruptores servían además para indicar direcciones de memoria concretas. El operador podía seleccionar una dirección, visualizar su contenido mediante los indicadores luminosos y modificarla manualmente. Era algo parecido a abrir hoy un editor hexadecimal, sólo que en lugar de una ventana tenías una consola metálica llena de bombillas.

El proceso de arranque, además, era especialmente delicado. Supongamos que el ordenador debía cargar el sistema desde una lectora de tarjetas perforadas, pero esa lectora todavía no podía utilizarse porque el equipo no sabía cómo comunicarse con ella. Por lo tanto, primero había que introducir mediante interruptores una rutina extremadamente pequeña, de apenas unas instrucciones en código máquina, que era capaz de leer unas pocas palabras desde la tarjeta. Lo leído contenía un cargador más potente que, a su vez, volcaba en memoria el resto del software. Era un proceso escalonado que los ingenieros llamaban bootstrap (arranque, en castellano), término del que deriva el actual boot de los sistemas operativos.

Un error de un solo bit podía arruinar la operación. Si el operador pretendía introducir una instrucción con valor hexadecimal 3A pero por descuido colocaba un interruptor incorrectamente y escribía 3B, el programa podía dejar de funcionar inmediatamente. No había mensajes explicativos ni depuradores sofisticados, y la solución habitual consistía en volver a revisar una por una las posiciones de los interruptores y compararlas con la documentación técnica.

Las luces del panel frontal eran igualmente importantes, pues no estaban pensadas para mostrar actividad de forma decorativa, como sucedería décadas después en muchos ordenadores domésticos. Habitualmente representaban el contenido de registros internos, direcciones de memoria o líneas de datos. Un operador experimentado podía observar el patrón de luces y deducir si el procesador estaba ejecutando instrucciones, atrapado en un bucle o esperando una entrada externa.

Algunos fabricantes llevaron la idea todavía más lejos. Los llamados sense switches permitían que los programas consultaran directamente el estado de determinados interruptores físicos durante la ejecución. En el IBM 701, por ejemplo, el software podía comprobar si un interruptor concreto estaba activado y tomar decisiones distintas en función de ello. En ciertos sistemas IBM, incluso el lenguaje FORTRAN incorporaba instrucciones específicas para leer estos interruptores y controlar luces del panel frontal. Esto daba lugar a situaciones que hoy resultan difíciles de imaginar, en las que, por ejemplo, un programa científico que llevaba horas ejecutándose podía modificar su comportamiento porque el operador había cambiado la posición de una pequeña palanca. También era posible activar modos de diagnóstico, solicitar información adicional o alterar estrategias de cálculo sin recompilar absolutamente nada, solo moviendo interruptores. En cierto modo, eran las opciones de configuración de una aplicación moderna, pero implementadas directamente en hardware.

Los paneles frontales también eran herramientas de mantenimiento. Cuando una máquina fallaba, los técnicos examinaban las luces para localizar el punto exacto del problema. Muchos manuales de servicio incluían tablas completas indicando qué combinación de indicadores correspondía a determinados errores. Hoy conectamos un depurador o revisamos un registro de eventos; entonces se observaba el comportamiento de las bombillas.

Lo más fascinante de todo es que aquellos operadores desarrollaban una comprensión extraordinariamente profunda de sus sistemas. No trabajaban sobre capas de abstracción, leían directamente los bits, las direcciones de memoria y los registros internos. Cuando un programa no funcionaba, podían seguir visualmente el recorrido de los datos por la máquina. La informática moderna nos ha dado herramientas infinitamente más cómodas, pero también nos ha alejado de esa relación casi física con el hardware.

Quizá por eso cuesta no sentir cierta admiración por aquellos pioneros. Mientras nosotros nos quejamos cuando un IDE tarda siete segundos en arrancar, ellos cargaban el programa inicial de un ordenador colocando docenas de interruptores en la posición correcta uno por uno. Y si se equivocaban en el último bit, tocaba empezar otra vez desde el principio. Eso sí que era programación de bajo nivel.

Fueron los tiempos en los que encender un PC compatible significaba enfrentarse a una pantalla negra, escribir comandos y aprender sobre la marcha cómo funcionaba aquella máquina. Y en el ámbito de la programación o el desarrollo ocurría tres cuartos de lo mismo. Bajo aquel contexto tecnológico apareció GORILLA.BAS, uno de los programas más recordados de Microsoft QBasic, un juego aparentemente sencillo que acabó convirtiéndose en la primera lección de programación, física y diseño de gráficos para toda una generación de usuarios. Muchos recuerdan Doom, Prince of Persia o Wolfenstein 3D como las grandes puertas de entrada al videojuego en PC, pero antes de ellos hubo miles de adolescentes lanzando plátanos explosivos entre rascacielos pixelados.

GORILLA.BAS (del año 1990) no era un producto comercial ni una demostración tecnológica destinada a impresionar a la prensa especializada. De hecho, su objetivo principal era enseñar. Microsoft lo distribuía junto con QBasic y QuickBASIC como ejemplo práctico de programación avanzada. Al instalar el entorno de desarrollo, el usuario encontraba no sólo el ejecutable, sino también todo el código fuente, algo que hoy parece inconcebible para la mayoría del software comercial. Bastaba pulsar unas teclas para abrir miles de líneas de BASIC perfectamente comentadas y comenzar a descubrir cómo estaba construido el juego. Para muchos futuros programadores aquello fue como desmontar un motor y comprobar cómo funcionaba pieza por pieza.

La mecánica era extraordinariamente simple. Dos gorilas aparecían situados sobre edificios de una ciudad generada aleatoriamente, cada jugador introducía mediante teclado el ángulo y la velocidad del lanzamiento y el ordenador calculaba entonces la trayectoria del proyectil y representaba el vuelo del plátano sobre el horizonte urbano. El primer jugador que acertaba a su rival ganaba la ronda. No había música digitalizada, no existían niveles, ni siquiera una inteligencia artificial elaborada. Sin embargo, como ocurría con los mejores juegos de la época, la sencillez escondía una enorme profundidad, pues cada partida planteaba un problema balístico diferente que exigía observación, ensayo y corrección continua.

Desde el punto de vista matemático, GORILLA.BAS —formalmente, QBasic GORILLAS— era una clase práctica de física de secundaria disfrazada de videojuego. La posición del plátano se calculaba mediante ecuaciones de movimiento parabólico. El programa tenía en cuenta la velocidad inicial, el ángulo de disparo, la gravedad y una variable adicional que simulaba la fuerza del viento. En cada iteración se recalculaba la posición horizontal y vertical del proyectil, dibujándolo en pantalla mientras avanzaba sobre los edificios. Lo interesante es que aquellos cálculos se realizaban en tiempo real sobre procesadores que hoy resultarían ridículos, y un 8088 o un 286 funcionando a unos pocos megahercios era más que suficiente para ofrecer una simulación convincente.

Uno de los aspectos más brillantes del diseño era precisamente la implementación del viento. En la parte inferior de la pantalla aparecía una pequeña indicación visual (una flecha) que mostraba la dirección e intensidad. Matemáticamente, el viento actuaba como una aceleración horizontal añadida a la ecuación del movimiento. Un valor elevado podía convertir un disparo aparentemente perfecto en un completo desastre, y los jugadores experimentados aprendían a estimar rápidamente cuántos grados debían corregir el lanzamiento o cuánta velocidad adicional necesitaban aplicar para compensar la desviación. Sin darse cuenta, estaban realizando cálculos aproximados similares a los que utilizan disciplinas tan distintas como la artillería o la aeronáutica.

La ciudad también escondía más trabajo técnico del que podía parecer a simple vista, ya que los edificios no estaban dibujados manualmente, sino que cada partida generaba un skyline diferente mediante procedimientos aleatorios. El programa elegía alturas, anchuras y posiciones dentro de ciertos márgenes para construir una ciudad única en cada ronda. Las ventanas iluminadas se distribuían igualmente mediante números aleatorios, creando la sensación de una auténtica metrópolis nocturna. Esta generación procedural era especialmente llamativa en una época en la que la mayoría de escenarios de videojuegos estaban completamente predefinidos por los desarrolladores.

Los propios gorilas representaban una demostración técnica muy interesante. Los personajes no eran imágenes cargadas desde disco ni sprites acelerados por hardware. Estaban definidos dentro del código mediante matrices de datos que describían pixel a pixel su apariencia y, durante la ejecución, el código convertía esos datos en gráficos visibles sobre la pantalla. Cuando el gorila lanzaba un plátano, levantaba los brazos mediante una sencilla pero eficaz animación. Resulta sorprendente comprobar cómo unos pocos cientos de bytes podían transmitir tanta personalidad a un personaje tan rudimentario.

También merece atención la forma en que el juego gestionaba las colisiones. Cada fotograma verificaba si el plátano había impactado contra un edificio, un gorila o había abandonado los límites de la pantalla. Cuando se producía un choque, el programa utilizaba primitivas gráficas para generar una explosión circular que alteraba permanentemente el escenario. Los edificios podían quedar parcialmente destruidos, modificando las condiciones de los siguientes disparos. Este detalle, aparentemente menor, introducía un nivel de interacción con el entorno que muchos títulos más sofisticados no ofrecían por aquella época. (¿Y que decir con la colisión con el sol? Dejamos este asunto para que el lector lo descubra por sí mismo).

A nivel gráfico, GORILLA.BAS aprovechaba las capacidades disponibles en CGA, EGA y VGA utilizando exclusivamente las funciones del lenguaje BASIC. Todo el dibujo se realizaba mediante comandos como LINE, CIRCLE, PAINT y PSET. Quien abría el código descubría que detrás de los edificios, los gorilas y las explosiones no existía ningún motor gráfico secreto; todo eran llamadas relativamente sencillas combinadas con ingenio y paciencia. Precisamente ahí radicaba gran parte de su valor educativo. El usuario comprendía que los videojuegos no eran magia, sino algoritmos.

Quizá el aspecto más importante de GORILLA.BAS fue su influencia silenciosa sobre una generación de aficionados. Miles de futuros programadores modificaron el código para cambiar colores, alterar la gravedad, transformar los plátanos en misiles o aumentar el tamaño de las explosiones. Algunos añadieron nuevos tipos de edificios, otros intentaron incorporar sonido o marcadores más sofisticados. Sin saberlo estaban aprendiendo conceptos fundamentales sobre programación estructurada, gestión de memoria, gráficos, simulación física y depuración. Muchas vocaciones informáticas comenzaron precisamente ahí, examinando un programa real y atreviéndose a romperlo para descubrir cómo funcionaba.

Visto desde 2026, cuando los videojuegos manejan mundos abiertos de cientos de kilómetros cuadrados y millones de polígonos por segundo, GORILLA.BAS podría parecer una reliquia irrelevante. Sin embargo, su importancia histórica va mucho más allá de sus gráficos primitivos y representa una época en la que los ordenadores invitaban a la curiosidad, en la que el usuario podía acceder al código fuente de un programa, modificarlo y aprender de él.

GORILLA.BAS tampoco estaba solo. Formaba parte de una tradición de programas demostrativos que acompañaban a los intérpretes y entornos de desarrollo BASIC de Microsoft, distribuyéndose con su código fuente completo para que los usuarios pudieran estudiarlo y modificarlo a voluntad. Entre ellos destacaba NIBBLES.BAS, una adictiva variante multijugador de Snake que servía para enseñar técnicas de animación en tiempo real, captura de teclado y detección de colisiones, o DONKEY.BAS, el sencillo juego de conducción creado por Bill Gates y Neil Konzen para los primeros IBM PC, concebido como demostración de las capacidades gráficas y sonoras del BASIC de Microsoft. Junto a ellos existían otros ejemplos como MONEY.BAS y diversos programas de simulación, matemáticas y gráficos destinados a enseñar programación de una forma práctica y entretenida.

Aquel enfrentamiento entre dos gorilas lanzándose plátanos sobre edificios generados aleatoriamente era mucho más que un pasatiempo, era una puerta de entrada a la programación, una lección de matemáticas interactiva y una demostración de que, con unos pocos cientos de líneas de BASIC y mucha imaginación, era posible crear algo capaz de permanecer grabado en la memoria de varias generaciones de aficionados a la informática. Y eso, probablemente, tiene mucho más mérito que muchos videojuegos multimillonarios de nuestros días.

Podemos descargar el juego, y también jugar online, desde la web de Internet Archive, concretamente desde su repositorio en https://archive.org/details/GorillasQbasic#.