Visu / Logik Server als KNXUF Gemeinschaftsprojekt

[henfri]

Hallo,

Naja bei sh.py sind immer noch pull requests von 2013 offen, ich selbst habe einen 1 Monat offen. Bei SmartVisu 3 offene pull requests vom vergangenen Jahr ohne dass irgendwas damit passiert.

Ja, das ist schade. Ich vermute, es liegt an Zeitmangel. Es ist ein schwieriger Kompromiss zwischen einem Anspruch an den Code (ein pull request durchwinken geht schnell. Den Code vorher zu prüfen und ggf. zu verbessern ist aufwändig). Ich bin aber auch nicht Glücklich damit.

Ich vermisse auch Issues die von den Hauptentwicklern an die Community weiter gegeben werden um a) eine Roadmap Ansicht zu haben und b) um auch die Community an deren Gedanken teilnehmen zu lassen.

Ack.

Und Nein, ich bin mit all dem nicht an die Entwickler herangetreten, ich manage diese Community nicht.

Was meinst du damit? Wer "managed" denn die Community?
Du hast schließlich diesen Thread eröffnet und ich kann deine Argumente nachvollziehen. Ich finde es auch schade, dass die Entwicklung von sh.py und SV stagniert. Das hat ja auch zur Folge, dass sich einige, die bisher dazu echt beigetragen haben von sh.py und SV abwenden. Das erzeugt schnell eine Abwärts-Spirale. Dennoch: Ich sehe nix in sh.py und SV was es rechtfertigt bei Null zu starten.
Ich denke, wenn Martin und Marcus die Entwicklung auf mehrere Schultern verteilen könnten, wäre das Hauptproblem gelöst. Das bedarf natürlich ein, zwei Köpfe, die ähnlich ticken (und ähnlich qualifiziert sind) wie die Beiden, um den Abstimmungsbedarf zu minimieren.

Das ist eben der Nachteil an einem derartigen "Community-Konzept"... Klar, es gibt auch genug Vorteile - keine Frage!
Aber leider gehen ziemlich viele Ressourcen für die Abstimmung und Organisation flöten - bei einer One-Man-Show ist dies nicht der Fall.

Hallo Christian, schön, dass du dich beteiligst.
Ich bin nicht sicher, ob der Abstimmungsbedarf wirklich "viele Ressourcen" benötigt. Sowohl im OSS Bereich als auch im Beruflichen Umfeld habe ich genügend One-Man-Shows gesehen.
Eine ganze Weile funktioniert es -mit viel Herzblut- die Entwicklung auf einem hohen Niveau zu halten. Aber irgendwann ist die Luft raus.
Darüber hinaus gibt es immer Features, die sinnvoll sind, die man aber selbst nicht braucht (Siehe unsere Unterhaltung über eine Mädchen-Visu). Ich würde nicht erwarten, dass du dich dafür motivierst in diese Richtung Zeit zu investieren. Was heisst das jetzt? Soll Sven deshalb bei Null anfangen und etwas ähnliches erschaffen? Oder soll er einen Fork starten? Das macht doch wenig Sinn.

@henrfi: Eine Weiterentwicklung eines bestehenden Projekts bzw. einen Fork zu erstellen ist ansich nicht ausgeschlossen, allerdings muss hier natürlich den bisherige Maintainer zustimmen. EInfach Projekte kapern halte ich für nicht zielführend.

Ich glaube nicht, dass ein Fork nötig ist. Aber wenn, dann halte ich das für besser, als etwas neues zu erstellen.
BTW: Es gibt ja nicht nur sh.py. Ich meine Tuxuedo entwickelt gerade auch etwas (java-basiert, IIRC) und es gibt Openhub, etc.

@gaert: klar, aber wenn der Maintainer keine Lust mehr hat, verschwindet das Projekt in der versenkung

ACK!

Aber es ist auch wieder so ein Projekt wo ein Mann genau weiß was er gemacht hat, was er haben wollte und möchte.

Nachvollziehbar. Ist ja für Christians Haus. Ich finde es klasse, dass er es teilt. Ich kann mir vorstellen, dass der Aufwand, das allgemeintauglich zu machen noch mal ähnlich viel Aufwand war, wie die ursprüngliche Entwicklung.

Nun stellst du es zumindest Teilweise unter GPL. Warum??? Warum lässt du die Software nicht einfach closed source und vertreibst diese als Freeware?
Wenn es ambitionierte Nutzer gibt bei offenem Quellcode, dann senden die dir schon Patches zu und du behällst die volle Kontrolle und verlierst auch keine Ressourcen.
Das gleiche gilt für neue Features und Roadmap des Produktes.

Hä? Wie sollen Nutzer Patches schicken, wenn der Code nicht offen ist (mal abgesehen von den praktischen Problemen bei php und js.)
Allerdings würde ich Christian auch ans Herz legen bzgl. der Weiterentwicklung einem "Community-Ansatz" offener gegenüber zu sein (vielleicht habe ich hier auch nur einen falschen Eindruck bekommen ("EDOMI soll in erster Linie nicht von der Community weiterentwickelt werden, sondern von mir. Aber die Community kann/soll z.B. Logikbausteine entwicklen und öffentlich zugänglich machen."))
@gaert: Erstmal kann ich mir nicht vorstellen, dass es kurzfristig Community-Beiträge gibt. Dazu ist EDOMI ein ganz schöner Brocken. Da braucht es sicher, bis sich jemand eingearbeitet hat.
Aber wenn: Was spricht dagegen? Nehmen wir die Mädchen-Visu (keine Sorge: Ich sehe mich nicht in der Lage sie beizusteuern). Wenn jemand diese entwicken möchte. Meinst du wirklich, dass der Abstimmungs-Bedarf auch nur annähernd so groß ist, wie der Entwicklungsaufwand?

Ein Software-Projekt über dieses Forum zu entwickeln scheint mir ziemlich aussichtslos. Man wird sich kaum auf die zu realisierenden Funktionen einigen können. Der eine will drüber nur GA senden und anzeigen, der nächste auch 1-Wire einbinden. Ein anderer möchte über die Visu auf Internetseiten zugreifen etc. Man kann natürlich ein solches System nach allen Seiten offen halten, um Software-Module anzudocken. Aber bis die Schnittstellen definiert sind...

Warum soll das nicht gehen? Schau dir z.B. Kodi an. Durch die Plugins ist sehr viel möglich, ohne dass Kodi ein Monster ist. Es ist so auch einfach, etwas beizutragen.
Das Gleiche gilt für sh.py.
Wer 1-Wire nutzen möchte, aktiviert das Plugin.
Ich habe ein Plugin für meinen Ofen geschrieben. Das geht bei EDOMI über die Logik-Bausteine sicher auch.
Was mich aber stört ist, dass es bei sh.py noch immer keine Möglichkeit einer relativen Adressierung von Items gibt. Einen Patch dafür gibt es, aber er ist nicht Upstream enthalten.
Bei EDOMI sehe ich nicht, dass es jemals eine Mädchen-Visu gibt. Schade! Ich verstehe wirklich nicht, was dagegen spricht, diese Optionen zu ermöglichen. Ich verstehe aber, wenn der Hauptentwickler kein Interesse hat, diese zu entwickeln.

Linux selbst ist auch ein Beispiel, bei dem viele Hundert Entwickler beitragen können, ohne dass der Abstimmungs-Bedarf zu hoch wird, oder ein unkontrollierbares Feature-Monster daraus wird.

Zurück zu Kodi: Ich finde dass Kodi ein gutes Beispiel ist, da ich zuvor den VDR nutzte. Da gibt es nur einen Maintainer. Und entsprechend langsam ist die Entwicklung so hat -für mich- Kodi dem VDR den Rang abgelaufen und ich nutze jetzt Kodi (VDR läuft nur noch als Server)

Kurzum: Wenn Sven ein "Community-Projekt" vorantreiben möchte, kann ich es nachvollziehen, denn ich sehe durchaus, dass es bei den bestehenden Projekten daran hakt sich einzubringen.
Allerdings denke ich dass dies nicht im geringsten rechtfertigt etwas neues aufzuziehen. Der Aufwand ist viel zu hoch.

Gruß,
Hendrik

[apoc4lyps]

Hallo,

Kurzum: Wenn Sven ein "Community-Projekt" vorantreiben möchte, kann ich es nachvollziehen, denn ich sehe durchaus, dass es bei den bestehenden Projekten daran hakt sich einzubringen.
Allerdings denke ich dass dies nicht im geringsten rechtfertigt etwas neues aufzuziehen. Der Aufwand ist viel zu hoch.

Das sehe ich genauso. SH.py hat eine solide CodeBasis und ins durch Python vielseitig erweiterbat. Die Entwicklung durch die Community voranzutreiben wäre super, hierzu muss aber der bisherige Maintainer sein GO geben. Ich glaube jeder von uns würde sich ein wenig verar***t vorkommen wenn die Community für die er das Projekt offengelegt hat, diese kapert

Da ich (momentan) nicht über das nötigen Wissen in Python und HTML5 verfüge, war meine intension die Maintainer und fähige Leute im Forum zusammenzubringen :P

[JuMi2006]

Also soll die Commuity für dich entwickeln?

Ich denke dass es über kurz oder lang einen Form von sh.py geben wird. In diesen kann man (wer auch immer) dann getrost die offenen PR einpflegen.

Die Stagnation ist m.M.n. auch kein Zeichen für fehlende Entwicklung sondern das hohe Niveau an vorhanden Plugins/Features.

Ich habe übrigens als erstes für "Kein Interesse" gestimmt. Der Hintergrund ist die mittlerweile wirklich sehr große Auswahl an freien Smarthome Projekten.

Vielleicht erklärst Du einfach mal genau was Dich an sh.py, smartvisu, openhab, fhem etc. Genau stört oder fehlt. OSS ist kein All Inclusive Urlaub!

[mwKNX]

Was die Dokumentation angeht wird Chris M. auch nicht müde zu betonen, dass gerne jeder willkommen ist etwas beizutragen.

Diese Hilfe habe ich schon mehrmals angeboten und teilweise im Wiki etwas geschrieben. Es ist aber sehr mühsam, wenn man erstens alleine ist und zweitens nicht weiß, was diese oder jene Funktion tut. Ein Zweizeiler vom Entwickler/den Entwicklern würde schon reichen, um daraus eine vernünftige Doku zu machen. Das ist aber leider nicht passiert. Und ich kann nicht auf eine Vermutung hin etwas dokumentieren von dem ich keine Ahnung habe was es bewirkt.

[gaert]

Da sieht man's doch am lebenden Beispiel: während hier Tagelang diskutiert wird, ob und wie und wer und wo, habe ich schon wieder ein paar Optimierungen an meinen Projekt implementiert

ich halte nunmal nicht viel von dieser neuartigen "alles muss geteilt werden" Philosophie. In vielen Bereichen ist dies natürlich toll und bringt auch Nützliches zu Tage, aber längst nicht immer. Nicht jede erdenkliche Software braucht eine Community. Sonst gäbe es ja nur noch diese Art der Entwicklung und Verbreitung...

Aber jetzt halte ich mich wieder zurück, ich wollte nicht stören oder das Thema wechseln.

[apoc4lyps]

Also soll die Commuity für dich entwickeln?

Nein, mir ist schon klar, dass OSS kein All inclusive Urlaub ist. Jeder soll den teil besteuern, den er leisten kann.

Ich war nur der Meinung, dass bevor jeder seine eigene Visu baut (SmartVisu, CometVisu, Home.js, EDOMi usw) könnte man die Entwickler gebündelt auf ein Projekt loslassen.

[tuxedo]

Ich war nur der Meinung, dass bevor jeder seine eigene Visu baut (SmartVisu, CometVisu, Home.js, EDOMi usw) könnte man die Entwickler gebündelt auf ein Projekt loslassen.

In der theorie, ja. In der Praxis hat es schon seinen Grund warum z.B. gaert sein eigenes Ding gemacht hat und nicht bei einem der anderen Projekte eingestiegen ist. Und mit den anderen Entwicklern der anderen Projekte ist es genau so.
Unterschiedliche Detail-Anforderungen führen eben zu unterschiedlichen Produkten. Und die eierlegende Wollmilchsau die alles kann und jeden zufriedenstellt, liegt in der gleichen Schublade wie das sagenumwobene Utopia.

[gaert]

Richtig. EDOMI ist übrigens nicht nur eine Visualisierung, sondern ein HS-Ersatz.

[mwKNX]

Unterschiedliche Detail-Anforderungen führen eben zu unterschiedlichen Produkten. Und die eierlegende Wollmilchsau die alles kann und jeden zufriedenstellt, liegt in der gleichen Schublade wie das sagenumwobene Utopia.

Sehr gut kommentiert! Sehe ich genauso!
Freuen wir uns also auf Christians EDOMI.