Verborgene Schätze

Es gibt viele Hobby-Programmierer:innen, die Skripte und Anwendungen für ihre eigenen Zwecke geschrieben haben. Oft handelt es sich um Schrott-Programme, die keinen Standards standhalten, oder um Trouvaillen, die unbedingt veröffentlicht werden sollten. Solche Schätze bleiben oft im Verborgenen, weil ihre Schöpfer sich nicht trauen, ihre Werke der Community zur Verfügung zu stellen.

Für diese Angst vor der Veröffentlichung kann es viele Gründe geben:

• Der Gedanke für eine Veröffentlichung kommt der Entwicklerin gar nicht in den Sinn.
• Man würde ja gerne, weiss aber nicht, wie es geht.
• Der Entwickler bezweifelt seine Programmier-Fähigkeiten.
• Das Produkt wird als uninteressant bewertet.
• Man scheut den Aufwand einer Veröffentlichung.
• Die Entwicklerin möchte den Pflege-Aufwand nicht auf sich nehmen.
• Die Angst davor, dass dich die Community in den Boden stampft, weil du irgendetwas falsch gemacht hast.
• ... und viele andere Gründe.

Es gibt noch mehr Gründe, die für eine Veröffentlichung sprechen:

Trotzdem ich mit einer Negativliste begonnen habe, wiegen die guten Gründe für eine Veröffentlichung deiner Werke die pessimistischen Argumente mehr als auf. Mit der positiven Liste möchte ich alle ermutigen, die Schätze auf ihrer Festplatte verbergen, ohne zu wissen, dass sich die Welt darüber freuen würde, zu veröffentlichen (Entschuldigung für den Schachtelsatz). Hier sind die Pro-Argumente:

• Es zwickt dich, weshalb du ein Skript schreibst. Andere Leute zwickt es auch.
• Dein Code ist schlecht; deine Idee ist gut. Veröffentliche deine Idee; der Code kann von der Community optimiert werden.
• Du weisst nicht, wie du dein Werk veröffentlichen kannst? Dann lies weiter!
• Zweifle nicht an deinem Code, solange er für dich funktioniert.
• Was du als uninteressant bewertest, kann für andere sehr interessant sein.
• Der Aufwand für die Veröffentlichung wird durch deinen Konsum von Freier Software aufgewogen.
• Du findest bestimmt andere Leute, die sich an der Pflege und Weiterentwicklung deines Codes beteiligen.
• Es ist deine Idee und dein Code. Lass dich von anderen nicht verunsichern, sondern fordere konstruktive Kritik ein.

Ich hoffe, dass diese positiven Argument ausreichen, um euch und euren Code in die Community zu pushen.

Wie veröffentliche ich meinen Code?

Dazu sind zwei Dinge nötig: eine Code-Versionierung und eine Code-Verwaltungs-Plattform. Das mit Abstand am häufigsten verwendete Werkzeug für die Code-Versionierung ist git. Insbesondere im Umfeld von Freier Software verwenden vermutlich 99 % aller Projekte git. Das Werkzeug ist Bestandteil jeder GNU/Linux-Distribution und wartet nur auf seine Verwendung für dein Projekt.

Damit dein Code den lokalen Rechner verlassen und von anderen gefunden und wiederverwendet werden kann, brauchst du eine Code-Verwaltungs-Plattform. Diese kannst du selbst hosten (z. B. mit Gitea), was ich aber Ungeübten nicht empfehle. Die bekanntesten Git-Hoster sind:

• GitHub (Microsoft)
• GitLab (GitLab Inc.)
• BitBucket (Atlassian)
• SourceForge (BIZX, LLC)
• (die Suche nach 'git hoster' zeigt euch weitere)

Aufgrund des kommerziellen Hintergrunds empfehle ich Anfänger:innen keine dieser Plattformen. Ich habe mich für den Berliner Git-Hoster Codeberg entschieden. Der Verein beschreibt sich selbst so:

Codeberg wird nicht von einem Unternehmen betrieben, sondern liegt in den Händen seiner Nutzer - über den gemeinnützigen Verein Codeberg e.V. mit Sitz in Berlin. Wir sind eine Gemeinschaft von gleichgesinnten Free Software und Content Creators. Kein Tracking. Deine Daten sind nicht käuflich. Alle Dienste laufen auf Servern unter unserer Kontrolle. Keine Abhängigkeiten von externen Diensten. Keine Cookies von Dritten, kein Tracking. Gehostet in der EU.

Ja, aber wie geht das jetzt konkret?

Dieser Artikel ist keine Anleitung zur Verwendung von git und einer Code-Hosting-Plattform. Dafür findet man im Internet und bei den Plattformen Anleitungen. Auch dafür empfehle ich die Dokumentation bei Codeberg. Dort wird sowohl der Umgang mit git, als auch der Plattform gut erklärt.

Dennoch möchte ich euch einen kleinen Eindruck vom Ablauf geben. Angenommen ihr habt ein Verzeichnis, in dem euer Skript oder Programm liegt; nennen wir es /home/dev/supercode/. Darin könnt ihr zu Testzwecken eine Datei erzeugen: touch supercode.py. Zuerst müsst ihr ein Git-Repository in diesem Verzeichnis anlegen, was mit der Eingabe von git init in diesem Verzeichnis schnell erledigt ist.

Danach gibt es neben eurer Codedatei (supercode.py) zusätzlich das versteckte Verzeichnis .git, in dem sich die Einstellungen für das Git-Repository befinden. Bei meinem Terminal (Manjaro) sieht man im Shell-Prompt nun auch, dass es ein Git-Repo gibt und, dass sich im Verzeichnis 1 Datei befindet, die nicht in das Repository aufgenommen wurde (git main ?1). Achtet bitte darauf, dass der Hauptentwicklungzweig main heisst. Gerade bei LTS-Systemen erzeugt git init gerne den veralteten Zwei master. Falls dem so ist, könnt ihr das mit diesem Befehl ändern: git branch -m master main.

Um alle geänderten Dateien in das Git-Repository einzuchecken, führt man den Befehl git add  -A aus. Damit werden alle neuen, geänderten und gelöschten Dateien versioniert. Zwischendurch kann man die aktuelle Situation immer mit git status überprüfen:

Nachdem die Datei supercode.py in das Repository aufgenommen wurde, kann man sich für eine Version seiner Software committen. Damit ist man bereit, eine (neue) Version seines Projektes auf die Code-Hosting-Plattform hochzuladen. Der commit-Befehl sieht so aus:

Damit seid ihr auf dem lokalen Rechner fertig. Im nächsten Schritt möchtet ihr die Version 0.01 beim Code-Hoster veröffentlichen. Dazu klickt ihr euch einen Account beim Git-Hoster eurer Wahl, wie z. B. codeberg.org. Diese Schritte beschreibe ich hier nicht, sondern gehe davon aus, dass ihr ein Repository für euer Projekt beim Hoster erstellt habt. Um beim Projekt SuperCode zu bleiben, würde die Adresse so heissen: https://codeberg.org/deinname/supercode.git

Bevor ihr die Version auf Codeberg hochladet, solltet ihr einen SSH-Schlüssel erzeugen, um die Übertragung abzusichern. Dazu gebt ihr diesen Befehl im Terminal ein: ssh-keygen -t ed25519 -C "E-Mail-Adresse". Damit bekommt ihr einen Private- und Public-Key im Verzeichnis ~/.ssh. Den Textinhalt des Public-Keys (id_ed25519.pub) kopiert ihr bei Codeberg/Nutzerprofil/SSH-/GPG-Schlüssel/Schlüssel hinzufügen in das Textfeld. Auf dem lokalen Rechner müsst ihr nichts machen; git fischt sich den SSH-Schlüssel aus dem ~/.ssh Verzeichnis.

Dann führt ihr diesen Befehl aus: git remote add origin git@codeberg.org:deinname/superscript.git. Damit teilt ihr git mit, wie euer Repository bei Codeberg heisst. Nun könnt ihr die committete Version eurer Software hochladen. Dies geschieht mit dem Git-Befehl push und sieht in etwa so aus:

Da SuperCode nur ein fiktives Projekt ist, habe ich für den Screenshot ein reales Projekt von mir verwendet. Nach dem Push ist euer Code beim Git-Hoster auf dem aktuellen Stand. Andere Nutzer oder Projektbeteiligte können diesen Code jetzt verwenden oder verbessern. Zum Schluss möchte ich noch zeigen, wie der gepushte Code bei Codeberg aussieht:

Diese kurze Beschreibung macht euch nicht zu Git-Profis. Sie soll euch nur eine Idee davon geben, wie der Umgang mit git ganz grob funktioniert. Bitte lest die Dokumentationen zum Thema, falls ihr euren Code befreien möchtet.

Quellen:

https://de.wikipedia.org/wiki/Git

https://git-scm.com/