Wie am opensource mitwirken?

S

spectre210

Well-Known Member
Hallo Leute,
Ich möchte mich gerne an der opensource Entwicklung mitbeteiligen.
Bisher beherrsche ich nur ein paar Sprachen, möchte nun jedoch auch das Wissen anwenden.
Es klingt jetzt vielleicht ein bisschen do*f, aber ich weis nicht so recht wie?
Ich weis auch nicht so recht, was man im Vorraus alles so wissen muss.
Vielen Dank im Vorraus.
Gruß spectre210.
 
Und wie funktioniert es dann?
Wenn ich einfach eine Idee zur Verbesserung hab, schicke ich den dann einfach mein Code?
Ich dachte eigentlich, dass man erstmal so etwas wie ein Mitglied werden muss.
 
spectre210 schrieb:
Und wie funktioniert es dann?
Wenn ich einfach eine Idee zur Verbesserung hab, schicke ich den dann einfach mein Code?
Ich dachte eigentlich, dass man erstmal so etwas wie ein Mitglied werden muss.
Zum Vergrößern anklicken....

Was kannst du denn? Die sache ist, du kannst dich als Kernel-Hacker fuer divese Betriebssysteme angagieren, und ja, eben einfach nur Code einzuschicken ohne dass jemand weiss wer du bist und somit was zum projekt beitragen. Die leute schauen sich den Code an und gucken ob man ihn mit einfliessen laesst, so einfach ist das. Du kannst auch irgendwo Mitglied werden als freiwilliger entwickler irgend eines projektes, aber du solltest schon wissen was du dich genau widmen willst
 
Überleg dir einfach mal bei den Programmen, die du benutzt, ob dir irgendetwas fehlt, was du dann programmtechnisch umsetzen kannst, oder wenn du Fehler findest, schau dir den Quellcode an und versuche, den Fehler dort zu beheben.
Erstelle dann einen Patch und schicke ihn an das Projekt.
Lass dich aber nicht entmutigen, wenn du gesagt bekommst, dass das neue Feature nicht angenommen wird oder dein Fehlerpatch einfach ignoriert wird. So etwas kommt vor, aber es ist eher die Ausnahme als die Regel.

Wenn du was ganz Neues starten willst: Registriere ein neues Projekt z.B. bei code.google.com oder github und fang an zu hacken. :)
 
Sinnvoll ist vielleicht noch sich kurz zu informieren, wie das Projekt arbeitet. Also was sind die Bedingungen, damit Patches angenommen werden. Wer ist dafür zuständig? Beim FreeBSD-Projekt ist es zum Beispiel so, dass viele Patches untergehen, da sie falsch eingereicht werden. D.h. falsche Mailingliste, kein PR geschrieben, etc. Und ebenso werden oft Patches abgelehnt, da sie nicht den Regeln in style(9) entsprechen. Praktisch jedes größere Projekt hat irgendwo solche Regelungen.
 
Wenn dich ein bestimmter Bereich interessiert, geh zu dem Projekt und mach dich daran Bugs zu fixen. So gewinnst du einen guten Überblick über den Code und machst dich beliebt. Wenn du ein paar Bugs gefixt hast, schreib an die Mailingliste des Projekts, dass du "mitmachen" willst und dich freuen würdest wenn dich jemand ein bisschen "mentored", d.h. dir kleinere Aufgaben überträgt und Fragen beantwortet etc.
 
Am einfachsten funktioniert es wohl mit Github. Issues eines Projekts anschauen, forken, pull request und wenn alles passt war's das.

Mit deinen Kenntnissen würde ich mir aber Firefox und das KDE-Projekt ansehen. Du kannst den beiden Projekten ja auch helfen, wenn du deine eigenen Projekte machst. Also eine App für KDE oder eine Firefox-Extension.

Ich denke der Standardweg für die Meisten ist es seine Bugs selbst zu fixen. Wenn es dir um Open Source an sich geht solltest du Dokumentation schreiben. Damit machst du immer Leute glücklich. Eine gute Möglichkeit ist auch das Übersetzen.

Achja, dann gibt es noch testen. Viele Projekte haben Testsuits (CPAN Testers, Parrot Smoke, Pike, pkgsrc bulkbuilds, ... - oder einfache Setups mit 'nem Buildbot). Die Fehler kannst du dann mit entsprechenden Kenntnissen auch gleich fixen. Natürlich hat jedes Projekt auch Testversionen. Betateste PC-BSD oder lade dir Firefox Aurora. Häufig haben Projekte auch entsprechende Mailinglisten.

Oh und dann kannst du andere Entwickler noch mit Support entlasten. Dazu muss man nur in den IRC-Channel, auf die Mailing List oder ins Forum.

Einigermaßen große Projekte haben zum Thema mitmachen meist etwas auf ihrer Website, während du bei kleineren häufig zumindest eine TODO findest. Das größte Hürde ist aber am Anfang sich an den Projektfluss zu gewöhnen. Man muss lernen, wie alles aufgebaut ist, was für ein Stil erwünscht ist, an wen man sich wenden kann, ... Allerdings sind die meisten Leute sehr zuvorkommend und nett, wenn man helfen will. Fehler sind meist recht einfach zu beheben, weil ohnehin alles Version Control hat.
 
Fixes sind nicht immer willkommen. Es muss oft viel Überzeugungsarbeit geleistet werden. Die folgenden Beispiele können übersprungen werden. Einfach bei Die Moral weiter lesen.

Mal ein Beispiel:
Bis meine Build-Fixes für FreeBSD in ioquake3 aufgenommen wurde hat es ein paar Wochen Diskussion gebraucht. Das Problem - ich habe hier(7) Unterstützung mit eingebaut. Aus Gründen die ich immer noch für Unverständnis halte sind die Entwickler dagegen. Ich musste den Bug Report aufspalten. Obwohl ioquake3 seit meiner 1.36 Portierung aus dem Stand unter FreeBSD kompiliert wird, liefere ich die ioquake3 Quellen mit einem Patchset aus, um das Programm nahtlos in FreeBSD zu integrieren.

Ein anderes Beispiel:
In ports/156901: [patch] devel/cmake breaks with CC containing spaces steckt eine Menge Arbeit und über 20 Tage Rechenzeit an Regressionstests (mit Tinderbox) auf meinem AMD Quadcore.

Das ganze ist jetzt auf nach das 9.0 Release vertagt. Wenn es so weit ist, werde ich noch mal mindestens 10 Tage investieren müssen um wieder alles zu aktualisieren.

Ein Problem mit ldd ist schon seit 2008 offen.

Der PR ports/144164: make package-noinstall does not include rc.d scripts hat erstaunlich schnell zu einem Commit geführt. Die erste Version vom Patch hat bei 5 (von über 20000) Ports noch ein Problem verursacht. Und am Schluss kam tatsächlich noch ein Folge-PR, weil alle Beteiligten ein Problem übersehen haben.

Die Moral des ganzen ist, dass Bugfixes eine Menge Arbeit für ein Projekt verursachen. Irgend jemand muss sich das genau ansehen und nachvollziehen ob es überhaupt ein Bug ist und den ggf. reproduzieren.
Viele Bugs werden erst einmal als unbedeutend betrachtet, ein Entwickler muss erst einmal von der spannenden Sache an der er eigentlich arbeitet weg gelockt werden.
Dann muss so ein Patch ausführlich getestet werden, selbst bei einem Exp-Run übersieht man gelegentlich noch Fehler.

Neue Features einbringen ist immer kritisch, monatelange Überzeugungsarbeit mit ungewissem Ausgang sind zu erwarten.

Mal ein paar Goldene Regeln:
- Niemals Bugfixes und zusätzliche Features mischen
- Regelmäßige Lebenszeichen überzeugen die Entwickler davon, dass ihr Projekt wichtig für Dich ist
- Verweise auf oder zitiere Dokumentation, ein bestimmtes Verhalten ist erst dann ein Bug, wenn es gegen die Dokumentation verstößt
- Wenn es keine Dokumentation gibt, nutze Analogien aus der Systemlandschaft und erkläre warum das aktuelle Verhalten nicht konsistent ist
- Frage nach, was gegen einen Commit spricht. Viele Entwickler lassen einen PR einfach schlafen, wenn Ihnen etwas an Deiner Lösung nicht passt. Hier ist Nachhaken angesagt, damit man seinen Fix anpassen kann
 
Mh, die Motivation zur Beteiligung an OpenSource liegt doch m.E. nicht darin, daß man eine Programmiersprache beherrscht und irgendwo mitmachen will, sondern schlicht der Frust am vorhandenem "Objekt"! Genau der Frust, warum auch OpenSource entstanden ist. Man benutzt ein System (OS, Prog egal) und ärgert sich, daß irgendwas falsch, nicht so geht, wie man sich es vorstellt usw. usw. Gutes Beispiel sind die pkgadmin-Skripte von Kamikaze... ich denke ich liege richtig, das Kamikaze völlig angenervt war, das es diese Tools nicht gab :)

Wenn der Leidensdruck ausreichen groß ist, wird man genug Motivation aufbringen sich mit fremden Sourcen herumzuschlagen, diese zu Patchen oder wer weiß, vielleicht gleich etwas völlig Neues und/oder Besseres zu bauen.

Also da anfangen, wo der Leidensdruck groß genug ist.

Just my 2 ¢
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben