# Manifiesto USEE ## Protocolo para el Desarrollo de Software Intercambiable **Versión 1.0** --- ## Declaración de Intención El software actual sufre de una enfermedad: la complejidad innecesaria. Programas que deberían hacer una cosa hacen cien. Sistemas que deberían durar décadas se vuelven obsoletos en meses. Herramientas que deberían ser accesibles requieren años de estudio para dominarse. Soluciones que deberían ser universales solo funcionan en contextos específicos. USEE nace como respuesta a esta enfermedad. Proponemos un protocolo para crear piezas de software que sean intercambiables entre proyectos, comprensibles por humanos, y resilientes al paso del tiempo. Piezas que cualquier persona pueda ensamblar para construir soluciones sin necesidad de programar, pero que cualquier programador pueda extender y adaptar. No buscamos reinventar el software. Buscamos recordar lo que el software debería ser. --- ## Los Cuatro Principios ### ÚTIL > *Lo que se ofrece es lo que se recibe.* Una pieza USEE existe para resolver un problema concreto. No para impresionar con su sofisticación, no para demostrar habilidad técnica, no para anticipar necesidades imaginarias. **Criterios de utilidad:** - La pieza resuelve un problema que personas reales tienen hoy - El problema puede explicarse en una oración - La solución puede demostrarse en menos de un minuto - El usuario obtiene valor desde el primer uso, sin configuración previa obligatoria **Preguntas que toda pieza debe responder con "sí":** - ¿Alguien usaría esto mañana si estuviera disponible hoy? - ¿El beneficio es evidente sin necesidad de explicación? - ¿Hace lo que dice que hace, sin sorpresas? **Lo que rechazamos:** - Funcionalidad especulativa ("por si acaso alguien lo necesita") - Características que requieren documentación extensa para justificar su existencia - Soluciones en busca de problemas --- ### SIMPLE > *Pocas piezas, poca complejidad, fácil de entender, fácil de integrar.* La simplicidad no es la ausencia de capacidad. Es la presencia de claridad. Una pieza simple es aquella que una persona puede comprender completamente, predecir su comportamiento, y confiar en sus resultados. **Criterios de simplicidad:** - La pieza puede explicarse completamente en una página - Un programador nuevo puede entender el código en una hora - Un usuario no técnico puede configurarla eligiendo entre opciones predefinidas - La pieza tiene un único archivo de entrada y un único archivo de salida conceptual **Métricas de simplicidad:** - Menos de 10 opciones de configuración para uso básico - Menos de 3 dependencias externas obligatorias - Menos de 1000 líneas de código para la funcionalidad central - Cero configuración requerida para el caso de uso más común **Lo que rechazamos:** - Abstracciones innecesarias - Configuración obligatoria antes del primer uso - Dependencias que el usuario no eligió explícitamente - Documentación que requiere documentación para entenderse --- ### ESENCIAL > *Fundamental, elemental, necesaria. Sin ella no funciona; con ella, nada sobra.* Una pieza USEE hace una cosa. La hace completamente. No hace nada más. Si una pieza de Login permite iniciar sesión, eso es todo lo que hace. No registra usuarios. No recupera contraseñas. No gestiona perfiles. Esas son otras piezas. **Criterios de esencialidad:** - La pieza tiene una única razón de existir - Esa razón puede expresarse en un verbo y un sustantivo (ej: "autenticar usuario", "enviar correo", "generar reporte") - Eliminar cualquier funcionalidad rompería su propósito central - Agregar cualquier funcionalidad la convertiría en dos piezas **La prueba del nombre:** Si no puedes nombrar la pieza con una sola palabra o concepto claro, probablemente hace demasiado. - ✓ "Login" - claro, hace una cosa - ✓ "Registro" - claro, hace una cosa - ✗ "GestorDeUsuarios" - ambiguo, probablemente hace varias cosas - ✗ "SistemaDeAutenticaciónCompleto" - definitivamente hace demasiado **Lo que rechazamos:** - Funcionalidad "conveniente" que no es central al propósito - Integraciones incluidas "porque los usuarios las esperan" - Características agregadas para competir con otras soluciones - La tentación de "ya que estamos, agreguemos también..." --- ### ESTABLE > *Resiliente a cambios, continúa funcionando con el paso de los años.* Una pieza USEE que funciona hoy debe funcionar mañana. Y el próximo año. Y en una década. La estabilidad no es un objetivo secundario; es un requisito fundamental. El software moderno tiene una deuda con sus usuarios: les promete soluciones y les entrega dependencias. Actualizaciones que rompen. Frameworks que mueren. APIs que cambian. USEE rechaza esta deuda. **Criterios de estabilidad:** - La pieza no depende de tecnologías con ciclos de vida cortos - Las actualizaciones son siempre retrocompatibles - La comunicación usa protocolos que han probado su permanencia (texto plano, HTTP, stdin/stdout) - El código puede ejecutarse sin conexión a servicios externos obligatorios **Compromisos de estabilidad:** - Las entradas válidas de la versión 1.0 serán válidas en todas las versiones futuras - Las salidas mantendrán su estructura; nuevos campos se agregan, nunca se eliminan o renombran - Los comportamientos existentes no cambian; nuevos comportamientos son opcionales - Si una pieza debe cambiar de forma incompatible, se convierte en una pieza nueva con nombre nuevo **La regla de los 30 años:** Antes de elegir una tecnología, pregunta: ¿existía hace 15 años? ¿Existirá en 15 años más? - ✓ Texto plano - 50+ años, seguirá existiendo - ✓ HTTP - 30+ años, seguirá existiendo - ✓ JSON - 20+ años, probablemente seguirá existiendo - ✗ [Framework JavaScript del momento] - 3 años, probablemente no **Lo que rechazamos:** - Dependencias de servicios que pueden desaparecer - Formatos propietarios o no documentados - Actualizaciones que requieren que el usuario cambie su código - La excusa de "es hora de modernizarse" --- ## La Doctrina de Comunicación Las piezas USEE se comunican mediante texto estructurado. Esta elección no es técnica; es filosófica. El texto es universal. El texto es legible. El texto sobrevive. ### Jerarquía de Comunicación **Nivel 1 - Obligatorio: Texto USEE via stdin/stdout** Toda pieza USEE debe poder recibir instrucciones por entrada estándar y emitir resultados por salida estándar, usando el Formato de Texto USEE (FTU). ``` # Entrada usuario: juan@ejemplo.com clave: secreto123 # Salida estado: ok sesion: abc123 ``` **Nivel 2 - Recomendado: Separación de salidas** Las piezas deberían usar stdout para resultados y stderr para errores. **Nivel 3 - Opcional: Adaptador JSON** Las piezas pueden ofrecer entrada/salida en JSON para integraciones que lo requieran. **Nivel 4 - Opcional: Adaptador HTTP** Las piezas pueden exponerse como servicios de red para contextos web. ### Por qué stdin/stdout es obligatorio - Funciona en todos los sistemas operativos desde 1970 - Funciona en todos los lenguajes de programación - No requiere librerías, frameworks, ni dependencias - Permite composición natural: `pieza1 | pieza2 | pieza3` - Es testeable con herramientas básicas: `echo "entrada" | pieza` - Es debuggeable por humanos sin herramientas especiales --- ## Compromisos del Creador Al publicar una pieza bajo el protocolo USEE, el creador se compromete a: ### 1. Verdad en la descripción La pieza hace exactamente lo que su descripción dice. Ni más, ni menos. Si la descripción dice "envía correos electrónicos", la pieza envía correos electrónicos. No los programa, no los plantilla, no los analiza. Solo los envía. ### 2. Transparencia en las dependencias Toda dependencia externa está documentada y justificada. El usuario sabe antes de instalar qué otras piezas o servicios necesitará. ### 3. Respeto por la estabilidad Las actualizaciones no rompen instalaciones existentes. Si un cambio es incompatible, se publica como una pieza nueva. ### 4. Honestidad en las limitaciones La documentación incluye lo que la pieza NO hace. Los límites son tan importantes como las capacidades. ### 5. Disponibilidad del código El código fuente está disponible para inspección. El usuario puede verificar qué hace la pieza antes de confiar en ella. --- ## Compromisos del Usuario Al utilizar piezas USEE, el usuario acepta que: ### 1. Las piezas son herramientas, no soluciones mágicas Las piezas hacen lo que dicen. La responsabilidad de combinarlas correctamente es del usuario. ### 2. La simplicidad tiene límites Una pieza simple puede no cubrir casos de uso complejos. Esto es intencional, no una falla. ### 3. El costo refleja el valor Las piezas tienen un costo por uso que remunera a sus creadores. Este costo es parte del ecosistema sostenible. ### 4. La retroalimentación mejora el ecosistema Reportar problemas, sugerir mejoras, y calificar piezas contribuye a la calidad del marketplace. --- ## El Ecosistema USEE USEE no es solo un protocolo técnico. Es un ecosistema donde: ### Creadores - Construyen piezas atómicas que resuelven problemas específicos - Reciben compensación proporcional al uso de sus piezas - Mantienen sus piezas siguiendo los compromisos del protocolo ### Usuarios - Ensamblan piezas para construir soluciones sin programar - Eligen entre opciones predefinidas o configuraciones personalizadas - Pagan por el valor que reciben ### El Marketplace - Certifica que las piezas cumplen el protocolo mediante tests automáticos - Mide y publica métricas de calidad (uptime, estabilidad, facilidad de uso) - Facilita el descubrimiento y la confianza entre creadores y usuarios ### La Plataforma - Provee servicios centralizados opcionales (almacenamiento, autenticación, analíticas) - Rastrea el uso para compensar a los creadores - Mantiene la infraestructura que hace posible el ecosistema --- ## Métricas de Calidad USEE Toda pieza en el marketplace es evaluada en: | Métrica | Descripción | |---------|-------------| | **Tiempo operacional** | Meses desde su publicación sin cambios incompatibles | | **Frecuencia de cambios** | Actualizaciones promedio por mes (menos es mejor para estabilidad) | | **Disponibilidad** | Porcentaje de uptime para piezas con componente de servicio | | **Tiempo de integración** | Minutos promedio para que un usuario nuevo la ponga en funcionamiento | | **Costo por uso** | Precio por llamada/operación | | **Satisfacción** | Calificación promedio de usuarios | | **Documentación** | Completitud y claridad de la documentación | --- ## Lo que USEE No Es ### No es un framework USEE no te dice cómo estructurar tu aplicación. Te da piezas; tú decides cómo combinarlas. ### No es un lenguaje USEE funciona con cualquier lenguaje de programación. Las piezas se comunican con texto, no con código. ### No es una plataforma cerrada El protocolo es abierto. Cualquiera puede crear piezas USEE. El marketplace es una implementación del ecosistema, no el ecosistema mismo. ### No es una solución para todo USEE es ideal para funcionalidad discreta y bien definida. Sistemas que requieren integración profunda y estado compartido complejo pueden no beneficiarse del enfoque atómico. --- ## Invitación Si crees que el software debería ser más simple, más estable, y más accesible, te invitamos a: - **Usar** piezas USEE en tus proyectos - **Crear** piezas que respeten el protocolo - **Contribuir** a la definición y evolución del estándar El software puede ser mejor. USEE es nuestra propuesta de cómo. --- *Este manifiesto es un documento vivo. Evolucionará con el ecosistema, pero sus principios fundamentales —Útil, Simple, Esencial, Estable— permanecerán constantes.* --- **USEE**: Porque el software debería funcionar para las personas, no al revés.