# Software libre con IA **Serie:** «Discernimiento humano y creatividad soberana mediada por IA» **Capítulo:** 3 de 3 **Duración considerada:** hasta 3 horas **Núcleo práctico:** 90 min · adaptación directa y situada de *Intro to Open Source Software*, de Liz Howard **Contextualización y cierre de serie:** hasta 60 min · adaptación para contexto hispanohablante/latinoamericano + integración conceptual de la serie **Margen flexible:** hasta 30 min · preguntas, conversación, pausas y profundización según el grupo **Formato:** Workshop remoto, aplicado y participativo **Idioma:** Español **Nivel:** Todos los niveles **Requisitos previos:** Ninguno *Adaptación situada al español del workshop «Intro to Open Source Software» de Liz Howard para The Multiverse School, con una capa adicional de alfabetización de repositorios, búsqueda asistida por IA y cierre conceptual de la serie.* **Este workshop propone una forma práctica de recuperar acceso, reducir dependencia y elegir con más criterio las herramientas digitales que usamos: partir de una necesidad real, encontrar alternativas libres, leer sus señales de salud, entender qué implica adoptarlas y decidir cuándo conviene reemplazar una herramienta, conservarla o reducir la dependencia que tenemos de ella.** --- ## Descripción general del curso Una herramienta digital puede volverse inaccesible por muchas razones. Puede costar demasiado. Puede exigir una suscripción recurrente. Puede limitar funciones detrás de un plan pagado, un trial o un watermark. Puede haber dejado de funcionar en nuestro hardware. Puede guardar nuestros datos en un formato difícil de mover. Puede depender de una cuenta, de un servicio remoto o de una empresa cuya continuidad no controlamos. El punto de partida de este workshop no es abandonar software comercial por principio ni reemplazar todo lo que usamos. La pregunta es más concreta: > **¿Qué necesito hacer, de qué herramienta o servicio dependo hoy para hacerlo y qué otras rutas existen?** Siguiendo el recorrido de *Intro to Open Source Software*, comenzaremos por identificar una suscripción, herramienta o capacidad que nos interese reemplazar o conseguir. Después recorreremos directorios de alternativas, aprenderemos a leer un repositorio sin convertirnos en desarrolladores, observaremos señales de mantenimiento y actividad humana, y usaremos IA como scout para ampliar la búsqueda cuando una lista curada no sea suficiente. El objetivo no es encontrar «el software más popular» ni asumir que toda alternativa libre es automáticamente la mejor elección. Queremos poder distinguir entre una aplicación que se descarga en minutos, una migración que requiere preparar datos y una solución self-hosted que implica infraestructura y mantenimiento. Una buena decisión puede ser cambiar de herramienta. También puede ser conservar la que ya tenemos. --- # Pregunta central > **¿De qué dependen mis herramientas digitales, qué puedo reemplazar y cuánto control necesito realmente?** Pregunta práctica complementaria: > **¿Qué capacidad necesito y qué software libre puede permitirme acceder a ella sin construir una dependencia innecesaria?** --- # Objetivos de aprendizaje Al finalizar este workshop, las personas participantes podrán: - identificar una herramienta, suscripción o capacidad digital que quieran reemplazar, abaratar o conseguir; - reconocer software libre y open source como una ruta legítima de acceso a herramientas que pueden descargarse, usarse, estudiarse y mantenerse sin piratear software propietario; - distinguir entre **aplicaciones locales, servicios web/hosted y soluciones self-hosted**; - utilizar **OpenAlternative** como punto de partida para encontrar alternativas; - comprender qué es un repositorio de GitHub y dónde encontrar README, documentación, releases e instrucciones de instalación; - distinguir entre **código fuente** y una **release/binario listo para instalar**; - leer señales básicas de actividad y madurez de un repositorio sin confundirlas con una certificación automática de seguridad o calidad; - interpretar stars, antigüedad, commits recientes, forks, contributors, releases, issues y pull requests como señales distintas; - utilizar IA para ampliar una búsqueda y comparar repositorios según necesidades definidas por la persona usuaria; - reconocer cuándo una alternativa supone una migración simple y cuándo implica datos, compatibilidad, hosting, almacenamiento, backups o mantenimiento; - decidir si conviene **reemplazar, conservar o reducir dependencia** de una herramienta; - diseñar una ruta de adopción gradual sin necesidad de reemplazar todo a la vez; - relacionar software libre, interoperabilidad y reimplementación con el arco de soberanía tecnológica desarrollado a través de la serie. --- # Para quién es este workshop Este workshop está pensado para: - personas que pagan suscripciones de software y quieren reducir costos; - personas que necesitan herramientas a las que actualmente no pueden acceder por precio, hardware, modelo de suscripción o restricciones del servicio; - freelancers, estudiantes, educadores, pequeños negocios y organizaciones que dependen de varias plataformas digitales; - personas que usan free tiers, trials, versiones antiguas o herramientas limitadas y quieren conocer otras rutas; - personas no técnicas que encuentran GitHub intimidante o confuso; - personas interesadas en privacidad, control de datos, interoperabilidad o self-hosting, sin que el workshop requiera conocimientos previos de servidores; - personas que simplemente quieren entender mejor de qué dependen las herramientas que usan. No necesitas programar. No necesitas conocer Git. No necesitas llegar con una suscripción activa. --- # Qué vas a necesitar - un computador con acceso a internet; - un navegador web; - acceso a un asistente de IA generalista; - idealmente una herramienta, suscripción o capacidad que te interese investigar; - un lugar donde anotar alternativas, señales del repositorio y próximos pasos. Si no tienes ninguna suscripción activa, piensa en una herramienta que te gustaría poder usar pero que hoy está fuera de tu alcance, limitada por un free tier o disponible sólo de una forma que no te resulta adecuada. --- # PARTE I · Núcleo práctico ## Adaptación directa de «Intro to Open Source Software» · 90 min --- # BLOQUE 1 · Partir de una necesidad **10 min** El workshop de Liz comienza auditando gasto de software. Conservamos esa entrada, pero ampliamos la pregunta para un contexto donde muchas personas no parten de una pila de suscripciones pagadas. Elige **una** herramienta o capacidad para tener en mente durante el recorrido. Puede ser: - una suscripción que quieres dejar de pagar; - una herramienta cuyo precio aumentó; - una función bloqueada detrás de un plan premium; - un programa que sólo usas mediante trial o watermark; - una versión antigua que mantienes porque la nueva es inaccesible; - una herramienta que necesitas pero nunca has podido pagar; - un servicio del que te gustaría depender menos. Registra tres cosas: 1. **qué herramienta o capacidad es**; 2. **qué necesitas hacer con ella**; 3. **qué problema quieres resolver al buscar una alternativa**. No es necesario auditar toda tu vida digital. El workshop necesita un problema concreto, no un inventario perfecto. --- # BLOQUE 2 · Qué significa «software libre» en la práctica **10 min** Explicación breve y no jurídica. Para este workshop nos interesa una consecuencia práctica: > **existe software que puedes descargar, instalar y utilizar legalmente sin pagar una licencia propietaria ni piratear una herramienta comercial.** El código abierto permite además que otras personas puedan inspeccionar, mantener, adaptar y redistribuir proyectos según sus licencias. No convertiremos esta sesión en una clase de licencias, Git ni modelos de gobernanza. ## Tres formas de encontrarnos con software libre | Forma | Qué significa para la persona usuaria | Complejidad aproximada | |---|---|---| | **Aplicación local** | Descargar e instalar en tu computador o teléfono | Baja | | **Servicio web / hosted** | Usar desde el navegador en infraestructura mantenida por otra persona u organización | Baja a media | | **Self-hosted** | Instalar y mantener el software en una máquina o servidor propio/alquilado | Media a alta | **Software gratis no significa necesariamente infraestructura gratis.** Una aplicación local puede no costar nada más allá del computador que ya tienes. Una solución self-hosted puede requerir servidor, almacenamiento, ancho de banda, electricidad, backups o tiempo de mantenimiento. Eso no cambia que el software pueda ser libre o gratuito: cambia **qué hace falta para operarlo**. --- # BLOQUE 3 · Primer mapa: OpenAlternative **15 min** Abrir [OpenAlternative](https://openalternative.co) como directorio inicial. La lógica del paseo es: 1. buscar una herramienta conocida o una función; 2. abrir varias alternativas, no sólo el primer resultado; 3. entender qué problema resuelve cada una; 4. distinguir local, web y self-hosted; 5. seguir el enlace hacia el repositorio cuando exista; 6. identificar qué tan difícil sería probarla o migrar hacia ella. ## Preguntas para una primera lectura - ¿Hace realmente lo que necesito? - ¿Corre en mi sistema operativo o dispositivo? - ¿Puedo descargarla y usarla inmediatamente? - ¿Necesito una cuenta? - ¿Necesito migrar datos? - ¿Necesito un servidor? - ¿Existe una versión hosted si no quiero administrar infraestructura? OpenAlternative es un **mapa inicial**, no una autoridad final. --- # BLOQUE 4 · Leer un repositorio: buscar ojos humanos, no sólo popularidad **20 min** Un repositorio puede mostrar muchas señales de actividad. Ninguna cifra aislada demuestra que un proyecto sea «seguro», «bueno» o adecuado para tu caso. La pregunta útil es: > **¿Qué señales sugieren que hay personas usando, observando, manteniendo y respondiendo por este software?** ## Stars Las stars funcionan principalmente como señal de atención o popularidad. Se parecen más a un like, bookmark o follow que a una auditoría. Muchas stars indican que el proyecto ha atraído interés. No demuestran por sí solas que el código esté bien mantenido ni que alguien haya revisado cada cambio. ## Último commit Permite observar si el proyecto parece seguir activo. Como heurística rápida utilizada por Liz: - actividad durante los últimos días o semanas: señal muy favorable; - actividad dentro de aproximadamente **dos meses**: proyecto aparentemente vivo; - períodos mucho más largos sin cambios: motivo para investigar si el proyecto está estable, congelado o abandonado. No es una ley. Un proyecto maduro puede necesitar pocos cambios. ## Antigüedad del proyecto Una historia de aproximadamente **dos años o más** puede ser una señal útil de madurez: el software ha tenido tiempo para encontrarse con usuarios, bugs, cambios de plataforma y situaciones reales de uso. Un proyecto nuevo puede ser excelente, pero todavía tiene menos historia operacional. ## Forks Un fork implica una interacción más fuerte con el código que una star: alguien creó una copia del repositorio sobre la que puede trabajar o experimentar. Liz usa una regla mental deliberadamente aproximada: > **forks ÷ 10 = orden de magnitud posible de personas técnicamente involucradas** No es una fórmula estadística ni un conteo real de contributors. Sirve para pensar rápidamente si estamos frente a un proyecto observado por unas pocas personas, decenas, cientos o una comunidad mucho mayor. ## Contributors, releases, issues y documentación También interesa observar: - cuántas personas aparecen contribuyendo; - si existen releases recientes y claramente etiquetadas; - si el README explica qué hace el proyecto; - si las instrucciones de instalación están actualizadas; - si existen issues recientes y respuestas de maintainers; - si hay documentación y comunidad donde buscar ayuda. ## Pull requests y actividad automatizada Una gran cantidad de pull requests o commits tampoco equivale automáticamente a una gran comunidad humana. Los repositorios actuales pueden recibir actividad de: - bots; - herramientas automáticas de dependencias; - agentes de IA; - contributors humanos ocasionales; - maintainers del proyecto. Además, un pull request sólo indica que alguien **propuso** un cambio. No certifica su intención, calidad ni aceptación. Por eso leemos las métricas como **proxies que se interpretan juntas**, no como una puntuación mágica. --- # BLOQUE 5 · GitHub sin convertirse en desarrollador **10 min** GitHub no es una App Store. Para instalar software no necesitas aprender Git, pero sí conviene reconocer algunas piezas: - **Repository / repo:** carpeta pública donde vive el proyecto y su historial. - **README:** portada y explicación principal. - **Releases:** versiones publicadas para uso real. - **Latest release:** versión estable más reciente cuando el proyecto utiliza releases. - **Assets:** archivos descargables de una release. - **Source code:** código fuente; no siempre es lo que una persona usuaria quiere descargar. - **Docs / Documentation:** instrucciones y manuales. - **Issues:** reportes, preguntas y problemas conocidos. Antes de descargar un archivo, revisa para qué sistema operativo y arquitectura fue construido. Si el proyecto sólo ofrece instrucciones para compilar, Docker, paquetes de servidor o comandos de terminal, probablemente no estás frente a un «easy win» para una persona no técnica. --- # BLOQUE 6 · IA como Repo Scout **15 min** Cuando OpenAlternative no encuentra lo que necesitas, cuando devuelve demasiadas opciones o cuando quieres comparar proyectos con mayor detalle, la IA puede funcionar como **scout de repositorios**. La IA no reemplaza la decisión. Reduce el trabajo de búsqueda y organiza evidencia para que la persona pueda decidir. ## Flujo **necesidad → búsqueda → candidatos → señales de salud → dificultad de adopción → comparación → decisión** ### Instrucción base para el scout > **Necesito software para [función]. Mi sistema/plataforma es [X]. Puedo/no puedo usar self-hosting. Mis restricciones son [presupuesto, hardware, privacidad, dificultad técnica, etc.]. Busca alternativas open source relevantes, incluyendo GitHub cuando sea necesario. No ordenes sólo por popularidad. Para cada candidato, revisa antigüedad del proyecto, actividad reciente, stars, forks, contributors, releases, documentación, modalidad de instalación y señales de mantenimiento. Distingue actividad humana visible de actividad potencialmente automatizada cuando sea posible. Explica incertidumbres. Después compáralos según mis necesidades y dime cuál vale la pena investigar primero.** La persona puede agregar estándares propios al prompt y reutilizarlos en un proyecto o workspace para futuras búsquedas. --- # BLOQUE 7 · Decidir la ruta de adopción **10 min** Encontrar un buen repositorio no obliga a migrar. Clasificaremos la decisión según el trabajo real que exige. ### Easy win - descarga o acceso inmediato; - no requiere servidor; - poca o ninguna migración; - puedes probarlo sin romper tu flujo actual. **Siguiente paso posible:** instalar y probar. ### Migración - necesitas exportar archivos, configuraciones o datos; - importa la compatibilidad con formatos existentes; - conviene mantener temporalmente ambas herramientas; - necesitas verificar que nada importante se pierda. **Siguiente paso posible:** planificar un período de transición. ### Self-hosted / proyecto mayor - requiere servidor o máquina dedicada; - almacenamiento y backups; - configuración de red o dominio; - actualizaciones y mantenimiento; - posiblemente ayuda técnica. **Siguiente paso posible:** salir del workshop con una ruta de implementación, no intentar desplegarlo completo durante la sesión. ## Ejemplo: una «instancia personal de Netflix» Herramientas como Jellyfin, Kodi o Plex pueden ayudar a organizar, presentar y reproducir una biblioteca de medios, pero **no traen una colección de películas, música o fotografías**. El software administra contenido al que la persona ya tiene acceso legítimo. Una solución de este tipo obliga además a pensar en: - dónde vive la biblioteca; - cuánto almacenamiento requiere; - qué máquina ejecutará el servicio; - si habrá acceso remoto; - si se necesita transcoding; - quién mantendrá el sistema. El workshop puede ayudar a **elegir la arquitectura y los repositorios adecuados**. No es un taller de despliegue de un media server específico. --- # Resultado del núcleo práctico Al terminar los primeros 90 minutos, una persona debería poder conservar: 1. una necesidad o dependencia digital claramente identificada; 2. varias alternativas posibles; 3. una lectura básica de sus repositorios; 4. una comparación que no dependa sólo de popularidad; 5. una decisión provisional: **probar, migrar, investigar más o conservar lo que ya usa**; 6. un próximo paso realista. No es necesario haber instalado nada para que el recorrido sea completo. Si existe un easy win y la instalación toma pocos minutos, se puede probar durante la sesión. --- # PARTE II · Adaptación situada y cierre de la serie ## Hasta 60 min Esta parte amplía el workshop original y conecta el recorrido práctico con el arco completo de **«Discernimiento humano y creatividad soberana mediada por IA»**. --- # BLOQUE 8 · El problema no siempre es «ahorrar» **20 min** El workshop original parte de una realidad frecuente en Estados Unidos: personas y pequeños negocios que acumulan suscripciones y pueden recuperar dinero reemplazando SaaS pagado. Ese argumento sigue siendo útil, pero no cubre todas las experiencias de acceso. En contextos latinoamericanos e hispanohablantes, una persona puede no tener una suscripción que cancelar porque nunca pudo pagarla. La restricción puede aparecer como: - usar solamente el free tier; - esperar promociones o trials; - tolerar watermarks; - conservar versiones antiguas; - compartir cuentas; - trabajar con hardware que ya no soporta el software comercial actual; - improvisar soluciones parciales; - simplemente renunciar a una capacidad porque parece fuera de alcance. Por eso ampliamos el marco: > **software libre no sólo puede significar ahorro; también puede significar acceso.** La pregunta deja de ser únicamente: > **¿Qué puedo dejar de pagar?** Y también puede ser: > **¿Qué puedo empezar a hacer porque ahora conozco otra ruta?** --- # BLOQUE 9 · (Material Complementario) ## Clean Room: conservar función, cambiar implementación: **10 min** El capítulo anterior trabajó una idea sencilla: un producto no tiene que ser aceptado como una unidad cerrada. Podemos mirar funciones, partes, interfaces, capacidades y restricciones. En software aparece una operación emparentada. Una implementación concreta no es necesariamente la única forma posible de conservar una función, una interfaz o una relación de interoperabilidad. **Clean-room implementation, reverse engineering para interoperabilidad y reimplementación funcional** permiten observar históricamente cómo sistemas diferentes han buscado mantener comportamiento o compatibilidad sin conservar la misma implementación. No enseñaremos Clean Room como procedimiento jurídico ni como permiso universal para copiar software. Lo utilizamos como **bisagra conceptual**: > **cuando una ruta tecnológica está cerrada, una respuesta posible es entender qué función o interfaz necesitamos conservar y construir otra implementación capaz de ocupar ese lugar.** ### CLEANROOM GRAPH <iframe src="https://www.acevedology.com/notes/inventiva-bajo-restriccion/clean-room-reimplementation/" width="100%" height="600" frameborder="0" style="border:1px solid #30363d; border-radius:12px;"></iframe> Click aquí si el grafo de arriba no carga: [Abrir grafo · Clean-room, reimplementation and interoperability](https://www.acevedology.com/notes/inventiva-bajo-restriccion/clean-room-reimplementation/) En el grafo se distinguen: - black-box analysis; - reverse engineering for interoperability; - clean-room implementation; - functional reimplementation; - interface/API reimplementation; - protocol reimplementation; - compatible implementations; - porting y rewrite como operaciones diferentes. La utilidad para este workshop no está en convertirnos en implementadores de una API. Está en reconocer que **función, interfaz, producto e implementación no son la misma cosa**. Ese desplazamiento conecta directamente con la manera en que buscamos alternativas de software. --- # BLOQUE 10 · Cerrar el círculo: soberanía tecnológica **10 min** La serie ha recorrido tres escalas de una misma pregunta. ## Capítulo 1 · Pensamiento y creatividad soberanos con IA Observamos procesos creativos mediados por IA y preguntamos: - qué estamos intentando hacer; - qué delegamos; - con qué criterio evaluamos; - qué decisiones queremos conservar. La soberanía no exigía realizar manualmente cada operación. Exigía conservar suficiente criterio para dirigir y decidir. ## Capítulo 2 · Inventiva bajo restricción con IA Llevamos esa mirada al mundo material. Un producto dejó de ser una identidad cerrada y se convirtió en: **funciones → partes → propiedades → módulos → interfaces → capacidades disponibles** La inventiva apareció en el espacio entre una necesidad y los recursos realmente accesibles. ## Capítulo 3 · Software libre con IA Ahora hacemos la misma operación sobre nuestras herramientas digitales. Una plataforma, aplicación o servicio deja de ser «la única manera de hacer X» y puede volver a leerse como: **función → datos → interfaces → dependencias → alternativas → rutas de adopción** La pregunta final de la serie no es: > **¿Puedo vivir sin software propietario?** Es: > **¿Conservo suficiente comprensión y capacidad de elección para decidir de qué herramientas quiero depender?** El software libre ocupa aquí un lugar práctico dentro de una idea más amplia de soberanía tecnológica. No exige self-hostear todo. No exige rechazar herramientas comerciales que funcionan bien para nuestro caso. Significa poder reconocer dependencias, conocer alternativas, movernos cuando una herramienta deja de servirnos y evitar que el acceso a una función quede confundido con el acceso a una única plataforma. La IA participa en este capítulo como mediadora de investigación: puede buscar, comparar, explicar, leer documentación y reducir la barrera de entrada a repositorios que antes podían resultar opacos. Pero la selección final vuelve al mismo lugar donde comenzó la serie: > **el criterio de la persona que sabe qué está intentando hacer y por qué una opción le sirve mejor que otra.** ### Movimiento completo de la serie > **imaginar → resolver → conservar capacidad de acción** Y su frase de cierre: > **La creatividad nos permite imaginar otras posibilidades; la inventiva nos permite construirlas con lo que tenemos; la soberanía nos permite conservar la capacidad de hacerlo.** --- # Conversación, Q&A y margen flexible ## Hasta 30 min El tiempo restante queda deliberadamente abierto. Puede utilizarse para: - preguntas sobre herramientas concretas; - comparar repositorios encontrados por participantes; - aclarar una instalación sencilla; - discutir una migración; - distinguir cuándo una solución self-hosted requiere ayuda técnica; - profundizar en Clean Room o en el arco de la serie; - hacer una pausa cuando el ritmo del grupo lo necesite. No es necesario extender la sesión artificialmente hasta completar tres horas. El núcleo práctico está diseñado para sostenerse en 90 minutos; el resto existe para permitir contexto, conversación y cierre sin comprimir el workshop ni obligar al grupo a permanecer en una profundización que no necesita. --- # Qué este workshop NO es No es: - una clase de Git; - una clase de licencias de software; - un curso de administración de servidores; - un laboratorio de Docker; - un tutorial para construir un media server específico; - una obligación de reemplazar cada herramienta comercial; - una promesa de que self-hosting siempre será más barato; - una afirmación de que más stars equivalen a mejor software; - una auditoría de seguridad profesional de repositorios; - una invitación a descargar contenido sin autorización; - una competencia por quién logra usar más software libre. Una conclusión válida puede ser: > **esta herramienta propietaria sigue siendo la mejor decisión para mi caso.** El objetivo es tener suficiente información para que esa elección sea deliberada. --- # Evidencia de aprendizaje Al finalizar, cada participante debería poder explicar: 1. qué capacidad digital estaba buscando; 2. qué alternativas encontró; 3. por qué descartó o priorizó algunas; 4. qué señales observó en sus repositorios; 5. qué dificultad real tendría adoptarlas; 6. si su siguiente paso es instalar, migrar, self-hostear, investigar más o conservar su herramienta actual; 7. dónde utilizó IA para ampliar la búsqueda y dónde necesitó ejercer criterio propio. --- # Recorrido de la sesión | Tiempo | Parte | |---:|---| | 10 min | Partir de una necesidad | | 10 min | Qué significa software libre en la práctica | | 15 min | OpenAlternative | | 20 min | Leer salud, madurez y actividad humana en repositorios | | 10 min | GitHub sin convertirse en desarrollador | | 15 min | IA como Repo Scout | | 10 min | Decidir la ruta de adopción | | **90 min** | **Núcleo práctico · adaptación directa del workshop de Liz Howard** | | hasta 20 min | Contexto hispanohablante/latinoamericano: ahorro y acceso | | hasta 20 min | Clean Room: función, interoperabilidad y reimplementación | | hasta 20 min | Soberanía tecnológica y cierre de la serie | | hasta 30 min | Q&A, conversación, pausas y profundización flexible | | **hasta 180 min** | **Tiempo total reservado** | --- # Recursos En los siguientes enlaces encontrarás recursos utilizados en este taller y su relación con el resto de la serie: - [OpenAlternative — directorio de alternativas open source](https://openalternative.co) - [GitHub](https://github.com) - [GitHub para leer repositorios](https://themultiverse.school/x/github-para-leer-repositorios) - [Repo Scout](https://themultiverse.school/x/repo-scout) - [Grafo · Clean-room, reimplementation and interoperability](https://www.acevedology.com/notes/inventiva-bajo-restriccion/clean-room-reimplementation/) - [Serie «Discernimiento humano y creatividad soberana mediada por IA»](https://github.com/SandraAcevedoA/serie-discernimiento-creatividad) - [Grafo completo · Inventiva bajo restricción](https://www.acevedology.com/notes/inventiva-bajo-restriccion/) - [Grafo · Cognición, creatividad y mirada funcional](https://www.acevedology.com/notes/inventiva-bajo-restriccion/cognicion-creatividad-mirada-funcional/) - [Grafo · Desobediencia tecnológica](https://www.acevedology.com/notes/inventiva-bajo-restriccion/00-technological-disobedience-index.html) - [Mapa · Fenómenos de inventiva bajo restricción](https://www.acevedology.com/notes/inventiva-bajo-restriccion/Fen%C3%B3menos-de-inventiva-bajo-restricci%C3%B3n.html) - [Recorrido web · Pensamiento y Creatividad Soberanos con IA](https://themultiverse.school/x/pensamiento-creatividad) --- # Procedencia y adaptación El núcleo práctico de este syllabus deriva de **«Intro to Open Source Software»**, de Liz Howard, para The Multiverse School. Se conservan como estructura principal: - partir de una necesidad o gasto de software; - explicar open source de forma breve y accesible; - utilizar OpenAlternative como directorio inicial; - evaluar proyectos mediante señales de actividad y mantenimiento; - diferenciar easy wins, migraciones y self-hosting; - migrar gradualmente en lugar de reemplazar todo a la vez. Esta adaptación agrega: - un punto de partida que incluye **acceso**, no solamente ahorro de suscripciones; - alfabetización mínima para leer repositorios y releases; - una heurística explícita centrada en **actividad humana y mantenimiento**, no sólo popularidad; - un flujo de **Repo Scout asistido por IA**; - una regla de salida que permite conservar software comercial cuando sea la mejor decisión; - contextualización para experiencias de acceso frecuentes en América Latina y otras comunidades hispanohablantes; - el puente conceptual de **Clean Room / reimplementación / interoperabilidad**; - el cierre del arco de la serie **«Discernimiento humano y creatividad soberana mediada por IA»**. --- *Contenido y adaptación del diseño pedagógico de Liz Howard por © Sandra Acevedo · Multiverse School.*