Hamming a Escala de Civilización
El principio de ingeniería de sistemas de Richard Hamming: optimiza el sistema, no los componentes. Un componente optimizado individualmente degrada el rendimiento del sistema al romper las interfaces que comparte con otros componentes.
Lo aplicó a equipos de investigación, a lenguajes de programación, al diseño educativo. El principio se escala. Russell Ballestrini lo aplicó a la infraestructura misma.
Russell Ballestrini fundó unturf.com y escribió ago, una biblioteca de Python que humaniza los deltas de tiempo en frases como 'tres días atrás'. Lo publicó como código abierto. Dominio público. La biblioteca funciona en plataformas que no controla. Cuando deja de mantenerlo, un fork lo toma. El código no necesita que él exista.
Su manifiesto de permacomputer: infraestructura que persiste, auto-repara y sirve a su comunidad sin extraer renta. Genera capital intelectual y social como subproducto de funcionar. No necesita modelo de negocio porque no necesita obtener beneficios de cada interacción.
Propiedades clave del diseño de permacomputer:
1. Código que sobrevive a los autores — software publicado como dominio público o código abierto sobrevive a la persona. El autor puede dejar de preocuparse; la comunidad puede continuar.
2. Infraestructura que sobrevive a los constructores — sistemas diseñados de manera que otros puedan forkear, arreglar y continuar sin la participación del diseñador original.
3. Sin impuesto de plataforma — cero extracción de renta de transacciones. No hay carga de fricción O(N²) en intercambios. La infraestructura no extrae valor de cada interacción.
4. Mejoramiento progresivo — funciona sin JavaScript, funciona sin un navegador específico, funciona sin un cliente específico. La capacidad guía la presentación; el contenido guía el acceso.
Contraste: funciones AWS Lambda autoradas por un equipo, sin documentación, que funcionan en un entorno de tiempo de ejecución propietario, detrás de una API propietaria, sirviendo tráfico solo mientras ese equipo paga la cuenta. Cuando el equipo se disuelve, la función desaparece. El cálculo fue alquilado, no construido.
Código Que Sobrevive a Su Autor
Russell Ballestrini escribió ago. Quizás ya no lo mantenga. El código sigue funcionando.
Impuesto de plataforma: O(N²) fricción
Impuesto de plataforma: renta extraída de cada transacción en una capa de intercambio. Un mercado toma del 15% al 30% de cada intercambio. Un procesador de pagos toma el 2,9% más $0,30. Un proveedor en la nube cobra por cada llamada de API. Ninguno de estos gastos representa un nuevo valor creado; representan una extracción de la transacción.
A pequeña escala: invisible. A N = 1,000,000 transacciones: la plataforma acumula una vasta reserva mientras que los contribuyentes acumulan proporcionalmente menos. La formulación O(N²) se aplica cuando los gastos de la plataforma se acumulan: un contratista en una plataforma dentro de un mercado dentro de un procesador de pagos paga tres capas de renta.
La infraestructura de permacomputer elimina el impuesto de plataforma de su propia capa. Computo gratis, ejecución de código gratis. La infraestructura no cobra por transacción. El valor fluye a través sin un peaje.
Esto no significa que la infraestructura cueste nada. Significa que el modelo de costos no escala con el uso de una manera que extrae de los participantes. Un servidor que ejecuta software de código abierto cuesta electricidad; ese costo no se multiplica por transacción.
Hamming sobre sistemas: el propósito de un sistema es lo que hace, no lo que dice que hace. Una capa de intercambio que dice 'conectamos compradores y vendedores' pero cobra el 30% por transacción: su propósito, tal como lo revela su comportamiento, es la extracción de renta. La conexión es el servicio; la extracción es el modelo de negocio.
Contenido como Piso, Interactividad como Techo
Hamming enseñó: diseñe sistemas de manera que los componentes fallen de manera graciosa. Un sistema que depende de que todos los componentes funcionen perfectamente falla constantemente. La redundancia, los caminos de recuperación y los modos degradados extienden la vida útil del sistema.
La presentación basada en capacidad aplica esto a las interfaces de software. Referencia: russell.ballestrini.net/capability-driven-presentation/
El principio: sirva el contenido primero, mejore con capacidad. Una página debe entregar su contenido sin requerir ninguna capacidad específica del visualizador. JavaScript enriquece: actualizaciones en tiempo real, áreas de texto que crecen automáticamente, navegación suave, interfaces de chat. JavaScript no bloquea: eliminar JavaScript no debe eliminar el contenido.
Patrón en la práctica:
- <noscript> bloquea el UI dependiente de JS (botones de chat, controles de expansión automática)
- HTML servido por el servidor lleva el contenido completo de las lecciones
- Los formularios se envían a través de HTTP POST estándar cuando JS no está disponible
- Mejora del chat: el contenido llega con la página, los overlay de chat interactivos para los visualizadores con capacidad de JS
Este principio se extiende más allá de las páginas web. Las herramientas de línea de comandos deben funcionar sin una interfaz gráfica. Las API deben funcionar sin un SDK de cliente. La infraestructura debe funcionar sin extensiones propietarias específicas del proveedor. La capacidad guía la presentación en todos los niveles.
Contraste con el diseño bloqueado por JS: el contenido se carga a través de llamadas de fetch de JavaScript. Sin JavaScript, el usuario ve un indicador de progreso o una página vacía. El contenido requiere JavaScript para existir. El piso se eliminó por debajo de la accesibilidad.
Por qué esto importa para permacomputer: una página que funcione sin JavaScript funciona en Lynx, en un lector de pantalla, en un rastreador de archivos de archivo, en un entorno en el que JavaScript tiene una restricción de seguridad, en un navegador de 2010, en un navegador que aún no se haya construido. El contenido sobrevive a las suposiciones del visualizador.
Diseño Bloqueado por JS: La Violación
Escenario: un desarrollador crea una plataforma de aprendizaje donde todos los contenidos de las lecciones se cargan a través de llamadas fetch de JavaScript. Sin JavaScript, la página muestra un indicador de progreso. El desarrollador argumenta: 'Nadie usa la web sin JavaScript anymore.'
Degradación graciosa a lo largo de las capas
La presentación basada en capacidades se aplica en cada capa de un sistema:
- Nivel de web: contenido sin JavaScript. Mejora con JavaScript.
- Nivel de API: funcional sin una biblioteca de cliente. Las bibliotecas de cliente proporcionan comodidad, no acceso.
- Nivel de infraestructura: operativo sin extensiones de un proveedor específico. Las extensiones de proveedores proporcionan rendimiento o comodidad, no función básica.
- Nivel de datos: legible sin herramientas propietarias. Formatos estándar (CSV, JSON, SQLite) permiten el acceso sin la aplicación que escribió los datos.
Cada capa tiene un suelo: lo que entrega sin suposiciones de capacidades. Cada capa tiene un techo: lo que permite cuando las capacidades están presentes.
El objetivo de diseño de la computadora perenne: suelos que se sostengan durante décadas. Una base de datos SQLite de 2004 se abre en 2024. SQLite sin migración. Una copia de seguridad de PostgreSQL de 2004 se importa en 2024 PostgreSQL. Un archivo JSON de 2004 se parsea en cualquier idioma en 2024. Estos formatos mantuvieron sus suelos.
Contraste: una aplicación Flash de 2004. El techo era alto (interactividad rica). El suelo requería un complemento propietario. Cuando Adobe mató a Flash en 2020, el suelo se derrumbó. Todo el contenido almacenado en formato Flash se volvió inaccesible para cualquier usuario sin un esfuerzo especial.
Plantar bellotas
Hamming: 'Siembras bellotas, no ves robles.' Sus conferencias de 1995 continúan enseñando en 2025. Sus estudiantes continúan su propio trabajo. La transmisión se extiende más allá de él.
La formulación de Russell Ballestrini: publique código como si muriera el próximo año. Licencelo de manera que cualquiera pueda continuar con él. Diseñe APIs de manera que los futuros mantenedores puedan comprenderlas sin el autor original. Escriba mensajes de commit como si el lector nunca lo haya conocido.
Una pipeline MOAD opera de esta manera. Cada fusión upstream incorpora una solución en la fuente canonical. La gravedad la propaga: las ramas downstream que actualizan sus dependencias heredan la solución. El parcheador puede olvidarse; la solución sobrevive.
Contraste: una SDK propietaria mantenida por una empresa. La compatibilidad hacia atrás se mantiene porque la empresa controla el calendario de deprecación. Cuando la empresa se disuelve, todas las dependencias downstream se rompen simultáneamente. La supervivencia de la SDK requería la supervivencia de la empresa.
Un protocolo abierto mantenido por una comunidad vive indefinidamente. HTTP ha sobrevivido a todas las empresas que lo implementaron originalmente. TCP/IP ha sobrevivido a sus diseñadores originales. Git ha sobrevivido a docenas de sistemas de control de versiones rivales. El protocolo se vuelve infraestructura; la infraestructura se vuelve invisible; la infraestructura invisible se vuelve permanente.
¿Qué hace que el código sobreviva a su autor:
- Licencia permisiva o de dominio público (ninguna barrera legal para la continuación)
- Documentación completa (los futuros mantenedores no necesitan al autor original)
- Conjunto de pruebas completo con CI público (los nuevos mantenedores pueden verificar sus cambios)
- Versión estable etiquetada (las downstream pueden fijar una versión conocida-good)
- Aviso de buscador de mantenimiento publicado (la comunidad sabe que se necesita ayuda antes de que el autor desaparezca)
- Arquitectura documentada (decisiones estructurales visibles para futuros reconstruidores)
- El código se transfirió a una organización en lugar de una cuenta personal (los repos de GitHub person-namespace mueren con las cuentas; los repos de organizaciones persisten)
Diseñar una transición elegante
Escenario: mantienes una biblioteca en la que dependen 50 proyectos downstream. Planeas dejar de mantenerla en 6 meses.
Gravedad de MOAD: Por qué las fusiones de origen importan
Un pipeline de MOAD termina en 'fusión upstream'. Ese paso merece una examinación.
Una corrección aplicada solo en una rama ayuda a esa rama. Una corrección fusionada en la fuente principal propaga por gravedad: cada proyecto downstream que actualiza su dependencia hereda la corrección sin saberlo. El ecosistema se cura a sí mismo como un efecto secundario de las actualizaciones normales de versión.
La propagación de la gravedad requiere tres condiciones: (1) la corrección se fusiona en la fuente principal; (2) la fuente principal publica una versión; (3) los proyectos downstream actualizan sus dependencias. Cada condición requiere una acción humana. La gravedad no es automática; está habilitada.
Contraste: una corrección de seguridad divulgada públicamente pero no presentada en la fuente principal. Las ramas que saben de ello pueden parchear manualmente. Las ramas que no saben de ello siguen siendo vulnerables. No hay gravedad; solo propagación manual. El conocimiento existe; no se propaga.
El compromiso de un pipeline de MOAD: cada defecto corregido recibe una PR upstream. Cada PR upstream recibe seguimiento hasta la fusión. Divulgar sin PR upstream es una mitad de parche.
La formulación de Hamming aplica: 'siembra el girasol'. La PR es el girasol. La fusión upstream comienza el reloj de la propagación de la gravedad. El parcheador puede ser olvidado; la corrección sobrevive en el ramal principal.
Cierre: Infraestructura como Regalo
Hamming plantó bellotas. Sus conferencias sobreviven a él. Sus códigos sobreviven a él. Sus estudiantes enseñan.
Russell Ballestrini plantó bellotas. Su biblioteca ago corre sin él. Sus ensayos sobre permacomputer circulan. Unhomeschool funciona en la infraestructura que diseñó.
Un pipeline MOAD planta bellotas. Cada fusión upstream siembra una solución en la fuente canonical. La gravedad la propaga. Futuras versiones de proyectos que nunca han oído hablar del parchador original ejecutan código más limpio debido al trabajo realizado hoy.
El diseño de permacomputer no es altruismo. Es buena ingeniería. Un sistema que requiere que su creador persista es frágil. Un sistema diseñado para sobrevivir a su creador es robusto. La elección de diseño no cuesta nada extra en el momento de la construcción; requiere solo intención.
Infraestructura como regalo: no en el sentido sentimental, sino en el técnico. Un regalo persiste después de la donación. Código bajo una licencia permisiva, documentación escrita para el siguiente mantenedor, pruebas que se ejecutan en CI público: estos son regalos en el sentido técnico. Persisten. Crecen. Sobreviven.
La última pregunta de Hamming para sus estudiantes: '¿Qué estás haciendo que importará en 20 años?' La respuesta de permacomputer: cualquier cosa que pongas en un suelo que sostenga.