The Calendar Problem Nobody Has Solved for Communities
How we're building a resource reservation system that actually understands how communities work — on Drupal, with open source, for the long haul.
Every community organization has the same problem.
They need to book a room. They need to track who reserved it, for what, and whether it conflicts with anything else on the calendar. They need to send a confirmation, handle a cancellation, and make sure the Tuesday morning yoga class doesn't collide with the town selectboard meeting that just got added.
This sounds simple. It isn't.
Outlook and Google Calendar solve this problem for enterprises and individuals. What they don't solve is the community version of the problem — where the room belongs to one group, the event is organized by another, and the audience is a third. Where a library branch, a residential hall, and a municipal department all need the same underlying system but with completely different workflows, branding, and access rules. Where a weekly recurring meeting series needs a confirmed room booking for every single occurrence, and someone needs to know what happens when the 14th instance gets a different speaker and a bigger room.
That gap is what we're building toward with RSVP-System.
Why We're Building This on Drupal
Drupal is the right foundation for this problem for a specific reason: it's one of the few platforms where you can build a genuinely complex content and workflow system without writing a lot of custom code — if you know what you're doing.
Two recent additions to Drupal's ecosystem made this the right time to build:
Drupal Recipes — a new mechanism for packaging and distributing site configuration as composable, reusable units. Instead of building a monolithic platform, we build a library of recipes. rsvp_calendar, rsvp_recurring_events, rsvp_reservation_workflow — each one is independent, installable via Composer, and opinionated about one thing. A municipal site installs different recipes than a university housing system. Same engine, different configuration.
ECA (Event-Condition-Action) — a BPMN-based workflow engine for Drupal that lets you build complex business logic through configuration rather than PHP. Conflict detection, reservation approval workflows, cancellation side effects — all of it lives in ECA models that a site builder can read and modify without touching code.
The combination of Recipes and ECA means we can build something sophisticated, keep it maintainable, and distribute it to other organizations without handing them a black box.
The Community Taxonomy — Everything's Spine
The architectural insight that makes RSVP-System work is treating the Community as a first-class data concept.
Every piece of content on the platform — events, reservations, announcements, resources, calendar months — carries two community fields: an owner (which community is accountable for this content) and an audience (which communities it should surface in). Every URL follows the same pattern: /{community-type}/{community}/{content-type}/{title}.
This means a library branch, a residence hall, and a town selectboard are all communities. They share the same platform infrastructure. They see only their own content by default. An event organized by the Town Office can appear on the Library's calendar too — because it's in the Library's audience field, not because someone built a special integration.
This is the kind of thing that sounds obvious in retrospect and takes years of Drupal work to get right.
The Hard Part: Recurring Events Meet Resource Reservations
Here's where it gets genuinely interesting.
Most booking systems handle reservations as a property of an event. You create an event, you attach a room. Simple. But what happens when the event is part of a recurring series? What happens when 26 instances of a weekly meeting each need their own confirmed room booking, and some of those instances have different speakers, different rooms, or conflict with something else on the calendar?
We're building RSVP-System around the principle that a Resource Reservation is its own first-class entity — independent of the event that requested it. An event references a reservation. The reservation has its own lifecycle: Tentative, Confirmed, Cancelled. ECA drives the transitions between states and handles the side effects.
For recurring series, we use a two-level model: the series carries a preferred resource as a soft suggestion, and each individual occurrence holds its own confirmed reservation. This means a series of 26 Tuesday meetings can have 26 independent room bookings — some confirmed, some still tentative, one that got bumped to a different room because of a conflict.
Conflict detection is where custom code is genuinely justified: a small ECA condition plugin that runs a date-overlap query against existing reservations before any booking is confirmed. Everything else — the approval workflow, the notifications, the cancellation cascade — lives in ECA configuration.
Who This Is For
We're building for three deployment contexts: community organizations and nonprofits, university and residential life programs, and municipal governments. Each gets a sector-specific theme and recipe set. The underlying platform is identical.
The code is open source, hosted on GitLab and distributed via Packagist. The recipes are composable — install what you need, leave the rest.
Where We Are
RSVP-System has reached MVP. The calendar, event, and recurring event systems are running on live sites. The resource reservation workflow is in active architectural development.
If you're building something similar — or if you manage a Drupal site for a community organization and this sounds familiar — follow the project on GitLab or reach out at gluebox.com. We're building in the open and always interested in real-world requirements.
The pie is big enough for all of us. We just need enough crumbs.
Stephen runs Gluebox.com, building calendar reservation and event systems on open source. He maintains RSVP-System.org.