Letzlich ist es natürlich das Projekt von Kevin&Co und entsprechend deren Entscheidung was daraus wird. Ich würde aber schon gerne dazu anregen über das Feedback welches in diesem Thread hier zustand gekommen ist nachzudenken. Das ganze soll jetzt nicht als "Beschwerde" rüber kommen, sondern Verständnis für die Perspektive öffnen, die ich als "externer" Nutzer und Entwickler habe und Ideen geben, wie ein offenerer Umgang dem Projekt helfen könnte.
OpenSource hat einige große Vorteile. Als Hersteller bedeutet es, dass man viel mehr Input bekommt. Es gibt viel mehr Leute die irgendwas entwickeln und beisteuern. Wenn jemandem ein Feature fehlt... Ja, dann programmier' es doch und mach ein PR auf! Der größte offensichtliche Nutzen bei der openWB sind die ganze Module die beigesteuert wurden. In einer komplett geschlossenen Umgebung sähe es da wohl dünn aus. Das allerdings hätte man auch mit einer Closed-Source Architektur, die jedoch pluginfähig ist erreichen können. Der Nutzen liegt bei der oWB auch darin, dass es Entwickler gibt, die am Kern mitarbeiten. Der Vorteil erstreckt sich dabei nicht nur darauf, dass Code geschrieben wird, sondern auch, dass diskutiert, reviewed und verbessert wird. Auch mir als versierter Anwender gibt das Ganze Sicherheit. Ich weiß, dass wenn oWB eingestellt wird oder sich in eine Richtung entwickelt, die mir garnicht gefällt, dann kann das Projekt geforkt werden und in eine andere Richtung weiter gebracht werden.
Natürlich hat das OpenSource auch Nachteile. Man muss den ganzen Prozess "managen". D.h. man muss sich die PRs die rein kommen auch ansehen, reviewen und auf Anmerkungen und Tickets auch antworten. Also gut, "muss" man natürlich nicht, aber wenn man es nicht tut, dann vergeht den Leuten die Lust sich am Projekt zu beteiligen und dann kann man von den genannten Vorteilen nicht mehr so sehr profitieren.
Ich verstehe, dass das ganze Arbeit ist. Ich bin der Meinung, die Arbeit ist es wert.
Hier sind ein paar Dinge, die man tun könnte, um mehr aus dem Vollen zu schöpfen:
-
Neben der README.md in Github eine CONTRIBUTING.md schreiben. Dort sollten so Dinge stehen wie "welche Abhängigkeiten gibt es (zum Beispiel die Info welche Python-Version)", "welcher Code-Style wird verwendet", "wie kann man seinen Code testen", "welche Art der Programmerung wird bevorzugt (Python vs. Bash)" etc.
-
Sich die PRs die man bekommt auch ansehen. Ich habe am 26.05., also vor fast einem halben Jahr einen
PR aufgemacht, der initial auch sofort Feedback bekam. Ich habe mich darüber gefreut und nochmal einige Stunden in den PR gesteckt und das ganze überarbeitet. Und danach kam einfach NICHTS mehr. Keine Zeit? Unter anderem habe ich in dem PR das Bash-Script für Discovergy auf Python umgeschrieben. Zwei Monate später hat dann auch nochmal jemand anders sich die
Arbeit gemacht das Modul auf Python zu ändern. Es wäre doch viel einfacher und zeitsparender gewesen meine fertige Lösung zu nehmen. Vielleicht war meine Lösung ja so nicht gewollt. Das ist OK, manchmal muss man auch einfach mal "nein" sagen, wenn ein PR nicht ins Konzept passt. Aber dann wäre es zumindest nett mal einen Satz dazu zu sagen und den PR nicht einfach völlig zu ignorieren. So ist das ganze eine loose-loose Situation: Ich habe für die Tonne gearbeitet und das oWB-Team hat sich unnötig doppelte Arbeit gemacht.
-
Sich frühzeitig und rechtzeitig zur zukünftigen Entwicklung äußern. Was kann man noch machen? Was wird über den Haufen geworfen? Ich hatte
selber schonmal nachgefragt ob es noch Sinn ergibt sich mit der alten Version zu beschäftigen. Kevin sagte "nein". Das ganze ist nicht ganz 1 Jahr her. Ich habe damals gedacht "OK, gib dem ganzen mal ein paar Wochen, dann wissen wir mehr". Nun ja, das ist nicht passiert. oWB 2.0 ist seit über einem Jahr offiziell angekündigt. Seit dem ist es eigentlich nicht mehr gewünscht sich noch groß mit der 1.X zu beschäftigen. Nach mehreren Monaten der Nicht-Information, war ich dann aber tatsächlich von einem störenden Bug betroffen und wollte jetzt nicht monatelang warten bis oWB 2.0 kommt. Also habe ich einen
PR mit Fix aufgemacht und natürlich kam prompt zurück: "Ist inkompatibel mit oWB 2.0.". Toll. In dem Fall war wenigstens ICH mir dem Risiko bewusst. Denn diese Info findet man nur, wenn man sehr aktiv danach sucht. Wer sich nichts-ahnend mit der 1.X beschäftigt, arbeitet potentiell für die Tonne und erfährt das dann danach. Es ist auch völlig unklar, was sich überhaupt wie in oWB 2.0 ändert.
Nachdem das
EVNotify-Modul ausgefallen ist habe ich dafür einen Fix entwickelt. Im Rahmen meiner Arbeit habe ich mich darüber geärgert, dass Logging und Config-Zugriff so umständlich ist. An oWB2.0 habe ich allmählich den Glauben verloren. Insofern habe ich dann mal
einen Vorschlag gemacht wie man es besser machen könnte. Prompt kam natürlich "da sind wir schon mit oWB 2 dran".
openWB hat geschrieben: ↑Mo Sep 27, 2021 6:12 am
Gab es eigentlich mal eine offizielle Aussage, warum 2.0 im Geheimen entwickelt wird?
Um aus der Erfahrung der letzten Jahre zu schöpfen und das Grundgerüst stellen zu können.
Das verhindert das zu früh zu viel diskutiert wird.
Ich frage mich wie es aussieht, wenn man "zu früh zu viel diskutiert", bzw. wie oder ob das ganze technisch überhaupt möglich ist. Dinge die man erst diskutiert, wenn alles schon fertig ist sind müßig, denn es ist ja schon alles da. Besser ist doch, wenn man so früh wie möglich diskutiert. Ohnehin wird das Ziel ja nicht erreicht. Es wird jede Menge über 2.0 diskutiert. Wobei man vielleicht eher sagen könnte "spekuliert".
Letztlich ist ja mit
dem PR #1592 doch ein bisschen was durchgedrungen. Ich habe mich daran beteiligt und ein umfangreiches Code-Review dazu gemacht. Den Reaktionen nach zu urteilen war das auch willkommen und ich sehe, dass im
#1628 auch viel von meinen Vorschlägen umgesetzt wurde. Es freut mich natürlich sehr zu sehen, dass die Arbeit die ich mir damit gemacht habe auch angekommen ist (etwas schade, dass ich den 1628 erst jetzt sehe, aber gut...). War das jetzt die "zu frühe Diskussion"?
Ich finde oWB ein super cooles Projekt. Ich finde es toll, dass es OpenSource ist und dass ich mich daran beteiligen kann. Ich mache da gerne bei mit um das Projekt weiter zu bringen. Wenn ihr noch etwas offener wärt gegenüber weiteren potentiellen Beitragenden würde es noch mehr Spaß machen und es gäbe noch mehr Input.
.