Organisation eines Open Source Projektes

[Florian N (Gast)]

Hallo an alle,
Als begeisterter Elektrotechnikstudent und Fan der Open Source Gemeinde, 
habe ich hier ein Thema, zu welchem ich mir in letzter Zeit den Kopf 
sehr stark zerbrochen habe. Es geht um die Organisation eines Open 
Source Projektes, welches ich mit ein paar Kumpels (und evtl. ein paar 
anderen Freiwilligen) bearbeiten möchte. Das Projekt beinhaltet sowohl 
Hardware auf µControllerbasis und PC-Software. Zur Realisierung gibt es 
bereits vielversprechende Lösungsansätze, um welche es hier aber nicht 
gehen soll. Viel mehr brauchen wir etwas Hilfe in der Organisation eines 
solchen Projektes, bzw. der Dokumentation, sodass jeder der an diesem 
Projekt mitwirken möchte sich größtenteils selbst einarbeiten kann. Da 
dieses Projekt auch zu Lernzwecken dienen soll wäre uns am Liebsten, 
wenn man sich an der Organisation wie in einem Unternehmen orientieren 
kann.

Hier unsere speziellen Fragen:
-Wir haben gelernt, dass man als ersten die Anforderungen genau 
definiert und anschließend das Projekt in kleine Module (Hard- und 
Software) aufteilt. Doch wie kann man die Schnittstellen so definieren, 
dass diese von unabhängigen Personen an unterschiedlichen Orten 
bearbeitet werden können?
-Sind Entwicklungsguidelines sinnvoll, sodass man sich darauf einigt, 
bspw. Variablen in der Software nach gleichen Richtlinien zu benennen? 
Kann man solche Regeln auch für die Hardware definieren?
-Welche Art von Dokumenten sind sinnvoll um ein komplettes Projekt zu 
dokumentieren? Wie organisiert man solche Dokumente, dass jeder immer 
die aktuelle Version vorliegen hat?
-Wie kann man die Module so eingrenzen und realisieren, dass man die 
Module auch für andere Anwendungen (andere bzw. größere Ausführung des 
Projektes) einfach verwenden kann?
-Wie kann man Tests sinnvoll dokumentieren?
-Gibt es weitere Punkte welche man noch beachten muss?

Da ich denke, dass sich in diesem Forum sehr fähige Leute tummeln, bitte 
ich um hilfreiche und ernst gemeinte Antworten. Gegen etwas spassige 
Ratschläge habe ich nichts, im Gegenteil, doch Leute (von denen es in 
diesem Forum leider auch sehr viele gibt), welche nur dumme Antworten 
geben um andere zu stressen, bitte ich sich zurück zuhalten, Danke!

In Freude auf eine angeregte Diskussion und im Vorraus ein großen 
Dankeschön für die Hilfe!!!
Florian

[hmpf (Gast)]

ich würd ein projekt auf sourceforge.net oder so erstellen,  da haste 
die ganzen sachen wie SVN etc. damit sollte zumindest auf software seite 
alles unabhängig voneinander immer auf dem neusten stand sein. wichtig 
ist, dass man sich auf gemeinsame schnittstellenkonventionen einigt 
sowohl für software und für hardware...

[MaWin (Gast)]

> -Gibt es weitere Punkte welche man noch beachten muss?

Du musst zunächst ein mal erkennen, daß ein OpenSource Projekt,
welches wirklich offen sein soll für weitere Leute die mitarbeiten,
und welches tstsächlich als Lernprojekt tauglich sein soll,
weit höhere Anforderungen zu erfüllen hat, als ein kommerzielles
Projekt einer Firma, was Struktur und Dokumentation anlangt, aber
auch die verwendeten Techniken. Es muss halt lehrbuchmässig sein.

Ein relativ brauchbares Beispiel wäre Knuth's TeX/Metafont, welche
als Buch erschienen sind mit mehr Text als Programmzeilen. Der
Mann war immerhin Professor. Ihr schafft das locker als Zusammenarbeit,
wenn die Doku als Wiki organisiert wird, welches auch mit Bildern
und Diagrammen durchsetzt ist. Als Beispiel wollte ich dir jetzt
http://www.freebus.org/ nennen, aber die haben was geändert, die
waren früher wesentlich übersichtlicher und einladener, sind
also auch inzwischen auch nur noch ein Beispiel, wie jedes Projekt
mit der Zeit bis zum geht nicht mehr verschlimmbessert wird.

Ein Gegenbeispiel wäre Schmidingers VDR. Unlesbarer mies dokumentierter
Privatpersonenverhau.

> -Sind Entwicklungsguidelines sinnvoll, sodass man sich darauf einigt,

Sicher, und das gute an einem Mehrpersonenprojekt ist, dass die
Richtlinien eine gemeinsame Übereinkunft sind statt einem aufgedrückten
von jemandem der sie sowieso nicht beholgen muss, also sicherlich
der härteste Unfug nicht drin auftaucht. Sie müssen sogar so intuitiv
sein, daß sie jedem der neu hinzukommt direkt einleuchten ohne dass er
erst lesen muss, sonst befolgt er sie eh nicht, und dessen Einstellung
setzt sich langsam im Projekt durch.

Zu allen anderen Punkte: Es wäre gut, wenn die Leute wenigstens schon 
irgendwas könnten, z.B. erfolgreich Programmieren könnten.

Wenn ihr also bereit seid, euch MEHR Arbeit zu machen, als bloss das 
Problem zu lösen: Nur zu.

[Florian N (Gast)]

Wow, das geht ja hier richtig schnell mit den Antworten, vielen Dank!

>Du musst zunächst ein mal erkennen, daß ein OpenSource Projekt,
>welches wirklich offen sein soll für weitere Leute die mitarbeiten,
>und welches tstsächlich als Lernprojekt tauglich sein soll,
>weit höhere Anforderungen zu erfüllen hat, als ein kommerzielles
>Projekt einer Firma, was Struktur und Dokumentation anlangt, aber
>auch die verwendeten Techniken. Es muss halt lehrbuchmässig sein.

Soll das bedeuten, dass die ganzen Open Source Projekte eigentlich viel 
besser organisiert sind als die Unternehmen? Wobei der wirtschaftliche 
Faktor, welche in einem Unternehmen zusätzlich einwirkt wahrscheinlich 
nicht zu vernachlässigen ist, oder?

An sourceforge haben wir bisher auch gedacht, doch hier ist es meines 
Wissens nur möglich die Software zu organisieren, die Hardware bleibt 
hier auf der Strecke, oder?

Für die Dokumentation haben wir uns heute folgendes überlegt:
-Als erstens müsste man doch zuerst in einem Dokument einen Überblick 
schaffen über die kompletten Module und den prinzipiellen Aufbau des 
Gerätes
-In der Übersicht müsste in tabelarischer Form von jedem Module (Soft- 
und Hardware) die aktuelle Version bekannt sein
-Ebenso könnte in der Übersicht in kurzer Form die Schnittstellen 
beschrieben werden
-Anschließend muss jeweils in einem separaten Dokument jeweils das 
betreffende Modul mit dem internen Aufbau beschrieben sein.
-Auch die Schnittstelle zu jedem Modul muss ausführlich dokumentiert 
werden
-Zu guter letzt müssen auch die Tests genau beschrieben und dokumentiert 
werden (zu jeder Releaseversion)

Gibt es irgendeine Software mit der sich soetwas organisieren lässt? Am 
besten natürlich auch Open Source oder zumindest Freeware? Evtl. auch 
ein entsprechendes Template für Joomla?

Wie kann man auf einfache Weise einen Bugreport realisieren?

Florian

[Jochen (Gast)]

Die "eine" Software gibt es imo nicht. Es gibt eine Reihe von Tools, die 
fuer sowas ganz nuetzlich seien kann.
Als Managementsoftware mag ich persoehnlich trac ganz gerne, aber da 
gibt es auch einige andere gute Programme 
(http://de.wikipedia.org/wiki/Kategorie:Freie_Projektmanagementsoftware). 
Die meisten duerften auch direkt ueber einen Bugtracker verfuegen und 
sind kompatibel zu den grossen Versionskontrollsystemen (git, svn, 
etc.).
Fuer eine automatische Dokuerstellung kann man Doxygen verwenden, aber 
da ists wie ueberall, die einen beschreiben ihren Code ausfuehrlich, die 
anderen eben nicht. Und um ein paar Worte in der Managementsoftware 
kommt man eh nicht drum herum, sonst ist der Einstieg in fuer 
Aussenstehende zu hart.

Gruss

[Andreas S. (andreas) (Admin)]

Florian N schrieb:
> An sourceforge haben wir bisher auch gedacht, doch hier ist es meines
> Wissens nur möglich die Software zu organisieren, die Hardware bleibt
> hier auf der Strecke, oder?

Hardware, Software, kommt doch auf's gleiche raus. Beides besteht aus 
Dateien die versioniert und dokumentiert werden müssen.

Sourceforge ist nicht mehr unbedingt die beste Wahl, ich würde mir eher 
mal Google Code anschauen.

> Für die Dokumentation haben wir uns heute folgendes überlegt:
...
> Gibt es irgendeine Software mit der sich soetwas organisieren lässt?

So etwas muss flexibel und einfach zugänglich sein, um potentiellen 
Mitarbeitern keine unnötigen Steine in den Weg zu legen oder sie zu 
stark einzuengen. Das geht am besten in einem Wiki. Google Code bietet 
eines, wenn man es selbst hosten möchte ist Trac zu empfehlen.

> Wie kann man auf einfache Weise einen Bugreport realisieren?

Geht ebenfalls mit Google Code und Trac.

[MaWin (Gast)]

> dass die ganzen Open Source Projekte eigentlich viel
> besser organisiert sind als die Unternehmen?

Nein, die meisten open source Projekte sind eine freche Zumutung
für alle, die sie sich ansehen.

Komplett undidaktisch aufgemacht und meist ein grober Verhau.


Das führt dazu, daß fast nichts von anderen Leuten gepflegt wird,
sondern lieber was Zusätzliches neu geschrieben wird um die Fehler
des anderen zu umgehen, weil man dessen Kram nicht verstehen konnte
und sich nicht rangetraut hat dadrin den Fehler bzw. die Anknüpfpunkte
zu suchen.