4future Kommunikation und Veranstalltungen
Ein Gespräch ist keine Veranstaltung

Wer eine digitale Arbeitsumgebung aufbaut, landet früher oder später bei einer scheinbar einfachen Frage: Welche Videokonferenzlösung verwenden wir?

Microsoft Teams? Zoom? Webex? Jitsi? Nextcloud Talk? BigBlueButton?

Wir haben festgestellt, dass schon die Frage falsch gestellt ist.

Denn wir brauchen nicht einfach „Videokonferenzen“. Wir haben unterschiedliche Formen digitaler Kommunikation – und diese stellen sehr unterschiedliche Anforderungen an die Technik.

Deshalb setzen wir bei 4future nicht auf ein einziges Werkzeug, das irgendwie alles können soll. Wir verwenden unterschiedliche Open-Source-Technologien für unterschiedliche Aufgaben – integrieren sie für unsere Benutzer aber zu einer gemeinsamen Plattform.

Ein Gespräch ist keine Veranstaltung

Die wichtigste Unterscheidung ist für uns jene zwischen laufender Kommunikation und einer Veranstaltung.

Wenn zwei Menschen miteinander chatten und irgendwann einer schreibt „Reden wir kurz?“, soll daraus mit möglichst wenig Aufwand ein Audio- oder Videogespräch werden. Das Gespräch entsteht aus der Kommunikation heraus.

Bei einer Veranstaltung ist das anders.

Ein 4future Event (z.B. Clubabend) hat einen Beginn, ein Thema, Gastgeber und Teilnehmer. Bei einem Vortrag gibt es Vortragende und Publikum. Ein Workshop benötigt vielleicht Arbeitsgruppen. Bei einem Seminar oder Workshop kommen Präsentationen, Whiteboard, Umfragen und Aufzeichnungen dazu.

Technisch handelt es sich in allen Fällen um Menschen, die über das Internet miteinander sprechen und einander sehen.

Organisatorisch sind es vollkommen unterschiedliche Dinge.

Diese Unterscheidung bestimmt unsere Architektur.

4future Kommunikation: Matrix und Element
für die tägliche Kommunikation (4future Chat)

Für unsere laufende Kommunikation verwenden wir Matrix mit Element als Client.

Matrix ist ein offenes Kommunikationsprotokoll. Unsere Matrix-Infrastruktur betreiben wir selbst. Element bietet darauf eine moderne Umgebung für persönliche Nachrichten, Gruppen- und Projekträume sowie Audio- und Videokommunikation.

Der entscheidende Punkt ist dabei nicht die Videokonferenzfunktion alleine. Ein Gespräch hat einen Kontext.

Ein Team diskutiert bereits seit Tagen in einem Raum. Zwei Personen schreiben miteinander. In einem Projektkanal taucht eine Frage auf, die sich schriftlich nur mühsam klären lässt.

Dann wird aus dem Chat unmittelbar ein Gespräch.

Genau dafür ist Matrix/Element bei uns gedacht.

Wir sind gerade dabei sogenannte Bridges (Brücken) zu den gängigsten Messenger Plattformen einzurichten. WhatsApp und Signal laufen bereits, an Telegram wird gerade gearbeitet. Damit kann man einen Messenger verwenden um über unterschiedlichste Plattformen erreichbar zu sein.

4future Chat ist unsere Plattform für Kommunikation.

Warum wir Nextcloud Talk nicht verwenden

Nextcloud ist ebenfalls ein wichtiger Bestandteil unserer Infrastruktur. Wir verwenden es für Dateien, Sharing und gemeinsames Arbeiten an Dokumenten.

Nextcloud bietet mit Talk auch eine eigene Kommunikations- und Videokonferenzlösung an. Es ist eine proprietäre Lösung innerhalb von Nextcloud – die nur mit anderen Usern auf Nextcloud kommunizieren kann.

Wir haben uns bewusst dagegen entschieden, damit eine zweite Kommunikationswelt aufzubauen.

Denn dann stellt sich plötzlich die Frage: Schreibe ich einer Kollegin in Element oder in Nextcloud? Wo finde ich die Unterhaltung von gestern? Wo starte ich einen spontanen Anruf?

Mehr Funktionen bedeuten nicht automatisch ein besseres System.

Deshalb ist die Aufgabenteilung bei uns klar:

Kommunikation findet in Matrix/Element statt.

Dateien und dateibasierte Zusammenarbeit an Inhalten finden in 4future Drive (Nextcloud) und 4future Docs (OnlyOffice) statt.

Und warum nicht Jitsi?

Natürlich haben wir uns auch Jitsi Meet angesehen.

Jitsi ist Open Source, kann selbst betrieben werden und eignet sich gut für klassische Videokonferenzen. Ein Link genügt und Teilnehmer können direkt über den Browser miteinander sprechen.

Bei unserer Architektur ergaben sich allerdings zwei Fragen.

Erstens überschneidet sich der Anwendungsfall stark mit dem, was wir ohnehin mit Matrix und Element abdecken.

Jitsi löst primär das Problem: Wir wollen jetzt eine Videokonferenz durchführen.

Matrix/Element löst für uns das umfassendere Problem: Wir wollen miteinander kommunizieren – und manchmal wird aus dieser Kommunikation ein Audio- oder Videogespräch.

Ein zusätzliches Jitsi hätte damit einen weiteren Kommunikationskanal geschaffen, ohne für uns einen zusätzlichen Nutzen zu bringen. Zweitens wird Jitsi technisch deutlich komplexer, sobald man eine größere Installation nicht einfach auf einem einzelnen Server betreiben möchte.

Ein produktiver Jitsi-Dienst besteht aus mehreren Komponenten. Sobald mehrere Videobridges, Skalierung, Hochverfügbarkeit und eine saubere Verteilung über mehrere Systeme ins Spiel kommen, wird aus dem zunächst sehr einfach wirkenden Jitsi-Server eine durchaus anspruchsvolle verteilte Architektur.

Das ist lösbar. Aber Infrastrukturkomplexität muss einen Nutzen haben.

Für einen Anwendungsfall, den Matrix/Element bei uns ohnehin abdeckt, wollten wir keine zweite komplexe Echtzeit-Kommunikationsplattform betreiben. Daher haben wir uns gegen Jitsi entschieden.

4future Veranstaltungen: BigBlueButton für Veranstaltungen (4future Chat)

Bei Veranstaltungen sieht die Sache anders aus.

Dafür verwenden wir BigBlueButton.

BigBlueButton ist ebenfalls Open Source und kann vollständig auf eigener Infrastruktur betrieben werden. Es wurde allerdings nicht primär als allgemeines Videokonferenzsystem entwickelt, sondern für virtuelle Klassenzimmer und strukturierte Online-Veranstaltungen.

Und genau das merkt man am Funktionsumfang.

Präsentationen, Moderationsrollen, Wortmeldungen, Umfragen, gemeinsames Whiteboard, öffentliche und private Chats, Shared Notes, Breakout-Räume und Aufzeichnungen gehören zum Konzept der Plattform.

Für uns bedeutet das:

BigBlueButton ist unsere Plattform für Veranstaltungen.

Das können Seminare und Workshops sein. Aber genauso Vorträge, Diskussionsveranstaltungen oder unsere Clubabende.

Nicht jede Veranstaltung benötigt alle Funktionen. Bei einem Clubabend brauchen wir vielleicht keine Breakout-Räume und kein Whiteboard.

Aber das zugrunde liegende Modell passt: Es gibt eine Veranstaltung, Gastgeber beziehungsweise Moderatoren und einen definierten Teilnehmerkreis.

Damit unterscheidet sich der Anwendungsfall grundsätzlich von einem spontanen Gespräch in Element.

Greenlight ist nicht das Ende der Integration

Als Verwaltungsoberfläche für BigBlueButton verwenden wir derzeit Greenlight. BigBlueButton kommt nämlich ohne Verwaltungsoberfläche.

Greenlight ermöglicht unter anderem das Anlegen von Räumen und die Verwaltung von Aufzeichnungen. Für uns ist es allerdings nicht das Ziel, Greenlight dauerhaft als vollständig getrennte Welt neben den anderen 4future-Diensten stehen zu lassen. Greenlight unterstützt beispielsweise auch nicht mehrere Mandanten (also verschiedene Unternehmen, Organisationen oder Vereine die gleichzeitig die Plattform verwenden und verwalten)

Teile dieser Funktionalität wollen wir direkt in unser Portal my.4future.id integrieren.

Damit folgt BigBlueButton derselben Entwicklung, die wir bei anderen Diensten bereits umgesetzt haben: Die zugrunde liegende Open-Source-Software soll für den Benutzer zunehmend in den Hintergrund treten.

Ein Benutzer soll nicht darüber nachdenken müssen, ob er gerade einen Matrix-, Nextcloud- oder BigBlueButton-Account benötigt.

Er besitzt eine 4future ID.

4future ID verbindet die Dienste

Das ist ein wesentlicher Bestandteil unserer Architektur.

Mail, Nextcloud sowie Matrix/Element sind bei uns bereits in die 4future ID integriert. Die Identität des Benutzers liegt damit nicht in jeder Anwendung getrennt.

Unser Ziel ist, auch die Veranstaltungsplattform zunehmend in diese gemeinsame Umgebung einzubinden.

my.4future.id wird dabei zum Portal, über das Benutzer ihre Dienste erreichen und verwalten können.

Das verändert auch die Perspektive auf unsere Open-Source-Strategie.

Wir bauen nicht einfach eine Sammlung von Open-Source-Anwendungen auf.

Wir bauen eine Plattform aus offenen Komponenten.

Für den Benutzer soll daraus eine zusammenhängende Umgebung entstehen. Unterhalb dieser Ebene bleiben die einzelnen Komponenten jedoch möglichst unabhängig.

Integration ohne Monolithen

Das klingt zunächst nach einem Widerspruch.

Auf der einen Seite wollen wir unterschiedliche spezialisierte Systeme einsetzen. Auf der anderen Seite sollen Benutzer möglichst wenig von deren technischen Grenzen bemerken.

Genau darin sehen wir aber einen wichtigen Architekturunterschied zu einer monolithischen Suite.

Wir integrieren die Systeme über Identität, Portal und definierte Schnittstellen, ohne sie technisch untrennbar miteinander zu verschmelzen.

Heute verwenden wir Matrix für Kommunikation, Nextcloud für Dateien und BigBlueButton für Veranstaltungen.

Sollte irgendwann eine dieser Komponenten unsere Anforderungen nicht mehr erfüllen, wollen wir sie ersetzen können, ohne deshalb Identität, E-Mail, Dateien und alle anderen Dienste ebenfalls migrieren zu müssen.

Die stabile Ebene ist nicht das einzelne Produkt.

Die stabile Ebene ist die 4future ID und die Beziehung zu unseren Benutzern.

Warum wir nicht einfach ein Produkt für alles verwenden

Natürlich könnte man versuchen, möglichst viele Anforderungen mit einer einzigen großen Plattform abzudecken.

Das erscheint zunächst komfortabel. Identität, Chat, Meetings, Dateien, Kalender und weitere Dienste kommen aus einer Hand.

Damit entsteht allerdings auch eine enorme Abhängigkeit von genau dieser Hand.

Unser Ansatz ist deshalb ein anderer.

Wir verwenden spezialisierte offene Komponenten:

Matrix/Element für Kommunikation.

Nextcloud für Dateien und Zusammenarbeit an Inhalten.

BigBlueButton für Veranstaltungen.

4future ID verbindet diese Komponenten zu einer gemeinsamen Plattform.

Für Benutzer soll die technische Trennung zunehmend irrelevant werden.

Für uns als Betreiber bleibt sie dagegen wichtig.

Open Source ist notwendig – aber nicht ausreichend

Dass eine Software Open Source ist, bedeutet noch nicht automatisch, dass sie für unsere Architektur geeignet ist.

Wir betrachten auch ihre Betriebsarchitektur.

Wie lässt sich ein Dienst redundant betreiben? Wie lässt er sich skalieren? Welche zusätzlichen Komponenten benötigt er? Wie funktioniert Authentifizierung? Wo liegen die Daten? Wie funktionieren Backup und Monitoring? Wie aufwendig sind Updates?

Und schließlich die vielleicht wichtigste Frage:

Welches zusätzliche Problem löst diese Software für unsere Benutzer?

Wenn die Antwort darauf nicht überzeugend ist, brauchen wir keinen weiteren Dienst.

Digitale Souveränität bedeutet nicht, alles selbst zu entwickeln

Wir entwickeln Matrix, Element, Nextcloud oder BigBlueButton nicht selbst.

Das müssen wir auch nicht.

Digitale Souveränität bedeutet für uns nicht, jedes Stück Software selbst zu schreiben.

Sie bedeutet, Kontrolle über die wesentlichen Entscheidungen zu behalten.

Wir können entscheiden, wo unsere Daten gespeichert werden. Wir können unsere Identitäten selbst verwalten. Wir können Systeme miteinander verbinden. Wir können unsere Infrastruktur selbst betreiben.

Und wir können eine Komponente ersetzen, wenn sie unsere Anforderungen irgendwann nicht mehr erfüllt.

Dabei ist ein Detail entscheidend:

Unsere Benutzer gehören nicht einer Software.

Eine 4future ID ist kein Nextcloud-Konto, kein Matrix-Konto und kein BigBlueButton-Konto. Sie ist die Identität des Menschen innerhalb unserer Plattform.

Die Anwendungen sind Dienste, die diese Identität verwenden.

Das heißt ein Nutzer meldet sich mit den gleichen Daten an die Plattform an. Alle Komponenten kennen ihn.

Die Architektur folgt dem Menschen

Am Ende lässt sich unsere Entscheidung deshalb erstaunlich einfach zusammenfassen.

Wenn Menschen miteinander kommunizieren, verwenden wir 4future Chat (Matrix und Element basierend).

Wenn Menschen gemeinsam mit Dateien und Inhalten arbeiten, verwenden wir 4future Drive (Nextcloud basierend) und Die Dokumenten Editoren von 4future Docs (OnlyOffice basierend).

Wenn Menschen an einer Veranstaltung teilnehmen, verwenden wir 4future Live (BigBlueButton basierend). Die Integration davon ist aktuell noch in Arbeit.

Und für all diese Dinge verwenden sie dieselbe 4future ID.

Die Technik folgt damit nicht der Frage, welches Produkt möglichst viele Features auf einer Vergleichsliste abhaken kann.

Sie folgt der Frage:

Was wollen die Menschen gerade miteinander tun?

Die einzelnen Open-Source-Produkte sind Werkzeuge.

Die Plattform, die daraus entsteht, ist 4future One für Unternehmen und 4future Me für private Einzelpersonen und Familien.

Unsere 4future Community Vollmitglieder (um € 10,–/ Monat) haben ein 4future Me als ihr persönliches digitales Zuhause im Mitgliedsbeitrag enthalten. An der Familienvariante arbeiten wir gerade. Wer upgraden möchte, bitte um kurze E-Mail.

4future One (Email/Kalender/Kontakte/Aufgabe/Dokumente/Office/Chat) ist mittlerweile auf der Website bestellbar.

4future.digital – backbone of your digital future.

Wir beschäftigen uns seit 1986 mit der Frage, wie Technologie Menschen unterstützen kann. Heute bauen und betreiben wir mit 4future.digital eine offene, souveräne digitale Infrastruktur in Österreich – von E-Mail und Cloud über Kommunikation bis zu gemeinsamen Arbeits- und Veranstaltungsplattformen.

Dabei geht es uns nicht darum, die nächste große Plattform zu bauen oder Menschen möglichst eng an einen Anbieter zu binden. Im Gegenteil: Wir setzen auf Open Source, offene Standards, eigene Infrastruktur und die Freiheit, Technologien auch wieder austauschen zu können.

Denn digitale Souveränität bedeutet für uns vor allem eines: Menschen und Organisationen sollen die Kontrolle über ihre digitale Zukunft behalten.

Daran arbeiten wir nicht erst seit gestern.

Since 1986.