Wir haben etwas mit Millionenwert als Open Source veröffentlicht. Absichtlich.

Seien wir ehrlich: Die meiste Software, mit der moderne Teams arbeiten – dein CMS, deine Design-Tools, deine Kommunikations-Apps – ist Closed Source. Und lange war das in Ordnung. Software war teuer zu entwickeln, und die Menschen, die sie gebaut haben, verdienten daran Geld.

Aber etwas hat sich geändert. Die Softwarequalität geht sichtbar in Zeitlupe den Bach runter, und das Frustrierendste daran ist: Du kannst nichts dagegen tun.

Jedes Update ist ein Glücksspiel. Wird es besser? Schlimmer? Wird ausgerechnet die Funktion, von der dein Workflow abhängt, still und leise kaputtgehen? Du weißt es nicht, weil du keinen Blick in den Code werfen kannst. Du kannst es nicht fixen. Du kannst es nicht forken. Du sitzt einfach fest und hoffst, dass das Team sich genug darum kümmert, es richtig zu machen.

Die KI-Ära hat das dramatisch verschlimmert. Teams liefern schneller als je zuvor – aber schneller ist nicht besser, wenn niemand für die Qualität des Ausgelieferten verantwortlich ist. Closed Source in der KI-Ära bedeutet, dass sich der Murks still und leise anhäuft, und du erfährst erst davon, wenn das Ding nicht mehr funktioniert.

Wir weigern uns, so ein Produkt zu bauen.

Es verändert etwas, wenn du etwas Bedeutungsvolles als Open Source veröffentlichst. Plötzlich kannst du dich nicht mehr hinter vagen Roadmaps oder „Wir arbeiten daran“ verstecken. Der Code liegt offen da. Deine Nutzer können ihn lesen, ihn forken und dich öffentlich darauf festnageln, wenn es in die falsche Richtung geht.

Genau diese Verantwortung wollen wir.

Wenn b10cks einen falschen Weg einschlägt – und jedes Projekt tut das irgendwann – wartest du nicht darauf, dass wir dein Problem in irgendeinem internen Backlog nach oben schieben. Du kannst dir den Code ansehen, verstehen, was passiert, und es beheben. Du kannst einen PR einreichen. Du kannst forken und deinen eigenen Weg gehen. Oder du zeigst uns einfach funktionierenden Code, der beweist, dass deine Lösung besser ist.

So sollte Software funktionieren. So funktioniert b10cks.

Es gibt einen Mindset-Wechsel, der großartige Engineers von guten unterscheidet. Große Engineers akzeptieren keine willkürlichen Grenzen in den Systemen, mit denen sie arbeiten. Wenn etwas nicht so funktioniert, wie sie es brauchen, basteln sie keine Notlösungen. Sie gehen zur Quelle und beheben es.

Closed-Source-Software macht das unmöglich. Du stößt gegen eine Wand, und die Wand ist echt. Du kannst nicht daran vorbei. Du musst damit arbeiten, dich damit abfinden oder das Tool ganz verlassen.

Open Source entfernt die Wände. Wenn b10cks etwas tut, das nicht zu deinen Anforderungen passt, bist du nicht dem, was wir in unserem Sprint planen, ausgeliefert. Du hast den Quellcode. Du kannst ihn verstehen, ändern, patchen und deine gepatchte Version noch heute in Produktion betreiben.

Ich habe b10cks als Open Source gebaut, weil wir glauben, dass die Entwickler, die es nutzen, so arbeiten sollten – und weil ich selbst mit derselben Verantwortung leben wollte.

Ich habe gesehen, was „Open Source“ in der Praxis manchmal bedeutet: ein kostenloser Tarif, der nichts abdeckt, ein öffentliches Repo ohne verwertbaren Code oder eine Lizenz, die genau so lange Open Source ist, bis jemand sie kommerziell nutzen will.

b10cks steht unter der GNU Affero General Public License v3. Das bedeutet für dich konkret:

Du kannst es selbst hosten. Für immer. Keine Genehmigung nötig, kein Lizenzschlüssel, kein Gespräch mit unserem Vertrieb. Repo klonen, Docker starten, fertig.

Du kannst jede Codezeile lesen. Das ganze Produkt. Keine verschleierten Bundles, kein Closed Core mit Open-Source-Hülle. Was du nutzt, ist das, was auf GitHub liegt.

Du kannst es forken. Wenn wir Entscheidungen treffen, mit denen du nicht einverstanden bist, kannst du das Projekt in deine Richtung weiterentwickeln. Wenn du es verbesserst, trägst du diese Verbesserungen zurück bei. Das ist die Vereinbarung – und sie ist fair.

Die AGPL schließt die Cloud-Schlupflöcher. Manche Firmen veröffentlichen ihren Code als Open Source und wissen genau, dass ihnen ohnehin niemand mit ihrem Managed Service wirklich Konkurrenz machen kann. Die AGPL bedeutet: Wenn jemand ein Geschäft auf Basis von b10cks aufbaut, bleiben diese Änderungen offen. Die Community, die das hier aufgebaut hat, bleibt geschützt.

Wir verdienen unser Geld damit, einen großartigen gehosteten Dienst zu betreiben. Nicht damit, dich an ihn zu binden.

Hier ist die unbequeme Wahrheit über KI-gestützte Entwicklung: Sie verstärkt bestehende Anreize. Teams, die Qualität priorisieren, liefern schneller bessere Qualität aus. Teams, die auf schnelles Ausliefern setzen, liefern schneller Murks aus.

In einer Closed-Source-Umgebung kannst du nicht erkennen, mit welcher Variante du es zu tun hast, bis der Schaden angerichtet ist. Du kannst die Codebasis nicht prüfen. Du siehst nicht, was ohne Review gemergt wurde. Du kannst nicht nachvollziehen, wie viel durchdachte Architektur im Verhältnis zu KI-generierten Patches steht, die niemand wirklich verstanden hat.

Open Source ist die Antwort darauf. Der Code ist sichtbar. Die Commit-Historie ist sichtbar. Die PRs, die Reviews, die Diskussionen – alles liegt offen. Wenn b10cks jemals anfängt, Murks auszuliefern, wirst du es sehen, bevor du es spürst. Und du hast die Werkzeuge, etwas dagegen zu tun.

Bei Coders Cantina haben wir unseren Ruf darauf gesetzt, Technologie zu bauen, die den Menschen, die sie nutzen, wirklich dient – nicht Technologie, die auf Kosten der Qualität Retention-Kennzahlen optimiert. Open Source ist der Weg, wie wir dieses Versprechen beweisen, statt es nur zu behaupten.

Manche hören „Open Source“ und denken sofort an etwas Untragbares oder an ein von Venture Capital finanziertes Giveaway, das am Ende doch in einem Pivot oder einer Lizenzänderung endet. Diese Geschichte haben wir auch schon gesehen.

b10cks basiert auf einem klaren Modell: Die Software ist frei und offen. Das Managed Hosting – also der Komfort, keine Infrastruktur betreiben zu müssen – ist das, wofür wir Geld verlangen. Mehr nicht. Speicher und Traffic. Keine Gebühren pro Nutzer. Keine Feature-Stufen. Kein Upselling.

Das funktioniert, weil die Leute, die ihre eigene Infrastruktur betreiben wollen, genau das auch tun werden. Und die Leute, die ein zuverlässiges, gepflegtes gehostetes Produkt wollen, zahlen dafür einen fairen Preis. Die Qualität des gehosteten Produkts bleibt ehrlich, weil die selbst gehostete Alternative immer nur einen git clone entfernt ist.

Wir sind nicht die Ersten, die dieses Modell versuchen. Wir sind nur die, die das CMS bauen, das dein Team wirklich braucht – mit der Überzeugung, dass der richtige Weg, Software zu bauen, der einzige ist, auf dem wir sie bauen wollen.