Cómo funciona
Una implementación compatible intenta ocupar el mismo lugar que otra dentro de un ecosistema. Su unidad de éxito no es una función aislada, sino la sustituibilidad: ¿arranca el mismo software?, ¿acepta los mismos archivos?, ¿responde a los mismos periféricos?, ¿conserva macros, controladores o hábitos de usuario? “Clon compatible” fue un nombre comercial e histórico frecuente cuando el nuevo producto reproducía una plataforma reconocible; no implica necesariamente identidad física ni copia literal. La compatibilidad debe expresarse con dirección y alcance —compatible con qué versión, para qué consumidores y en qué capa— porque dos sistemas pueden ser compatibles para aplicaciones y no para controladores, o leer datos sin reproducir la interfaz de usuario.
El proceso construye una matriz de dependencias del ecosistema y prioriza las que permiten sustitución. Se implementan interfaces, formatos, firmware y conductas; se ejecutan programas representativos; las diferencias se clasifican como defectos, extensiones o límites declarados. A veces hay que conservar peculiaridades no documentadas. Si una aplicación popular depende de un error del referente, ese error dejó de ser un detalle puramente interno y pasó a ejercer presión sobre la frontera observable. Compatibilidad no equivale, por tanto, a cumplimiento abstracto de una especificación.
El caso IBM PC
El IBM PC combinó componentes relativamente disponibles con una BIOS cuya conducta esperaba el software. Columbia Data Products lanzó en 1982 el MPC, que el Computer History Museum identifica como el primer clon de IBM PC, recreando una BIOS equivalente en un entorno limpio. Compaq anunció el Portable en noviembre de 1982 y lo distribuyó en 1983; su propuesta de “compatibilidad” significaba que el computador móvil podía usar la inversión ya hecha en software IBM PC. Phoenix dio el siguiente paso en mayo de 1984 al ofrecer una ROM BIOS compatible que otros fabricantes podían licenciar, convirtiendo una costosa reimplementación por empresa en un componente del mercado. Estas implementaciones sustituyeron placa, carcasa y BIOS concreta, mientras conservaron suficientes convenciones de hardware y firmware para integrarse en el mismo ecosistema.
Ese episodio conecta Clean-room implementation y clon compatible sin fusionarlos. Clean room fue un método de procedencia para una parte crítica; “compatible” fue la propiedad que el producto ofrecía a usuarios y desarrolladores. Un fabricante también podía licenciar una BIOS, copiarla indebidamente o lograr compatibilidad parcial por otras vías. El adjetivo no revela el método ni certifica su situación jurídica.
Compatibilidad sin clon total
Wine es una capa capaz de ejecutar aplicaciones Windows sobre sistemas POSIX, no una copia de Windows ni una máquina virtual completa. ReactOS persigue compatibilidad de aplicaciones y controladores con una arquitectura de sistema similar a Windows y reconoce que su cobertura sigue incompleta. Ambos muestran compatibilidad por capas: Wine sustituye principalmente APIs de espacio de usuario y traduce llamadas; ReactOS busca además una plataforma de sistema operativo. Una API reimplementada o una reimplementación de protocolo puede habilitar compatibilidad, pero sólo el alcance efectivamente cubierto permite hablar de sustitución.
Frente a Porting, el consumidor heredado permanece quieto: en un clon compatible, el nuevo entorno se adapta para recibir software existente; al portar, se modifica el software para otro entorno. Frente a Functional reimplementation, “compatible” enfatiza dependientes externos y reemplazo dentro de una red de complementos. Ninguno de estos términos determina por sí mismo copyright, patentes, contratos, marcas o secretos.
Operación de inventiva
La operación consiste en conservar una posición relacional: no el objeto original entero, sino los acoplamientos por los que otros objetos lo reconocen. Exige identificar qué dependencias son constitutivas del ecosistema y cuáles pueden romperse o traducirse. La sustitución se vuelve posible cuando suficientes vecinos no necesitan saber que el interior cambió.
Fuentes
- Computer History Museum. “Columbia personal computer”. Ficha del MPC de 1982, su condición de primer clon y la BIOS equivalente recreada en entorno clean room. https://www.computerhistory.org/revolution/personal-computers/17/302/1188
- Computer History Museum. “The Boston Computer Society: Dawn of the Business Personal Computer and Cost-Efficient Home PC”. Presentación histórica de Compaq y el valor comercial de la compatibilidad con sistemas de trabajo. https://computerhistory.org/blog/bcs-1982-dawn-of-the-business-personal-computer-and-cost-efficient-home-pc/
- Mike Boston y Paul Narushoff. System BIOS for IBM PC/XT/AT Computers and Compatibles. Addison-Wesley / Phoenix Technologies, 1989, prólogo de Neil Colvin sobre la ROM BIOS de mayo de 1984 y su método clean room. https://bitsavers.org/pdf/ibm/pc/ps2/bios/System_BIOS_for_IBM_PC_XT_AT_Computers_and_Compatibles_198908.pdf
- WineHQ. “About Wine”. Alcance de la capa de compatibilidad, traducción de APIs e historia desde 1993. https://www.winehq.org/about
- ReactOS Project. “FAQ”. Objetivo de ejecutar aplicaciones y controladores Windows, junto con la advertencia sobre cobertura incompleta. https://reactos.org/faq/
- ReactOS Project. “30 years of ReactOS”. 22 de enero de 2026. Cronología desde FreeWin95, cambio de objetivo hacia Windows NT y evolución del proyecto. https://reactos.org/blogs/30yrs-of-ros/
- Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000). Ejemplo de compatibilidad con juegos de otra plataforma mediante un producto nuevo. https://law.justia.com/cases/federal/appellate-courts/F3/203/596/474793/