Grösseres open Source Projekt starten

[melmager]

Seit ein paar Wochen treibt in meinem Kopf eine (eventuell irre Idee) sein Unwesen.

Thema Client / Server kommunikation auf Java Basis - ohne Cloud ,ohne Javascript -
statt Browser - JavaFX.
In der richtung was Gluon mit MobileFX aufgezogen hat - das ganze dann als Opensource und
ohne Cloud zwangseinsatz.

Ist halt ein riesen projekt - wie zieht man das auf ?
Grundzüge (Pflichtenheft) erstellen und schon mal ein Paar Classen anfangen und hoffen das
jemand dazustösst. Oder wie sonst - Sprich wie findet man Mitstreiter ?
Mir allein ist das zu gross und erlich so java fit wie ich da sein müsste für ein alleingang
bin ich auch nicht - und leider neige ich dazu was anzufangen aber nicht zu beenden :-(

 

[sheel]

Hi

um Illusionen gleich zu vernichten (sorry):
a) Das durchschnittliche Opensource-Team besteht aus einer Person. Leider.
b) Wenn Helfer gesucht sind, die auch nach ein paar Wochen noch erreichbar sind, und die technisch auch nicht komplette Anfänger sind, nicht jeden akzeptieren. Auch wenn man gern mehr Leute hätte.
...
Der vermutlich häufigste Grund zum Einsteigen bei einem Projekt ist Egoismus Also dass man das schon als User verwendet, gut findet, und gern eine bestimmte Zusatzfunktion / Bugverbesserung usw. hat. Nach der Implementierung bleibt man "kleben". ... Daraus folgt dann aber auch, dass man oft niemanden findet, bevor es nicht relativ viel User gibt.

...

Sonst ... ein paar Sachen, die mir bei Projekten jeder Größe leider viel zu oft als fehlend auffallen, und die oft auch schon verhindert haben, dass ich etwas beitrage (auch wenns oft nur einzelne Bugfixes/Features etc. waren, statt dauerhafte Mitarbeit):

Auf der Webpräsenz bitte in einfachen, klaren Worten erklären, was "das" eigentlich ist und wofür es gut ist. Klingt blöd, aber das schaffen viele nicht. Keine riesige Liste von Vorteilen, keine Fotos von Menschen mit Drogen-Grinsen, kein Marketinggeblubber, kein "Meine Es64 in CPP" (= ein einfacher Zugsteuerungs-Simulator einer "Taurus"-Lok - sowas kann bei dem Namen auch nur ein Eisenbahnsüchtiger wissen), kein "Java zeigt ihnen 3D-Filme und steuert ihr Auto" (Original von Sun/Oracle - wtf) usw.

Ähnlich trivial, aber für Opensourceprojekte sicherstellen, dass man den Source als Unbeteiligter auch irgendwie finden kann. Und die Lizenz. Bedingungen zur Copyrightübergabe bei Beiträgen etc. Codestyle-Richtlinien, falls man hat. Irgendwo ein Datum der letzten Codeänderung/Version/etc. Eine Kontaktmöglichkeit. Eine Buildanleitung die auch Anfänger verstehen (was muss man installiert haben, welche Befehle, usw.) ... das sind alles Sachen, die mit dem eigentlichen Programm nichts zu tun haben, aber wichtig sind.

Dritter Punkt, bei halbwegs großen Projekten nicht nur hoffentlich gute Codedokumentation in den Files, bei den Methoden usw., sondern auch irgendwo eine Beschreibung vom "Big Picture". Macht keinen Spaß, bei 1000 Files erstmal suchen zu müssen, wo das main ist. Welche Ordner beinhalten welche wichtigen Teile des Programms und wie hängen sie zusammen. Usw

Und natürlich, wie von dir angesprochen, abstecken was man eigentlich erreichen will und was nicht. Sonst artet es oft zur "eierlegenden Wollmilchsau" aus - und während man immer neue Features addet während die bestehenden noch nicht mal fertig sind macht man das Programm irgendwann komplett unwartbar und kann von vorne anfangen (oder aufgeben).

Noch ein Punkt: Wenn irgendwas halbwegs Wichtiges im geplanten Programm von was Bestehendem abhängen soll - egal ob Libraries, Algorithmen, Datenformaten, etc. - die zuerst anlernen. Beispielprojekte machen, die Fähigkeiten und Limitierungen verstehen, usw. Ist zwar für den Tatendrang am Hauptprojekt nicht zuträglich, aber man will auch nicht erst viel später draufkommen, dass das Programmdesign wegen sowas nicht passt.

 

[ComFreek]

Eine Buildanleitung die auch Anfänger verstehen (was muss man installiert haben, welche Befehle, usw.)

Definitiv ein wichtiger Punkt! Der Build soll unbedingt auch reproduzierbar sein, am besten sind die Abhängigkeiten einem Paketmanager überlassen und man hat die Versionen irgendwo fixiert (z. B. package.json + package-lock.json bei NPM). Und wenn möglich und sinnvoll, bitte auch plattformübergreifend oder alternativ per VM-Image (siehe Vagrant).

Ein paar Dinge, die mich abhalten, bei einem Projekt tiefer einzusteigen (in abnehmender Relevanz, wobei 5 immer noch ganz wichtig ist ):

1. Kein reproduzierbarer und automatisierter Build.
2. Keine Tests.
3. Keine sinnvollen Commit-Nachrichten. Ganz so hohe Ansprüche habe ich bei einem OSS-Projekt nicht, aber wenn da nur "update" oder "fix" (ohne Bugnummer) steht, dann sagt das einiges über die Sorgfalt des Autors aus, finde ich.
4. Kein CI-Server. Gerade bei GitHub mit Travis CI sehr leicht einzurichten. Am besten auch mit einem Code Coverage Tool verbunden.
5. Kein Big Picture, wie von @sheel angesprochen.

 

[melmager]

erst mal danke für die Kommentare.
Mich hat das ja auch schon oft geärgert das oft fehlt was mit dem Projekt erreicht werden soll.
Und ja an vertiefte Installation Anleitungen fehlt es bei fast allen :-(
das für mich abschreckendes Beispiel war ein Java Programm was die Leute per Docker ausliefern.
Die Installationsanleitung bestand dann aus 3 Sätzen - ich hätte fast meine Socken kaputt gemacht weil sich die Fußnägel hochrollen wollten

 

[ComFreek]

das für mich abschreckendes Beispiel war ein Java Programm was die Leute per Docker ausliefern.
Die Installationsanleitung bestand dann aus 3 Sätzen - ich hätte fast meine Socken kaputt gemacht weil sich die Fußnägel hochrollen wollten

Warum abschreckend? Wenn das Programm genügend (native) Abhängigkeiten zu Bibliotheken hat, finde ich eine ("leichtgewichtige") VM die beste Option.
Das ist um Welten besser als eine riesige Anleitung zu bauen, um die nativen Abhängigkeiten erst einmal zu kompilieren - und dann scheitert das, weil dein Betriebssystem oder deine Distro ein/e anderes ist. Außerdem wird oft verlangt, systemweite Änderungen vorzunehmen oder systemweite Abhängigkeiten zu installieren. Sobald das verlangt wird, bin ich 100% für eine VM.

Die Installationsanleitung bestand dann aus 3 Sätzen

Das finde ich übrigens den Best Case: Ein Befehl für die lokale Installation + ein Befehl zum Ausführen.

 

[sheel]

Wenn ich da mal anderer Meinung sein darf....
a) Was ist, wenn die eine Person die die VM versteht, nichts mehr macht? => Imho "muss" man das auch so schaffen können, ohne abhängig davon zu sein, dass jemand anderes einem die Bildumgebung einrichtet. (Und "in der veralteten VM nachschauen was gebraucht wurde" ist kein Argument. Bevor ich ein ganzes OS durchsuche nach Files die zum Projekt gehören oder nicht, lass ich es lieber).
b) Es ist ein schönes Malwarerisiko, uA. auch wegen der selben Unübersichtlichkeit. Es kann beliebig viel verstecktes Zeug in so einer VM sein, und auch die "öffentlichen" Sachen hätt ich gern auch einer offizielleren Quelle.
c) Es wäre auch nett, wenn man nicht gezwungen wird, die gewohnte Umgebung am Computer aufzugeben.
d) Es macht jeden, der es einmal builden will, extrem langsam - nur weil jemand zu faul war die nötigen Sachen einfach mal aufzuschreiben.

 

[ComFreek]

Oh, ich glaube, ich hatte mich bei 'VM' unzureichend ausgedrückt Ich meinte kein fertiges binäres VM-Abbild, sondern zum Beispiel so etwas wie Vagrant, bei dem die Installation der Abhängigkeiten ("Provisioning") in Skriptform erfolgt, siehe https://www.vagrantup.com/intro/getting-started/provisioning.html. Wenn man einen CI-Server verwenden will, muss man diese Skripte sowieso erstellen.

Und "in der veralteten VM nachschauen was gebraucht wurde" ist kein Argument. Bevor ich ein ganzes OS durchsuche nach Files die zum Projekt gehören oder nicht, lass ich es lieber.

Du musst lediglich die Provisioning-Skripte dir durchlesen.

b) Es ist ein schönes Malwarerisiko, uA. auch wegen der selben Unübersichtlichkeit.

Wenn du den Provisioning-Skripten nicht traust, so kannst du auch keinem "npm install" trauen. Beide erfordern dasselbe Level an Vertrauen imo.

c) Es wäre auch nett, wenn man nicht gezwungen wird, die gewohnte Umgebung am Computer aufzugeben.

Die meisten solche VMs sind sowieso headless ohne GUI, deinen Lieblingseditor kannst du immer noch benutzen, da der Projektordner innerhalb der VM gemountet ist.
Ansonsten schließt sich solch ein VM-Angebot mit einer Installationanleitung in menschenlesbarer README-Form auch nicht aus.

d) Es macht jeden, der es einmal builden will, extrem langsam

Mit Hardware-Virtualisierung und leichtgewichtigen VMs à la Docker unter Linux ist das auch kein Problem mehr.

 

[sheel]

Ich hab mich wohl teilweise auch falsch ausgedrückt

Ok, Scripte sind natürlich keine VM, ja. Und ja, Scripte kann man mit sinnvollem Zeitaufwand lesen und ihnen dann trauen.

Zur Umgebung, ein Editor ist lang nicht alles. Sachen die nur auf den Files im gemounteten Teil arbeiten und absolut nichts anderes vom Zielsystem brauchen (auch keine OS-weiten Hilfsprogramme, keine Umgebungsvariablen, usw.usw.) kann man auf beiden Systemen ausführen, sicher. Aber wenn alles so wäre hätte man keine VM.

Und zum "langsam", meinte damit nicht direkt die Ausführung, sondern die Einrichtung. Für manche Arten von Projekten sicher kein nennenswertes Problem, aber für Anderes ist schon der Overhead vom Docker/VM-Download ein vielfacher Zeitaufwand vom direkten Installieren. Und nicht jeder will die nächsten Jahre immer an etwas arbeiten, sondern vielleicht einfach einen einzelnen Bug verbessern und einreichen. ... Während ich bei meinen Floss-Beiträgen noch auf keinen VM/Docker-Zwang gestoßen bin, würde ich einen (nicht weltbewegenden) Bug in so einem Fall sicher nicht mehr selbst ausbessern.

...
tldr, alle Varianten sind in manchen Situationen nützlich

 

[melmager]

Ich fange mal ganz einfach mal an Zuerst mal die Basicfunction
Action > Netz > Listener mal kucken wie komplex es wird sowas einfaches zu machen.
Lust das zu machen habe ich schon (aus Eigennutz )

 

[sheel]

aus Eigennutz

Das ist immer so
Der Eigennutz kann zB. auch "nur" sein "ich freu mich, dass ich anderen damit helfen konnte" - aber irgendwas gibts immer