Lo que Mage-OS le da y Magento y Adobe Commerce no

Mage-OS no es una plataforma distinta. Es una distribución de Magento Open Source, construida sobre el mismo código y que actualmente sigue la línea 2.4.9, y su base de datos, su tema, sus extensiones y sus integraciones se comportan igual que ahora.

Las ventajas son más estrechas que en una comparación de plataformas y bastante más concretas que el argumento de la gobernanza que suele abrir esta conversación. Dos son funciones que Adobe solo vende con una licencia Commerce. Varias más son módulos que no existen ni en Magento ni en Adobe Commerce. Una es un tema de admin de sustitución, que es lo primero que la gente nota de verdad.

Dos funciones por las que Adobe cobra

Mage-OS 3.0 llegó en mayo de 2026 sobre la base 2.4.9, e incluye dos módulos que Adobe reserva para Adobe Commerce.

El primero son las devoluciones. mage-os/module-rma permite a los clientes abrir una devolución desde su cuenta y da a los comerciantes un sitio donde revisarla, aprobarla y responder al cliente. La propia documentación de Adobe sobre devoluciones lleva una etiqueta de disponibilidad que dice: «This is an exclusive feature that is available only in Adobe Commerce and is not available in Magento Open Source».

El segundo es mage-os/module-admin-activity-log, que registra quién cambió qué y cuándo. Las páginas de Action Logs de Adobe llevan esa misma etiqueta.

En Magento Open Source los dos se compran en el Marketplace o se construyen. Ninguna de las dos capacidades es exótica y existen extensiones comerciales para ambas, así que nada de esto era inalcanzable. Lo que elimina son dos partidas del presupuesto de extensiones de cualquier tienda que necesite gestionar las devoluciones dentro del admin, o un registro de auditoría por cumplimiento normativo.

Una salvedad que querríamos que cualquier cliente oyera: son implementaciones de Mage-OS. El código de Adobe no se movió. No hemos hecho una comparación en profundidad de ninguna de las dos contra los originales de Commerce, así que si deja Commerce precisamente para conservar el RMA, pruébelo contra su proceso real de devoluciones antes de comprometerse.

Cosas que no tienen ni Magento ni Adobe Commerce

Esta es la parte que se queda fuera de la mayoría de las comparaciones, y en una tienda que ya ejecuta Open Source es el argumento más fuerte a favor de la distribución.

Mage-OS mantiene un Lab, un espacio abierto donde se incuban módulos de la comunidad, y Mage-OS 2.0, en octubre de 2025, pasó un lote de ellos a la propia distribución. Parte de lo que sigue es ingeniería propia de Mage-OS y parte es trabajo de terceros que agrupan y fijan; hemos indicado cuál es cuál, porque importa para saber quién lo mantiene. Nada de esto viene en Magento Open Source ni en Adobe Commerce.

El trabajo de rendimiento

Aquí hay tres piezas, y son lo bastante sustanciales como para tener su propio artículo, así que en breve.

La distribución fija creatuity/magento2-interceptors, que compila los interceptors de plugins de Magento a partir de la configuración estática, de modo que los métodos interceptados dejan de consultar la lista de plugins en tiempo de ejecución. Sus autores sitúan la ganancia en torno a un 10 % del tiempo de respuesta del servidor. Esa misma optimización se propuso a Magento hace años y nunca se integró, que es la ilustración más nítida que conozco de lo que una distribución de la comunidad publica y un proveedor no.

Mage-OS también hizo trabajo propio en el núcleo con los objetos lazy-ghost de PHP 8.4 en la factoría de DI, eximiendo 74 clases a partir de telemetría y no de intuición. Y mage-os/module-theme-optimization activa la back/forward cache, la precarga por speculation rules y las view transitions, con una lista de exclusión que ya cubre el carrito y el checkout, para que no prerenderice una URL de añadir al carrito.

Cada cifra de ahí viene de quienes escribieron el código, así que verifíquela en su propia tienda antes de citársela a nadie. Y la mayoría se instalan perfectamente en un Magento normal. Lo que obtiene de Mage-OS es la selección y los valores por defecto.

Todo lo demás

El resto es una lista, y una realmente útil. Hay un módulo PCI DSS 4.0 que impone una contraseña de admin de 12 caracteres, un cierre por inactividad a los 15 minutos, la desactivación automática de cuentas inactivas y reglas de bloqueo más estrictas. Hay control de NOINDEX, NOFOLLOW y NOARCHIVE por página, para lo que cualquiera que haya gestionado la indexación de un catálogo grande ha comprado antes una extensión. La traducción del catálogo corre por cron a través de DeepL, OpenAI o Gemini y lleva la cuenta de lo que ya ha hecho. Una cuadrícula de reservas de inventario hace visibles las reservas en el admin, que suele ser la respuesta a «¿por qué dice agotado si tenemos cuarenta?». Page Builder gana widgets CMS con vista previa, más importación y exportación de plantillas con sincronización con Dropbox. El pie del admin le avisa cuando sale una versión nueva mediante una comprobación de Composer en segundo plano. Y hay un módulo de monitorización del rendimiento de la aplicación con un complemento para New Relic, ambos fijados.

Una cosa que conviene dejar clara, porque afecta a quién lo arregla cuando se rompe. Varios de estos son paquetes de código abierto de terceros que Mage-OS fija, no código escrito por la asociación: las políticas PCI son de Aligent, Varnish Extended es de Elgentos, las páginas de error de Ignition son de Swissup, el logo de admin personalizado es de element119, y n98-magerun2 lleva años siendo un proyecto propio. Seleccionar, integrar y fijar todo eso es trabajo real. No es lo mismo que la autoría, y el mantenimiento recae en los autores originales.

El tema de admin

Mage-OS Lab también produjo M137, una sustitución completa de la interfaz de admin de Magento. Es el elemento más visible de esta lista y el que casi nunca sale en la conversación.

M137 reconstruye el backend sobre la tipografía Inter y una paleta creada en el espacio de color HCT, con iconografía nueva para Mage-OS, Magento Open Source y Page Builder. Hay un M137 Design System publicado en Figma Community, que importa si construye pantallas de admin a medida y quiere que convivan con las de serie sin parecer un añadido.

El detalle que importa: no viene incluido. Lo instala usted, y el módulo conmutador es obligatorio junto con él:

composer require mage-os/theme-adminhtml-m137
bin/magento module:enable MageOS_ThemeAdminhtmlSwitcher
bin/magento setup:upgrade

El conmutador es la parte buena. Los usuarios del admin eligen el tema activo desde la configuración, así que puede ponérselo delante a una persona, dejar al resto del equipo en el tema de serie y retirarlo sin un deploy.

Conozca su procedencia antes de venderlo internamente, eso sí. M137 salió de Mage-OS Lab y lo construyó Artem Kozynets en buena parte en su tiempo libre. Mucho del mejor trabajo de este ecosistema ocurre exactamente así, y sigue siendo un perfil de mantenimiento distinto del de un módulo del núcleo incluido. Yo lo usaría sin problema y me lo pensaría dos veces antes de convertirlo en la interfaz diaria de un equipo de quince personas que no pueden volver atrás por su cuenta.

Aparte, la distribución sí incluye un módulo de logo de admin personalizado, así que la imagen del admin y del inicio de sesión ya no necesita una sobreescritura del tema.

Instalar sin cuenta de Adobe

El repositorio de Composer de Magento exige claves de autenticación generadas desde una cuenta del Marketplace. El de Mage-OS no. Comprobamos los dos al escribir esto:

curl -s -o /dev/null -w "%{http_code}\n" https://repo.mage-os.org/packages.json
# 200

curl -s -o /dev/null -w "%{http_code}\n" https://repo.magento.com/packages.json
# 401

Eso parece una nota al pie hasta que ha perdido una tarde con ello. La clave caducada. El auth.json que nunca llegó al runner nuevo de CI. El contratista que no puede construir el proyecto porque las credenciales viven en una cuenta de Adobe de alguien que se fue. Cada uno de esos fallos desaparece para los paquetes del núcleo.

No desaparece del todo. Las extensiones comerciales compradas en el Adobe Marketplace se siguen sirviendo desde repo.magento.com y siguen necesitando credenciales, así que la mayoría de las tiendas reales acaban con los dos repositorios configurados y Composer instruido sobre qué vendor viene de dónde.

Una instalación más pequeña, si la quiere

Mage-OS 3.0 añadió una Minimal Distribution opcional: unos 98 paquetes del núcleo por defecto, con los módulos, temas y paquetes de idioma disponibles como paquetes de Composer individuales en lugar de llegar los pidiera o no.

El argumento a favor es la superficie de ataque. El código que nunca activó sigue siendo código en el disco, sigue en el autoloader y sigue siendo suyo para parchearlo: la misma razón por la que decimos a los clientes que eliminen las extensiones que no usan en lugar de desactivarlas. Una tienda sin B2B, sin Page Builder y con un solo idioma tiene menos que defender.

No hemos medido qué hace con los tiempos de compilación y de deploy, así que no vamos a dar una cifra.

Herramientas que suelen ser tarea del primer día

El nuevo bin/magento install es un asistente interactivo que cubre la base de datos, la cuenta de admin, la configuración de la tienda, los servicios, los datos de ejemplo y el tema, con detección de servicios y recuperación cuando un paso falla. Incluye la configuración de Hyvä, aunque Hyvä sigue siendo un tema con licencia comercial: el instalador lo configura, no se lo regala.

Las herramientas para desarrolladores mencionadas arriba también vienen instaladas, y la mayoría de las agencias ya añadían n98-magerun2 e Ignition a cada proyecto de todos modos.

La pregunta de seguridad que la gente hace de verdad

El miedo es razonable: una distribución de la comunidad sentada entre usted y los parches de Adobe suena a un retraso que antes no tenía.

Hasta ahora no lo ha sido. Mage-OS 3.4.0 se publicó el 11 de agosto de 2026, portando el parche aislado de Adobe 249-2026-08-001-CE del boletín APSB26-92, el mismo día en que Adobe lo publicó. Mage-OS dice en su página de versiones que normalmente publica a los pocos días de cada versión de Adobe, y las tres versiones documentadas ahí son coherentes con eso.

Nada de lo cual cambia su parte del trato. El parche sigue teniendo que aplicarlo alguien, con un calendario y un rollback ensayado. La elección de distribución nunca ha sido lo que determina si una tienda está parcheada.

Frente a Adobe Commerce, la distancia sigue siendo distancia

Mage-OS 3.0 cerró dos casillas de esa tabla comparativa. El resto está donde estaba: sin módulo B2B, sin Content Staging y Preview, sin segmentos de clientes ni reglas dirigidas, sin merchandising avanzado, sin Commerce Cloud, y sin contrato de soporte de Adobe al que escalar a las dos de la mañana.

Si está en Commerce y usa eso, lo que tiene delante es un cambio de plataforma con un backlog de funciones, no un cambio de distribución; hemos escrito cómo se define de verdad el alcance de ese proyecto. Si está en Commerce y no usa casi nada de eso, que es más habitual de lo que sugieren las renovaciones de licencia, audite el uso real antes de dar por hecho que son estructurales.

Sobre el coste, solo diremos lo que se puede decir con honestidad. Adobe no publica precios de lista de Commerce, así que el ahorro es el que diga su propio presupuesto, medido contra lo que le cuesta sustituir las funciones. Cualquiera que le dé una cifra genérica está adivinando.

Lo que asume

Empiece por el tamaño de la organización. Mage-OS publica sus propias cifras: más de 213 contribuyentes financieros, más de 153.000 € en contribuciones totales, más de 95 miembros de la comunidad y más de 80 miembros profesionales, gobernados por una asociación en Poznań con una junta elegida y finanzas públicas. Es una organización real gestionada con transparencia, y también es una fracción del peso de Adobe detrás del mismo código. Está haciendo un intercambio, no evitando un problema.

Los proveedores de extensiones son una respuesta proveedor por proveedor. A la mayoría no le importa qué distribución ejecuta; unos pocos tienen servidores de licencias que validan contra una instalación de Magento y se comportan de forma inesperada. Haga inventario de sus extensiones de pago y escriba a cada proveedor antes de poner una fecha en el calendario.

Luego está la otra cara de todos esos módulos incluidos, y es que cada uno de ellos es código que las tiendas Magento y Adobe Commerce sencillamente no ejecutan. Eso pasó factura en agosto de 2026. Mage-OS 3.3.0 corrigió un fallo crítico de ejecución remota de código en su propio módulo incluido de importación y exportación de plantillas de Page Builder —aviso GHSA-hrj3-88v2-6wjx—, con el que un admin con acceso a la importación podía escribir contenido ejecutable en un directorio servido por el servidor web. Explotarlo requiere acceso de admin, así que es más limitado de lo que suena, y las tiendas Magento y Adobe Commerce nunca estuvieron expuestas porque no incluyen el módulo. Mage-OS lo encontró y lo corrigió en su propia versión, que es el sistema funcionando. Sigue siendo la factura de llevar más que upstream, y debería esperar verla otra vez.

Y nadie responde salvo usted. Sin SLA, sin proveedor al que escalar, sin contraparte comercial en el peor momento de la peor noche. Si ya tiene una agencia de confianza, ese es el acuerdo en el que estaba de todos modos.

Para quién es esto de verdad

Cambiar tiene sentido si está en Magento Open Source, razonablemente al día, y encaja en uno de estos casos: quiere devoluciones o un registro de auditoría del admin sin comprarlos, de otro modo estaría montando usted mismo los módulos de bfcache, speculation rules y políticas PCI, su equipo de admin se beneficiaría de una interfaz mejor, está harto de gestionar claves de Adobe en su pipeline de build, o prefiere tener voto en la hoja de ruta a mirarla desde fuera. El riesgo técnico es bajo y el cambio se revierte limpiamente, porque la base de datos nunca se mueve.

No tiene ningún sentido como arreglo para una tienda abandonada. Tres años de retraso, extensiones que nadie mantiene, parches sin aplicar: Mage-OS hereda todo eso. Póngase al día primero, sea cual sea la distribución en la que acabe.

Si quiere mi lectura honesta: para una tienda Open Source bien mantenida, es un cambio de bajo riesgo con un puñado de ganancias reales y sin licencia que negociar. Para una tienda Adobe Commerce es una conversación mucho mayor, y la he escrito aparte porque merece el espacio.

Emyrix trabaja en Magento Open Source, Adobe Commerce y Mage-OS, incluidos los cambios de distribución y la auditoría de compatibilidad de extensiones que decide si uno es sencillo. No tenemos ninguna relación comercial con la Mage-OS Association. Si quiere que evaluemos su tienda, escríbanos.

Las etiquetas de disponibilidad de funciones se citan de la propia documentación de producto de Adobe; el contenido de las versiones, las fechas, el comportamiento de los módulos y las cifras de la asociación proceden de mage-os.org y de los repositorios de Mage-OS en GitHub. Las respuestas del repositorio de Composer de arriba se comprobaron el 16 de agosto de 2026. Los nombres y versiones de los paquetes de Mage-OS cambian más rápido que los artículos, así que confirme la versión actual antes de planificar contra una concreta.