cine:plom
cine:tv:plom
kommentar:plom
reste:plom
Eines von mehreren
plomlompom-Projekten
Datenschutz-Erklärung
Impressum

futur:plom

Enjoying das Zukunft
Über diese Seite

Futuristische und utopische Notizen von Christian Heller a.k.a. plomlompom.

Orientierung

Themen-Einstiege

Berichte, Lektüren

Abonnement

Letzte Kommentare

24c3 #22: geschlechtspolitisches Sich-um-Kopf-und-Kragen-Reden (2)
     Günter Komoll, egal

Antisozialdemokratische Utopie Grundeinkommen (7)
     Martin Werner, Philipp, Klaus Gieg, ...

Afrikas größter Exportschlager: die Supercomputerisierung der Erde (3)
     Christian, Christian, sunny

Blogroll

Englisch

Deutsch

Lizenz

Für alle von mir verfassten Texte auf dieser Seite gilt folgende Lizenz:

Creative Commons License

Partnerschaften

[hier war mal ein Amazon.de-Affiliate-Banner, heute aber nicht mehr; frühere Amazon.de-Affiliate-Links im Blog sind nun nur noch unaffiliierte Amazon.de-Links]

Werbung

(hier war mal AdSense-Werbung, heute aber nicht mehr)

   

24c3 #4: Wir designen einen Hackerspace!

(Bloggen vom Chaos Communication Congress)

14.00 Uhr: Building a Hackerspace – A Hacker Space Design Pattern Catalogue

Nein, ich will nicht unbedingt an der Gründung eines Hackerspace mitwirken, aber vielleicht an etwas ähnlichem, darum schau ich mir das hier mit regem Interesse an …

IMG_6911

Lars Weiler und Jens Ohlig halten ihren Vortrag über die funktionstüchtige Gestaltung eines Raums für Hacker bereits zum x-ten Mal. Er entstand in Konfrontation mit der Neugier amerikanischer Hacker, wie die Deutschen und Österreicher so tolle “Hackerspace”-Infrastrukturen geschaffen kriegen würden, im Kontrast zu einem Mangel in dieser Frage bei den Amis daheim. Dieser Neugier solle mit “Design Patterns” für einen Hackerspace entgegen gekommen werden, orientiert an Erfahrungen mit einem Kölner CCC-Hackerspace.

Aaaalso (und hierin finden sich Schätze zur politischen, kulturellen und psychologischen Analyse der Geek-Kultur, die Rose White sich eigentlich für ihr soziologisches Projekt hätte geben müssen):

Das Ding sollte “infrastructure-driven” konzipiert werden, mit einem thematischen laissez faire: Eine Infrastruktur hinstellen, in der sich Dinge und Themen von sich aus entwickeln können, anstatt umgekehrt ausgehend von einem vorgegebenen Thema eine Infrastruktur zu gestalten, die für coole Emergenzen keinen Raum lässt. “A common theme” entwickelt sich am besten von selbst. Man schaffe auch eine virtuelle Kommunikationsinfrastruktur für den Ort, genauer: Infrastruktur für drei wichtige Dinge: Diskussion, Documentation, Echtzeitkommunikation: also z.B. Mailing-Liste, Wiki, IRC.

Man möge sich nicht durch zuviele Bedenken und Voraussorgen in seinem Vorhaben abhalten lassen, man folge der Grace Hopper‘schen Regel: “Its always easier to ask for forgiveness than it is to get permission.” (Na das ist doch ganz im Sinne der aktionsaffirmativen Interpretation des deutschen Congress-Mottos “Volldampf voraus!”)

Die kritische Personenmasse zum Loslegen ist 4: 2, die die Idee haben, 2 weitere, die mithelfen, sie praktisch umzusetzen. Damit kann man anfangen und von dort ausgehend weitere Hacker rekrutieren; erfahrungsgemäß wird der Ort “sustainable”, sobald er 10 Hacker umfasst. Um Dinge zum Laufen zu bringen, braucht man starke Persönlichkeiten mit natürlicher Autorität und Erfahrung im Aufbauen von Strukturen.

Wichtig ist eine gute Beziehung zum Vermieter und zur Nachbarschaft, da sollte man sich eines toleranten personalen Umfelds versichern. Der Kölner Hackerspace fährt gut Wand an Wand mit einem Dominatrixstudio: Die kleiden sich komisch — wir auch; die schätzen Privacy — wir auch. In Karlsruhe hat man auch gute Erfahrungen im Benachbarn mit schwulen Aktivisten gemacht.

Man sollte niemanden im Hackerspace leben lassen. Ein Ort, der als persönlicher und privater Lebens- und Rückzugsraum von jemandem benutzt wird, generiert Unwohlsein fuer jene Anderen, die in ihm arbeiten wollen. Der perfekte Hackerspace ist “the perfect living room without people living there.”

Man denke an Versorgung mit Essen und Trinken, an einen Kühlschrank, an Gelegenheiten zum gemeinsamen Kochen (das bringt die Leute richtig gut zusammen!), an Abwaschgelegenheiten (eine Spüle ist wirklich, wirklich, wirklich wichtig, im Zweifelsfall sogar wichtiger noch als das nächste Technik-Upgrade!). Softdrinks verkaufen! Die machen 50% der Einnahmen des Kölner Hackerspaces aus.

Der Raum sollte sich in separate Bereiche abtrennen lassen, man denke an: Séparées, Vorhänge, Türen, kleine Räume. Man sorge auch fuer “Coziness” mittels Gemütlichkeitsutensilien von der Couch bis zum Ascher, man sorge für eine Stereo-Anlage und einen Beamer. Mit Pflanzen dagegen klappt es erfahrungsgemäß nicht ganz so gut:

IMG_6916

Man braucht für die durchschwitzten, stinkenden Nerd-Körper nach langen Hacking-Sessions und für die nachts anreisenden Hacker-Wanderer aus fernen Städten ein Badezimmer mit Dusche, vielleicht sogar mit einer Waschmaschine für die bald dreckigen Handtücher.

Man verlange zur Finanzierung einen Mitgliedsbeitrag, regelmäßig und ohne Ausnahme, wenn auch gerne mit Ermäßigung für Studenten. Man habe für den Notfall immer die Miete für drei Monate im Voraus auf dem Konto. “Elect a totalitarian, fascist, stalinist treasurer!” (Großen, großen Applaus kriegt der Satz.)

Man mache sich nicht von einem Sponsor abhängig, vor allem nicht für den Ort. Kapitalismus fordert immer seinen Preis ein, man kriegt nix geschenkt. Auch universitäre Räume sind ein No-No, da muss man nämlich raus, wenn der Hausmeister kommt, und soll außerdem alles aufgeräumt hinterlassen. Geht gar nich. (Und auch nicht jeder fühlt sich in universitären Räumen daheim.)

Man führe zur Klärung von Konflikten, für Diskussionen über Vergangenheit und wichtige Entscheidungen für die Zukunft regelmäßige Treffen aller Mitglieder durch, mit jeweils im Voraus klar abgesteckter Agenda und Zielgebung. Für ein solches Treffen braucht man eine terminliche Regelmäßigkeit, und da ist die einzige funktionierende: einmal pro Woche. Und an welchem Wochentag? Am Dienstag. Weil, der ist genauso schlecht oder gut wie jeder andere. Man wird nie mit irgendeinem Wochentag alle zufriedenstellen.

Entscheidungen auf dem öffentlichen Plenum treffe man idealerweise im diskussionsgenerierten Gesamtkonsens; erst bei Punkten, wo derlei Konsens unerreichbar ist, stimme man mit Mehrheitssuche ab. Wenn niemand abwäscht oder den Müll rausbringt, darf auch gerne mal autoritär selbiges befohlen werden, aber der Befehlende sollte dann mitwirken, sonst fühlen sich die Befohlenen verarscht. Da die Diskussionskultur unter Geeks dank jahrzehntelanger Flamewarschulung nachholbedürftig sei, sollte man die Diskussionsleitung erfahrenen Diskussionsleitern mit social skills und Hintergründen z.B. in politischer Diskussionskultur überlassen. Wenn jemand Probleme macht, die in der Gruppenöffentlichkeit nicht befriedigend gelöst oder angesprochen werden können, sollte ein erfahrenes Gruppenmitglied mit der Person im Privaten reden. Ihr zuhören, ihr aber auch auseinandersetzen, was die Gruppe für ein Problem mit ihr hat.

Interessante neue Leute für den Hackerspace lockt man durch monatliche öffentliche Events, Vorträge, Workshops, whatever an. Wen man dort hackerspace-kompatibel findet, den kann man auch auf die geschlossenen Events einladen. Die Weirdos dagegen, die man nicht so hackerspace-kompatibel findet — nicht.

Der Enthusiasmus für den Hackerspace hat die Form einer Sinuskurve mit 4-Jahres-Zyklus. Wenn der Enthusiasmus nach zwei Jahren am Bod liegt, lasse man den Space trotzdem laufen, halte ihn offen, denn wer weiß, wann doch mal wieder was Spannendes an die Tür klopft; in zwei Jahren ist die Begeisterungskurve bestimmt wieder auf Maximum!

Man verhindere die Diktatur eines einzelnen Hackergottes. Man bemühe sich stattdessen um eine “sudo leadership pattern”: kein “single root”, sondern, wo notwendig, nur temporäres “leadership” festlegen.

Wenn man sich für dauerhafte Volontärarbeit zugunsten des Hackerspaces gemeldet hat, dann verrichte man sie mit Eifer, Stolz und Überzeugung. Kann man derlei nicht aufbringen, sollte man seinen Posten für jemand anderen frei machen.

Mit Projekten, die man ins Laufen bringen woll, sollte man sich nicht unbedingt an alle Mitglieder richten. Weil: Bikeshed-Problem. Was ist das Bikeshed-Problem? Man kriegt eher die Errichtung eines neuen Atomkraftwerks vom Firmenvorstand bewilligt als die eines Fahrradschuppens. Denn: Niemand fühlt sich für Detailfragen der Errichtung eines Atomkraftwerks kompetent, jeder aber für Detailfragen der Einrichtung eines so einfachen Dinges wie eines Fahrradschuppens. Die Entstehung des Fahrradschuppens wird an der endlosen Diskussion und Entscheidungsunfähigkeit über die unwichtigsten Details seiner Gestaltung scheitern, weil jeder mitreden will. Man identifiziere notfalls ins Nichts führende Diskussionen und beende sie einfach, wenn sie die notwendige Erledigung einer Aufgabe behindern. (Yay, noch mehr Aktionsaffirmation!)

Alten Technik-Krams, der Platz für neue Technik wegnimmt, regelmäßig ausmisten. Dreimal nachfragen, ob’s noch plausibel gebraucht wird, dann auf einen Kann-mitnehmen-wer-will-Haufen tun. Was zu lange liegen bleibt, wandert in den Müll. (Rigoros!)

Einlass zu dem Hackerspace gewährt ein Schlüssel, den man gegen Pfand entleihen kann. Oder ein avanciertes, so experimentelles wie problembeladenes “electronic locking system”.

Merke: Alle weiteren Fragen/Probleme lassen sich über einen ausreichend großen Club-Mate-Vorrat lösen.

Thursday December 27, 2007

Werbung
(hier war mal AdSense-Werbung, heute aber nicht mehr)

Kommentarfunktion für diesen Artikel geschlossen.