Warum diese Seite von Tag eins an in einem öffentlichen Repo liegt

Als ich zum ersten Mal darüber nachdachte, meinen Code auf GitHub zu veröffentlichen, zog sich mir der Magen zusammen – ähnlich wie vor einem schwierigen Kundengespräch.

Nicht, weil sich geheime Informationen im Repository befanden. Sondern weil sich das Repository selbst wie ein Geheimnis anfühlte: unsaubere Commits, halbfertige Seiten, Platzhaltertexte mit „Demnächst“.

Ich bin Geschäftsführer eines kleinen Metallbauunternehmens. Ich bin es gewohnt, Stahl zu liefern, der hält – oder eben nicht. Bei Software fühlt es sich anders an. Man kann sie im Verborgenen weiterentwickeln, bis alles glänzt. Die meisten tun genau das.

Ich hätte es beinahe auch getan.

Die bequeme Lüge vom „Später“

Jahrelang war mein digitales Leben in zwei Bereiche geteilt.

Auf dem Shopfloor: Systeme, die ich nicht einfach verändern kann – teuer, träge und aus einer anderen Zeit.

Zu Hause: Ideen. Etwas besser dokumentieren. Ein kleines Tool für einen lästigen Ablauf. Eine Seite, auf der ich über das Programmierenlernen schreiben kann, ohne so zu tun, als würde ich das seit zwanzig Jahren machen.

Jedes Mal schloss ich mit mir selbst denselben stillen Deal:

Erst privat, bis es gut genug ist.

Private Repositories fühlen sich sicher an. Niemand sieht den Tippfehler im dritten Commit. Niemand merkt, dass du dieselbe Seite viermal neu gebaut hast, weil das Spacing auf dem Laptop nicht richtig wirkte. Niemand fragt, warum ein Geschäftsführer um Mitternacht Docker lernt.

Aber dieses „Später“ hat seinen Preis.

Private Repositories trainieren dich darauf, für ein Publikum von genau einer Person zu arbeiten: für dich selbst. Du optimierst gegen deine eigene Peinlichkeit statt für Verständlichkeit. Du wartest auf eine Perfektion, die nie kommt – weil du kein Vollzeitentwickler bist. Und weil du das auch nicht sein musst.

Der Wendepunkt war unspektakulär: ein Dienstagabend. Eine Stunde Arbeit an etwas Kleinem – Routing oder einer Datenbankmigration, ich weiß es nicht mehr genau. Dann kam mir ein Gedanke:

Wenn ich das wirklich lernen will, brauche ich Gewohnheiten wie bei echter Softwareentwicklung.

Echte Software wird 2026 häufig öffentlich entwickelt. Oder zumindest so, als könnte morgen jemand mitlesen.

Also habe ich WERKSCODE auf GitHub vom ersten Tag an öffentlich gemacht. Nicht am ersten Tag einer fertigen Website, sondern am ersten Tag ihres Fundaments.

Wovor ich Angst hatte

Ehrlich gesagt: vor denselben Dingen, die vielleicht auch dich beschäftigen.

„Die denken, ich bin kein echter Entwickler.“ Stimmt. Das bin ich nicht.

Ich bin Unternehmer und wollte aufhören, auf Erlaubnis zu warten, um eigene Probleme anzugehen. Ein öffentliches Repository behauptet keine Expertise. Es zeigt eine Absicht: lernen, bauen und sichtbar besser werden.

„Jemand klaut meine Idee.“ Die Ideen, die auf meinem Shopfloor wirklich zählen, liegen nicht in diesem Repository.

Diese Seite ist Blog und Portfolio zugleich – ein Ort, um öffentlich zu denken. Werkzeuge für den internen Betrieb bleiben privat. Öffentlich bedeutet nicht, alles offenzulegen.

„Ich veröffentliche etwas, das ich nicht veröffentlichen sollte.“ Diese Sorge ist berechtigt.

Ein öffentliches Repository verlangt Disziplin: keine .env-Dateien, keine Kundennamen, keine Produktions-URLs und keine internen Systeme in Commits oder Markdown-Dateien.

Ich versuche, alles so zu schreiben, als würde ein Fremder mitlesen. Vielleicht tut er es ja.

Das klingt zunächst unbequem, ist aber befreiend. Man lernt, die Lektion vom vertraulichen Detail zu trennen.

„Es sieht noch unfertig aus.“ Das stimmte. Und an manchen Stellen stimmt es noch immer.

Aber Unfertiges in der Öffentlichkeit ist ehrlich. Selbstständige brauchen nicht noch eine Hochglanz-Landingpage. Sie brauchen den Beweis, dass ein normaler Mensch anfangen kann.

Was sich verändert hat, seit das Repository öffentlich ist

Die größte Überraschung waren nicht GitHub-Sterne oder viraler Traffic. Damit rechne ich nicht – und das ist auch nicht mein Ziel.

Die eigentliche Überraschung war, wie sich meine Arbeitsweise verändert hat.

In einem öffentlichen Repository schreibt man keine Commit-Nachrichten mehr wie fix stuff. Man formuliert sie so, dass man sie auch einem Mitarbeitenden zeigen könnte.

Man legt eine .gitignore an, bevor man sie dringend braucht. Man liest den eigenen Diff noch einmal. Man bittet den KI-Assistenten – bei mir ist es Cursor –, die Projektregeln zu beachten, weil diese Regeln Teil des Produkts sind und nicht nur eine private Notiz.

KI-Tools helfen mir in einem öffentlichen Repository sogar mehr, nicht weniger.

Wenn klar geregelt ist, wie Commits aussehen sollen, wie Blogbeiträge anonymisiert werden und welche Informationen niemals in einen Chat gehören, muss der Assistent weniger improvisieren. Die Codebasis wird zu einer gemeinsamen Arbeitsfläche – zwischen mir, den Tools und vielleicht jemandem, der das Projekt später forkt und selbst damit experimentiert.

Ich verwechsle außerdem Lernen nicht mehr mit Launchen.

Die Startseite darf „Demnächst“ sagen, während das Repository den Weg bereits dokumentiert. Der Blog darf noch leer sein, während Makefile und Docker-Setup schon funktionieren.

Ein öffentliches Repository bedeutet nicht öffentliches Marketing. Es bedeutet einen öffentlichen Prozess.

Sackgassen gab es trotzdem

Das Repository öffentlich zu machen, hat mich nicht auf magische Weise produktiv gemacht.

Ich habe die Entwicklungsumgebung nach Änderungen an Abhängigkeiten neu gebaut. Ich bin auf Content-Cache-Fehler gestoßen und habe gelernt, was Nuxt Content in SQLite speichert. Ich habe Layout-Code mehrfach umgeschrieben, bis sich gemeinsame Seitenkomponenten ergeben haben.

Die Git-History im Repository zeigt diesen Weg. Und das ist in Ordnung.

Was die Öffentlichkeit verhindert hat, war etwas anderes: das perfekte private Projekt, das nie live geht, weil es letztlich nur für mich selbst gedacht war.

Was ich anderen Selbstständigen sagen würde

Wenn du neben deinem Betrieb programmieren lernst, brauchst du keinen privaten Sandkasten, bis du dich „bereit“ fühlst.

Du brauchst einen kleinen öffentlichen Ort – mit klaren Grenzen.

Wähle etwas Unkritisches: eine Website, ein Skript oder ein Template. Nicht deine Kronjuwelen. Schreibe auf, was niemals in Git landen darf. Nutze Entwürfe für Inhalte, die noch nicht auf der Website erscheinen sollen, auch wenn das Repository bereits sichtbar ist.

Das Repository soll zeigen, wie du arbeitest – nicht jedes Detail darüber, womit du Geld verdienst.

WERKSCODE ist mein kleiner öffentlicher Ort. Der Name ist Wortspiel und Versprechen zugleich: Werk trifft Code.

Dass das Repository vom ersten Tag an öffentlich ist, gehört dazu. So lerne ich wirklich – nicht nur so lange, bis alles hübsch genug aussieht, um es zu zeigen.

Du musst nicht deine Fertigung ins Internet stellen. Du musst kein Influencer werden.

Du musst nur entscheiden, ob das Verstecken dir noch hilft – oder ob es dieselbe Geschichte ist wie: „Wir digitalisieren, wenn wir Zeit haben.“

Eine Geschichte, die der Shopfloor nur zu gut kennt.

Ich habe Sichtbarkeit gewählt. Nicht, weil ich besonders mutig bin, sondern weil privat zu bequem war.

Und weil Bequemlichkeit die Arbeit nicht erledigt.