Wenn Erfolg selbst zum Problem wird – HAWKI-Zweiteiler, Teil 2

Wenn Erfolg selbst zum Problem wird – HAWKI-Zweiteiler, Teil 2

27.10.26

Illustration einer Person beim Stapeln wachsender Säulen; Titelgrafik zum HAWKI-Zweiteiler Teil 2 „Wenn Erfolg selbst zum Problem wird“.

Vincent Timm fragt, was geschieht, wenn aus einem Feierabendprojekt ein Open-Source-Angebot wird, das an zahlreichen Hochschulen genutzt wird. Am Beispiel von HAWKI zeigt er, warum mit wachsendem Erfolg auch Erwartungen, Verantwortung und Aufwand wachsen – und was Hochschulen brauchen, um daraus dauerhaft verlässliche Infrastruktur zu machen.

Im ersten Teil dieser Geschichte habe ich erzählt, wie aus ein paar Feierabenden in unserem Interaction Design Lab HAWKI entstand: zunächst als einfacher Zugang zu generativer KI an unserer Hochschule, später als Open-Source-Projekt, das von immer mehr Hochschulen aufgegriffen wurde. Aus einer kleinen Idee entwickelten sich Kooperationen, eine wachsende Community und schließlich Förderprojekte, mit denen wir HAWKI weiterentwickeln konnten.

Man könnte darin eine ziemlich gelungene Geschichte von Bottom-up-Innovation sehen. Für mich zeigt sie aber auch, was im Hochschulsystem strukturell fehlt: verlässliche Übergänge, wenn aus einem Experiment ein dauerhaft genutzter Dienst wird. Denn umso erfolgreicher HAWKI wurde, desto deutlicher merkten wir, dass die Strukturen, die diesen Erfolg langfristig tragen sollten, nicht im gleichen Tempo mitwuchsen.

Eine der merkwürdigsten Erfahrungen der vergangenen Jahre war, dass jeder Erfolg zunächst einmal neue Arbeit bedeutete. Eine weitere Hochschule, die HAWKI einsetzen wollte, war natürlich eine Bestätigung unserer Idee. Gleichzeitig bedeutete sie häufig einen weiteren Videocall, die Klärung von Datenschutz- und Konfigurationsfragen oder den Kontakt zu einem Präsidium, das verstehen wollte, welches Risiko es mit einer solchen Infrastruktur eingeht.

„Der Erfolg erzeugte einen Ressourcenbedarf, den wir erst durch den Nachweis eben dieses Erfolgs decken konnten.“

Mit zunehmender Sichtbarkeit wuchs die Zahl der Hochschulen, die HAWKI einsetzten, und mit ihr die Erwartungen an die Software. Mehr Nutzende bedeuteten mehr Featurewünsche, mehr Support und einen steigenden Anspruch an eine professionelle Weiterentwicklung. Um dem gerecht zu werden, brauchten wir zusätzliche Ressourcen. Doch um die zu bekommen, mussten wir zunächst zeigen, dass HAWKI erfolgreich war, dass es genutzt wurde und dass sich weitere Investitionen lohnten. Wir steckten in einer Zwickmühle: Der Erfolg erzeugte einen Ressourcenbedarf, den wir erst durch den Nachweis eben dieses Erfolgs decken konnten.

Unsere Antwort darauf waren Förderanträge, Konferenzauftritte, Gespräche mit möglichen Partnern und der kontinuierliche Aufbau unseres Teams. Inzwischen arbeiten vier Entwickler und zwei Designer an HAWKI. Doch all diese Schritte kosteten selbst Zeit und Energie, die an anderer Stelle fehlten. Während wir versuchten, die Voraussetzungen für eine professionelle Weiterentwicklung zu schaffen, mussten wir gleichzeitig den wachsenden Anforderungen an die bestehende Software gerecht werden. Es entstand eine seltsame Schleife: Jeder Schritt, der uns langfristig entlasten sollte, bedeutete zunächst zusätzliche Arbeit. Vielleicht könnte man von einer Erfolgssteuer sprechen.

Kommerzielle Erwartungseffekte

Hochschulische Open-Source-Projekte konkurrieren nicht nur funktional mit milliardenschweren Unternehmen. Sie konkurrieren auch mit den Erwartungen, die diese Unternehmen erzeugen. Ein neuer Dateiupload, eine Bildfunktion oder ein anderes Feature bei einem kommerziellen Anbieter wird innerhalb kürzester Zeit zur scheinbar selbstverständlichen Anforderung an ein öffentlich finanziertes Projekt, das nebenbei noch Datenschutz, Barrierefreiheit, Hochschul-IT, unterschiedliche Authentifizierungssysteme, Mitbestimmung und langfristige Wartbarkeit berücksichtigen muss.

„Ein Prototyp lässt sich aus Begeisterung bauen. Ein dauerhaft verlässlicher Dienst nicht.“

Das Problem daran ist nicht, dass Nutzende Erwartungen haben. Das ist wichtig und bringt das Projekt nach vorne. Die interessante Frage ist, welche Strukturen wir Projekten zur Verfügung stellen, von denen wir dieselbe Zuverlässigkeit erwarten wie von einem Produkt, ohne sie wie eine Infrastruktur zu behandeln. Ein Prototyp lässt sich aus Begeisterung bauen. Ein dauerhaft verlässlicher Dienst nicht. Letzterer erfordert unspektakuläre Aufgaben: Fehler beheben, Abhängigkeiten aktualisieren, Sicherheitslücken schließen, Dokumentationen schreiben, Support leisten, Barrierefreiheit verbessern, Releases testen, Community-Beiträge prüfen, Datenschutzfragen beantworten und Entscheidungen darüber treffen, welche Funktion gerade (nicht) gebaut wird.

Förderprogramme hingegen interessieren sich verständlicherweise für das Neue: neue Forschungsfragen, neue Anwendungen, neue Modelle, neue Konzepte. Digitale Infrastruktur benötigt irgendwann jedoch das Gegenteil. Sie benötigt Kontinuität, Wartung, und Verlässlichkeit. Menschen, die gerade dann Leistung erzielen, wenn an einem Dienstagmorgen nichts Besonderes passiert und sie sicherstellen können, dass das System einfach funktioniert.

Falsche Schlussfolgerungen

An dieser Stelle wird die Geschichte für mich persönlich ambivalent. Denn natürlich bin ich stolz darauf, was aus diesen ersten Abenden entstanden ist. Gleichzeitig möchte ich nicht, dass aus dieser Geschichte die Botschaft abgeleitet wird: Seht her, man muss engagierten Menschen nur genügend Freiraum geben, dann regelt sich der Rest schon. Freiraum ist eine Voraussetzung für Innovation. Selbstausbeutung sollte keine sein. Ein System, das darauf angewiesen ist, dass Einzelne strukturelle Lücken aus Begeisterung, Verantwortungsgefühl oder persönlicher Identifikation mit einem Projekt schließen, kann erstaunliche Ergebnisse produzieren. Aber diese Ergebnisse dürfen nicht mit struktureller Funktionsfähigkeit verwechselt werden. Vielleicht ist das sogar eine Gefahr von Erfolgsgeschichten. Sie machen sichtbar, was entstanden ist, und unsichtbar, was dafür kompensiert werden musste.

Innovation ist nicht das Problem

Deshalb beschäftigt mich inzwischen weniger die Frage, wie Hochschulen mehr Innovation hervorbringen können. Ich weiß, davon gibt es erstaunlich viel. Das Problem beginnt häufig einen Schritt später. Was passiert, wenn etwas funktioniert? Wer erkennt den Moment, in dem aus einem Experiment eine dauerhaft genutzte Infrastruktur wird, und wer schafft die Strukturen, um diesen Übergang zu ermöglichen? Bei HAWKI wurde diese Frage mit jeder weiteren Hochschule drängender. Was als Prototyp begann, um Zugang zu generativer KI und eine Auseinandersetzung mit ihr zu ermöglichen, brachte zunehmend technische, rechtliche und organisatorische Verantwortung mit sich.

„Software lässt sich leichter verteilen als Verantwortung.“

Unser Open-Source-Ansatz ermöglichte es Hochschulen, unabhängig voneinander eigene Instanzen zu betreiben. Genau das war gewollt. Aber Software lässt sich leichter verteilen als Verantwortung. Wer kümmert sich langfristig um den gemeinsamen Kern, wer finanziert die Weiterentwicklung und wie organisieren wir Mitbestimmung, ohne dass am Ende diejenigen mit den größten Budgets die Richtung vorgeben? Wir diskutierten Umlageverfahren, Vereine, Genossenschaften und andere Organisationsformen. Doch hinter diesen Überlegungen stand zunehmend eine grundsätzlichere Frage: Wie organisieren Hochschulen gemeinsames digitales Eigentum?

Wenn wir digitale Souveränität ernst meinen, kann sie nicht nur bedeuten, dass irgendwo Quellcode auf GitHub liegt. Souveränität bedeutet auch, dauerhaft handlungsfähig zu sein: entscheiden zu können, was weiterentwickelt wird, Expertise zu erhalten, Betrieb sicherzustellen und nicht bei jeder technologischen Veränderung wieder bei null anzufangen. Dafür braucht es ökonomische Modelle. Denn auch offene Infrastruktur hat Kosten. Wenn diese Kosten nicht ausdrücklich organisiert werden, verschwinden sie nicht. Sie tauchen an anderer Stelle wieder auf: als Mehrarbeit, als Projektverlängerung, als unbezahlter Support, als Abhängigkeit von Einzelpersonen oder als technische Schuld.

Übergänge besser organisieren

Hier sehe ich nochmal eine interessante Rolle von Organisationen wie dem Hochschulforum Digitalisierung. Vielleicht besteht ihre Wirkung nicht nur darin, einzelne Projekte sichtbar zu machen. Vielleicht können solche intermediären Strukturen dabei helfen, den Übergang zwischen Idee und Institution zu organisieren, in einem Hochschulsystem, das stark segmentiert ist: Eine gute Lösung kann an einer Hochschule entstehen, während hundert Kilometer weiter dieselbe Frage noch einmal von vorne bearbeitet wird. Eine Hochschule verfügt über Entwicklungsressourcen, eine andere über juristische Expertise, eine dritte über Erfahrungen im Betrieb.

Dazwischen braucht es Strukturen, die diese Erfahrungen zirkulieren lassen. Für uns waren Veranstaltungen, Beiträge und Netzwerke des HFD Teil einer solchen Struktur. Sie haben HAWKI nicht entwickelt, aber sie haben dazu beigetragen, dass Menschen davon erfahren haben, dass Kontakte entstanden und dass aus einer lokalen Entwicklung eine gemeinsame Diskussion werden konnte.

Vielleicht sollten wir deshalb weniger danach fragen, welcher einzelne Akteur welchen konkreten Output erzeugt hat. Interessanter wäre die Frage, ob das Hochschulsystem in der Lage ist, gute Ideen zu erkennen, sie miteinander zu verbinden und ihnen einen Weg aus dem Experiment in eine tragfähige Struktur zu eröffnen. HAWKI hat nach Feierabend angefangen. Dass ich heute darüber scherzen kann, seitdem keinen Feierabend mehr zu haben, funktioniert als Pointe. Als Organisationsmodell für digitale Hochschulinfrastruktur funktioniert es nicht.

Wie HAWKI seinen Anfang nahm und warum das Projekt so schnell wuchs, beschreibt der erste Teil dieser Reihe.

Blog
Illustration einer Person mit Fernglas; Titelgrafik zum HAWKI-Zweiteiler Teil 1 „Vom Feierabendprojekt zum Projekt ohne Feierabend“.

Vom Feierabendprojekt zum Projekt ohne Feierabend – HAWKI-Zweiteiler, Teil 1

Portrait von Vincent Timm
Vincent Timm
27.10.2026

Autor

Vincent Timm ist wissenschaftlicher Mitarbeiter und Interaction Designer an der HAWK Hochschule für angewandte Wissenschaft und Kunst, wo er das Interaction Design Lab leitet. Seine Arbeit beschäftigt sich mit menschenzentrierter KI, Digitaler Souveränität und offenen Infrastrukturen für Hochschulen. Er ist Teil des Teams hinter HAWKI, einer Open-Source-Plattform für generative KI. Im Mittelpunkt seiner Arbeit steht die Frage, wie Hochschulen KI so gestalten können, dass sie nutzbar, transparent, interoperabel und institutionell nachhaltig bleibt.

Zur Entstehung dieses Beitrags

Dieser Text ist im Rahmen eines Experiments mit generativer KI entstanden. Anstatt direkt einen Artikel zu schreiben, habe ich mich von einem KI-System zu den vergangenen Jahren mit HAWKI interviewen lassen. Die Fragen und Rückfragen halfen mir dabei, Erinnerungen zu sortieren, Zusammenhänge sichtbar zu machen und meine eigenen Gedanken zu schärfen. Aus diesem Gespräch ist in mehreren Überarbeitungsrunden der vorliegende Beitrag entstanden. Die darin enthaltenen Erfahrungen, Einschätzungen und Schlussfolgerungen stammen von mir. Das KI-System war dabei ein Gegenüber im Reflexions- und Schreibprozess.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert