Buchungssystem Open Source: was 2026 übrig ist

Die naheliegende Antwort ist seit April keine mehr

Wer in den letzten fünf Jahren ein quelloffenes Terminbuchungssystem gesucht hat, landete bei Cal.com. Selbst hostbar, aktiv entwickelt, als Calendly-Alternative gestartet. Das war die Empfehlung, die man ohne langes Nachdenken geben konnte.

Am 15. April 2026 hat Cal.com angekündigt, auf ein geschlossenes Lizenzmodell umzustellen. Die Begründung des Mitgründers Bailey Pumfleet: KI-gestützte Werkzeuge machen es zu einfach, öffentlichen Code systematisch nach Schwachstellen abzusuchen. Vorausgegangen war ein Fund der Sicherheitsfirma Gecko Security im Januar 2026 — eine Kette aus drei Lücken, über die sich fremde Konten übernehmen ließen.

Der alte Code lebt weiter, als Cal.diy unter MIT-Lizenz. Und hier lohnt es sich, das Kleingedruckte zu lesen, bevor man einen Server bestellt: Das Projekt wird von der Community gepflegt, nicht von Cal.com, und die Dokumentation beschreibt es selbst als "strictly recommended for personal, non-production use". Teams, Organizations, SAML SSO, SCIM, Workflows, Routing Forms und das Insights-Dashboard fehlen. Wer etwas Kommerzielles damit vorhat, wird in der Dokumentation zurück zum bezahlten Cal.com geschickt.

Meine Meinung zur Begründung: Sie überzeugt mich nicht. Geschlossener Code heißt nicht weniger Lücken, sondern weniger Leute, die sie finden — Heartbleed und Log4Shell wurden gefunden, weil jemand hineinsehen konnte. Aber meine Meinung ändert an deiner Lage nichts. Wenn du heute ein quelloffenes Buchungssystem produktiv nehmen willst, ist die bekannteste Option keine mehr.

Open Source und DSGVO sind zwei verschiedene Fragen

Bei fast jeder deutschsprachigen Suche nach „Buchungssystem Open Source" steckt eine zweite, unausgesprochene Frage dahinter: Bleiben die Daten bei uns? Häufig steht ein Datenschutzbeauftragter dahinter, der von einem US-Anbieter abgeraten hat, und Open Source klingt nach der Lösung.

Ist es aber nicht — jedenfalls nicht von allein. Selbsthosten verändert genau zwei Dinge: Du bestimmst den Serverstandort, und du brauchst keinen Auftragsverarbeitungsvertrag mit einem Software-Anbieter, weil es keinen gibt. Alles andere bleibt, wo es war, und einiges kommt dazu.

Der Punkt, den ich in Foren am häufigsten falsch gelesen habe: Auch beim eigenen Server bei einem gemieteten Hoster brauchst du einen AVV nach Art. 28 — mit dem Hoster. Selbsthosten tauscht ein Vertragsproblem gegen ein Betriebsproblem. Ob dieser Tausch gut für dich ist, hängt davon ab, wer bei euch die Backups fährt und die CVE-Meldungen liest. Wenn die Antwort „eigentlich niemand" lautet, ist ein gehosteter Dienst mit einem sauberen AVV datenschutzrechtlich meist die ehrlichere Wahl als ein ungepatchtes PHP auf einem vergessenen VPS.

Easy!Appointments ist das, was für Kundentermine bleibt

Easy!Appointments ist seit rund zehn Jahren unterwegs, hat 4.300 Sterne und 1.600 Forks auf GitHub, steht unter GPL-3.0 und läuft auf Technik, die jeder deutsche Webhoster kann: Apache oder Nginx, PHP 8.2+, MySQL. Installation heißt Ordner hochladen, config-sample.php umbenennen, Setup-Assistent durchklicken. Für die Entwicklung liegt ein Docker-Compose-Setup bei.

Drin ist, was ein Terminkalender braucht: Dienstleistungen, Mitarbeitende mit eigenen Arbeitsplänen, Kundenverwaltung, Buchungsregeln, Google-Kalender-Sync, E-Mail-Benachrichtigungen, eine mehrsprachige Oberfläche und eine REST-API mit OpenAPI-Beschreibung.

Was nicht drin ist, steht nicht in der Feature-Liste, und genau deshalb erwische ich mich dabei, es zweimal zu sagen: Zahlungen. Keine Anzahlung, kein Stripe-Checkout, keine Rechnung. Dazu kommt eine Oberfläche, der man ihr Alter ansieht, und eine Instanz pro Betrieb — mehrere Standorte mit getrennten Kalendern baut man nicht mal eben nach.

Mein Urteil: Für eine Praxis, ein Studio, eine Fahrschule oder eine Beratungsstelle, die Termine vergeben will und dabei kein Geld kassiert, ist Easy!Appointments 2026 die Antwort. Es ist die einzige Option in dieser Kategorie, die alt genug ist, um bewiesen zu haben, dass sie nicht nächstes Jahr die Lizenz wechselt.

Was mich umstimmen würde: sobald am Buchungspunkt Geld fließen soll, oder sobald es mehr als einen Standort gibt. Dann arbeitest du gegen das Programm statt mit ihm.

Räume, Arbeitsplätze und Geräte: derselbe Suchbegriff, ein anderes Programm

Ein Teil der Leute, die nach „Buchungssystem Open Source" suchen, will gar keine Kundentermine. Sie wollen Besprechungsräume, Arbeitsplätze im Großraumbüro, das Vereinsheim oder die geteilte Kamera reservieren. Das ist eine andere Softwarekategorie mit anderen Projekten — MRBS und LibreBooking für Räume, Seatsurfing für Arbeitsplätze, Snipe-IT und GLPI im Umfeld von Geräten.

Ich habe jede dieser Kategorien einzeln durchgearbeitet, allerdings auf Englisch:

Kurzfassung für Eilige: MRBS, wenn es wirklich nur Besprechungsräume sind. LibreBooking, wenn Räume nur eine von mehreren Ressourcenarten sind. Seatsurfing, wenn Arbeitsplätze im Spiel sind. Für Geräte reicht kein Inventarsystem — Snipe-IT kann bis heute keinen Termin in der Zukunft blocken.

Rechnung, SEPA und Anzahlung — hier hört die Liste auf

An dieser Stelle brechen deutsche Projekte reihenweise ab, und es liegt nicht an der Terminlogik.

Ein Friseursalon, der eine Anzahlung für die Balayage nehmen will. Eine Physiotherapiepraxis, die Selbstzahlerleistungen sofort abrechnet. Ein Tonstudio, das die Stunde im Voraus kassiert. Alle drei brauchen dasselbe: eine Zahlung am Buchungspunkt und eine Rechnung mit ausgewiesener Umsatzsteuer nach § 14 UStG. Keines der hier genannten Projekte bringt das mit. Bei Easy!Appointments ist Zahlung kein Feature, bei MRBS und LibreBooking war es nie vorgesehen, und Cal.diy ist ausdrücklich nicht für den kommerziellen Einsatz gedacht.

Was in der Praxis daraus wird, sieht man in den Foren: Vorkasse per Überweisung mit Verwendungszweck, danach ein Abgleich in der Buchhaltung von Hand. Oder ein zweites Werkzeug für die Zahlung, das nichts vom Kalender weiß, mit allen Abstimmungsfehlern, die das mit sich bringt. SEPA-Lastschrift mit Mandat fällt ohnehin aus — dafür gibt es in keinem dieser Projekte auch nur einen Ansatz.

Wenn Geld also zum Termin gehört, ist die Frage nicht mehr „welches Open-Source-Projekt", sondern „wie viel Eigenbau bin ich bereit zu bezahlen". Das ist eine legitime Antwort. Sie ist nur teurer, als sie am ersten Tag aussieht.

Wo Opencals steht, und wo nicht

Damit hier nichts durcheinandergerät: Opencals ist kein Open-Source-Projekt. Es ist eine gehostete Plattform. Quelloffen sind die Next.js-Buchungsseiten-Vorlagen unter MIT-Lizenz und das Storefront-SDK — den Kalender, die Verfügbarkeitsberechnung und die Zahlungsabwicklung betreiben wir.

Wenn dein Grund für die Suche „ich will keine monatliche Grundgebühr" war und nicht „der Code muss bei mir liegen", dann ist das eine faire Alternative: Abrechnung pro abgeschlossenem Termin, 0,99 $, in ruhigen Monaten entsprechend wenig. Die Buchungsoberfläche gibt es auf Deutsch, wie in 16 weiteren Sprachen. Und die Zahlung samt Anzahlung ist der Teil, der eingebaut ist, statt zu fehlen.

Wenn dein Grund dagegen Datenhoheit war, dann sind wir nicht die Antwort auf diese Frage, und ich werde in einem Blogartikel keine pauschale Zusage zu Serverstandort und AVV machen, die dein Datenschutzbeauftragter am Ende anders bewertet. Frag uns direkt danach, bevor du dich entscheidest — nicht danach.

Für Entwicklerinnen und Agenturen, die genau hier landen, liegen die offenen Teile auf /open-source und die API auf /developers.

Was ich dir nicht sagen kann

Drei Dinge, bei denen ich raten würde, wenn ich so täte, als wüsste ich es.

Ob Cal.diy in einem Jahr noch gepflegt wird. Ein Community-Fork ohne Rückhalt des ursprünglichen Teams kann laufen oder einschlafen; die ersten Monate sagen darüber wenig.

Ob Easy!Appointments den gleichen Weg geht. Das Projekt hat inzwischen ein kostenpflichtiges Premium-Angebot. Das ist erst mal eine gute Nachricht — jemand verdient daran und kann es weiterpflegen. Es ist auch genau der Punkt, an dem Lizenzmodelle anfangen, sich zu bewegen.

Und: Ich habe keines dieser Projekte selbst in einem deutschen Produktivbetrieb laufen sehen. Was ich über sie weiß, stammt aus dem Code, der Dokumentation und den Issue-Trackern. Wer dir ohne diesen Vorbehalt Erfahrungsberichte verkauft, hat sie meistens auch nicht.

Wenn ich für dich entscheiden müsste: Termine ohne Geld — Easy!Appointments installieren und den Nachmittag einplanen. Termine mit Geld — die Open-Source-Liste aufgeben und stattdessen entscheiden, wem du die Zahlungsabwicklung anvertraust.