Entradas de la categoría ‘Informática en general’

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.

Cuando pensamos en las grandes innovaciones de la informática clásica solemos imaginar microprocesadores cada vez más rápidos, discos duros con capacidades que entonces parecían imposibles o tarjetas gráficas capaces de poner más colores y píxeles en pantalla. Sin embargo, durante los años ochenta existió otra clase de innovación bastante menos sofisticada que podía duplicar, al menos en determinadas máquinas, la capacidad útil de nuestros disquetes. La tecnología necesaria no podía ser más sencilla: hacer una muesca adicional en un trozo de plástico. Y no se trataba simplemente de una chapuza doméstica, porque llegó a existir una pequeña industria dedicada a fabricar herramientas cuya única misión consistía en practicar ese corte exactamente en el lugar adecuado.

Para entender por qué aquello funcionaba hay que regresar a la época de los disquetes flexibles de 5¼ pulgadas. Ordenadores como el Commodore 64, el Apple II y otros muchos sistemas domésticos utilizaban unidades que, en determinados modelos, disponían de una sola cabeza de lectura y escritura. Eso significaba que la unidad únicamente podía acceder a una de las superficies magnéticas del disco mientras este se encontraba introducido en su posición normal. Si queríamos utilizar la otra cara, la cabeza no podía desplazarse mágicamente hasta ella porque, sencillamente, no había una segunda cabeza al otro lado.

Dentro de la funda cuadrada de un disquete de 5¼ pulgadas había un disco circular flexible, normalmente fabricado con una base de poliéster y recubierto con material magnético. Aunque un disquete se comercializase como single sided, o de una sola cara, físicamente existía otra superficie magnética al otro lado. Ello no significaba necesariamente que el fabricante hubiese probado y certificado esa segunda superficie para almacenar datos con la misma fiabilidad, pero sí abría una posibilidad bastante evidente para cualquiera que se parase a pensar cómo funcionaba la unidad, ya que, si la cabeza sólo podía acceder a una cara, quizá bastaba con sacar el disco, darle la vuelta y volver a introducirlo.

Eso fue exactamente lo que empezaron a hacer muchos usuarios. Una vez llena la primera cara, extraían el disquete, lo giraban físicamente e intentaban utilizar la superficie posterior como si se tratase de otro disco completamente diferente. Desde el punto de vista magnético, la idea tenía sentido, pero existía un pequeño inconveniente mecánico. Las unidades de 5¼ pulgadas no se limitaban a leer el material magnético, sino que también utilizaban determinadas características de la funda exterior para saber cómo tratar el soporte que acababa de introducir el usuario.

Además de la gran abertura central y de la ventana longitudinal por la que la cabeza entraba en contacto con la superficie magnética, los disquetes podían incorporar otras referencias físicas. Una de las más importantes para esta historia era la muesca lateral utilizada por el mecanismo de protección contra escritura. Dependiendo del diseño de la unidad, la presencia o ausencia de esa abertura indicaba si estaba permitido modificar el contenido del disco. Cuando se daba la vuelta al soporte, la muesca original quedaba en el lado contrario y dejaba de encontrarse donde la unidad esperaba verla.

La solución consistió en practicar otra muesca en posición simétrica. De esta manera, al girar físicamente el disquete, la unidad volvía a encontrar la abertura en el lugar adecuado y permitía escribir sobre la segunda superficie. La modificación no aumentaba la densidad del soporte, no alteraba electrónicamente la unidad y tampoco activaba ninguna característica oculta del material magnético; simplemente engañaba a un mecanismo de detección extraordinariamente sencillo para permitir que el disco fuese utilizado en una orientación para la que su funda no había sido preparada originalmente.

Así nacieron los llamados flippy disks, cuyo nombre describía perfectamente su funcionamiento. Cuando una cara estaba llena, el usuario sacaba el disquete, le daba la vuelta —flip— y continuaba utilizando la otra superficie. En las máquinas compatibles, cada cara podía tratarse prácticamente como un disco independiente, de modo que un sencillo corte en la carcasa permitía obtener aproximadamente el doble de almacenamiento aprovechable.

Uno de los sistemas en los que esta práctica se hizo especialmente popular fue Commodore 64 con su unidad Commodore 1541. Un disquete formateado normalmente por la 1541 podía almacenar alrededor de 170 KB por cara, de manera que convertirlo en flippy permitía disponer de dos superficies independientes y superar los 300 KB de capacidad total. Visto desde un ordenador actual parece una cantidad ridícula, pero en aquella época 170 KB podían contener numerosos programas, documentos, partidas guardadas o una colección considerable de pequeños archivos.

La 1541, además, tenía una característica que facilitaba considerablemente el truco. Algunas unidades de disquete utilizaban el denominado agujero de índice, una perforación de referencia que, junto con un sensor de la unidad, permitía conocer la posición angular del disco durante su rotación. En sistemas que dependían de este mecanismo, darle la vuelta al soporte podía provocar problemas porque la geometría de las perforaciones dejaba de coincidir con la posición esperada. El sistema utilizado por la unidad Commodore 1541 no dependía de ese agujero de índice de la misma manera, ya que obtenía la sincronización necesaria a partir de la información grabada magnéticamente en las pistas. Aquello convertía a la unidad de Commodore en una candidata especialmente apropiada para utilizar discos invertidos.

La famosa muesca lateral, por su parte, tenía una función mucho más sencilla de lo que podría sugerir el truco, y es que estaba relacionada con la protección contra escritura. En muchos disquetes de 5¼, la unidad detectaba aquella abertura para determinar si podía grabar información. Si el usuario quería proteger el contenido, había de cubrir la muesca con una pequeña pegatina opaca, evitando así que la unidad autorizase operaciones de escritura. Al darle la vuelta al disquete, la abertura original dejaba de estar en la posición esperada, por lo que crear una segunda muesca simétrica permitía recuperar la posibilidad de escribir en la cara invertida.

Como ocurre con casi cualquier truco informático suficientemente popular, alguien terminó viendo una oportunidad comercial. Aparecieron herramientas diseñadas específicamente para convertir disquetes normales en flippy disks, conocidas habitualmente como disk notchers o diskette notchers. Su aspecto recordaba a una mezcla entre unos alicates, una grapadora y una perforadora de oficina. El usuario introducía el borde del disquete, apretaba la herramienta y esta retiraba un pequeño fragmento de plástico exactamente en la posición necesaria. No había electrónica, motores, circuitos ni ninguna clase de comunicación con el ordenador. Era, en esencia, un sacabocados especialmente preciso para disquetes.

Naturalmente, los propietarios de ordenadores domésticos de los años ochenta tampoco eran conocidos por comprar un accesorio especializado cuando el mismo resultado podía conseguirse con lo que hubiera por casa. Las perforadoras comerciales convivieron con toda clase de soluciones artesanales, y tijeras, cúteres, perforadoras de cuero, pequeñas limas, alicates modificados y plantillas caseras terminaron utilizándose para fabricar flippy disks. Un procedimiento bastante lógico consistía en tomar otro disco como referencia, marcar cuidadosamente la posición equivalente en el lado contrario y retirar una pequeña sección de la funda.

Había que hacerlo con cierto cuidado, porque dentro de aquella aparentemente robusta carcasa de plástico se encontraba una superficie magnética bastante más delicada. Un corte excesivamente profundo podía alcanzar el disco propiamente dicho, y dejar pequeños restos de plástico dentro de la funda tampoco era una idea particularmente buena. El soporte giraba a varios cientos de revoluciones por minuto y la cabeza trabajaba muy cerca de su superficie, así que introducir fragmentos de plástico, polvo o suciedad podía convertir un intento de ahorrar dinero en una excelente forma de destruir datos. Aun así, muchos usuarios adquirieron bastante práctica y algunos discos modificados artesanalmente presentaban un acabado sorprendentemente limpio. Otros parecían haber sido abiertos con los dientes, pero mientras la muesca estuviera aproximadamente en el lugar correcto podían funcionar exactamente igual.

La cuestión más discutible era si la segunda cara de un disquete vendido como de una sola cara resultaba realmente tan fiable como la primera. Que existiese material magnético por ambos lados no significaba necesariamente que las dos superficies hubieran pasado los mismos controles de calidad. La industria distinguía entre soportes single sided y double sided, y un fabricante podía certificar únicamente la superficie destinada oficialmente a almacenar información. La cara posterior podía funcionar perfectamente, presentar algunos defectos o empezar a producir errores después de cierto tiempo.

En la práctica, muchos usuarios comprobaron que una gran cantidad de discos de una cara podían formatearse y utilizarse por ambos lados sin ningún problema aparente. Aquello alimentó durante años la discusión sobre hasta qué punto existían diferencias reales entre determinados modelos comercializados como de una o de dos caras. La respuesta dependía del fabricante, de la época, del proceso de producción y de los controles de calidad aplicados. No era correcto asumir que todos los disquetes de una cara eran simplemente modelos de doble cara vendidos más baratos, pero tampoco era raro encontrar unidades cuya segunda superficie funcionaba sin inconvenientes.

La filosofía doméstica solía ser bastante pragmática: si la segunda cara podía formatearse, superar una verificación y guardar archivos sin producir errores, se utilizaba. Probablemente no era el lugar ideal para conservar la única copia existente de un trabajo importante, pero para juegos, programas fácilmente recuperables, copias temporales o software intercambiado entre amigos resultaba difícil resistirse a la posibilidad de obtener el doble de espacio sin comprar más discos.

Para comprender hasta qué punto podía resultar atractivo hay que situarse en la economía informática de principios y mediados de los años ochenta. El almacenamiento era caro y los discos duros se encontraban fuera del alcance de buena parte de los propietarios de microordenadores domésticos. Una colección de unas decenas o centenares de disquetes podía representar prácticamente todo el archivo digital de una persona. Programas, juegos, documentos y copias de seguridad ocupaban un soporte físico que había que comprar, etiquetar, ordenar y conservar. Si una caja de diez disquetes podía proporcionar, a efectos prácticos, veinte superficies independientes de almacenamiento, el ahorro resultaba evidente. Para estudiantes, aficionados y usuarios que intercambiaban constantemente programas, la diferencia tenía bastante más importancia que la que podemos imaginar desde un mundo en el que una diminuta tarjeta de memoria almacena millones de veces más información.

Además, un flippy disk no era exactamente equivalente a un disquete convencional de doble cara utilizado en una unidad de dos cabezas. En el primero, las superficies podían funcionar como dos discos independientes y era necesario invertir físicamente el soporte para pasar de una a otra. En una unidad de doble cara, en cambio, el hardware podía acceder a las dos superficies sin intervención del usuario. Esta diferencia explica también por qué algunos programas comerciales llegaron a distribuirse en discos que debían darse la vuelta manualmente. En determinados ecosistemas aquello dejó de ser un truco de aficionados y se convirtió en una forma perfectamente normal de distribuir software.

Los flippy disks resultan especialmente interesantes porque pertenecen a una clase de trucos informáticos que hoy parece casi arqueológica. No había que modificar el firmware, parchear el sistema operativo, instalar un controlador ni escribir una sola línea de código. El truco consistía en comprender la interacción entre el soporte físico, la unidad y sus sensores y modificar unos pocos milímetros de plástico para conseguir que el hardware aceptase algo que su diseño exterior no contemplaba directamente. Esa forma de enfrentarse a las limitaciones era muy característica de la microinformática de los años setenta y ochenta. Las máquinas tenían unas capacidades extremadamente reducidas comparadas con las actuales, pero muchos de sus mecanismos eran suficientemente visibles y comprensibles como para que un usuario curioso pudiera investigar cómo funcionaban. Era posible abrir el ordenador, estudiar sus conectores, observar cómo giraba un disquete, averiguar para qué servía cada abertura de la funda y terminar descubriendo que un problema de almacenamiento podía resolverse con una modificación puramente mecánica.

Y es por todo ello que ahí residía buena parte del encanto de los flippy disks. No añadían transistores, no aumentaban la frecuencia del procesador, no inventaban un nuevo sistema de codificación magnética y ni siquiera modificaban realmente la capacidad física del medio. Se limitaban a aprovechar una característica que ya estaba allí y que las limitaciones mecánicas de determinadas unidades dejaban sin utilizar. Miles de usuarios descubrieron que, en algunos ordenadores, la frontera entre quedarse sin espacio y disponer prácticamente del doble podía depender de retirar unos pocos milímetros de plástico. Y pocas veces en la historia de la informática se ha conseguido tanto haciendo, literalmente, un agujero en el sitio correcto.

Hubo una época en la que la mayoría de la gente compraba un ordenador sin saber demasiado qué se escondía bajo aquella carcasa beis que ocupaba medio escritorio. Se hablaba de los megas de memoria, del tamaño del disco duro o de si la tarjeta de sonido era capaz de reproducir decentemente las explosiones del último juego de moda, pero el procesador era un componente prácticamente invisible para el usuario medio. Estaba ahí, escondido bajo disipadores, manuales y términos técnicos que pocos entendían y menos aún necesitaban comprender.

A principios de los años noventa, Intel tuvo una idea tan sencilla que hoy parece obvia, aunque en aquel momento resultaba casi revolucionaria. La empresa no vendía ordenadores completos al gran público, sino los chips que utilizaban los fabricantes para construirlos, sobre todo microprocesadores de CPU y coprocesadores matemáticos. Sin embargo, decidió que ya no le bastaba con que las marcas de los equipos conocieran sus productos, también quería que los conociera el comprador que paseaba por una tienda sin tener la menor idea de arquitecturas informáticas.

La estrategia fue sobresaliente. La compañía estadounidense comenzó a financiar campañas publicitarias junto a los fabricantes de ordenadores con una condición muy simple, que el nombre de Intel apareciera claramente asociado al producto. De aquella operación nacería uno de los eslóganes más reconocibles de la historia de la tecnología: ‘Intel Inside‘. Lo que parecía una campaña más, terminó convirtiéndose en un fenómeno cultural que transformó la forma de vender componentes informáticos.

La famosa pegatina comenzó entonces a adherirse en millones de equipos. Daba igual que el ordenador fuera de IBM, Compaq, Olivetti, Inves o cualquier ensamblador local de barrio, allí estaba aquella etiqueta brillante colocada en un lugar eminentemente visible de la torre o del portátil. Lo curioso es que muy poca gente sabía exactamente qué significaban los números y letras que acompañaban al logotipo, pero eso tampoco importaba demasiado. La pegatina transmitía confianza incluso a quienes no entendían nada de procesadores.

En poco tiempo ocurrió algo insólito. Los usuarios comenzaron a hablar de Intel como si fuera una marca de consumo corriente. De la noche al día surgieron conversaciones en las que alguien presumía de tener un «486», un «Pentium» o un «Pentium II» del mismo modo que otros presumían de coche nuevo. La mayoría no habría sabido explicar qué ventajas técnicas ofrecía cada modelo respecto al anterior, pero sí había aprendido que uno era mejor que otro y que Intel representaba lo deseable.

Aquello generó una situación bastante peculiar para la competencia. Empresas como AMD, Cyrix o IBM también fabricaban procesadores capaces de competir con Intel e incluso de superarla en determinados momentos. Sin embargo, en la mente de muchos compradores existía una asociación casi automática entre ordenador de calidad y procesador Intel. No era raro encontrar clientes que acudían a una tienda pidiendo expresamente «un ordenador Pentium» sin conocer una sola de sus características técnicas.

Lo más divertido era la relación emocional que muchos usuarios desarrollaron con aquella pequeña pegatina. Los ordenadores podían llenarse de polvo, amarillear con los años o sobrevivir a varias mudanzas, pero la etiqueta seguía ahí, perfectamente conservada. Había quien incluso mantenía intacto el plástico protector transparente durante años para evitar que se rayara. Parecía más un símbolo de prestigio que una simple indicación técnica.

En realidad, Intel había entendido algo fundamental sobre el comportamiento de los consumidores, y es que la mayoría de las personas no quieren estudiar complejas especificaciones técnicas antes de comprar tecnología, lo que buscan es una referencia sencilla que les permita sentir que están tomando una decisión segura. ‘Intel Inside’ funcionó precisamente porque resumía toda esa complejidad en una idea muy fácil de comprender: si lleva esta pegatina, debe de ser bueno.

Así pues, desde un punto de vista psicológico, el fenómeno de ‘Intel Inside’ demuestra que las personas no siempre tomamos decisiones basándonos en el conocimiento técnico, sino en símbolos que nos transmiten seguridad y pertenencia. Aquella pequeña pegatina funcionaba como una especie de certificado social. Pocos usuarios podían explicar qué hacía realmente un procesador, pero muchos experimentaban una sensación de tranquilidad al ver el logo de Intel en la carcasa. En cierto modo, la marca consiguió convertir un componente invisible en un elemento de identidad, permitiendo que los compradores sintieran que estaban tomando una decisión informada sin necesidad de comprender la complejidad que había detrás. Es el mismo mecanismo por el que algunos consumidores prefieren determinadas marcas de coches, relojes o teléfonos móviles: no adquieren únicamente un producto, sino también la confianza, el estatus y la tranquilidad asociados a él. Intel no vendía procesadores en aquella época, vendía la sensación de estar comprando «el procesador bueno», y pocas campañas de marketing han logrado manipular con tanta elegancia un comportamiento tan profundamente humano.

Con el tiempo, la tecnología evolucionó y el mercado cambió por completo, pero la estrategia dejó una huella enorme. Muchas de las campañas modernas siguen utilizando exactamente la misma fórmula. Cuando Apple presume de sus chips M, AMD destaca sus Ryzen o NVIDIA hace lo propio con GeForce, en el fondo están intentando reproducir aquella misma conexión emocional entre un componente interno y la percepción del usuario final.

Quizá por eso, la pegatina ‘Intel Inside’ ocupa un lugar tan especial en la memoria colectiva de quienes crecieron rodeados de ordenadores en los noventa. No era la pieza más importante del equipo ni la más sofisticada, pero consiguió algo mucho más difícil, convertirse en un icono reconocible para millones de personas que jamás habían visto un procesador. Y eso tiene bastante mérito para una empresa cuyo producto, por definición, estaba diseñado para permanecer oculto dentro de una caja cerrada.

Antes de que proliferaran los espacios de coworking llenos de MacBooks plateados y café de especialidad, existieron unos emplazamientos de culto y perdición conocidos como cibercafés, lugares extraños, oscuros y ligeramente decadentes donde convivían gamers jugando al ‘Counter-Strike’, chavales descargando nuevas ROM de Neo Geo, universitarios imprimiendo trabajos cinco minutos antes de entregarlos y personajes bastante sospechosos, que parecían llevar allí sentados desde siempre, copiando comandos del recién aparecido Nmap en un artículo de la revista ‘Phrack Magazine’.

Durante unos años, ya irrepetibles, los cibercafés fueron el verdadero corazón físico de la cultura underground de Internet. Reconvertidos de los antiguos locutorios pero con el tufillo de las salas de recreativos de los años ochenta, entrar en uno de aquellos locales era acceder a una dimensión paralela. El olor era una mezcla de tabaco incrustado en las paredes, plástico caliente de monitores CRT y comida recalentada. El sonido dominante era un caos glorioso compuesto por ventiladores de Pentium III, teclados mecánicos baratos aporreados con violencia y el ruido inconfundible de decenas de partidas de ‘Quake III Arena’ simultáneas. Había pantallas por todas partes mostrando escritorios de Windows 98, Windows 2000 o XP llenos de iconos sospechosos y salvapantallas de ‘The Matrix’.

Muchos cibercafés empezaron simplemente ofreciendo acceso a Internet por horas, algo revolucionario en una época en la que la mayoría de la gente todavía navegaba mediante módems de 56K (los más afortunados) pagando a precio de oro las llamadas telefónicas. Poder conectarte con ADSL o RDSI era casi ciencia ficción. Pero rápidamente aquellos sitios evolucionaron hacia algo mucho más importante: se convirtieron en puntos de encuentro de la escena informática underground. Allí se compartían cedés grabados, herramientas, tutoriales, cracks, exploits y conocimientos técnicos que rara vez aparecían en sitios «oficiales».

Las máquinas eran auténticas bestias para la época: torres de color beis gigantescas con pegatinas de NVIDIA, Sound Blaster o Iomega, monitores de tubo con un culo enorme de 17 pulgadas capaces de freírte la retina o ratones ópticos recién llegados que sustituían lentamente a los de bola y su acumulación incesante de pelusas. Y debajo del escritorio, casi siempre, una maraña infernal de cables ethernet conectados a hubs o switches que parpadeaban constantemente. Algunos locales más avanzados montaban auténticas LAN parties permanentes con redes a 100 Mbps que parecía tecnología militar comparada con el Internet doméstico de aquel entonces.

Pero el verdadero espectáculo ocurría dentro de los sistemas operativos. Muchas máquinas estaban completamente destrozadas tras semanas de uso salvaje, de barras de herramientas imposibles instaladas en Internet Explorer, de Kazaa ejecutándose permanentemente en segundo plano, de Winamp reproduciendo trance alemán y de carpetas compartidas llenas de material dudoso, muy dudoso. Los administradores vivían una guerra constante intentando limpiar virus, troyanos y spyware. Y perdían siempre.

Porque sí, los cibercafés eran auténticos laboratorios biológicos de malware. Disquetes, discos CD-ROM y memorias USB pasaban de una máquina a otra infectando todo lo que encontraban. Gusanos como Blaster, Sasser o Mydoom campaban a sus anchas por redes locales mal configuradas, mientras Norton y Panda consumían más de la mitad de la RAM de los equipos intentando contener el desastre. Muchas veces bastaba con sentarte en un PC para heredar veinte troyanos distintos en menos de media hora.

Y aun así, precisamente por ese caos, muchísima gente aprendió allí cómo funcionaban realmente los ordenadores. Los cibercafés eran universidades no oficiales de los bajos fondos digitales. El típico muchacho que iba inicialmente a jugar en línea terminaba descubriendo el correo electrónico y Eudora, luego aprendía a usar un FTP pirata, después comenzaba a tocar scripts de mIRC y acababa investigando sobre redes, Linux o programación en C. Existía una transmisión constante de conocimiento informal entre usuarios; todo el mundo enseñaba algo a alguien.

Los administradores de los cibercafés eran personajes fascinantes. Algunos parecían simples dueños de negocio, pero otros claramente habían salido de la BBS ‘Galletas’ o de algún oscuro grupo de la jerarquía alt.* de Usenet. Lo mismo reinstalaban un Windows XP en veinte minutos, que crimpaban cables RJ45 como si fueran cirujanos o mantenían en orden sus colecciones absurdas de cederrones grabados con utilidades, drivers y software pirata. Eran individuos que miraban siempre hacia otro lado.

Había también una dimensión social muy peculiar, y es que mucha gente vivió sus primeras experiencias reales en Internet desde un cibercafé: primeras partidas online interminables de ‘Age of Empires II’ en red local, primeras descargas eternas de eMule, primeras conversaciones en IRC o primeros ligues digitales con nicks de todo punto disparatados en Terra Chat o LatinChat, donde media adolescencia descubrió que hablar con desconocidos a través de una pantalla resultaba muchísimo más fácil que hacerlo cara a cara. Mucha gente creó allí su primer correo electrónico, abrió su primera cuenta de Messenger o descubrió por primera vez que existían comunidades enteras de personas obsesionadas con exactamente las mismas rarezas que ellos.

La escena española de principios de siglo estaba profundamente ligada a estos sitios. En España, a mediados de la década de 1990, abrió en Oviedo el establecimiento ‘Laser Internet Center’, descrito por la agencia Europa Press como el primer local dedicado al acceso público a Internet del país. En ese mismo periodo surgieron, en ciudades como Madrid, locales orientados al ocio tecnológico que popularizaron el término «cibercafé» en su sentido social. Allí circulaban decenas de CD de Wifislax antes de que la gente supiera siquiera qué era GNU/Linux, allí se compartían versiones modificadas de programas, paquetes de exploits, tutoriales para romper WEP y colecciones gigantescas de software descargado mediante Direct Connect o eDonkey. Algunos cibercafés incluso tenían pequeñas redes internas clandestinas para compartir archivos localmente a velocidades descabelladamente rápidas (para la época).

Con la llegada del ADSL barato y la expansión del Internet doméstico, muchos cibercafés empezaron a desaparecer, ya que no tenía sentido pagar por conectarte cuando cualquiera podía tener banda ancha en casa a un precio fijo —la conocida como «tarifa plana»— . Después llegaron Steam, Discord y las redes sociales modernas, que terminaron de matar aquella cultura física y local.

Pero durante unos años gloriosos y caóticos, los cibercafés fueron mucho más que negocios. Fueron pequeños nodos cyberpunk donde nació gran parte de la cultura informática underground de toda una generación.

Estamos de acuerdo en que siempre existe un elemento de riesgo a la hora de respaldar una campaña de crowdfunding, incluso aunque dicha campaña esté respaldada por una figura mítica del mundo de la tecnología ochentera —como es Clive Sinclair— o, incluso, aunque el mecenazgo esté sobrefinanciado, algo que siempre parece ser un punto a favor para la credibilidad de la operación. Siempre hay una posibilidad de que la empresa no llegue a buen puerto, y el Sinclair ZX Spectrum Vega Plus es un ejemplo brillante de ello.

El crowdfunding en Indiegogo del Vega+ rompió su objetivo de financiación y, para el 27 de marzo del año 2016, contaba con un 367% de recaudación con respecto a la cifra original solicitada (100.000 £). Ganando el respaldo de Sir Clive Sinclair y teniendo detrás a la compañía Retro Computers Ltd., que ya había hecho ver la luz (con éxito) un año antes al hermano mayor de esta consola portátil, el Sinclair ZX Spectrum Vega (sin Plus), todo apuntaba a que la maquinita iba a ser un éxito de mercado sin precedentes; ¿quién no quiere jugar a sus legendarios juegos de ZX Spectrum en una portátil con un diseño de lujo? El retro y la nostalgia mandan.

Sin embargo, los problemas comenzaron a aparecer. Lo que iba a ser liberado en octubre del propio 2016, comenzó a retrasarse hasta llegar a febrero de 2017. Pero eso no es del todo un contratiempo, siempre y cuando los responsables sepan comunicar correctamente el progreso y las trabas a los patrocinadores, y es precisamente lo que no ha ocurrido aquí: problemas empresariales que llegan por boca de terceros, muy escasas imágenes del desarrollo del producto o simplemente diseños renderizados, fotos con pantallas rotas y planteamientos totalmente distintos al original, nulo intercambio de mensajes entre los desarrolladores y los mecenas, parca información sesgada y un largo etcétera.

Al final, y entrados ya en marzo, los aportadores a este crowdfunding se han hartado y han comenzado a pedir la devolución de su dinero sin más pretexto, disculpa ni subterfugio. La reacción de Indiegogo ha sido fulminante, cerrando unilateralmente el micromecenazgo del Vega+ y dando carpetazo a esta tomadura de pelo de manera tajante.

Los detalles sórdidos de esta problemática campaña fueron dados a conocer ayer mismo en una explosiva investigación de la BBC. Según el artículo, Retro Computers Ltd. pidió a la BBC que retrasara su cobertura debido a «amenazas creíbles de violencia» contra los empleados de la compañía. La BBC ha asegurado que ha pospuesto la publicación del artículo para proporcionar a Retro Computers Ltd. la oportunidad de compartir pruebas de las amenazas, cosa que no se ha producido.

Suponemos que esto se ha ido al traste definitivamente. Y es una pena, porque el proyecto era bonito, entrañable y atractivo, aunque no todas las voces del entorno retrotecnológico estén de acuerdo con esta afirmación. Desde luego, para hacer lo que han hecho, habría sido mejor que ni siquiera hubieran empezado. Siempre nos quedará una Nintendo DSi XL con el emulador ZXDS de Spectrum, hoy por hoy, la mejor forma —portátil— de disfrutar de nuestros míticos títulos del gomas con harta diferencia.