GitBook, una de las plataformas más utilizadas por equipos técnicos para documentar producto, APIs y procesos internos, ha dado un paso relevante en su estrategia: publicar como software libre el código que utiliza para renderizar el contenido ya publicado en sus sitios de documentación. En otras palabras, no se trata de “liberar GitBook entero”, sino de abrir la pieza que convierte una documentación publicada en una web navegable, rápida y con la estética característica de la plataforma.
Ese componente —disponible en el repositorio público GitbookIO/gitbook— se presenta como “el frontend open source para los sitios de documentación de GitBook” y llega con una advertencia importante: aunque es posible autoalojarlo, GitBook no lo recomienda salvo que se tenga muy claro el motivo. El mensaje busca dejar claro que, para la mayoría, el camino preferente sigue siendo contribuir al producto principal o usar el servicio gestionado, en lugar de mantener un fork propio a largo plazo.
Qué es exactamente lo que GitBook ha liberado
El repositorio abierto contiene el código usado para renderizar el contenido publicado de GitBook. Es un matiz que cambia el encuadre: el valor está en el “renderer” (la parte que pinta la web final), no en el editor ni en la plataforma SaaS completa. Aun así, para desarrolladores y responsables de documentación, la apertura es significativa porque habilita escenarios hasta ahora difíciles: integrar la documentación publicada dentro de un producto, personalizar la experiencia visual o experimentar con cambios sin depender del ciclo de releases del servicio.
El propio proyecto deja pistas de su madurez: a fecha de actualización reciente del repositorio, acumula 1.777 commits, y en GitHub se mueve en cifras de adopción muy elevadas, con alrededor de 28.484 estrellas, 4.013 forks y 687 watchers, además de un stack claramente moderno donde predomina TypeScript (con un 96,4 % del código, según GitHub).
Un “stack” moderno: Next.js, Bun y desarrollo local con cualquier GitBook publicado
A nivel técnico, GitBook describe su motor como un proyecto basado en Next.js, y pide dos requisitos muy concretos para levantar el entorno de desarrollo:
- Node.js en versión ≥ 22.3
- Bun en versión ≥ 1.2.15
La razón de Bun no es un capricho: el repositorio usa un lockfile en formato texto que, según el proyecto, no está soportado en versiones anteriores. El arranque local sigue una receta clara para cualquiera con experiencia en front moderno: instalar dependencias con Bun y levantar el servidor con bun dev.
Lo más interesante es el modo de prueba: el motor local permite abrir cualquier site publicado de GitBook a través de una URL con prefijo http://localhost:3000/url/…. Es decir, no hace falta tener un contenido propio para ver el render funcionando: se puede apuntar al sitio público de GitBook o a cualquier espacio publicado y comprobar cambios al vuelo.
Contribuir sí, pero con “letra pequeña”: iconos, CI y dependencias
GitBook también explica una situación habitual en proyectos con estética muy cuidada: la diferencia entre desarrollo local y lo que exige el CI. En este caso, el proyecto usa Font Awesome y, durante el desarrollo, se instala la variante gratuita. Sin embargo, el pipeline de CI solo acepta la versión “pro”, lo que puede provocar errores si alguien modifica dependencias y ese cambio queda persistido en el lockfile.
La solución que plantea el propio proyecto dibuja una frontera clara: solo el equipo de GitBook puede desbloquear ese punto, aportando un token de NPM en un fichero .env.local (variable BUN_NPM_TOKEN) y reinstalando dependencias. Para el contribuidor externo, el mensaje es simple: si el CI falla por iconos, hay que coordinarlo con el equipo.
Aun así, el repositorio anima a contribuir en áreas accesibles, como traducciones de la interfaz, que se gestionan en ficheros dentro de packages/gitbook/src/intl/translations, además de bugs y mejoras incrementales. También deja claro que los pull requests se someten a tests visuales y de rendimiento, una forma de proteger un producto que, por definición, se mide por experiencia de lectura y rapidez.
Autoalojar el renderer: ventajas reales, pero responsabilidad total
La parte más directa del README está en el apartado de despliegue: GitBook reconoce que es posible autoalojar el proyecto, pero insiste en que no lo recomienda salvo necesidad clara. La razón no es técnica, sino operativa: quien se autoaloja pasa a ser responsable de la fiabilidad del sitio, de aplicar actualizaciones y de mantener compatibilidad con los cambios de la plataforma GitBook.
El proyecto resume bien el intercambio:
- Pros: más control sobre el look & feel y mejor integración de la documentación en una aplicación propia.
- Contras: mantenimiento continuo y obligación de seguir el ritmo de cambios de GitBook si se quiere evitar quedarse atrás.
En paralelo, el repositorio introduce un punto crítico para empresas: la licencia. El código se distribuye bajo GNU GPLv3, y GitBook advierte que si se va a distribuir el software, el código debe permanecer público para cumplir la licencia. Para trabajar en un repositorio privado con intención de distribuir, el propio proyecto remite a la opción de licencia comercial.
Una vuelta a los orígenes open source (sin abrirlo todo)
GitBook también ha enmarcado este movimiento como un regreso a sus raíces: la compañía recuerda que el proyecto nació hace más de una década con ADN open source y que abrir el motor de publicación es una forma de reforzar esa relación con la comunidad. Con ello, GitBook busca que el “cómo se ve” la documentación publicada sea auditable y mejorable por terceros, sin prometer —al menos por ahora— la apertura completa del producto.
Preguntas frecuentes
¿Qué parte de GitBook es open source exactamente: el editor o el motor de publicación?
Lo que se ha publicado como open source es el código que renderiza el contenido publicado (el frontend del site), no el editor completo ni toda la plataforma SaaS.
¿Se puede autoalojar GitBook Open para documentación interna en una intranet?
Es posible autoalojar el renderer, pero GitBook advierte que no lo recomienda salvo casos muy justificados, porque obliga a mantener actualizaciones y fiabilidad por cuenta propia.
¿Qué implica la licencia GPLv3 si una empresa modifica el código y lo distribuye?
Según la licencia y las indicaciones del repositorio, si se distribuye el software, hay que hacer público el código fuente; para escenarios privados con distribución, GitBook remite a una licencia comercial.
¿Qué requisitos técnicos pide GitBook Open para desarrollo local y pruebas?
El README indica Node.js ≥ 22.3 y Bun ≥ 1.2.15, y permite probar cualquier site publicado usando la ruta http://localhost:3000/url/....
