Immer mehr Module in Symcon sind verwaist:
Entwickler sind nicht mehr aktiv. Vielleicht wurde die Hardware entsorgt und durch was anderes ersetzt, das Interesse geringer oder sie haben gar Symcon ganz den Rücken gekehrt.
Ich denke es wird Zeit zu klären, wie man damit umgeht.
Welche Module für wen essentiell sind ist natürlich eine sehr individuelle Sache.
Mein persönliches Horrorszenario: @KaiS oder @da8ter gehen. Dann verlieren wir Kernelemente, ohne die, zumindest ich, nicht mehr auskomme.
Wenn Kernmodule nicht mehr gewartet werden wird wohl oder übel Symcon die weiterpflegen müssen. Aber an was macht man das genau fest und was ist mit all den anderen.
Mein aktuell relevantes Problem @kris und das Faikin Modul.
Wenn man seine Hausautomation auf etwas aufbaut, das dann wegbricht ist dies dramatisch.
Und das soll, weiß Gott, keine Anklage sein. Jedem, der ein Modul für die Community entwickelt hat, gehört zumindest enormer Respekt.
Es ist das eine etwas für sich zu entwickeln und was völlig anderes es auch der Community zu schenken. Der Aufwand ist eine Dimension höher.
Der Store braucht zumindest eine Kennzeichnung welche Module nicht mehr gepflegt werden. Vielleicht findet sich ja jemand, der sie weiterpflegt.
Von den Myriaden an Beta Modulen mag ich erst gar nicht anfangen.
Ja, das ist auch meine große Befürchtung.
Und wir sind da sicher nicht allein.
Eine Kennzeichnung nicht mehr supporteter Module würde schon mal helfen.
Auf Grund des Beitrags: Eure Erfahrungen & Meinungen: Bezahlte Module in Symcon
habe ich mal eine Liste meiner eingesetzten Module erstellt. Aufgeteilt nach Ersteller (Symcon, Entwickler) und Verwendung (für den Betrieb unentbehrlich, nice to have).
Von 32 installierten Modulen ist keins von Symcon. 8 sind für meinen Betrieb unentbehrlich.
Ich würde mich sehr viel wohler fühlen, wenn Symcon zu diesem Thema Stellung beziehen würde. Natürlich müssten sie dann auf kurz oder lang für die Module Geld nehmen.
Kann ein professionelles System sich auf freie, unbezahlte, Entwickler verlassen?
Zur Bezahlung: Wäre es denkbar, je nach Menge der installierten Modulen die Subskription anzupassen?
Also ich werde aus dem Grab noch weiter machen.
Klar mein Support ist aktuell etwas eingeschränkt, aber ich werde vor allem die großen und aktivsten Module nicht links liegen lassen.
Und sollte schnell Hilfe benötigt werden hilft auch das IPS Team aus.
Der Code ich ja frei zugänglich.
Ich denke wir sollten hier nicht über Entlohnung der Modulentwickler sprechen, denn wir machen das auch, um Symcon zu unterstützen, weil wir diese Software lieben und ein Teil davon sein wollen.
Ich denke @paresy würde niemals große Module die für Symcon existenziell sind liegen lassen, sollte ein Entwickler aufhören.
Prinzipiell hängt das von unserer Seite natürlich vom Einzelfall ab, haben aber sicherlich einiges an Möglichkeiten. Außerdem muss ein Modul nur weil es länger keine Updates bekommen hat ja auch nicht schlecht werden. Ansonsten die Möglichkeiten, die wir so haben und auch schon angewandt haben:
Ein Modul kann als nicht mehr funktioniernd markiert werden. Klar, das ist dann doof. Das passiert aber üblicherweise nur, wenn das Modul beispielsweise auf einer Cloud oder einem Web-Dienst basiert und diese abgeschaltet wurde. Da kann leider dann niemand etwas machen…
Mit der Erlaubnis des ursprünglichen Entwicklers kann jemand anderes das Modul übernehmen. Das können dann wir sein oder auch ein anderes Mitglied der Community. Da sind auch schon beide Varianten vorgekommen.
Prinzipiell hat @KaiS es aber sicherlich passend getroffen. Wenn ein Modul viel genutzt wird und der Entwickler es nicht mehr pflegen kann, dann werden wir unser bestes geben um Mittel und Wege finden, dass dies weiter lauffähig bleibt.
Ich kenne jetzt die AGB vom Module Store nicht auswendig. Würde euch aber raten sich da ein wenig abzusichern.
Könnte ja auch durchaus vorkommen das mal jemand IPS im Streit verlässt. Wenn der dann auch seine Module löscht oder die Weiterverwendung seines Codes untersagt schauts auch net gut aus.
Du setzt OpenSource-Module ein, da liegt das Risiko bei dir. Natürlich ist es toll, wenn sich jemand gefunden hat, der ein Modul gebaut hat, aber damit geht er keine Verantwortung ein es auf ewig zu pflegen. Das ist eben das Risiko bei OS-Modulen. Das Risiko kann man abschwächen, wenn man sich die Pflege selber zutraut (der Code ist ja zugänglich und ich habe noch kein Modul gesehen der ein Fork verboten hätte) oder in dem man jemand mit der Wartung beauftragt. Dafür musst du dann natürlich zahlen, für die Wartung, nicht für das Modul! Denn der Weiterverkauf auf OS basierender Software ist idR untersagt. Naja, es gäbe noch die Möglichkeit, dass jemand (ob gegen Gebühr oder umsonst) das Modul übernimmt und für dich weiterentwickelt und um die Kosten zu decken kostenpflichtig anbietet.
Auch wenn es hier zwischen den Zeilen angeboten wurde, aber du kannst von Symcon nicht verlangen, dass sie immer in die Verantwortung dafür gehen, wenn jemand anderes ein Modul angefangen hat und dann liegen gelassen hat. Natürlich kann Symcon bei intensiver Nutzung und in Absprache mit dem Entwickler sich überlegen es zu “seinen” Modulen zu machen… aber verlangen kann man es erstmal nicht.
Viel mehr Sorge als die Module machen MIR allerdings die Hersteller von Systemen… ganz viele Anbindungen bauen auf Schnittstellen auf die so “Semi-Offiziell” sind und selbst bei offiziellen Schnittstellen sagt ja keiner das der Hersteller die weiter pflegt oder offen lässt. Dieses Risiko sollte man beim Einsatz auch mit bewerten.
Natürlich, daher ja auch “Mit der Erlaubnis des ursprünglichen Entwicklers”. Wenn dieser nicht möchte, dass jemand sein Modul übernimmt, dann geht das auch nicht. Das haben wir aber bisher noch nicht erlebt. Bisher gab es ein paar Fälle, in denen der Entwickler keine Zeit mehr für sein Modul hatte oder kein Interesse mehr daran, dies aber gerne abgegeben hat.
Ich meinte ja auch nur das ihr euch bei Code der euch wichtig erscheint VORHER um etwaige Weiternutzungsrechte kümmern solltet.
Wenns mal Streit gibt (geben sollte) ists zu spät.
Da könnte man nicht Mal wirklich drüber streiten, dass liegt an den “Billigkomponenten“ , professionelle Hardware läuft auch mit Symcon ohne Zusatz-Module.
Aber das ist glaube ich nicht wirklich eine Diskussion wert.
Die Module liegen im Source-Code vor, damit ist die Grundlagen für Anpassungen vorhanden. Ich finde diese “Konsumentenhaltung” etwas schwierig, also Module einzuforden ohne selbst etwas dafür zu tun.
Ja, ich weiß, der Kern von Symcon ist nicht Open Source, aber bei den kostenlosen Modulen ist’s eben wie bei anderer Open-Source-Software auch: da muss eine Community ran, das ist kein “Konsumenten-Vollservice für umsonst”.
Ich habe sehr früh nach meinem Diplom festgestellt, dass entwickeln nicht meine Kernkompetenz ist
Und ich lege hier wahrlich keine Konsumentenhaltung an den Tag.
Ich stelle nur Fragen, wie tragfähig mein Homeautomation Konzept ist.
Wer basteln möchte kann das ja gerne tun.
Ich denke nicht, dass wir hier in Panik verfallen müssen
Klar ist es doof, wenn jemand die Community verlässt und natürlich ist es spürbarer, wenn dieser User viele Module entwickelt hat. Aber mit @Fonzo haben wir dies in der Vergangenheit auch erlebt und dies gut gelöst bekommen. Die Module wurden einfach neu verteilt (für die es viel Bedarf gab), einige haben wir (Symcon) übernommen (z.B. TaHoma/Honeywell Home) und für einige weniger genutzt Module haben wir über den Premium Support für Kunden auch fixes gebaut (z.B. für Ondilo Modul). Dieser Weg steht ja jedem frei - auch wenn er potenziell etwas mehr kostet.
Die Idee, wie @bbernhard die beschreibt, dass im Moment der Store-Einreichung alle Rechte am Quellcode an uns übergehen, sehe ich kritisch. Ich persönlich würde niemals einem Unternehmen einfach so Rechte an meiner Arbeit überlassen. Und diese Probleme hast du in den großen App Stores ja auch. Nur weil ich heute sogar viel Geld für eine App ausgebe - niemand garantiert mir, dass der Entwickler Morgen noch Lust hat die weiterzuentwickeln oder nicht Morgen aus dem App Store rausnimmt (z.B. weil er bei Apple die 99€ nicht bezahlt hat ).
Solange die Geräte ohne Cloud laufen, ist die Wahrscheinlichkeit, dass ein Gerät die API ändert zum Glück sehr gering. Die meisten Probleme (auch für aktive Entwickler und wir unsere Symcon Module) haben wir mit ständig ändernden Cloud APIs, Abkündigungen oder neuen Geräten, die sich immer wieder neue APIs ausdenken (Shelly )
Hier haben wir aber das Glück, dass wir als Community eine echt tolle Gemeinschaft sind - und bisher wurden Module vertrauensvoll an neue Hände weitergegeben. Ich sehe dort auch keinen Grund daran zu Zweifeln, dass dies in Zukunft anders sein wird
da bekomme ich ja fast ein schlechtes gewissen aber letzen endes kann man bei dem betreffenden Modul auch stattdessen einfach MQTT nutzen, ist halt mehr arbeit aber machbar.
Es ist aber ein Problem das die Einstiegshürden für ein Modul doch so hoch sind. Das schreckt den Gelegenheitscoder einfach ab. Aber wie der Kölner so schön sagt, „et is, wie et es“ und dahinter noch „Et hätt noch emmer joot jejange“
Das sind doch mal gute Nachrichten!
, professionelle Hardware läuft auch mit Symcon ohne Zusatz-Module.
