Entwicklungsförderung

[eghetto]

Muss man da als Projekt-Admin etwas machen? Oder können dort die Förderer und die potentiellen Programmierer alles unter sich ausmachen?

Nach meinem Kenntnisstand ist es stark community-getrieben. Die Aufgaben eines Admins sind hier näher erläutert:
https://www.bountysource.com/faq#i-m...in-all-of-this

Und da das wohl eine amerikanische Seite ist: gibt's da schon Erfahrungen wenn beide Parteien in Europa sitzen?

Es dürfte egal sein, wo jemand sitzt. Die Einzahlungen laufen primär über PayPal, Google Wallet oder Bitcoins. Die Auszahlung funktioniert über:

• PayPal
• Bitcoin
• Ripple
• Mastercoin
• Check

Sobald die Auszahlung der Prämie vom Programmierer aus seinem Account angefordert wird, kassiert Bountysource 10% davon.

[makki]

Da muss ich zu einem Punkt jetzt doch meine 2ct dazu geben:

Wenn sich die CometVisu nicht ständig auf das WireGate als Referenzplattform versteift hätte wäre der Stand sicherlich ein anderer. Spezielles backend

Das backend im eibd war & ist vom ersten Augenblick an auch GPL. Nachzulesen auf der bcusdk-devel Mailings-liste.
Dafür das es seinerzeit nicht "upstream" in den eibd kam, naja, lange Geschichte, konnte irgendwie keiner was.

Aus den verfügbaren Source-Paketen kann man - bis heute - das ganze problemlos für i386/64/MIPS/armel bauen.
Das haben auch viele gemacht, sonst gäbe es wohl keinen CometVisu-Nutzer mit RPi..
Nur vielleicht diese Informationen nicht weitergegeben?

Also, ran an die Buletten: im knxd ist es drin!
Ob der Code "schlecht" ist oder nicht mögen andere beurteilen, funktioniert aber seit ein paar Jahren doch recht gut

und gepatchte rrd-Tools tragen eben nicht dazu bei neue Entwickler ohne WireGate zu gewinnen.

Auch das war eine Notwendigkeit, um kurzfristig eine akzeptable Performance zu erreichen, damit man nicht vom User ausgelacht wird!
Und auch das hat - nach Jahren! Einzug ins rrdtool gefunden (in kaum veränderter Form übrigens..), aber darauf wollte ich damals eben nicht zu ungunsten der täglichen Visu verzichten und 3J warten, bis es als sinnvoll angesehen wird..

Das ich diesen Missstand schon lange kritisiere ist dem geneigten Leser bekannt,

Mit Verlaub: wo sind die eMails, die eine Integration dieser - wie ich meine bis heute guten - Techniken bei den Maintainern/Autoren fordern ?

Nicht jammern, machen

Eine Öffnung des Backends ist sicherlich sehr schwierig,

Verstehe ich nicht! Was ist daran schwierig oder zu öffnen?
ChrisM (primär) und ich haben uns damals wirklich sehr, sehr viele Gedanken gemacht, versucht das bekannte zu bedenken, ausgetestet, optimiert etc.pp.
Wir sprechen da sicherlich über Mannwochen, nicht Manntage. Ist übrigens alles hier nachzulesen.

Makki

Edit/P.S.: Auslöser dieser Threads war, das zuviele Limits eingebaut sind (was ich aus heutiger Sicht auch übertrieben finde) um jeglichen Buffer-overflow etc. zu vermeiden, weil bei 800-1000 GA's - in einer einzigen Visu!! Schluss ist. (was sich einfach beheben lässt)

[ctr]

Aus den verfügbaren Source-Paketen kann man - bis heute - das ganze problemlos für i386/64/MIPS/armel bauen.
Das haben auch viele gemacht, sonst gäbe es wohl keinen CometVisu-Nutzer mit RPi..
Nur vielleicht diese Informationen nicht weitergegeben?

Da muss ich mal meine 2cents dazugeben.
Siehe: https://sourceforge.net/p/openautoma...eibd/examples/
(seit 1,5 Jahren)

Wenn hier im Forum entsprechende Fragen aufkommen zeige ich auch immer dahin.

Zum Thema Weiterentwicklung des Backends müssten auch mal konkrete Ziele gesetzt werden, ich hatte verschiedentlich schon angesprochen, dass ich da was machen würde (z.B. hier https://knx-user-forum.de/454139-post22.html ), aber Feedback gab es auch nie. Ohne Anforderungen, eine konkrete Zielsetzung oder massive Probleme mit der bisherigen Lösungen mach ich mir die Mühe nicht just 4 fun...

[makki]

@ctr: nur in kurz, denn das gehört eigentlich nicht hier her:

Der Grund dafür war einzig und allein der komplette Stillstand beim bcusdk/eibd + dem Anwender ohne WG (was mir ja immernoch vorgeworfen wird, das es nicht ohne geht..) eine Lösung zu bieten.

Ich denke auch wir werden das mittelfristig aus dem repo dort entfernen, weiter geht es damit jetzt hier:
https://knx-user-forum.de/knx-eib-fo...fork-knxd.html
https://github.com/Makki1/knxd

Makki

[JuMi2006]

Aus den verfügbaren Source-Paketen kann man - bis heute - das ganze problemlos für i386/64/MIPS/armel bauen.
Das haben auch viele gemacht, sonst gäbe es wohl keinen CometVisu-Nutzer mit RPi..
Nur vielleicht diese Informationen nicht weitergegeben?

Teilweise erledigt 03/2013:
Open Automation / Code / [r2352] /tools/arm-deb

Auch das war eine Notwendigkeit, um kurzfristig eine akzeptable Performance zu erreichen, damit man nicht vom User ausgelacht wird!
Und auch das hat - nach Jahren! Einzug ins rrdtool gefunden (in kaum veränderter Form übrigens..), aber darauf wollte ich damals eben nicht zu ungunsten der täglichen Visu verzichten und 3J warten, bis es als sinnvoll angesehen wird.

Teilweise erledigt 03/2013:
Open Automation / Code / [r2352] /tools/arm-deb

https://knx-user-forum.de/315884-post41.html
Das sich Dinge davon nicht mehr in Wikis wiederfinden ist nun aber auch nicht meine Schuld.

https://knx-user-forum.de/cometvisu/...h-rrdtool.html

https://knx-user-forum.de/cometvisu/...allscript.html

Mit Verlaub: wo sind die eMails, die eine Integration dieser - wie ich meine bis heute guten - Techniken bei den Maintainern/Autoren fordern ?

Nicht jammern, machen

Also emails an die Autoren von eibd und rrdtool hab ich nicht geschrieben, das stimmt.

Mirko

Verstehe ich nicht! Was ist daran schwierig oder zu öffnen?
ChrisM (primär) und ich haben uns damals wirklich sehr, sehr viele Gedanken gemacht, versucht das bekannte zu bedenken, ausgetestet, optimiert etc.pp.
Wir sprechen da sicherlich über Mannwochen, nicht Manntage. Ist übrigens alles hier nachzulesen.

Makki

Hast Du mal versucht in 2013 auf einem aktuellen System ohne Build-Umgebung die CometVisu zu installieren? Ich habs hinbekommen, die Einstiegshürde ist aber wesentlich größer als über ein vernünftiges Paket. Wozu ich mich im übrigen auch angeboten hatte.

https://knx-user-forum.de/344415-post26.html

Also mangelnde Beteiligung lass ich mir in diesem Falle nicht vorwerfen. Aber wie sauer Bier muss ich mich auch nicht anbieten.

[ctr]

@ctr: nur in kurz, denn das gehört eigentlich nicht hier her:

Der Grund dafür war einzig und allein der komplette Stillstand beim bcusdk/eibd + dem Anwender ohne WG (was mir ja immernoch vorgeworfen wird, das es nicht ohne geht..) eine Lösung zu bieten.

Ich denke auch wir werden das mittelfristig aus dem repo dort entfernen, weiter geht es damit jetzt hier:
https://knx-user-forum.de/knx-eib-fo...fork-knxd.html
https://github.com/Makki1/knxd

Makki

Das war keine Kritik am derzeitigen Stand, sondern der Beleg dafür, dass die Information entgegen Deiner Behauptung "Nur vielleicht diese Informationen nicht weitergegeben?" sehr wohl weitergegeben wurde.

[makki]

Also mangelnde Beteiligung lass ich mir in diesem Falle nicht vorwerfen. Aber wie sauer Bier muss ich mich auch nicht anbieten.

Ach menno, darum gehts doch garnicht.

Ich weiss natürlich, das es Anleitungen gibt, nur können - zurecht! - 99% der Bevölkerung mit dem ganzen auto*-Kram nichts anfangen.
Ausserdem verlieren sich diese Informationen im Forum..

Habe selbst mehrfach versucht, eibd(jetzt bitte knxd) z.B. in OpenWRT zu schicken (Debian war wegen pthsem nie eine Option) - gescheitert.
Othmar hats jetzt geschafft.

Um jetzt die Kurve zum Topic wieder zu bekommen:
Aber man kann nicht alles gleichzeitig machen: Entwicklung, Promotion, brauchbare Pakete, Doku.
Daher braucht es dafür mehrere, GitHub bietet dafür die Plattform, ich bin mir sicher Chris sieht das genauso.

Makki

[makki]

Das war keine Kritik am derzeitigen Stand, sondern der Beleg dafür, dass die Information entgegen Deiner Behauptung "Nur vielleicht diese Informationen nicht weitergegeben?" sehr wohl weitergegeben wurde.

Na dann kann man jetzt ja iSv Entwicklungsförderung voll loslegen!
Tests auf verschiedenen Plattformen, Pakete, Doku: alles ist gefragt..

Makki

[Linuxer]

Bevor sich hier alle bekriegen auch meine 2ct dazu:

Ich finde die CV richtig gut und bin sehr froh darüber, dass es sie in der Form (open source) gibt.

Danke, Danke, Danke.

Was das Auffinden der Informationen betrifft, kann ich nur zustimmen, weil alles im Forum zu finden ist, aber fast immer irgendwo versteckt. Ich kann und möchte aber von den Entwicklern nicht verlangen, dass dies besser wird, weil sie ihre Zeit bereits in die Entwicklung stecken.
Alle machen dies hier in ihrer Freizeit und freiwillig. Darauf finde ich muss man Rücksicht nehmen.
Ich finde manchmal die einfachsten Informotionen nicht sofort (z.B: Unter welcher Adresse finde ich nochmal die WG-Plugins? (wenn jetzt auch nicht CV)). Aber diesen Schuh ziehe ich mir auch an, weil ich könnte, wie jeder andere auch z.B. einen Lexikoneintrag machen.

Ich persönlich bin gerne bereit die CV finanziell zu unterstüzen, weil mir selber häufig die Zeit Mitarbeit fehlt.

Bitte macht in dieser guten Qualität weiter, besonders mit dem Augenmerk auf offende Standards, wie es bereits jetzt passiert.

Viele Grüße,
Linuxer

[Gringo885]

Hui was ist denn hier los??? Da liest man mal ne Woche oder zwei nicht mit und schon ist der Ton zumindest gefühlt sehr rau ....

Also ich muss auch sagen ich bin für die CV sehr sehr dankbar. Ich hätte sonst irgend eine Visu Lösung kaufen müssen, für sicherlich 500+€ und wenn ich ehrlich bin wirklich entscheiden könnte ich mich da im Moment nicht ... Also macht bitte weite ...

Ich persönlich kann leider mangels Fähigkeiten und Stress in der Uni nicht am Code oder an tieferen Dingen mitarbeiten:

Das Entwickler fehlen die sich damit intensiv beschäftigen stimmt bestimmt. Das es teilweise nicht einfach ist den Überblick zu behalten aber auch. Ich muss sagen die SVN Version in ihrer aktuellen Fassung hat sich schon wieder so weit entwickelt das ich echt gucken muss, bzw. teils Schwierigkeiten habe alle Funktionen im Blick zu behalten. Viel Suchen im Forum gehört meist dazu was durchaus recht anstrengend sein kann. ..

Ein Vorschlag zur Güte:

Ziel: CV Version 1.0 (wenn ich das Recht im Kopf habe waren irgendwelche 3D Funktionen da für ChrisM mal wichtig für, evtl lässt sich das aber verhandeln. )
Version 1.0 dann mit einer definierten Menge an Funktionen und Fähigkeiten, mit fertigen Installationspaketen inkl. Anleitungen für viele Systeme und inkl. einer mglst. vollständigen Doku.
Ich weiss das ist nen Hammer an Arbeit, aber man sollte ein Ziel haben

Vorgehen bzw Meilensteine.
1. Festlegen der Funktionen und To Do's
Was hier alles nötig ist weiß ich nicht aber es gibt Bestimmt genug Baustellen die fertig werden müssen, neue Dinge sollten dann nur mit Vorsicht noch begonnen werden bzw nur dazu wenn sie für das "runde" Paket notwendig sind.

2. Abschätzen von benötigten Ressourcen.
Es gibt viele Leute darunter auch ich die die die CV echt gerne nutzen aber die leider bei den recht versierten Disskussionen hier abgehängt werden. Ist einfach nicht mein Fachbereich. vlt gibt es aber trotzdem Dinge bei denen wir auch helfen können. Hier ist einfach die Übersicht das wichtige....
Vlt macht es auch Sinn die Aufgaben in Kategorien einzuteilen, damit jeder dann Abschätzen kann ob er sich so etwas zutraut.
Dann können wir gucken was wir im Forum zusammen bekommen und wo wir engpässe haben ( ich rate mal vermutlich bei Programmierern)
Für diese Engpässen müssen wir dann externe Ressourcen bemühen, aber wenn man es abschätzen kann denke ich bekommen wir durchaus über Crowdfunding in welcher Form auch immer die Sachen zusammen. Wenn am Ende für alle eine super Verson 1.0 rauskommt sind da glaube ich viele motiviert. Wenn jetzt natürlich 100k€ auf der benötigt Liste stehen wäre ich etwas skeptisch.

3. Realisieren ^^.

So vlt. ist das ja nen Weg wie man die Sache vernünftig geregelt bekommt. Die CV hat da echt Potential würde mich sehr ärgern wenn das alles nicht genutzt wird.

Gruß

Gringo

[derBert]

Auch die umgekehrte Fragestellung wäre in dem Zusammenhang interessant:
- Wieviele Leute setzen derzeit die Cometvisu ein?
- Wieviele würden es zusätzlich tun? Bei welchen Features?
- Zielgruppe? Freaks? techn. Versierte? Laien/Normalos?
- Was wäre denen die Software wert?

[swiss]

Hmmm... Für mich klingt die Fragestellung zu pesimistisch. Solche Fragen stellen Manager die damit Geld verdienen wollen. Das passt aber nicht ganz zu OpenSource.

Wieviele die CV zurzeit einsetzen kann ich nicht beurteilen. Dazu gibt es keinerlei Statistik von der ich wüste. (Ist aber auch nicht sooo wichtig denn die Entwikler nutzen selber die CV und durch ihre eigenen Verbesserungen die sie teilen profitieren alle die die CometVisu auch einsetzen)...

Die Zielgruppe sollten natürlich die Normalos und Laien sein. Aber das grosse Problem bei ist, dass bei der schnell voranschreitenden Entwiklung diejenigen etwas auf der Strecke bleiben die nicht immer aktiv voll dabei sind. Das Problem ist schlicht und einfach dass es fast nicht möglich ist so schnell mit der Doku auf Änderungen der Entwikler zu reagieren dass mit der Zeit etwas der Antrieb fehlt da immer auf Stand zu sein. Ich helfe gerne wo ich kann aber momentan ist ein aktuelle endbenutzertaugliches Hanbuch für die CV zu schreiben etwa wie der Versuch als einzelperson jeden Tag eine komplette Zeitung mit allen News herauszubringen... Was ich heute schreibe kann morgen schon wieder Makulatur sein. Das frustriert mit der Zeit etwas. Dazu kommt dass ich genau so in meiner begrenzten Freizet nebenbei daran arbeite wie die Entwikler vor deren Leistung ich grössten Respekt habe.

Hier finde ich den Vorschlag mal wirklich auf eine Version 1.0 hin zu arbeiten sinnvoll. Das bedeutet dann dass es für einige Zeit weder neue Funktionen noch irgend welche grossen Syntaxumstellungen gibt sondern möglichst alle offenen Baustellen mal geschlossen werden. Da lohnt es sich dann auch wieder dafür eine Handbuch zu verfassen das den Stand der Entwicklung entspricht. Es wird aber wohl nie so sein, dass die Dokumentation zu jeder Zeit dem Stand der Entwicklung folgen kann. Erst recht nicht consumertauglich da dort viel mehr Dokuaufwand betrieben werden muss als für Entwickler die schon mit Einzeilern zufrieden sind...

Auf die Frage was denen die Software wert wäre ist auch nicht leicht zu beantworten da es ja nicht darum get mit der CometVisu Geld zu verdienen... Es wäre also eher die Frage ob und wiviel die Leute freiwillig spenden würden um die Entwicklung weiter voran zu treiben und da hätten sich schon einige (meine wehnigkeit eingeschlossen) dazu bereit erklärt. Das hat aber nichts damit zutun wiviel geld man den Leuten ausreissen müsste damit bei der CV was passiert. Das wäre der absolut falsche Ansatz. Ich spende gerne für eine gute Sache aber ich möchte ungern dazu genötigt werden in der Form..."Wenn du die Funktion XY haben möchtest musst du 500.- Euro hinblättern".

Von daher finde ich den Ansatz von Gringo schon recht gut und er kann uns helfen die CometVisu noch weiter zu bringen

[Chris M.]

Die Zahl der real betriebenen CometVisus würde mich auch interessieren - diese Zahl wird sich aber nicht bestimmen lassen(*).

Zur Versionsnummer 1.0:
Versionsnummern, sind Nummern. Das Peano-Axiom #2 garantiert uns sogar, das es nach einer Nummer eine darauf folgende, größere Nummer gibt. Es ist also nichts besonderes an einer 1.0 - außer einer selbst gewählten Zahlenmystik.

Für mich bedeutet eine 1.0, dass es Feature Complete ist. Dazu gehören für mich die 3D-Seiten, die mangels Kappa aber erst mal hinten angestellt sind...

Die aktuelle 0.8.x sehe ich übrigens schon als sehr stabil an. So dass sich da das Handbuch durchaus "rentiert".

Der interne(!) Bruch, den ich wg. Performance aktuell im Kopf habe ändert etwas an der Code-Struktur - aber nicht an der Config.
Wegen der möglichen, größeren Änderung, überlege ich mir, ob die Version, die auf diesen Änderungen basiert, als 0.9.x veröffentlicht werden sollte. (Hintergrund: Für Custom-Widgets wird diese Änderung vermutlich nicht mehr abwärtskompatibel sein. Für die Config sollte es aber egal sein).

Übrigens, Frage: was kommt nach 0.9?
(Antwort: natürlich eine 0.10.x - so lange die 3D-Seiten nicht da sind )

=> Sucht lieber Punkte, die die Leute interessieren als was eine 1.0 "fertig" machen würde.
(Gut, wer die 3D Seiten fertig machen möchte: gerne!)

Ich sehe als Hauptpunkte:

• Editor nutzerfreundlicher machen
• weitere, sexy Designs (<- muss man nicht programmieren können; wer da was macht kann sich am schnellsten und leichtesten den meisten Respekt der User holen...)
• Performance optimieren, insb. bei großen Configs
• Weitere Widgets und Plugins
• Doku, Homepage, Werbung, ... je nach Bedarf aufhübschen, erweitern, erstellen, ... (<- muss man auch nicht programmieren können; kann aber weitere Entwickler anziehen und so indirekt die anderen Punkte hier fördern)

Parallel dazu:

• Mehr Backends, bzw. bestehenden Systemen das CometVisu-Protokoll beibringen!
  • SmartHome.py
  • MisterHouse
  • FHEM
  • ...
  • Bestehendes um weitere Datenquellen erweitern
  • GrAF
  
  

--
(*) Wenn ich es unbedingt wissen wollte, könnte ich natürlich einen Web-Bug o.ä. einbauen. Damit würde ich aber nichts über der Bestand wissen - und hätte das Vertrauen der Anwender missbraucht. Etwas das gar nicht geht. Und folglich wir nie herausfinden können werden, wie viele Installationen im Betrieb sind...

[derBert]

@swiss: Du hast schon recht, dass das ein bischen wie Bill Gates im Vorstands-Meeting klingt.

Die hier diskutierte Frage, wie hoch Entwicklungskosten sind, macht doch aber nur Sinn, wenn man auch eine Einschätzung hat, wieviel man von der Zielgruppe "einsammeln" kann (ob nun via Preistag, Spende oder Crowdfunding sei mal dahin gestellt).

Mein Eindruck ist zudem, dass genau die mangelnde konkrete Ziel(gruppen)formulierung einiges ausbremst.

Du schreibst die Zielgruppe sollten natürlich die Laien sein. Wirklich? Echter Laie ist für mich mein Apotheker-Nachbar der I-Phone-Apps bedienen kann. Er weiss nicht, was ein Verzeichnisbaum ist, oder Logfiles und kann schon gar nicht selbst html/php/pearl/xml etc. schreiben. Er weiss aber auch nicht, was eine Gruppenadresse ist. Sind die wirklich die (dann zunächst mal riesige)Zielgruppe?

Ich würde eher die technisch Interessierten sehen. Wissen grundsätzlich, was ein Logfile ist, nutzen selbst die ETS, haben eine gewisse Leidensfähigkeit. Aber dann teilt es sich sehr schnell: Müssen die XML/html/pearl können? Sollen die selbst Dateien in Unterverzeichnissen herumkopieren und Fehler in Logfiles finden? Müssen die selbst Ihr Linux installieren und warten können? Das sind (entgegen wie ich glaube der Wahrnehmung vieler Freaks hier) nur ein Bruchteil der vorgenannten.

Ich glaube dass der Verbreitungserfolg der CV stark davon abhängt, sich darüber klar zu werden, wer denn die Zielgruppe ist und was man für diese konkret braucht (WYSIWYG statt xml-Zeilen schreiben? Installer-/Update-Konfigurationsmenus statt manuelles Anlegen und Herumkopieren von Datein und Verzeichnissen? etc...).

@ChrisM: "Sucht lieber Punkte, die die Leute interessieren":
Vorschlag: Eine Umfrage hier im Forum bei denen, die die CV derzeit _nicht_ nutzen, wieso dies so ist.
- fehlender WYSIWYG-Editor
- mangels passender Hardware?
- Software unbekannt
- gefühlt zuviel Aufwand / zu hohe Einstiegshürde?
- fehlende zentrale, übersichtliche Stelle, wo man alle Infos findet: Software, Installationsanleitung mit Schnelleinstieg und eine ausführliche Doku.
- zuwenig Features?
- schlechtes Design?
-...

Ich weiss, klingt wieder wie der BWLer, aber wie es ein Kollege mal so schön formulierte: "Es nutzt nichts, schnell zu laufen, wenn es in die falsche Richtung ist."

Gerne würde ich mich selbst mehr in dieses wirklich tolle Projekt einbringen. Allein, ich fürchte, dass ich im gegenwärtigen Stand technisch keine Hilfe bin. Aber vielleicht ja mit so grundlegenden Überlegungen und konstruktivem Feedback etwas beitragen kann.

[mfd]

Ich würde mich bereit erklären soweit es mir zeitlich und von meinen Fähigkeiten möglich ist, am "Grafikteil" der Entwicklung mitzuwirken.
Ein Stundenlohn fällt dafür nicht an.