via Linux and Open Source Blog

via Golem und Pro Linux

via Golem

Als Frickelware könnte man auch als Software definieren, die lieblos, halbherzig und unprofessionell programmiert wurde. Doch auch das ist ein Argument, welches mit nichten zutrifft. Hinter den meisten Open Source stehen Programmierer, die wissen, was sie tun. Nicht wenige verdienen ihr täglich Brot mit dem Programmieren von Software. Eine gewisse Professionalität kann man also voraus setzen :). Auch stehen sie nicht halbherzig oder lieblos hinter dem Projekt. Denn – warum sollten sie sich die Arbeit machen, wenn sie nicht voll hinter dem Projekt stehen würden? Es zwingt sie ja keine dazu, die Arbeit zu machen.

Das Hauptargument der Open Source Gegner ist aber, dass ja jeder ankommen könnte, um das Programm zu verändern. Dies ist bei den wenigsten Projekten der Fall. Oft gibt es eine Reihe von „Kernentwicklern“. Sie allein dürfen entscheiden, was in das Programm hinein fließt. Und auch nur sie haben uneingeschränkten Schreibzugriff auf die Versionskontrolle. Wollen andere Leute nun ihren Beitrag zu der Software leisten, so können sie das auch tun. Programmänderungen werden den Kernentwicklern als sogenannter Patch zugesandt, von diesen auf Qualität überprüft und in die Software übernommen – sofern sie denn die Qualitätskontrolle überstanden haben.

Weiterhin als Argument genutzt wird die Haupteigenschaft von Open Source. Die quelloffenheit. Jeder kann also ankommen, sich den Quelltext herunter laden und begutachten. „Böse Menschen“ könnten nun nach Sicherheitslücken suchen und diese nutzen. Um niemanden die Illusion zu nehmen, sei zu sagen, das dies auch nicht selten der Fall ist. Es gibt „böse Menschen“, die genau dies machen. Sie suchen Sicherheitslücken in Programmen um einen Fehler zu finden, den sie ausnutzen können. Doch genau so gibt es Leute, die eine solche Suche nach Sicherheitslücken machen, um die Qualität der Software zu verbessern. Und so ist die Sicherheitslücke dann schnelle behoben, als von den besagten „böschen Menschen“ gefunden. Und wenn es nun doch einmal dazu kommt, das ein „böser Mensch“ eine Sicherheitslücke findet und ausnutzt, so haben dank der offenen Quellen viele Menschen die Möglichkeit nach dem Fehler zu suchen – Programmverbesserungen sind meist schnell verfügbar.

Das Jahrbuch kann übrigens auf der Homepage der Macher heruntergeladen oder für 24,80 Euro bestellt werden. Das neueste Buch erschien am 15. März 2007.

via Pro Linux und Golem

Wer braucht Hilfe?

Wie schon gesagt stehen hinter den OpenSource-Projekten Menschen, die die Arbeit in ihrer Freizeit machen. Hilfe ist also fast immer gerne gesehen. Eine Anlaufstelle kann die Webseite des Projektes sein. Auf der Seite des Mozilla-Projektes wird zum Beispiel ausführlich über die möglichen Arten der Hilfe gesprochen. .

Eine weitere Anlaufstelle für Hilfewillige ist Sourceforge.net. Sourceforge bietet OpenSource-Projekten eine Plattform für ihre Arbeit. Hier können unter anderem die Webseiten gehostet, Maillisten verwaltet und eine Versionskontrolle wie Subversion oder CVS genutzt werden. Auf Sourceforge suchen viele Projekte auch nach Mitstreitern. Auf einer eigens eingerichteten Seite wird dabei nach Übersetzern, Administratoren, Grafiker oder Entwicklern gesucht. Im Idealfall beinhaltet diese Suche auch eine ausführliche Beschreibung der Tätigkeit, sowie ein Anforderungsprofil an den Interessenten.

I can speak English

Eine gern gesehene Art der Hilfe sind die Übersetzungen. Ist eine Software in möglichst vielen Sprachen zugänglich, so ist es leichter möglich diese in der ganzen Welt zu verbreiten. Im Idealfall ist die Software so ausgelegt, das eine Übersetzung leicht möglich ist. Dies ist zum Beispiel gegeben, wenn die zu übersetzenden Zeichenketten in eine oder mehrere Dateien ausgelagert sind. Dabei gibt es für so ziemlich jede Programmiersprache verschiedene “Standards“.

Was also tun, wenn ich merke, das meine Lieblingssoftware nicht in meiner Sprache verfügbar ist? Als erstes kann man die Webseite des Projektes besuchen, und dort gucken, ob es Informationen über Übersetzungen gibt. Vielleicht arbeitet ja schon jemand an der Übersetzung oder es gibt Richtlinien, an die sich der potenzielle Übersetzer halten muss. Ein Beispiel für solch eine Reihe von Richtlinien und Dokumentationen ist die Seite des “KDE Localization“-Projektes, welches es sich zum Ziel gemacht hat die Desktopumgebung KDE in verschiedenen Sprachen verfügbar zu machen.

Am Anfang einer Übersetzung steht meist die zu übersetzende Datei. In den meisten Fällen beinhaltet sie eine Menge von Datensätzen, die meist aus einem Schlüssel und einer Übersetzung bestehen. Der Schlüssel ist der Wert, mit dem auf die Übersetzung zugegriffen werden kann. Die Übersetzung ist der Text, der dann im Programm selber angezeigt wird. Am einfachsten ist es, wenn man sich eine Sprache zur Grundlage nimmt, die man auch beherrscht – das hilft dem Ganzen ungemein :). Die entsprechende Datei kann man sich kopieren und in der Kopie die einzelnen Textteile übersetzen. Ist die Übersetzung dann irgendwann fertig, so kann man sie im Programm testen, eventuelle Fehler berichtigen und letztendlich dem Projekt zur Verfügung stellen, damit die Übersetzung integriert werden kann.

Such den Fehler

Um ein Programm stetig zu verbessern sind die Entwickler auf Wünsche, Verbesserungsvorschläge und Fehlermeldungen der Anwender angewiesen. Um ein Programm zu testen, kann man entweder die aktuelle Version nehmen oder eine so genannte Entwicklerversion. Dies können zum Beispiel Daily Snapshots, Alpha- oder Betaversionen sein. Daily Snapshots sind Versionen eines Programmes, die einen relativ aktuellen Stand der Entwicklung darlegen. Sie sind in aller Regel noch recht fehlerhaft und invollständig. Alpha- und Betaversionen sind Bezeichnungen für den Stand der Entwicklung. Betaversionen sind meist schon recht stabil und stehen “kurz“ vor der Veröffentlichung, wobei es auch da noch verschiedene Versionen geben kann.

Hat man jetzt eine Version zum testen, so kann man sie einem ausführlichen Funktionstest unterziehen. Fehler und Wünsche kann man dem Projekt meist in einem so genannten Bugtracking-System (zum Beispiel Bugzilla von Mozilla) mitteilen. Hier werden eben solche Fehler festgehalten. Wichtig ist, das man vorher die Datenbank absucht, ob ein ähnlicher Fehler schon vorhanden ist. Diesen kann man dann gegebenenfalls mit einem Kommentar ergänzen. Existiert noch kein entsprechender Eintrag, so kann man einen neuen anlegen. Wichtig sind dabei vor allem Angaben zum System (Betriebssystem, Arbeitsspeicher etc.), Angaben zum Fehler selbst (welche Fehlermeldung, gab es einen Absturz) und wie man den Fehler produziert hat.

Wie geht das noch gleich?

Was nützt das beste Programm, wenn der Anwender nicht weiß, was er wie machen muss. Klar – im Idealfall ist das Programm intuitiv bedienbar, aber was, wenn das mal nicht der Fall ist? Dann muss eine Hilfe her, eine Dokumentation oder auch mal das ein oder andere Tutorial. Hier kann sich der geneigte OpenSource-Liebhaber super einbringen. Wenn er sich gut mit der Software auskennt, dann weiß er in der Regel auch darüber zu schreiben. Den Themen sind hier keine Grenzen gesetzt. Man kann zum Beispiel daran denken, womit man selber die meisten Probleme nach dem ersten Start des Programmes hatte.

Existiert auf der Webseite des gewählten Projektes schon eine Dokumentation, so kann man gucken, ob man sich da irgendwie einbringen kann. Zum Beispiel ein Kapitel erweitern, einen Abschnitt hinzufügen oder Teile überarbeiten. Und wenn einem nichts einfällt – einfach die Projektmitarbeiter fragen, was denn noch so benötigt wird.

Und weiter?

Natürlich gibt es noch viel mehr Möglichkeiten ein Projekt zu unterstützen. Gern gesehen sind natürlich Geldspenden. Mit ihnen können zum Beispiel Server oder Software bezahlt werden. In machen Fällen erhalten die Spender auch eine Gegenleistung. Fast schon legendär ist eine Aktion der Firefox Entwickler. Von Spenden für den Firefox Browser wurden unter anderem Anzeigen in Zeitungen geschaltet, welche neben Werbung für das eigentliche Projekt auch die Namen der Spender enthielt (Heise I, Heise II, Firefox kommt).

Eine andere Art der Hilfe ist die Werbung. Man kann seinen Freunden und Bekannten von der tollen Software erzählen und so helfen, dass Leute darauf aufmerksam werden.

Die Liste mit Arten der Hilfe lässt sich schier endlos fortsetzen. Man kann Grafiken erstellen, Webseiten administrieren, Support leisten und und und. Nicht zuletzt kann man helfen die Software zu entwickeln, indem man Programmteile implementiert oder bestehende Fehler behebt. Da die primäre Zielgruppe dieses Blogs aber nicht Softwareentwickler sind, sondern “normale“ Anwender, wird dieses Thema vorerst nicht in diesem Artikel behandelt.

Schlusswort

So – das war also mein erster Artikel im Freiblog. Ich hoffe, er hat euch gefallen. Über Feedback würde ich mich freuen. Wer ich bin? Ich heiße René Tauchnitz, wohne in der schönen Stadt Hamburg und arbeite hier als Softwareentwickler. Neben meiner privaten Seite betreibe ich noch den Einsteiger-Blog.