Polaris vs Carbon: governance comparada
Polaris Carbon
Polaris opera con un equipo central pequeño y mayor frecuencia de releases. Carbon tiene un comité multi-empresa, releases planificadas con calendario fijo y RFC formal. Las dos formas funcionan; eligen problemas distintos.
Quién es cada uno
Polaris es el design system público de Shopify. Sirve a su propio producto (admin de Shopify), a su tema base (Liquid + React) y a los desarrolladores externos que construyen apps para la plataforma. Open source, repositorio activo, alta cadencia de cambios.
Carbon es el design system de IBM. Cubre el portafolio IBM completo: nube, IA, software empresarial, comunicación corporativa. Open source, repositorio activo, releases planificados con calendario público, comité de governance multi-empresa porque también lo consumen Red Hat y otras divisiones.
Comparar los dos no es comparar diseños: los componentes son razonablemente equivalentes. Es comparar modelos de governance, y ese es el problema que un Design System Architect senior tiene que resolver antes de copiar nada.
Frecuencia de releases
| Sistema | Ciclo | Modelo |
|---|---|---|
| Polaris | semanas | minor frecuentes, breaking changes en majors anunciadas con preaviso |
| Carbon | trimestral planificado | releases con roadmap público, breaking changes anunciados con 6 meses de antelación |
Polaris asume que su consumidor principal (apps de Shopify) puede actualizarse rápido. Carbon asume lo contrario: muchos clientes son productos enterprise con ciclos de release largos, y un breaking change requiere previsibilidad o mata el sistema.
Para un sistema in-house en una empresa española de tamaño medio, la pregunta es: ¿cuántos productos te consumen y a qué velocidad pueden adoptar? Si la respuesta es “tres equipos que liberan cada dos semanas”, el modelo Polaris es viable. Si son doce equipos con ciclos de quince meses, Carbon es la referencia obligatoria.
Modelo de RFC
Carbon tiene un proceso formal de RFC en su repo (carbon-design-system/carbon): cualquier propuesta de cambio significativo abre una Discussion, pasa por revisión técnica del comité, y solo entonces se convierte en PR. Es lento. Es deliberado. Filtra el ruido.
Polaris no tiene RFC público explícito. Las propuestas externas viven en GitHub issues y PRs. La aprobación es de equipo interno. Es rápido. También filtra menos.
Si tu sistema es público (cliente externo lo consume), un RFC formal es una herramienta. Si tu sistema es interno y los consumidores son los tres equipos del piso, un RFC es burocracia.
Contribuciones externas
Carbon acepta PRs externos pero documenta una lista corta de áreas donde son bienvenidos (iconografía, ejemplos, fixes de docs). Cambios en componentes core requieren autorización previa del equipo. Es un sistema con permeabilidad controlada.
Polaris acepta menos PRs externos. La mayoría se redirigen a sugerencias en discussions. El sistema es público pero la dirección la marca Shopify.
Ninguno de los dos es un “open source verdadero” tipo Tailwind, donde la comunidad mantiene una parte sustancial del código. Los dos son sistemas corporativos con código abierto a lectura, no a contribución libre.
Deprecación
Carbon publica una página de “deprecated components” con cada release, especifica desde qué versión, qué sustituye, y mantiene los componentes deprecados al menos dos releases más como red de seguridad.
Polaris hace lo mismo pero con menor preaviso. Una breaking change en un componente puede aparecer en una minor con console.warn, y desaparecer en la siguiente major. El consumidor tiene menos margen.
Capa agéntica
Cuando aparece la capa agéntica encima del sistema (un agente que consume tokens y componentes), la diferencia se amplifica:
- Carbon ya publica sus tokens en formato consumible por agente desde 2024 (en
@carbon/themescon metadata estructurada). El RFC público y el calendario predecible le dan al agente fechas fiables. - Polaris está construyendo esa capa más lento. Su catálogo de componentes existe en React + Liquid + Storybook, pero la documentación legible por agente está fragmentada.
Para un sistema que está pensando “cómo me adapto para agentes”, Carbon es la mejor referencia de governance, aunque sea más lento. Polaris es la mejor referencia de operativa, aunque sea menos predecible.
Veredicto técnico
No hay ganador. Hay dos respuestas a problemas distintos:
- Polaris = sistema operado por equipo central pequeño, consumidores ágiles, ciclo corto.
- Carbon = sistema operado por comité, consumidores con ciclos largos, predictibilidad obligatoria.
Para un sistema in-house de empresa española mediana, lo razonable es híbrido: ciclos cortos como Polaris en releases internas, comunicación formal como Carbon en breaking changes públicos. La trampa es importar el modelo entero sin cuestionarlo.
Ver también
Los modelos de governance se cubren en profundidad en la cohorte (semana 03, con Cristian Morales y Marta Yécora). Si tu sistema necesita acompañamiento para definir el suyo, solicita plaza en la cohorte de septiembre.