Hamming a Escala de Civilización
El principio de ingeniería de sistemas de Richard Hamming: optimizar el sistema, no los componentes. Un componente optimizado de forma aislada degrada el rendimiento del sistema al romper las interfaces que comparte con otros componentes.
Lo aplicó a equipos de investigación, lenguajes de programación y diseño educativo. El principio escala. Russell Ballestrini lo aplicó a la propia infraestructura.
Russell Ballestrini fundó unturf.com y escribió ago, una biblioteca de Python que humaniza deltas de tiempo en frases como 'hace tres días'. La publicó como código abierto. Dominio público. La biblioteca funciona en plataformas que él no controla. Cuando deja de mantenerla, un fork la continúa. El código no requiere que él exista.
Su manifiesto de permacomputadora: infraestructura que persiste, se autocura y sirve a su comunidad sin cobrar renta. Crece el capital intelectual y social como subproducto de su funcionamiento. No necesita un modelo de negocio porque no necesita obtener ganancias de cada interacción. [BLOCK_TYPE SECTION/STEP]
Propiedades clave del diseño de permacomputadora: [BLOCK_TYPE SECTION/STEP]
1. El código sobrevive a sus autores — el software publicado como dominio público o código abierto sobrevive al individuo. El autor puede dejar de interesarse; la comunidad puede continuar. [BLOCK_TYPE SECTION/STEP]
2. La infraestructura sobrevive a sus constructores — sistemas diseñados para que otros puedan bifurcarlos, corregirlos y continuarlos sin la participación del diseñador original. [BLOCK_TYPE SECTION/STEP]
3. Sin impuesto de plataforma — cero extracción de renta de las transacciones. Sin cargo de fricción O(N²) en los intercambios. La infraestructura no extrae valor de cada interacción. [BLOCK_TYPE SECTION/STEP]
4. Mejora progresiva — funciona sin JavaScript, funciona sin un navegador específico, funciona sin un cliente específico. La capacidad impulsa la presentación; el contenido impulsa el acceso. [BLOCK_TYPE SECTION/STEP]
Contraste: funciones de AWS Lambda escritas por un equipo, sin documentación, ejecutadas en un entorno propietario, detrás de una API propietaria, sirviendo tráfico solo mientras ese equipo paga la factura. Cuando el equipo se disuelve, la función desaparece. El cómputo fue alquilado, no construido. [BLOCK_TYPE SECTION/STEP]
Código que sobrevive a su autor
Russell Ballestrini escribió ago. Puede que ya no lo mantenga. El código sigue funcionando.
Impuesto de plataforma: fricción O(N²)
Impuesto de plataforma: renta extraída de cada transacción en una capa de intercambio. Un mercado se queda con el 15-30 % de cada intercambio. Un procesador de pagos cobra 2,9 % + 0,30 $. Un proveedor en la nube cobra por cada llamada a la API. Ninguna de estas tarifas representa valor nuevo creado; representan extracción del intercambio.
A pequeña escala: invisible. A N=1 000 000 transacciones: la plataforma acumula una reserva enorme mientras los contribuyentes acumulan proporcionalmente menos. La formulación O(N²) se aplica cuando las comisiones de 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 desde su propia capa. Cómputo gratuito, ejecución de código gratuita. La infraestructura no cobra por transacción. El valor fluye sin peaje.
Esto no significa que la infraestructura no tenga costos. Significa que el modelo de costos no escala con el uso de forma que extraiga valor de los participantes. Un servidor que ejecuta software de código abierto consume 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 un 30 % por transacción: su propósito, revelado por su comportamiento, es la extracción de renta. La conexión es el servicio; la extracción es el modelo de negocio.
Contenido como suelo, interactividad como techo
Hamming enseñó: diseña sistemas para que los componentes fallen con elegancia. Un sistema que depende de que cada componente funcione perfectamente falla constantemente. La redundancia, las rutas de respaldo y los modos degradados pero funcionales prolongan la vida útil del sistema.
La presentación orientada a capacidades aplica esto a las interfaces de software. Referencia: russell.ballestrini.net/capability-driven-presentation/
El principio: sirve el contenido primero, mejora con capacidad. Una página debe entregar su contenido sin requerir ninguna capacidad específica del visor. JavaScript enriquece: actualizaciones en tiempo real, áreas de texto de auto-expansión, navegación fluida, interfaces de chat. JavaScript no bloquea: eliminar JavaScript no debe eliminar el contenido.
Patrón en la práctica:
- Los bloques <noscript> ocultan la interfaz dependiente de JS (botones de chat, controles de auto-expansión)
- El HTML renderizado en el servidor lleva todo el contenido de la lección
- Los formularios se envían mediante HTTP POST estándar cuando JS no está disponible
- Mejora del chat: el contenido llega con la página, chat interactivo superpuesto para espectadores con JS
Este principio va más allá de las páginas web. Las herramientas CLI deben funcionar sin GUI. Las APIs deben funcionar sin un SDK de cliente. La infraestructura debe funcionar sin extensiones propietarias de un proveedor específico. La capacidad impulsa la presentación en cada capa.
Contraste con el diseño dependiente de JS: el contenido se carga mediante llamadas fetch de JavaScript. Sin JavaScript, el usuario ve un spinner o una página vacía. El contenido requiere JavaScript para existir. El suelo cayó por debajo de la accesibilidad.
Por qué importa para la permacomputadora: una página que funciona sin JavaScript funciona en Lynx, en un lector de pantalla, en un rastreador de archivos, en un entorno donde JavaScript tiene una restricción de seguridad, en un navegador de 2010, en un navegador que aún no se ha construido. El contenido sobrevive a las suposiciones del visor.
Diseño dependiente de JS: la violación
Escenario: un desarrollador crea una plataforma de aprendizaje donde todo el contenido de las lecciones se carga mediante llamadas fetch de JavaScript. Sin JavaScript, la página muestra un spinner. El desarrollador argumenta: «Nadie usa la web sin JavaScript hoy en día».
Degradación elegante entre capas
La presentación basada en capacidades se aplica en cada capa de un sistema:
- Capa web: contenido sin JavaScript. Mejora con JavaScript.
-
- Infrastructure tier: operational without a specific vendor's extensions. Vendor extensions provide performance or convenience, not core function.
- Data tier: readable without proprietary tooling. Standard formats (CSV, JSON, SQLite) allow access without the application that wrote the data.
Cada capa tiene un piso: lo que entrega sin suponer capacidades. Cada capa tiene un techo: lo que habilita cuando las capacidades están presentes.
El objetivo de diseño del permacomputador: pisos que se mantengan durante décadas. Una base de datos SQLite de 2004 se abre en SQLite 2024 sin migración. Un volcado de PostgreSQL de 2004 se importa en PostgreSQL 2024. Un archivo JSON de 2004 se analiza en cualquier lenguaje de 2024. Estos formatos mantuvieron sus pisos.
Contraste: una aplicación Flash de 2004. El techo era alto (interactividad rica). El piso requería un complemento propietario. Cuando Adobe eliminó Flash en 2020, el piso colapsó. Todo el contenido almacenado en formato Flash quedó inaccesible para cualquier visor sin esfuerzo especial.
Plantando Bellotas
Hamming: 'Plantas bellotas, no ves robles.' Sus conferencias de 1995 siguen enseñando en 2025. Sus estudiantes continúan su propio trabajo. La transmisión va más allá de él.
La perspectiva de Russell Ballestrini: publica código como si fueras a morir el año siguiente. Licéncialo para que cualquiera pueda continuarlo. Diseña APIs para que futuros mantenedores puedan entenderlas sin el autor original. Escribe mensajes de commit como si el lector nunca te hubiera conocido.
Una cadena MOAD funciona así. Cada fusión upstream incorpora una corrección en la fuente canónica. La gravedad la propaga: los forks downstream que actualizan sus dependencias heredan la corrección. El parcheador puede ser olvidado; el parche sobrevive.
Contraste: un SDK propietario mantenido por una empresa. La compatibilidad hacia atrás se mantiene porque la empresa controla el calendario de obsolescencia. Cuando la empresa desaparece, todas las dependencias downstream se rompen simultáneamente. La supervivencia del 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 competidores. El protocolo se convierte en 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 (sin barrera legal para la continuación)
- Documentación completa (los futuros mantenedores no necesitan al autor original)
- Conjunto de pruebas que pasa con CI público (los nuevos mantenedores pueden verificar sus cambios)
- Versión estable etiquetada (los downstream pueden fijar una versión conocida y estable)
- Aviso de “se busca mantenedor” publicado (la comunidad sabe que se necesita ayuda antes de que el autor desaparezca)
- Arquitectura documentada (las decisiones estructurales son visibles para quienes reconstruyan el proyecto en el futuro)
- Código transferido a una organización en lugar de una cuenta personal (los repositorios en el espacio de nombres personal de GitHub mueren con las cuentas; los repositorios de organización persisten)
Diseñando una transición elegante
Escenario: mantienes una biblioteca de la que dependen 50 proyectos downstream. Planeas dejar de mantenerla en 6 meses.
Gravedad MOAD: Por qué las fusiones upstream importan
Un pipeline MOAD termina en 'fusión upstream'. Ese paso merece un examen.
Un parche aplicado solo a un fork ayuda a ese fork. Un parche fusionado upstream se propaga por gravedad: cada proyecto downstream que actualiza su dependencia hereda la corrección sin saberlo. El ecosistema se cura a sí mismo como efecto secundario de los bumps normales de versión.
La propagación por gravedad requiere tres condiciones: (1) la corrección se fusiona en la fuente canónica; (2) la fuente canónica publica un lanzamiento; (3) los proyectos downstream actualizan sus pines de dependencia. Cada condición requiere acción humana. La gravedad no es automática; está habilitada.
Contraste: una corrección de seguridad divulgada públicamente pero no enviada al repositorio principal. Los forks que la conocen pueden parchearla manualmente. Los forks que no la conocen siguen vulnerables. Sin gravedad; solo propagación manual. El conocimiento existe; no se propaga.
El compromiso de un pipeline MOAD: cada defecto corregido genera un PR al repositorio principal. Cada PR al repositorio principal se sigue hasta su fusión. Divulgar sin un PR al repositorio principal es medio parche.
Se aplica el marco de Hamming: «planta la bellota». El PR es la bellota. La fusión en el repositorio principal inicia el reloj de la propagación por gravedad. Quien parchea puede ser olvidado; la corrección sobrevive en la rama canónica.
Cierre: Infraestructura como regalo
Hamming plantó bellotas. Sus conferencias le sobreviven. Sus códigos le sobreviven. Sus estudiantes enseñan.
Russell Ballestrini plantó bellotas. Su biblioteca ago funciona sin él. Sus ensayos sobre permacomputadoras circulan. Unhomeschool funciona sobre la infraestructura que diseñó.
Una canalización MOAD planta bellotas. Cada fusión upstream siembra una corrección en la fuente canónica. La gravedad la propaga. Versiones futuras de proyectos que nunca han oído hablar del parcheador original ejecutan código más limpio gracias al trabajo realizado hoy.
El diseño de permacomputadoras 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; solo requiere intención.
Infraestructura como regalo: no en el sentido sentimental, sino en el sentido técnico. Un regalo persiste después de ser dado. Código bajo 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 a sus estudiantes: «¿Qué estás haciendo que importará dentro de 20 años?». La respuesta del permacomputador: cualquier cosa que coloques en un suelo que se mantenga.