¿El beneficio marginal de que macOS sea de código cerrado hoy ya casi no alcanza al código abierto?

General
1

Tras leer una serie de artículos y debates recientes, mi conclusión es bastante clara: en el último medio año, efectivamente ha habido más discusión que antes en torno a “si los beneficios de que macOS sea de código cerrado se están debilitando”.

Pero primero hay que dejar algo claro:
este tipo de debates normalmente no se plantean directamente como “¿debería macOS ser de código abierto?”, sino que están dispersos en varios temas más concretos: seguridad, ecosistema de desarrollo, apertura de la plataforma en la era de la IA y la dependencia continua de Apple de componentes de código abierto. Es decir, ya es una línea de discusión que existe de verdad, solo que aún no se ha condensado en un gran tema unificado.

1. Código cerrado = más seguro: esta narrativa se está debilitando

Apple siempre ha sido muy hábil empaquetando un ecosistema cerrado como fuente de seguridad y estabilidad. Antes esta lógica funcionaba muy bien:

  • Cerrado, así que más controlable
  • Controlable, así que más estable
  • Estable, así que el usuario se preocupa menos

Pero en el último medio año, algunas discusiones sobre TCC, permisos de privacidad y vulnerabilidades de servicios del sistema relacionadas con macOS, en realidad ya están debilitando esa narrativa. Porque hay una pregunta muy real sobre la mesa:

Si el código cerrado no ha impedido vulnerabilidades críticas ni la evasión de permisos, ¿cuánto beneficio de seguridad aporta realmente el código cerrado?

Esto no equivale a “el código abierto es necesariamente más seguro”, pero al menos indica: la prima de seguridad del código cerrado ya no se sostiene de forma natural como antes.

2. A los desarrolladores les gusta macOS, cada vez menos por ser cerrado

Hoy muchos desarrolladores siguen apreciando macOS, pero rara vez es “porque es de código cerrado”.
Las razones más comunes son:

  • La cadena de herramientas en espacio de usuario tipo Unix es cómoda
  • La experiencia GUI es aceptable
  • Software comercial, software creativo y un ecosistema completo para desarrollo móvil
  • La autonomía y la eficiencia energética de Apple Silicon son muy fuertes

Es decir, hoy lo que la gente suele reconocer es:
la capacidad de Apple para entregar un conjunto completo hardware + plataforma, y no “que sea cerrado” en sí.

Dicho de otro modo, la fuente de valor de macOS se parece cada vez más a:

  • Hardware
  • Integración del ecosistema
  • Cadena de herramientas
  • Soporte de software comercial

y no al “código cerrado en sí”.

Esto es clave. Porque implica:
el código cerrado puede seguir siendo una forma de que Apple mantenga el control, pero quizá ya no sea la fuente de valor más central de macOS.

3. En la era de la IA, es más fácil que se cuestione el rendimiento marginal de las plataformas cerradas

Antes, que una plataforma fuera cerrada a menudo podía intercambiarse por consistencia, calidad y una capacidad de integración más fuerte.
Pero en la era de la IA / los agentes, la velocidad de innovación externa se ha acelerado claramente. Lo que los desarrolladores tocan con alta frecuencia es:

  • Modelos locales
  • Frameworks de inferencia de código abierto
  • Cadenas de herramientas de Python / Rust / JS
  • Flujos de trabajo de agent / automation
  • Integraciones de terceros y mejoras del sistema

Mientras que el estilo del lado de Apple sigue siendo:

  • Modelo de permisos estricto
  • Interfaces profundas opacas
  • La automatización tiene límites
  • El grado de apertura de la plataforma está controlado

Entonces aparece un juicio cada vez más común:

En la era de la IA, cuanto más cerrada es la plataforma, más probable es que frene la velocidad de innovación periférica.

Esto no significa que macOS deba ser de código abierto, pero sí indica:
los beneficios del código cerrado ya no son tan invencibles como antes, y el coste de oportunidad que trae se vuelve más visible.

4. Apple en realidad también sabe que un circuito totalmente cerrado no es la solución óptima

Apple no es “cerrada en todo”.
Siempre ha practicado una “apertura selectiva” muy típica:

  • Darwin / XNU tiene partes abiertas
  • Swift es de código abierto
  • WebKit es de código abierto
  • y una serie de proyectos de Apple Open Source

Esto muestra que la propia Apple también entiende:
para cosas como el ecosistema de lenguajes, el motor del navegador, la cadena de herramientas básica y componentes públicos, cerrar todo no es la opción con mayor beneficio.

Así que la estrategia real de Apple se parece más a:

  • Mantener cerrado el control del núcleo de la plataforma
  • Abrir selectivamente lo que favorece la expansión del ecosistema

Esto por sí solo ya dice mucho.
Si “ser cerrado en todos los niveles fuese lo que más rinde”, Apple ni siquiera tendría necesidad de liberar cosas como Swift y WebKit.

5. Entonces, ¿cuál es la respuesta?

Si reescribimos la pregunta de forma más precisa, creo que no es:

¿macOS debería ser completamente de código abierto ahora?

sino:

¿las ventajas centrales de macOS hoy provienen todavía principalmente de ser de código cerrado?

Mi juicio es: cada vez menos.

Hoy el código cerrado, por supuesto, aún tiene beneficios:

  • Garantizar el control de la plataforma
  • Mantener barreras comerciales
  • Mantener el liderazgo sobre las interfaces del sistema
  • Mantener margen para la afinación conjunta de software y hardware
  • Mantener el derecho de interpretación sobre firmas, revisiones y el modelo de seguridad

Pero al mismo tiempo, su rendimiento marginal realmente está bajando:

  • El beneficio de seguridad ya no es tan sólido como antes
  • La velocidad de innovación no necesariamente supera a la del ecosistema abierto
  • En la era de la IA, las cadenas de herramientas externas son cada vez más fuertes
  • Muchas capacidades de las que dependen de verdad los desarrolladores no vienen de la “fe en el código cerrado”

Así que mi conclusión es:

El macOS de hoy sigue obteniendo valor de ser cerrado, pero ya no es esa ventaja central de “una fórmula infalible para todo”.

Dicho de forma más directa:
macOS hoy se apoya más en el hardware de Apple, la integración del ecosistema y la capacidad de entrega de producto, que en “ser fuerte porque es cerrado”.

Y por eso, en el último medio año, cada vez más personas han empezado a debatir en serio:

si los beneficios de que macOS sea de código cerrado hoy ya están a punto de no alcanzar a los del código abierto.

Enlaces de referencia

2

Un complemento posterior más orientado a “qué querrían cambiar usuarios reales”.

Si cambiamos la pregunta de “¿es bueno o malo que macOS sea de código abierto?” a “después de que macOS sea de código abierto, ¿qué querría realmente tocar la gente en primer lugar?”, entonces, por lo que he visto últimamente en proyectos públicos y discusiones de usuarios, la dirección en realidad es muy concentrada: la mayoría no quiere derribar macOS y reescribirlo entero, sino cortar primero los molestos diseños por defecto de Apple, las restricciones del sistema y las interacciones ‘sabelotodo’.

1. Primer corte: cortar animaciones, des-teatralizar

Este punto aparece incluso más a menudo de lo que yo esperaba.

Muchos usuarios avanzados, si de verdad pudieran meter mano al fondo del sistema, su primera reacción no sería “dadme una UI más llamativa”, sino:

  • desactivar la animación de cambio de Space
  • desactivar las animaciones de abrir/cerrar/escalar ventanas
  • desactivar las transiciones de Mission Control
  • reducir la latencia de la respuesta de la interfaz
  • hacer que el comportamiento de las ventanas sea más directo, más “herramienta”

Herramientas maduras de gestión de ventanas en macOS como yabai ya convierten “desactivar la animación de cambio de space” en un punto de venta.

Esto muestra que lo que muchos usuarios realmente no soportan no es que el sistema no sea lo bastante bonito, sino que el sistema siempre quiere educarte sobre lo que es la elegancia, pero tú solo quieres rapidez.

Así que si macOS de verdad fuera open source, dudo mucho que la primera ola de mods más populares fuese algún tema nuevo; más bien sería:

  • de-bloat macOS
  • disable all animations
  • low-latency UX build

Eso de “primero limpiemos todas las animaciones”, me parece que no es una idea rara; al contrario, se parece mucho a lo mainstream.

2. Segundo corte: convertir el sistema de ventanas de ‘para mirar’ a ‘para producir’

Esta línea también es muy evidente.

Lo que muchos usuarios de verdad quieren complementar no es cambiar el fondo de pantalla, sino rehacer a fondo la gestión de ventanas de macOS:

  • añadir gestión de ventanas en mosaico (tiling)
  • prioridad al teclado
  • lógica de múltiples monitores más libre
  • reglas más libres para múltiples escritorios/Spaces
  • menos interacción impulsada por el ratón

En pocas palabras:
convertir el sistema de ventanas de macOS de un “escritorio para contemplar” a un “escritorio para producir”.

La actividad sostenida de herramientas como yabai / skhd lo deja claro: esta necesidad no es el autoentretenimiento de cuatro obsesivos, sino un requisito duro que siempre ha existido.

3. Tercer corte: sin telemetría, sin cuenta, sin dependencia de la nube

En los proyectos públicos recientes, el consenso más evidente es:

  • no tracking
  • no telemetry
  • local-first
  • no cloud
  • no account
  • plain files

En algunos proyectos recientes de macOS lo ponen de forma muy directa en la descripción:

  • Local Hours: local-first, JSON puro, sin cuenta, sin analytics
  • ScreenTranslate: OCR + translation on-device, sin pasar por servidores
  • Stik: markdown puramente local, sin “second brain”, sin sistema de cuentas
  • Cai: acciones locales de portapapeles, prioridad a modelos locales

Esto indica que los usuarios reales no necesariamente quieren un macOS “más inteligente, más en la nube, más totalmente gestionado”.
Lo que mucha gente realmente quiere es:
un macOS más silencioso, más local, con menos monitorización y menos intervención de plataforma.

4. Cuarto corte: reordenar la barra de menús, los residentes en segundo plano y las mini-funciones

Esto también es muy real.

Últimamente bastantes proyectos públicos están haciendo un tipo de cosas:

  • gestión de la barra de menús
  • OCR / traducción
  • mejora del portapapeles
  • registro/nota rápida
  • acciones con modelos pequeños locales
  • herramientas residentes en segundo plano más ligeras

La mentalidad detrás de estas necesidades es:
“No quiero cambiar de sistema; solo quiero que los rincones de este sistema se vuelvan más cómodos.”

Es decir, muchos usuarios reales no quieren una revolución; solo quieren remendar las costuras que Apple nunca arregló, y remendarlas de forma ligera, rápida y silenciosa.

5. Quinto corte: añadir el control a nivel de sistema que Apple no quiere dar

Este es uno de los puntos que más quieren tocar los usuarios avanzados.
Por ejemplo:

  • control de red más potente
  • restricciones más finas de salida por proceso
  • automatización y hooks más libres
  • APIs del sistema más abiertas
  • menos límites tipo SIP / TCC de “yo lo decido por ti”

Que un firewall open source como LuLu tenga usuarios durante tanto tiempo, en el fondo ya lo explica:
muchos usuarios siempre han sentido que macOS da demasiado poco en “controlabilidad del sistema”.

Si macOS de verdad fuera open source, esta parte muy probablemente se trabajaría a fondo, e incluso podría dar resultados más rápido que la remodelación de la UI.

6. Lo que los usuarios reales no parecen hacer primero

Al menos por lo que se ve en proyectos y discusiones públicas recientes, no parece que la gente vaya a lanzarse a hacer esto de entrada:

  • reescribir el kernel
  • hacer fork de un macOS comunitario completo
  • sustituir por completo el stack de escritorio oficial de Apple

La razón es muy realista:

  • la magnitud de ingeniería es absurda
  • la compatibilidad de drivers es un infierno
  • los puntos de dolor de alta frecuencia no están en el kernel, sino en las restricciones, interacciones y límites que Apple apila encima

Así que la primera ola más realista sin duda sería:

  1. quitar restricciones
  2. quitar animaciones
  3. quitar telemetría
  4. mejorar el sistema de ventanas
  5. mejorar herramientas de control del sistema
  6. abrir interfaces originalmente bloqueadas

7. Mi juicio actual sobre esta pregunta

Si macOS de verdad fuera open source, lo primero que más probablemente explotaría en popularidad no sería un “macOS comunitario”, sino una “cadena de herramientas para debloat / de-Apple-ify macOS”.

O sea, todo un conjunto de cosas como:

  • disable animations
  • tiling WM
  • no telemetry build
  • local-first build
  • stronger firewall / automation / hooks
  • menu bar and clipboard sane defaults

En el fondo, lo que los usuarios reales quieren no es “reinventar Apple”, sino:
cortar las partes de Apple que hoy tienen demasiados gestos, demasiadas restricciones, demasiadas ganas de controlar y demasiado ‘listillo’.

Y eso que dices de “primero limpiar animaciones”, me parece muy parecido al primer corte que ocurriría en todo esto.

Enlaces de referencia

3

error 422