Skip to main content

Contexto​

Eigenoid arranca como proyecto multi-componente (paquete Python, runtime A2A, documentación interna, tooling). Hasta este momento el código vivía bajo la cuenta personal @andylow92 (andylow92/SPIRE-A2A-Protocol), lo que es razonable para un experimento individual pero se vuelve frágil en cuanto entran más personas, agentes IA contribuyendo, o automatización con bots: la propiedad del repo, la facturación, los secrets y los permisos quedan acoplados a un usuario humano. Antes de añadir más repos o invitar colaboradores, hay que decidir el hogar de largo plazo.

Decisión​

Creamos una organización de GitHub dedicada llamada eigenoid para alojar todo el código, documentación e infraestructura del proyecto, en lugar de continuar trabajando bajo cuentas personales.

Consecuencias​

  • Identidad y propiedad claras: el código y los repos pertenecen al proyecto, no a un individuo. Si una persona se va, no se pierde acceso ni continuidad.
  • Permisos centralizados: podemos gestionar miembros, equipos y permisos a nivel de org en lugar de invitar caso por caso a cada repo.
  • Bots y apps reutilizables: las GitHub Apps y secrets se pueden definir una sola vez a nivel de org y aplicarse a todos los repos.
  • Visibilidad controlada: todos los repos nacen privados por default, alineado con la naturaleza interna del producto.
  • Costo operativo extra: hay que mantener la membresía, configurar settings de org (security, billing, branch protection a nivel de org), y migrar repos preexistentes que vivían en cuentas personales.
  • Necesitamos un plan tier mínimamente útil (Free alcanza para empezar, pero algunas features como required reviewers en orgs requieren Team).

Alternativas evaluadas​

  • Seguir con repos en cuentas personales (andylow92/...): cero costo de migración, pero acopla el proyecto a una persona y dificulta colaboración formal y gestión de permisos.
  • Monorepo en una cuenta personal: simplifica navegación pero hereda los mismos problemas de propiedad y, además, complica el versionado independiente de subcomponentes.
  • Organización en otro proveedor (GitLab, Bitbucket): el ecosistema de tooling y community que necesitamos (Actions, Discussions, Apps, Copilot) está más maduro en GitHub.

Referencias​