Regis­ter­me­thode 2.0 – Einige Über­le­gungen zur syndi­ka­lis­ti­schen Kampf­taktik.

Hat dir gefallen? Dann teile diesen Beitrag.

Disclaimer vorneweg: Ich bin kein Program­mierer und habe bis heute nicht eine Zeile code selbst geschrieben, weshalb einige Gedan­ken­gänge nie umsetzbar wären.

Ich habe nachge­dacht. Mal wieder. Seid ein paar Tagen lässt mich die Idee einer techni­schen Aktua­li­sierung des Syndi­ka­lismus nicht mehr locker. Bzw. einer konkreten Taktik des Syndi­ka­lismus: Das Lohn- und Arbeits­re­gister.

Unter der sogenannten Regis­ter­me­thode wurde die lokale Erfassung aller Arbeits­re­le­vanten Daten innerhalb der an die Arbeits­börse angeschlos­senen Organi­sa­tionen verstanden. Damals wurde das i.d. Regel durch noch vorhandene Systeme der Haus- und Straßen­kas­sierung wöchentlich beim sogenannten Arbeits­nachweis gemacht. Jedes Mitglied der lokalis­ti­schen Gewerk­schaften war demnach wöchentlich gezwungen, seine aktuelle Arbeits­si­tuation gegen­über der Gewerk­schaft offen zu legen. Dies erfolgte gleich­zeitig mit der Kassierung der wöchent­lichen Mitglieds­bei­träge und Aushän­digung der Gewerk­schafts­zeitung. Über diese Art der Abfrage war der Gewerk­schaft ein wichtiges Instrument ihrer Arbeit gegeben: Sie wusste zu jedem Wochen­turnus den Kranken­stand in der Organi­sation, wie viel Stunden die Mitglieder gearbeitet haben, zu welchen Löhnen, wo Mitglieder im Streik sich befanden, wo Mitglieder entlassen wurden, wo Hilfs­zah­lungen notwendig waren und natürlich auch wo Verbes­se­rungen der Löhne im Bereich des möglichen waren. (Kurze Anmerkung, damals war eine Gewerk­schaft zumeist für einen Beruf vorhanden, die Gliederung in Branchen­ge­werk­schaften erfolgte erst nach dem 1. Weltkrieg, wo die Regis­ter­me­thode zumeist nicht mehr zur Anwendung kam).

Da die Gewerk­schaft eine Über­sicht hatte, wie die Stunden­löhne in einem Beruf in einem Lokalen Rahmen waren, konnten sie lokal für sich Lohnun­ter­grenzen praktisch festlegen, in dem beschlossen wurde, dass Mitgliedern verboten wurde, unter einem Bestimmten Lohn zu arbeiten. Wer es dennoch machte, hatte mit Diszi­pli­nar­ver­fahren zu rechnen, aller­dings waren die Hilfs­kassen auch so organi­siert, dass dies i.d.Regel nicht notwendig wurde. So konnten auch Verhand­lungen nach zeitlich begrenzten Tarif­ver­trägen umgangen werden, da sie durch direkte Ökono­mische Aktion nicht mehr notwendig wurden. (Beispiele sind hierfür die Fliesen­leger in Düsseldorf, oder die Textil­ar­beiter in Teilen Sachsens.) Als Erwei­terung des Registers war in vielen Arbeits­börsen auch ein Stellen­re­gister angeschlossen, das Genossen in Jobs verhalf, gerade in Zeiten der Schwarzen Listen (Nicht-Einstel­lungs­listen der Betriebe!) ein wichtiges Unter­stüt­zungs­werkzeug.

Heute wäre so etwas technisch wesentlich einfacher möglich und könnte Helfen, das (Stunden-)Lohnge­fälle von Freibe­rufler, Freelancer und anderen Schein­selbst­stän­digen zu minimieren.

Was ist dafür zu tun? Nun es gibt zwei für mich sehr wichtige Anfor­de­rungen an das System:
1. Es muss dezentral organi­siert sein
2. Es muss belastbar sein

Zu Punkt 1) Die Dezen­trale Organi­sierung hat folgenden Grund: $Struk­turen sind korrum­pierbar. Wenn das System nur auf einem Server liegt, kann es aus $Gründen abgeschaltet werden, oder noch schlimmer ab geschnor­chelt werden. Ich bin zwar dafür, die Daten anony­mi­siert als Open Data zu betreiben, aber dagegen Zentral­systeme zu betreiben. Repression ist nur das eine, auch Distri­bution. Wenn z.B. der Deutsche Gewerk­schaftsbund diese Idee gut findet, eine Instanz aufbaut und viele (TM) Menschen mitmachen, der DGB aber eines Tages beschließt, dieses System behindert seine Existenz, dann darf das System selbst nicht abschaltbar sein. Gerade aus dem Bereich Peer-2-Peer kennt die Netzge­meinde schon verteilte System und Daten­banken, auch hier müsste ein solches zum Tragen kommen. Am besten über Verifi­zierung in einem Trustnetz*. Eine der Schlimmsten Abhän­gig­keiten der Arbei­ter­be­we­gungen entstanden, als sie die Sozial­systeme – welche vorher selbst organi­siert waren (und durchaus Ineffi­zienz aufwiesen) – in staat­liche Hand über­eignet wurden.

Zu Punkt 2) Wenn das System wächst und an Brisanz zunimmt, dann wird es aus verschie­denen Bereichen beschossen werden, nicht nur von Anons, die meinen das Selbst­be­stim­mungs­recht wäre gefährdet (auch deshalb ist ein dezen­trales System notwendig), sondern auch Kapita­listen die die Dienst­leistung “Daten­ma­ni­pu­lation” als Geschäftsfeld entdecken werden (nicht so schlimm wie die Histo­rische Parallele Pisto­leros, aber genauso zerschießend!). Also muss es möglich sein, jeden Angestellten zu verifi­zieren, das kann über die Steuer­nummer sein, das kann aber auch ander­weitig z.B. über ein Trustnetz* möglich sein. Auch muss das System es aushalten sowohl 10k Leute als auch 10Mio Leute sich selbst organi­sieren zu lassen. Eine Verifi­zierung ist zwingend erfor­derlich, da der größte Schaden des Systems wäre, wenn seine Glaub­wür­digkeit, die Belast­barkeit der Daten selbst angegriffen werden kann.

Was stelle ich mir also vor (wenn es denn möglich ist):
Als Endan­wender habe ich mich am Anfang an einer noch nicht näher zu benen­nenden Stelle verifi­ziert, dass ich ich bin. Dann erhalte ich ein Client oder ein Dashboard, in dem ich meine Steuer­daten und ähnliches eingeben kann (Maschi­nen­les­barkeit herstellen!), auch die eigenen Vertrags­be­din­gungen als Angestellter (z.B. Festlegung der Arbeits­zeiten, Über­stun­den­re­ge­lungen etc.) sollten hinter­legbar sein. Für Freelancer natürlich das gleiche mit Werks­ver­trags­daten oder andere Vertrags­daten, die die Bedin­gungen festschreiben.
Wichtig wird jetzt natürlich eine Maske in der die geleistete Arbeitszeit eintragbar ist, sowie Pausen­zeiten, Stück­zahlen (Produ­zie­rendes Gewerbe), ect.pp.
Im Hinter­grund läuft der Abgleich bzw. Vergleich dieser Daten mit den anderen im System gemit­telten Daten. Wenn es bereits Verein­ba­rungen gibt, wie z.B. die Über­stunden geregelt sind, und man diese verletzt muss dem Endan­wender sowie der eventuell vorhan­denen Gewerk­schaft dies anzeigbar sein (Alert vielleicht?). Hier kann dann inter­ve­niert werden.
Die Daten werden im besten Falle via einem Peer-2-Peer Ansatz ausge­tauscht, am besten noch erweitert um einen Mesh-Ansatz, damit die Daten nicht zensierbar sind. Die Software muss API´s bieten, die offen und nachvoll­ziehbar ist, damit weitere Entwick­lungen program­mierbar sind. Über­haupt ist eine Grundlage der Software offener Quellcode und freie Lizenzen.

Ich hoffe die Ideenskizze war jetzt nicht zu wirr und ich bekomme Feedback zu den Ideen, Diskus­sionen bitte in den Kommen­taren oder auf Twitter @syndi­ka­lista.

*Trustnetz: Zunehmend geht die Zerti­fi­zierung für Webseiten weg von Zentralin­stanzen, die Zerti­ficate signen hin zu Trust­netzen, die sich gegen­seitig bestä­tigen “echt” zu sein.

2 Gedanken zu “Regis­ter­me­thode 2.0 – Einige Über­le­gungen zur syndi­ka­lis­ti­schen Kampf­taktik.

  1. aus technischer Sicht ist das sicherlich möglich, allerdings bin ich nicht sicher, ob das Konzept funktionieren würde.

    Wenn ich dich richtig verstehe ist das Hauptziel, Arbeitsbedingungen und v.a. Löhne vergleichen zu können. Also z.B. 1000 Menschen tragen sich ein, davon haben z.B. 30 Menschen einen ähnlichen Job und die bekommen dann eine Ansicht die ihnen den Vergleich des eigenen Lohns zu dem der anderen 29 anzeigt.

    Welche Daten sind nötig um Löhne vergleichen zu können? Branche, Ausbildung, Aufgabe, Überstundenregelung, Urlaubstage, Sonderzahlungen, …? Wenn das nur als Text festgehalten wird, ist es nicht machinell vergleichbar. Wenn es machinell vergleichbar sein soll, müssen Kategorien (zur Auswahl von den Benutzenden) und Formeln (in der Software zum Vergleich von z.B. 2 Urlaubstage mehr dafür 2 unbezahlte Überstunden pro…) her.

    Warum sollte Arbeitszeit gespeichert werden? Warum die Stückzahlen? Willst du Lohn nach Leistung vergleichen?

    Ein weiteres Problem ist IMO die Aktualität der Daten. Die Benutzer_innen sollten jedes Halbe Jahr ihre Daten aktualisieren, sonst wird mit historischen Werten verglichen und die Glaubwürdigkeit des System sinkt. Die Frage ist also, ob sich innerhalb eines halben Jahres genug Menschen mit vergleichbaren Voraussetzungen eintragen.

  2. Eine Sache, die man sich da angucken könnte, ist XMPP, das Protokoll hinter Jabber, Google Talk etc. Das ist nicht dezentral, sondern serverbasiert und mir ist nicht ganz klar, inwieweit man da offline-Daten haben kann — für den Fall, dass Server verschwindet, warum auch immer. Es ist aber immerhin frei und funktional, also etwas, womit man in diesem Moment arbeiten könnte. ZB Gewerkschaftsserver, ArbeiterInnen haben ein Konto auf der Ebene der Nutzerkonten bei Jabber. Daten landen von den einzelnen Peers auf dem Server, der macht damit was immer er tun soll.

    Cooler, dezentral und noch im Entstehen ist Freedombox. Die Boxen sollen mal wie Router + x funktionieren, mit der Möglichkeit, direkt auf deinem Gerät alles zur Netzkommunikation bereitzustellen, also Infrastruktur von Dritten zu meiden. Bestandteil davon ist FreedomBuddy, das eines Tages dafür sorgen soll, dass sich über das Zusammenspiel von Freedombox und Tor-Netzwerk (du hast einen Tor-Service dafür auf der Box laufen) Peers finden und dann in direkte Kommunikation treten können. Ich stelle mir das vereinfacht wie eine moderne Form der dyndns-Services vor, über die man eine dynamische IP wiederfindet, falls du die kennst. Ein paar Infos gibts es unter https://gitorious.org/freedombuddy/freedombuddy/blobs/master/wiki/README.rst Wann diese Teile wirklich für normale Menschen benutzbar sind, weiss ich nicht, wird aber vermutlich noch recht lange dauern.

    Vielleicht können die Freifunk-Kisten schon ähnliche Sachen, da bin ich nicht so auf dem Laufenden. Ist aber ja nicht unbedingt deren Einsatzgebiet.

    Was du auf jeden Fall erstmal bräuchtest, wäre meiner Meinung nach ein Rahmen für die Daten, die du austauschen möchtest. Du willst die automatisch abgleichen und verarbeiten, dafür müssen die konsistent sein. Und du willst die übers Netz tauschen und abgleichen, also sollte das Format dafür geeignet sein. Vielleicht ein Syndikalismus-Subset von XML entwickeln oder sowas 🙂

    Vielleicht gibt es auch schon Ansätze in die Richtung, hast du mal bei Genossenschaften/co-ops nach sowas geguckt bzw. gefragt?

Schreibe einen Kommentar