Pasar a código cerrado: los cambios técnicos

Qué es Cal.diy

Cal.diy es la plataforma de programación de código abierto. Incluye el motor de programación completo, el marco de la App Store y la infraestructura de reservas. Es todo lo que hace que Cal.com sea potente como solución autohospedada para particulares.

Se han eliminado las funciones comerciales y empresariales que solo aplican a Cal.com como servicio gestionado. Todas las funciones gratuitas siguen en Cal.diy.

Qué se eliminó

La separación entre Cal.com y Cal.diy se reduce a las funciones comerciales y empresariales. Esto es lo que ya no se incluye en Cal.diy:

• Organizations y Teams: gestión de organizaciones multiinquilino, creación de equipos, disponibilidad de equipos, flujos de reserva de equipo, herramientas de migración de organizaciones, PBAC (control de acceso basado en permisos) y todos los endpoints relacionados de API v2

• Routing Forms: el paquete completo de la app de formularios de routing de la App Store, incluyendo el creador de rutas, acciones del formulario, el diálogo de pruebas, la integración de routing de Salesforce, la funcionalidad de seguimiento de routing y la gestión de respuestas en cola

• Workflows: motor automatizado de workflows (recordatorios, seguimientos, disparadores) y todas las referencias relacionadas en API v2, bibliotecas de la plataforma y flujos de reserva

• Instant Booking: tipos de evento instantáneos y todo el código asociado del servicio de reservas

• AI Phone: ejecución de llamadas telefónicas de Cal.ai y la pestaña del tipo de evento de teléfono con IA

• Attributes and Segments: React Awesome Query Builder (RAQB), atributos de miembros, filtrado basado en segmentos y ajustes de la plataforma del espacio de trabajo

• SAML/SSO: flujo de registro empresarial con SAML/SSO

• Insights: paneles de analítica e informes

• API v1: se eliminó toda la aplicación de API v1. Cal.diy se entrega solo con API v2

• Enterprise UI: asistente de configuración de licencia, descargas de documentos de cumplimiento, consejos de EE, funciones premium para nombres de usuario, página de facturación de admin, traducción con IA, flujo de compra de créditos

• Booking Audit: registro de auditoría de reservas (función de observabilidad empresarial)

• Impersonation: suplantación de usuarios admin en los flujos de sincronización de reservas y calendario

Todo lo demás sigue en Cal.diy: la lógica de programación central, la App Store, los flujos de reserva y API v2.

Preparando el código para Cal.diy

Para preparar el repositorio calcom/cal.com para su transición a calcom/cal.diy, mantuvimos una rama separada en el repositorio privado que se mantuvo sincronizada con la rama principal del repositorio público. Esta rama fue el punto de referencia desde el que identificamos y eliminamos las funciones comerciales antes del cambio de nombre. Al comparar con ella, pudimos ver exactamente qué código había que separar para que, cuando calcom/cal.com se convirtiera en calcom/cal.diy, solo quedara el código de código abierto.

También usamos esta rama para confirmar que todas las comprobaciones de GitHub pasaban correctamente. Queríamos que la entrega del repositorio fuera limpia, así que antes de que el cambio de nombre entrara en vigor, nos aseguramos de que CI estuviera en verde y de que la base de código estuviera en buen estado para que la comunidad pudiera empezar a usarla desde el primer día.

Cambio de licencia: de AGPL 3.0 a MIT

Cambiamos la licencia de Cal.diy de AGPL 3.0 a MIT.

Cal.diy es un producto distinto con un propósito distinto al de Cal.com: ofrecer a la comunidad la plataforma de programación más permisiva posible. MIT encaja mejor con ese objetivo.

Mantenedores de Cal.diy

Cal.diy está mantenido por antiguos becarios de Cal.com que ahora son mantenedores oficiales del repositorio.

Estos ingenieros pasaron tiempo dentro de la base de código de Cal.com. Entienden la arquitectura, los patrones y el producto. Lanzaron funciones reales durante sus becas, revisaron PRs y depuraron incidencias de producción.

El equipo de ingeniería de Cal.com se centra en el producto comercial. Los mantenedores de Cal.diy se centran en la comunidad.

Cambios de infraestructura

El repositorio público tenía años de configuración de CI/CD, integraciones de bots y automatización DevOps. Todo eso había que reconstruirlo para el repositorio privado.

GitHub actions

Cal.diy tiene 53 workflows de GitHub Actions. El repositorio privado tiene 62. Tocamos casi todos los workflows existentes para actualizar las referencias al repositorio antiguo en los pasos de checkout, las URLs de API, las rutas de artefactos y los hooks de despliegue.

Los repositorios privados tienen modelos de permisos diferentes. Varias de las primeras PRs abordaron fallos de CI porque el checkout del repositorio privado requiere permisos explícitos contents: read que los repositorios públicos obtienen de forma implícita.

Secrets y configuración de entorno

La mayoría de los secrets se trasladan, pero algunos hay que aprovisionarlos de nuevo para el repositorio público, como las credenciales de los conjuntos de pruebas que se ejecutan contra Google y Stripe. Los nuevos mantenedores los aprovisionarán pronto y los conjuntos de pruebas se reactivarán automáticamente cuando detecten la configuración.

Backporting de seguridad

Mientras los dos repositorios se mantenían en paralelo, la seguridad fue una prioridad en ambas direcciones. Las vulnerabilidades se parcheaban en el repositorio que las detectara primero y luego se backportaban al otro. A veces una corrección llegaba al repositorio público y se cherry-pickeaba al privado. Otras veces ocurría al revés.

Entre los ejemplos están actualizar axios a 1.15.0 para corregir CVEs críticos, actualizar handlebars a 4.7.9 para resolver una vulnerabilidad crítica, bloquear localhost y direcciones loopback en la protección SSRF, añadir protección CSRF a los callbacks de OAuth mediante nonces firmados con HMAC, impedir IDOR en endpoints de tRPC y resolver fallos de auditoría de seguridad de fast-xml-parser.

Nuestro objetivo era entregar Cal.diy a la comunidad en un estado sólido desde el punto de vista de la seguridad. Eso significaba tratar el repositorio público como una base de código de producción, no como una ocurrencia tardía, incluso mientras el producto comercial se desarrollaba en el repositorio privado.