Si estás buscando una oficina virtual de código abierto, no necesitas que te expliquen el «porqué». Precio por usuario en una herramienta que toda la empresa mantiene abierta todo el día, datos de presencia que prefieres tener en tus propios servidores, una categoría con historial de cambios de rumbo y cierres: estás aquí por alguna mezcla de todo eso.
Lo difícil es que no hay muchas opciones reales, y la etiqueta «código abierto» esconde grandes diferencias. Algunas herramientas son open-core con las partes útiles detrás de una edición de pago, y otras necesitan una pequeña flota de servicios para poder autoalojarse. Así que este artículo hace dos cosas. Primero, te da una lista de cinco puntos para evaluar cualquier oficina virtual de código abierto. Segundo, recorre un candidato concreto: Hiroba, una oficina virtual Apache-2.0 con un servidor en Rust autoalojable de un único binario y un cliente de escritorio nativo.
Qué mirar en una oficina virtual de código abierto
Una cosa que aclarar antes de la lista: para qué sirve realmente la herramienta. Las reuniones ya están cubiertas; Zoom y Google Meet no van a desaparecer. Lo que una oficina virtual recupera es el momento anterior a una conversación: ver que un compañero anda por ahí, acercarse y preguntar «¿tienes un segundo?». Eso se reduce a dos cometidos, presencia de un vistazo y conversación sin ceremonias. Las herramientas que añaden videollamadas, grabación y pizarras encima de esos dos cometidos se vuelven pesadas de ejecutar y pesadas de alojar, así que la lista de abajo usa estos dos cometidos como vara de medir.
Con eso resuelto, estas son las preguntas que de verdad separan las opciones. «Código abierto» en la etiqueta dice poco por sí solo.
1. ¿Qué cubre realmente la licencia?
Comprueba dos cosas: la licencia en sí (permisiva como Apache-2.0/MIT frente a copyleft como AGPL, que importa si piensas modificarla y ofrecerla como servicio) y qué queda excluido. Algunos productos de «código abierto» son open-core: las partes interesantes, como SSO, controles de administración y escalabilidad, viven en una edición cerrada de pago. Lee la sección de licencia del repositorio, no la página de marketing.
2. ¿Cuánto trabajo es el self-hosting, de verdad?
Aquí es donde más difieren las oficinas virtuales. Algunas requieren una pila de docker-compose: un servidor de aplicación, una base de datos, un servidor de medios (SFU), un servidor TURN, Redis. Eso es un compromiso operativo real; cada pieza móvil es algo que hay que parchear y monitorizar. En el otro extremo, algunos servidores son un único binario que copias a una VM y ejecutas. Antes de comprometerte, busca la guía de self-hosting y cuenta las cajas del diagrama de arquitectura.
3. ¿Por dónde pasa realmente el audio?
Una pregunta infravalorada. Si la voz se enruta por un servidor de medios (SFU), tu servidor necesita ancho de banda y CPU para cada conversación simultánea, y técnicamente toca el audio. Si la voz es WebRTC peer-to-peer, el servidor solo negocia conexiones, sigue siendo barato de operar y nunca maneja un solo paquete de audio. El P2P tiene límites (el audio en malla no escala a salas grandes), pero para las conversaciones pequeñas y espontáneas para las que existe una oficina virtual, es un compromiso que merece la pena.
4. ¿Puede quedarse abierta todo el día en portátiles normales?
Una oficina virtual solo es útil cuando todo el mundo está dentro, y la forma más rápida de matar la adopción es un cliente que hace girar los ventiladores. Las pestañas del navegador y las apps Electron pueden estar bien, pero luchan contra el peso de su plataforma. Busca cifras publicadas de CPU y memoria en reposo, y prueba en la máquina más antigua de tu equipo, no en la más nueva.
5. ¿Qué datos envía a casa?
El código abierto permite comprobarlo, así que compruébalo: qué telemetría existe, dónde está documentada y si un despliegue autoalojado contacta con el proveedor en absoluto.
Hiroba: una oficina virtual de código abierto y autoalojable
Hiroba («plaza» en japonés) es nuestro intento de la oficina virtual de dos cometidos descrita arriba, construida para puntuar bien exactamente en esas cinco preguntas.
Cómo es usarla
Tu organización recibe una planta: un vestíbulo compartido en el centro y salas de equipo alrededor. Cuando abres Hiroba, tu avatar aparece en la planta, y eso por sí solo le dice a tu equipo que estás por ahí.
- Presencia de un vistazo. La planta muestra quién está activo, ausente, ocupado o ya en una llamada.
- Acércate para hablar. Mueve tu avatar cerca de un compañero y la voz espacial aparece gradualmente. Sin enlace, sin invitación, sin ceremonias.
- Llama a cualquiera con un clic. Para alguien en otra sala, pulsa Call junto a su nombre en la lista. Es el equivalente digital de dar un toque en el hombro.
- Pantalla compartida y cámara cuando las necesites. Dentro de una llamada, ambas están a un clic y van peer to peer. El resto del tiempo no hay nada en marcha, y eso es parte de por qué el cliente se mantiene ligero.
Cómo está construida (y por qué eso la mantiene ligera)
El servidor está escrito en Rust (axum + tokio) y se compila en un único binario estático. Solo mueve datos de control: la lista, las posiciones de los avatares, las decisiones de proximidad y el handshake de WebRTC. El audio nunca pasa por el servidor. La voz es una malla WebRTC peer-to-peer (Opus), así que el servidor se mantiene diminuto y barato en reposo, y tus conversaciones se conectan directamente entre las personas que las tienen.
El cliente es una app nativa hecha con Tauri (una capa en Rust sobre el WebView del sistema operativo, con un frontend en TypeScript puro + Canvas 2D) en lugar de un paquete Electron que arrastra su propia copia de Chromium. En nuestras mediciones, en reposo ronda los 100 MB de memoria (medido en macOS; varía según el entorno) con una CPU en reposo casi nula. Está diseñado para quedarse en segundo plano de la mañana a la tarde sin competir con tu trabajo real.
Licencia y telemetría, en términos claros
Hiroba está bajo Apache-2.0 en GitHub: código, documentación y protocolo, con concesión de patentes. Una salvedad honesta: el nombre «Hiroba», el logotipo y los iconos de la app están excluidos de la licencia, así que un fork no puede distribuirse con nuestra marca. Todo lo funcional es abierto.
La telemetría se limita a la comprobación de actualizaciones en las compilaciones oficiales, documentada en el README: una fila por dispositivo y día (plataforma, arquitectura, versión, país aproximado), no vinculable entre días y eliminada a los 90 días. No hay otra telemetría: nada sobre tu organización, planta, compañeros o llamadas. Los despliegues autoalojados que compilan su propio cliente nunca contactan con nosotros.
Autoalojar Hiroba en la práctica
La versión corta: copia un binario a un servidor y ejecútalo.
- Sin piezas auxiliares. Sin servidor de medios, sin Redis, sin base de datos externa. La persistencia es SQLite opcional, activada con una variable de entorno. El diagrama de arquitectura tiene una sola caja.
- Sin límite de puestos ni funciones bloqueadas. El servidor autoalojado es el producto completo, para tantas personas como quieras traer.
- Los clientes se compilan desde el mismo repositorio. Compilas el cliente de escritorio con la URL de tu servidor incorporada; los instaladores oficiales son para macOS y Windows.
- Las notas de red están documentadas. Como la voz es P2P, la mayoría de las configuraciones no necesitan nada especial, pero los NAT restrictivos pueden requerir un servidor TURN; la guía de self-hosting cubre despliegue, configuración y detalles de firewall/NAT.
Y si te gusta el producto pero no quieres operarlo: hay una edición alojada gestionada con inicio de sesión OAuth, invitaciones y facturación a 2 $ por usuario al mes, con 30 días de prueba gratis y sin tarjeta. Los detalles están en la página de precios. El mismo núcleo de código abierto en ambos casos.
La forma más rápida de juzgarla es usarla una jornada de trabajo junto a tu trabajo real y ver si sigue abierta al final. La app de escritorio es una descarga normal, y la prueba de 30 días de la edición alojada empieza al iniciar sesión, sin tarjeta.
Descargar Hiroba→Preguntas frecuentes
¿Hay una alternativa gratuita y de código abierto a Gather u oVice?
Hiroba es una: con licencia Apache-2.0, servidor autoalojable y sin límite de puestos, y mucho más ligera que cualquiera de las dos, ya que funciona como app de escritorio nativa con CPU en reposo cerca del 0 % en lugar de una pestaña del navegador. Las reuniones programadas se quedan en tu herramienta de reuniones. La comparamos con Kumospace, SoWork y WorkAdventure en Las mejores alternativas a Gather en 2026.
¿Hiroba es realmente gratis, o es open-core?
El código, la documentación y el protocolo son Apache-2.0, y el servidor autoalojado es el producto completo, sin límite de puestos ni funciones bloqueadas. Lo que pagas, opcionalmente, es la edición alojada gestionada (2 $/usuario/mes) en la que nosotros operamos el servidor y nos encargamos del inicio de sesión, las invitaciones y la facturación. Lo único que no cubre la licencia es la marca: el nombre Hiroba, el logotipo y los iconos no pueden reutilizarse en un fork.
¿Mi audio pasa por el servidor?
No. La voz es WebRTC peer-to-peer entre clientes; el servidor solo gestiona la lista, las posiciones y la señalización de conexión, y nunca toca los medios. No se graba nada.
¿Qué necesito para ejecutar el servidor?
Una VM pequeña y un binario estático en Rust. La persistencia es SQLite opcional mediante una variable de entorno; no hay base de datos externa, servidor de medios ni cola de mensajes. Los NAT corporativos restrictivos pueden necesitar además un servidor TURN, y la guía de self-hosting del repositorio explica cuándo y cómo.
¿Qué plataformas admite el cliente?
Hay instaladores oficiales para macOS y Windows, así que los equipos con hardware mixto no tienen problema.