Veni, Vidi, VISA

Diese Woche hatte ich einen interessanten Mailaustausch mit einem Newbie, der seit einem Jahr Linux nutzt und Fragen zu meinen Konfigurationsdateien hatte. In einer Mail hatte ich "Free software: Contribute nothing, expect nothing." als Signatur stehen und als Antwort kam von ihm

Schön und gut, aber wie soll ich freie Software unterstüzen? Ich kann nicht programmieren und hab auch nicht soviel Kohle das ich was spenden könnte.

Jetzt muss ich dazu sagen, dass mir persoenlich ein User der "zugibt" nicht programmieren zu koennen lieber ist, als 100 User die meinen sie koennten es, aber egal. Man muss nicht programmieren koennen um OpenSource zu unterstuetzen. In der Mail mit dem Subjekt Greyday? Eher ein Tag zum Feiern. von Kristian Koehntopp steht wie er "zu Linux gekommen ist". Es gibt etliche Moeglichkeiten wie man OpenSource unterstuetzten kann.

Dokumentationen:
Jeder User kann Dokumentationen schreiben! Wichtig dabei ist nur, dass sie uebersichtlich und technisch korrekt sind. Mit "$foo herunterladen und installieren!" kann ein Anfaenger nicht sonderlich viel anfangen. Schreibt den genauen Vorgang; am besten fuegt die von euch eingegebenen Kommandos via copy&paste ein und erklaert sie kurz.
Ueberlegt euch was ihr dokumentieren wollt. Niemand braucht die 2342. Erklaerung wie man ein rpm-Paket installiert oder wie man ein tar.gz-Archiv entpackt; sowas sollte allenfalls der Vollstaendigkeit halber in einer Anleitung erwaehnt werden. Sorgt dafuer das der Text uebersichtlich bleibt und hebt wichtige Passagen hervor (pre, blockquote, ..). Korrekturlesen! Das ist besonders bei technischen Dokumentationen unverzichtbar! Einige User arbeiten mit copy&paste; wenn ein Leser nach diesem Prinzip vorgeht, sorgt ein Fehler in einer Kommandozeile u. U. dafuer, dass er entweder sein System schrottet oder die Anleitung als "unbrauchbar" einstuft (auch wenn der Rest korrekt ist).
Wenn man eine Dokumentation schreibt, sollte man dazu sagen auf welches System sich nachfolgende Anleitung bezieht oder ob sie "Distributionsunabhaengig" ist. In beiden Faellen sollte man angeben welche Programme benoetigt werden, welche Programmversionen eingesetzt wurden und woher man diese beziehen kann (bzw. wie man diese ggf. installiert). Gebt dem Leser die Moeglichkeit euch kontaktieren zu koennen. Auch Dokumentationen ziehen Support nach sich. Man bekommt immer wieder Mails in denen Fragen gestellt werden oder man auf Fehler aufmerksam gemacht wird. Interessant ist auch noch der Text Irgendwann wie Stevens schreiben aus der Datenschleuder des CCC. mikas Artikel Die Gesetze von OpenSource... sind ebenfalls lesenswert (auch wenn sie auf eine andere Zielgruppe bezogen sind).

Konfigurationsdateien/Scripte:
Dokumentiert und veroeffentlicht die Konfigurationsdateien der von euch eingesetzten Programme. Je ausfuehrlicher, desto besser. Aber auch ein kurzer Kommentar traegt zum besseren Verstaendnis bei. Innerhalb von Scripten sollte man function()en aussagekraeftige Namen zuweisen. Mit function hurga() { perl -ne 'while ( m/"((www|ftp|http):\/\/.*?)"/gic ) { print $1, "\n"; }' $* } werden die wenigsten User was anfangen koennen, waehrend ein

# PERL: Get all www/ftp/http- URIs of a given file

function getlinks() { perl -ne 'while ( m/"((www|ftp|http):\/\/.*?)"/gic ) { print $1, "\n"; }' $* }

mehr oder weniger selbsterklaerend ist.
Gleiches gilt auch fuer Scripte. Wenn ihr Scripte veroeffentlicht, dann spart nicht mit Kommentaren; Kommentare sind genauso wichtig wie uebersichtlich formatierter Quelltext. Und bevor elise mich jetzt wieder schimpft: Ja. Auch wenn das notwendig ist halte ich mich selber selten daran. Kommentierter und uebersichtlich formatierter Quelltext erleichtert das Lesen und Verstehen erheblich.
Der groesste "Fehler" der bei Shellscripten gemacht wird, ist das ueberfluessige Benutzen einer Shebang-Zeile, welche die Bash aufruft. Die Bash ist nur ein Standard; nicht *der* Standard! Oder - um genauer zu werden - die Bash ist nur auf GNU/Linux - Systemen die Standardshell (und selbst hier nicht auf allen Distributionen). Ein Shellscript, welches /bin/bash als Interpreter nutzt, wird unter Free-/Open-/NetBSD, AIX, IRIX, SunOS und HP-UX nicht funktionieren. Verzichtet also wenn moeglich auf #!/bin/bash als Shebang und verwendet stattdessen #!/bin/sh. /bin/sh ist naemlich auf jedem Linux/Unix vorhanden.

Mailinglisten/Foren:
Tragt euch in den offiziellen Mailinglisten ein und/oder registriert euch in den Foren. Dort koennt ihr Fragen stellen (nachdem ihr die FAQ bzw. HowTo RTFM gelesen habt) und anderen Usern bei Problemen helfen. Je mehr Arbeit ihr den Developern abnehmt, desto mehr Zeit haben diese ihre Software weiter zu entwickeln. Anfaengern hilft man am besten, wenn man ihnen Hilfe zur Selbsthilfe gibt. Ein "Lies Dir das Handbuch durch (http://link.zum.handbuch/abschnitt.html)!" ist sinnvoller als eine Step-by-Step - Anleitung.
Man sollte sich auch darueber im Klaren sein, dass eine "Step-by-Step" - Anleitung u. U. andere User faul werden laesst. Wenn sie wissen wer ihnen das Denken abnimmt, werden sie mit Sicherheit nicht selbst anfangen Eigeninitiative zu entwickeln. Diverse Kiddies reagieren zwar etwas .. komisch darauf aber solche Reaktionen sind Gott sei Dank nicht die Mehrheit. Schweigen mit arrogantem Unterton ist manchmal die beste Antwort.

Push it, don't hype / Werbung:
Jeder hat sein favorisiertes Programm; nur sollte man nicht davon ausgehen das andere User die gleichen Vorlieben haben. Menschen Programmieren und Menschen machen Fehler; ergo sollte man auch eingestehen koennen, dass $FOO auch Vorteile gegenueber $BAR hat. Linux/Unix - User finden immer wieder einen Grund einen Holy war zu beginnen (Es wurde zwar schon ueber jedes Thema einer gefuehrt, aber egal. Da gehts ums Prinzip.); laecherlich wird es erst, wenn ein Teilnehmer die Scheuklappen aufsetzt und entgegen aller Argumente "sein" System verteidigt.
Aehnliches gilt auch fuer Werbung; es spricht absolut nichts dagegen wenn man fuer "seine" Software Werbung macht, jedoch sollte man dann auch die Nachteile auflisten, damit andere User auch wissen ob das Programm fuer sie geeignet ist. Meine Meinung ueber Debian sollte hinreichend bekannt sein, aber Debian steht im Gegensatz zu dem Grossteil der Benutzer wenigstens dazu nicht perfekt zu sein.