Die 10 goldenen Regeln für Linux-Programm-Entwickler
1. Protze mit deinem Halbwissen aus der germanischen Mythologie: Alle Programme, die du schreibst,
müssen nach germanischen Göttern, mythologischen Orten oder magischen Klodeckeln benannt sein, völlig egal ob
der verwendete Name auch nur irgendetwas mit dem Zweck deines Programms zu tun hat.
Jeder ahnungslose User wird sofort verstehen, dass Yggdrasil-0.7-beta ein CD-Verwaltungsprogramm ist,
Valhalla-3.1 eine Entwicklungsumgebung für Brainfuck ist und Einherjer-0.9b ein Frontend für Bifröst-0.9.1a ist,
dessen Zweck kein Mensch je herausfinden wird.
2. Achte drauf, dass deine Versionsnummern nie die 1.0 überschreiten. Beginne groß Rumzutönen, was dein Programm
in der nächsten Version alles können wird, und welche Bugs in der 1.0 gefixt sein werden, achte jedoch sorgfältig
darauf, nach Version 0.6c erstmal 0.6.01a zu releasen. Fahre mit diesem Verfahren mindestens zwei Jahre lang fort.
Fange in der Zwischenzeit ein neues Projekt an und bewirb die 0.0.1 - Version in allen dir bekannten Newsgroups und Foren.
Nachdem ein neuer Kernel released wurde, beklage dich, dass es sich nicht mehr lohnen würde, 0.9d für den neuen
Kernel upzudaten und stelle die Arbeit am Projekt ganz ein.
3. RPMs sind nur was für Weicheier! Achte sorgfältig darauf, auf deiner Webseite nur Sourcen von Heimdal-0.6 anzubieten und beachte
besonders die Regel 4. Jeder Nachfrage nach einem RPM oder einem install-script begegnest du mit völligem Unverständnis
und verweist auf die INSTALL, die deine Entwicklungsumgebung irgendwann mal automatisch erzeugt hat und die du nie
an dein Programm angepasst hast.
4. Gebe ums verrecken nicht bekannt, welche exotischen Flags dem compiler übergeben werden müssen, damit
Skidbladner-0.4.3-alpha sich kompilieren lässt. Erwarte von allen Nutzern, dass sie alle deine .h-Dateien durchforsten
und alle #import-Anweisungen an ihr System anpassen.
5. Lerne die GPL auswendig, ohne auch nur im entferntesten zu verstehen, was da eigentlich drinsteht.
Füge in jede .h-Datei, die eine Zweizeilen-Funktion enthält, die gesamte GPL ein.
6. Achte darauf, dass deine Programme niemals grafische Oberflächen haben. Stelle sicher, dass deine Schnittstelle
lausig kommentiert ist und reagiere auf jede Frage nach einer GUI mit der Antwort, dass es jedem freigestellt sei, eine solche
zu schreiben, da dein Programm ja eine gut dokumentierte Schnittstelle habe.
7. Falls irgendjemand wirklich eine GUI für dein Programm schreibt, dann stelle sicher, dass pünktlich zum Release der GUI für
Version 0.5a deine Version 0.5.0.1a erscheint, die so total anders ist, dass die GUI nicht mehr mit ihr zusammenarbeitet.
Sorge dafür, dass der GUI-Programmierer nicht arbeitslos wird, indem du Regel 7 mindestens 10 mal wiederholst.
8. Sorge dafür, dass die Versionsnummern für GUI und backend auf keinen Fall synchron sind. Jeder wird schließlich begierig sein herauszufinden,
das Gladsheim-0.6 nur mit Gladsheim-GUI-0.1b und Gladsheim-0.6a nur mit Gladsheim-GUI-0.9c zusammenarbeitet.
9. Stelle sicher, dass Gjallarhornet-0.3.2a nur funktioniert, wenn vorher Brynhild-0.6 und Rimfaxe-0.2 korrekt installiert wurden.
Reagiere auf die Frage, wo zum Geier man die herbekommen soll und welcher längst in der Gummizelle sitzende Programmierer
die vor 5 Jahren mal entwickelt hat, mit völligem Unverständnis und gib bekannt, dass diese Programme "ja wohl auf jedem Standard-
System installiert" seien. Dass sie in keiner der 258 bekanntesten Distributionen enthalten sind, ist dir nicht bekannt.
Nutze diese Gelegenheit, lautstark zu verkünden, dass nur deine selbst zusammengestellte Distro die einzig richtige ist.
10. Befolge Regel 9 nur, wenn du sicher bist, dass sich auch die Entwickler der von deinem Programm benötigten Backends
an die Regeln 1-9 gehalten haben, so dass jeder, der versucht dein Programm zu benutzen, in einer Endlosschleife von benötigten
libs gefangen ist. Philosophiere anschließend sinnfrei über seltsame Schleifen in der Gödelschen Mathematik und erkläre jedem,
dass er dein Programm sowieso nur benutzen könne, wenn er "Gödel, Escher, Bach" von Hofstadter gelesen und verstanden hätte.
Diese 10 goldenen Regeln entsprangen heute meiner Feder, bei dem Veruch unter Aurox11 Mupad zum laufen zu bringen.
1. Protze mit deinem Halbwissen aus der germanischen Mythologie: Alle Programme, die du schreibst,
müssen nach germanischen Göttern, mythologischen Orten oder magischen Klodeckeln benannt sein, völlig egal ob
der verwendete Name auch nur irgendetwas mit dem Zweck deines Programms zu tun hat.
Jeder ahnungslose User wird sofort verstehen, dass Yggdrasil-0.7-beta ein CD-Verwaltungsprogramm ist,
Valhalla-3.1 eine Entwicklungsumgebung für Brainfuck ist und Einherjer-0.9b ein Frontend für Bifröst-0.9.1a ist,
dessen Zweck kein Mensch je herausfinden wird.
2. Achte drauf, dass deine Versionsnummern nie die 1.0 überschreiten. Beginne groß Rumzutönen, was dein Programm
in der nächsten Version alles können wird, und welche Bugs in der 1.0 gefixt sein werden, achte jedoch sorgfältig
darauf, nach Version 0.6c erstmal 0.6.01a zu releasen. Fahre mit diesem Verfahren mindestens zwei Jahre lang fort.
Fange in der Zwischenzeit ein neues Projekt an und bewirb die 0.0.1 - Version in allen dir bekannten Newsgroups und Foren.
Nachdem ein neuer Kernel released wurde, beklage dich, dass es sich nicht mehr lohnen würde, 0.9d für den neuen
Kernel upzudaten und stelle die Arbeit am Projekt ganz ein.
3. RPMs sind nur was für Weicheier! Achte sorgfältig darauf, auf deiner Webseite nur Sourcen von Heimdal-0.6 anzubieten und beachte
besonders die Regel 4. Jeder Nachfrage nach einem RPM oder einem install-script begegnest du mit völligem Unverständnis
und verweist auf die INSTALL, die deine Entwicklungsumgebung irgendwann mal automatisch erzeugt hat und die du nie
an dein Programm angepasst hast.
4. Gebe ums verrecken nicht bekannt, welche exotischen Flags dem compiler übergeben werden müssen, damit
Skidbladner-0.4.3-alpha sich kompilieren lässt. Erwarte von allen Nutzern, dass sie alle deine .h-Dateien durchforsten
und alle #import-Anweisungen an ihr System anpassen.
5. Lerne die GPL auswendig, ohne auch nur im entferntesten zu verstehen, was da eigentlich drinsteht.
Füge in jede .h-Datei, die eine Zweizeilen-Funktion enthält, die gesamte GPL ein.
6. Achte darauf, dass deine Programme niemals grafische Oberflächen haben. Stelle sicher, dass deine Schnittstelle
lausig kommentiert ist und reagiere auf jede Frage nach einer GUI mit der Antwort, dass es jedem freigestellt sei, eine solche
zu schreiben, da dein Programm ja eine gut dokumentierte Schnittstelle habe.
7. Falls irgendjemand wirklich eine GUI für dein Programm schreibt, dann stelle sicher, dass pünktlich zum Release der GUI für
Version 0.5a deine Version 0.5.0.1a erscheint, die so total anders ist, dass die GUI nicht mehr mit ihr zusammenarbeitet.
Sorge dafür, dass der GUI-Programmierer nicht arbeitslos wird, indem du Regel 7 mindestens 10 mal wiederholst.
8. Sorge dafür, dass die Versionsnummern für GUI und backend auf keinen Fall synchron sind. Jeder wird schließlich begierig sein herauszufinden,
das Gladsheim-0.6 nur mit Gladsheim-GUI-0.1b und Gladsheim-0.6a nur mit Gladsheim-GUI-0.9c zusammenarbeitet.
9. Stelle sicher, dass Gjallarhornet-0.3.2a nur funktioniert, wenn vorher Brynhild-0.6 und Rimfaxe-0.2 korrekt installiert wurden.
Reagiere auf die Frage, wo zum Geier man die herbekommen soll und welcher längst in der Gummizelle sitzende Programmierer
die vor 5 Jahren mal entwickelt hat, mit völligem Unverständnis und gib bekannt, dass diese Programme "ja wohl auf jedem Standard-
System installiert" seien. Dass sie in keiner der 258 bekanntesten Distributionen enthalten sind, ist dir nicht bekannt.
Nutze diese Gelegenheit, lautstark zu verkünden, dass nur deine selbst zusammengestellte Distro die einzig richtige ist.
10. Befolge Regel 9 nur, wenn du sicher bist, dass sich auch die Entwickler der von deinem Programm benötigten Backends
an die Regeln 1-9 gehalten haben, so dass jeder, der versucht dein Programm zu benutzen, in einer Endlosschleife von benötigten
libs gefangen ist. Philosophiere anschließend sinnfrei über seltsame Schleifen in der Gödelschen Mathematik und erkläre jedem,
dass er dein Programm sowieso nur benutzen könne, wenn er "Gödel, Escher, Bach" von Hofstadter gelesen und verstanden hätte.
Diese 10 goldenen Regeln entsprangen heute meiner Feder, bei dem Veruch unter Aurox11 Mupad zum laufen zu bringen.
Kommentar