Der Weg zu guten FLOSS Tools für meine Solawi

Jo.

Schöner Ansatz @felix mit dem itinic. Verstehe aber nicht weshalb du
nicht eine offenere Technik verwendet hast. Durch die große Vielfalt
unserer Bewegung unterliegen wir natürlich sehr der Gefahr, und das
zeigt sich ja auch immer wieder, dass wir unsere kleinen Daten Silos
schaffen, die die effektive Kollaboration erschweren.

Daher sollten wir auf jeden Fall auf offene Platformen setzen, wenn wir
in das internationale Netzwerken kommen, den inter-organisations
Austausch.

U.A. wird dieses Problem gerade hier diskutiert:

Mit SolidBase machen wir ja auch eine Erhebung von bestehender
Software, und wollen dann unsere Ergebnisse auch gebündelt der
Öffentlichkeit präsentieren, inklusive einem Workshop zu Digital
Skills. Schnell zusammen gesuchte Software Listen sind da eher wenig
behilflich, wir brauchen gut evaluierte Tools, von denen wir wirklich
überzeugt sind, dass sie funktionieren.
Hier gehts allerdings auch vor allem um Dedicated CSA & FoodCoop
Software, den ganzen Bereich zu Community Organisation / FLOSS Online
Collaboration sind wir ja schon gut dabei zusammen zu entwickeln.

Meinst du mit “offen” einfacher zugänglich? Leichter erweiterbar? Ohne login-wall? Das ganze ist wie gesagt nur ein Prototyp gewesen, auch mit der Idee ein Netzwerk zu schaffen, bei dem ich zB als Ökodorf Sieben Linden-Bewohner herausfinden kann, wer z.B. im ZEGG eine ähnliche Technologie einsetzt und dann mit der Person in Kontakt gehen kann (“wie macht ihr…?”). Eine Idee dazu war auch direkt an Nutzerprofile dranzukleben ob man ggfs gegen Energieaustausch z.B. Beratung oder Entwicklung (wiki, php, …) anbieten kann. Die Ökodorf/ Intentional Community-Szene ist da extrem schlecht vernetzt (aber das ändert sich gerade). Und natürlich sollte da keine “schnell zusammengesuchte Software Liste” entstehen, deswegen gibt es ja die zwei Felder bzgl. Qualität und Kenntniss.

Von der Technik und Lizenz ist itinic offen (mit prominenten links zum git repository). Ich finde auch, dass Ruby on Rails-Projekte in der Größe hervorragend einfach erweiterbar sind.

Dann pumpe ich hier eben doch nochmal den Prototypen der Österreicher:

https://tool.kollabor.at

Ich bin mit den Jungs in Kontakt, noch hat das Teil u.a. das Problem dass jeder die Daten von jedem verändern kann. Es ist in dem Sinne “offener” als das es sich eigentlich nur um ein MediaWiki + Semantic handelt. Nett, aber hat natürlich Einschränkungen.

Ich denke dass es bei diesen Tool-Sammlungen schon auch um eine gewisse Zentralität geht (und wenn sich die Idee dann in der Subkultur X umgesetzt hat, könnte es danach ja ruhig noch einen Ableger zum Beispiel für Audio- und Studio-Tools, CSA, DevOps, … geben). Wenn damals mehr “Ohja” Rufe gekommen wären (zB von GEN) wäre itinic vielleicht heute mehr als ein Protoype-Hack und ich hätte die Werbetrommel gerührt.

Ich hoffe jetzt dass Armin und Tobias es schaffen das Feedback aufzunehmen und wir uns dann gemeinsam darauf stürzen können dort Daten zu pflegen.

Die SolidBase-Geschichte klingt super. GEN International hat da wohl auch schon ein bisschen was gemacht (https://ecovillage.org/it-solutions-climate-change/), aber außer der webseite sieht man leider kein Ergebnis-Bericht (bin dran und hab da mal nachgehakt).

Na, ich benutze “offen” als organisationsstrukturelles Paradigma. Bin da ein bischen angefixt von der OpenOrganisation Welle von Jim Whitehurst.

Bezogen auf unseren Zweck meint das wohl v.a. offene Daten Standards und gute Möglichkeiten für Multilingualität.

Ich weiss nicht ob es so gut ist die beiden Ebenen zu vermischen: Das Netzwerk der IT-Verantwortlichen und die Liste der angemessenen Tools.
Den tool.kollabora.at Ansatz finde ich erstmal spannend. Langfristg sollten wir sowas in Richtung privacytools.io anpeilen.

Da wir bei SolidBase ziemlich OldSchool arbeiten, mit nem zu publizierenden Booklet und Workshops und so, braucht das Interface zum Erstellen unserer FeatureMatrix (zum Glück) nicht besonders offenen zu sein im Sinne von öffentlichem Zugang.

@felix, @tantebootsy, @chris, und Fabi, ich hab euch jetzt auch mal die SolidBase Gruppe freigeschaltet.

Hier entwickeln wir die Featurematrix, der für uns besonders interessanten Tools, Wär super wenn ihr das mitdenken würdet, und vielleicht auch mitentwickeln würdet.

https://discourse.solawi.allmende.io/t/the-list-of-auxiliary-tools/89

In dem typischen Ökodorf sinds halt die gleichen Nutzergruppen :wink:

Mit Ruby-On-Rails / itinic wäre es vermutlich recht trivial irgendeine RDF/JSON-Präsentation der Daten zu haben - und auch i18n ist natürlich keine schwarze Magie (das könnte tatsächlich bei wikimedia mit semantic schwieriger sein, aber I dont know). Aber ich hänge nicht an itinic und würde es auch nur weiter-/ neu entwickeln, wenn es dafür Bedarf gibt (und Energieausgleich). Derzeit scheint mir der mediawiki-Ansatz von Tobias und Armin erstmal völlig ausreichend.

Mir waren noch keine Standards bewusst und die Interoperabilität mit irgendwelchen anderen (semantischen) Datenbank war kein Ziel. Scheint mir auch für meinen Nutzungszweck nicht relevant. Ich will nur möglichst schnell sehen wer mit welchem tool für was welche Erfahrungen (und Beurteilungen/Assessment) hat. CSV oder JSON auszuspucken ist vergleichsweise trivial, einen der JSON-schema ansätze zu verfolgen dürfte auch noch machbar sein, aber das sich bewegende semantic-data Ziel zu treffen ist natürlich ne andere Nummer.

Hallo Leute,
ich wollte nur mal kurz meinen Hut in den Ring werfen und ein paar Sätze zu unserem bisherigen Weg loslassen. Wir bei der GartenCoop waren auch von Anfang an darauf bedacht FLOSS Lösungen für unsere Verwaltung einzusetzen.

Anforderung derzeitige Lösung aut/man anvisierte Lösung
Adressverwaltung Mitglieder Jverein manuell
Mailinglisten Mailman manuell/automatisch
Kontrolle der Beiträge Jverein
Buchhaltung GnuCash semiautomatisch GnuCash
Dokumentenverwaltung (analog) Papierordner manuell Papier & digital (scannen)
Dokumentenverwaltung (digital) owncloud autm. Sync Nextcloud
Website (auch intern Drupal 6 (!) Wordpress (für öffentlich)

Das größte Problem, und da wiederhole ich vermutlich viele Vorredner*innen, ist die Integration der verschiedenen Lösungen.

Wenn ein Mitglied beitritt muß unser Büro-Team in 3-4 verschiedenen Systemen Daten anfassen. Das selbe passiert wenn jemand austritt oder die Mailadresse ändert…
Diesen Zustand würden wir gerne abstellen und so viel wie möglich den Mitgliedern selbst überlassen.

ligrü aus Freiburg
Fabian

Hast schon recht. Finde den mediawiki Ansatz auch ganz gut. Mein Link zum indiehosters Github Thread schiesst auch etwas über unser Ziel hinaus.

Willkommen an Bord, @fabzgy!
super, dass ihr von Anfang an auf FLOSS gesetzt habt. Die mangelnde Interoperabilität von den einzelnen Tools ist ja genau das nervige, weshalb die ein oder andere Solawi dann doch zur teuren All - inclusive Variante greift.
Die mir bisher bekannten CSA Solawi tools Junagrico und OpenOlitor sind noch relativ speziell für CSA Varianten geschrieben, um sie allgemeiner Nutzen zu können ist noch einiges an Programmieraufwand nötig, aber zmd. bei OpenOlitor gehts ja gerade ganz gut voran.
Die SolidBase BudgetPlanungs “App” wollen wir vielleicht auf Nextcloud/OnlyOffice Basis basteln. Wäre spannend Nextclouds Fähigkeiten auch in Richtung Mitgliederverwaltung auszuloten. Da kann uns bestimmt @florian.humer wertvolle Tipps geben. Auch dir ein herzliches Willkommen!! :tada:

Wer weiß, vielleicht klappts ja diesmal mit meiner Prototypefund.de einreichung für (m)eine Vereinsverwaltungssoftware … Wir sind da auch noch auf der Suche nach etwas brauchbarem. Hat jemand von Euch schon engeren Kontakt zu JVerein oder GnuCash-Entwicklern?

Magst du dazu Details / Antragstext teilen?

@Mitgliederverwaltung hat mt den von dir anesprochenen Entwicklern schon was zu tun gehabt.

Ich hab den Text von letztem Jahr noch nicht überarbeitet, teile ihn dann gerne hier. Oder wollt ihr ein Fingerchen mit im Spiel haben? Dann können wir ein neues Topic aufmachen. Mir geht es eher um klein-aber-fein Mitgliederverwaltung ohne Buchhaltung - aber die Schnittstelle zu einem gnucash, odoo, nexterp oder so könnte man sich natürlich im Vorfeld ansehen und schon mal in die Richtung luschern. Ein Hintergrund ist auch, dass man später andere Verwaltungsgeschichten die in Gemeinschaften üblich sind mit integrieren könnte. Aber ganz ehrlich - ich glaube nicht dass so ein Töölchen bei prototypefund mitstinken kann; da sind schon ziemlich coole andere Anträge am Start.

Kommt drauf an wie cool die Schnittstellen sind. Eine Ausgefeilte Mitgliederverwaltung als plugin für Nextcloud wär der burner. @florian.humer hatte ja was in die Richtung quasi als Proof of concept geschrieben.

Ich glaube ich habe Beiträge von Sunu-Menschen schon gelesen. Sind auch aktive Entwickler*innen von juntagrico.org hier am mitlesen?

jo, @juntagrico ist grad gelandet. Herzlich willkommen! Hab für dich extra nen thread aufgemacht: https://discourse.solawi.allmende.io/t/juntagrico/198

1 Like

hallo

wieso verwendet ihr nicht openldap zur provisionierung der verschiedenen systeme?

da juntagrico mit django läuft gibt es etliche anbieter die einen sync nbieten zwischen ldap und django

sprich die mitglieder melden sich via juntagrico an und können da (zum teil*) ihre daten anpassen und von da wird das dann ins openldap gespeisst und und von da in die anderen systeme

  • zum teil weil benutzer email name und vorname nicht selber anpassen können weil es da probleme mit genossenschafts anteilscheinen gab, aber die admin kann das im juntagrico/django admin gui machen und dann wird das gesynched

Wir nutzen beide tools aber haben da keinen direkten Kontakt zu den Entwicklern aufgebaut.
Für mich ist die Buchhaltung (über GnusCash) ziemlich unabhängig von der restlichen Vereinsverwaltung.

In den ersten Jahren haben wir die Rechnungsprüfung über GnuCash gemacht aber das bedeutet, dass wir alle Mitglieder dort erfassen mussten. Das ist für die Buchhaltung aber nicht wirklicht relevant denn dort ist nur wichtig in welcher Höhe Mitgliedsbeiträge bzw. Abo-Zahlungen eingegangen sind. Das Controlling, ob auch alle bezahlt haben, interessiert das Finanzamt am Ende überhaupt nicht.

Wir haben das also getrennt. In JVerein werden die Mitgliederdaten gepflegt und überprüft ob alle Beiträge eingegangen sind. In GnuCash machen wir wirklich nur die reine Buchhaltung für unseren Jahresabschluss. DIese Trennung halte ich auch für sinnvoll und würde sie beibehalten.

LDAP ist eine großartige Idee - ich bin nicht der technisch versierteste aber es klingt zumindest mal vielversprechend. Ich würde mich gerne über Arbeitsszenarios / Work Flows an die gute FLOSS Lösung herantasten:

Bsplsw:
Szenario 1: Neues Mitglied wird erfasst
Szenario 2: Mitglied wechselt den Verteilpunkt / das DEpot
Szenario 3: Mitglied hat eine neue E-Mail Adresse
Szenario 4: Verwaltung möchte überprüfen wer mit seinen Zahlungen im Rückstand ist
Szenario 5: Mitglied würde gerne einer Arbeitsgruppe beitreten

Ich trete mal mit unserem Büro Team in Kontakt und versuche eine entsprechende Liste zu vervollständigen.

Wir haben im Laufe des letzten Jahres Max aus Berlin getroffen, der ebenfalls an einer Vereinssoftware arbeitet, mit besonderem Fokus auf Buchhaltung. Wenn du Interesse hast, kann ich euch in Verbindung bringen!

Danke, ganz unbedingt!

Ein fork von odoo für non-profit Organisationen wäre ja auch mal was feines! Kennst du / sonst jemand wen bei denen das im Einsatz ist?

Hast du dir schon Galette angeschaut, @felix? Was hältst du davon?

1 Like