Cómo contribuir

Dónde vive el catálogo

Cada herramienta es una entrada en src/data/tools.ts. La traducción al inglés de esa misma entrada (descripción, features, pros/cons) va en src/data/tools.en.ts, con el mismo id. No hay ningún otro sitio donde se guarden los datos — lo que ves en la web es literalmente el contenido de ese archivo en el último build.

Añadir una herramienta nueva

1. Haz fork del repo y abre src/data/tools.ts.
2. Copia una entrada existente de una categoría parecida como plantilla y añade la tuya al array.
3. Añade la traducción al inglés (mismo id) en tools.en.ts.
4. Ejecuta npm run dev y comprueba que la ficha se ve bien, luego npm run build para confirmar que no rompe nada.
5. Abre un Pull Request. Si prefieres no tocar código, abre un Issue en su lugar (ver más abajo) y lo añadimos nosotros.

Campos de una ficha

El tipo OpenSourceTool (en src/lib/types.ts) exige estos campos para que el build compile:

• id / slug — el mismo string en minúsculas y guiones (ej. "n8n"). Tiene que ser único en todo el catálogo.
• name, description, shortDescription.
• replaces — array con el/los SaaS al que sustituye, ej. ["Notion", "Slite"].
• category — una de las categorías existentes en ToolCategory (src/lib/types.ts). Si ninguna encaja, dilo en el PR/Issue y lo discutimos.
• websiteUrl / githubUrl.
• license — la licencia real tal cual aparece en el archivo LICENSE del repo (ej. "MIT", "AGPL-3.0", "Sustainable Use License (Fair-code)"), no un genérico "open source".
• dockerCompose — el docker-compose.yml real del proyecto, con imágenes en una versión fijada cuando el proyecto publique una (evita :latest si existe un tag estable). Si de verdad no se despliega con docker-compose (instalador propio tipo curl | bash), pon ese script en su lugar con un comentario explicando qué hace.
• features, techStack, pros, cons, tags.

Estos otros campos son opcionales para que el build compile, pero los esperamos en cualquier herramienta nueva desde que empezamos a exigirlos de forma sistemática:

• fossModel — "FOSS" (licencia OSI, sin función de pago), "OpenCore" (núcleo OSI + funciones de pago), "FairCode" (sin límites de uso pero licencia no-OSI que prohíbe revenderlo) o "SourceAvailable" (código público, licencia no-OSI). No lo pongas si no estás seguro — lo revisamos antes de publicar.
• minRamMb / difficulty — si los omites, se infieren automáticamente contando los servicios de tu dockerCompose. Solo fíjalos a mano si sabes el requisito real de RAM del proyecto y quieres que sea más preciso que la estimación.
• dockerStatus — "VERIFIED_PINNED" si has comprobado que la imagen existe con ese tag exacto en su registro real. No lo pongas si no lo has verificado tú mismo.

Qué aceptamos

• Software self-hosted que de verdad funcione — no un anuncio de producto ni un proyecto en fase de idea.
• Repositorio de código público y accesible (GitHub, GitLab, Codeberg...).
• Licencia identificable y verificable en ese repositorio — no "es de código abierto" sin más.
• Actividad reciente reconocible (commits, releases o issues respondidos en los últimos meses). No tenemos un umbral exacto de días — si el proyecto lleva mucho tiempo sin ningún movimiento, dilo en el PR y lo valoramos caso por caso; no rechazamos automáticamente por una fecha concreta.

Reportar un dato desactualizado

Si ves una licencia que cambió, una imagen Docker en :latest que ya debería estar fijada a una versión, un enlace roto o cualquier otro dato desactualizado, abre un Issue con la plantilla de abajo — no hace falta que sepas resolverlo, solo señalarlo con un enlace a la fuente real (el LICENSE del repo, la página de tags del registro, etc.).

Enlaces directos