{"id":4096,"date":"2019-07-11T06:37:34","date_gmt":"2019-07-11T04:37:34","guid":{"rendered":"http:\/\/www.bernhardschloss.de\/blog\/?p=4096"},"modified":"2019-07-11T06:37:34","modified_gmt":"2019-07-11T04:37:34","slug":"communities-und-community-projekte","status":"publish","type":"post","link":"https:\/\/www.bernhardschloss.de\/blog\/communities-und-community-projekte\/","title":{"rendered":"Communities und Community-Projekte"},"content":{"rendered":"

Communities ticken anders. Entsprechend funktionieren Community-Projekte auch anders als andere Projekte. Was Communities anders macht ist das Prinzip der „Freiwilligkeit<\/strong>„. Egal ob es um Open Source Software-Entwicklung geht oder um ein Entwicklungshilfeprojekt eines NGOs, wenn die Akteure auf freiwilliger Basis an Bord sind, stellt das viele Spielregeln auf den Kopf.<\/p>\n

Eine liebe Freundin trieb mich einst beinahe in den Wahnsinn, weil f\u00fcr sie vor der Arbeit noch das Tee-Kochen und ein freundlicher Plausch wichtig waren, w\u00e4hrend ich erst einmal (auch im Ehrenamt) die Arbeit schaffen wollte, um dann in aller Ruhe mit ihr und den anderen noch weiter „abzuh\u00e4ngen“. Die Lektion, die ich damals lernen musste, ist, dass man bei „Freiwilligkeit“ nichts einklagen kann und wir die Eigenheiten der anderen weit mehr akzeptieren m\u00fcssen, als wir im (Berufs-)Alltag bereit w\u00e4ren, das zu tun. Letztlich m\u00fcssen wir froh sein, egal ob im Sportverein, im Sozialen oder wo auch immer, wenn sich jemand engagiert und die Grenzen der Kritikf\u00e4higkeit verlaufen einfach anders bei Volunteers.<\/p>\n

Um Communites besser zu verstehen bin ich vor einer Weile \u00fcber ein sch\u00f6nes Werkzeug gestolpert. Wie k\u00f6nnte es auch anders sein: Es ist ein Canvas – Der Community-Canvas<\/a>.
\"\"<\/p>\n\n\n

<\/p>\n\n\n\n

Mit seinen Feldern bietet der Canvas bereits eine Tiefenstruktur zur Analyse einer Community. Im ersten Schritt reicht vielleicht schon die Grobstruktur (gekennzeichnet durch die Farben): Identity <\/strong>(blau) – Expierience <\/strong>(rot) – Structure<\/strong> (gr\u00fcn).<\/p>\n\n\n\n

Wenden wir dieses Werkzeug exemplarisch auf 3 Beispiele an:<\/p>\n\n\n\n

\"\"openPM ist zum Einen ein Projektmanagement-Wiki<\/a>, aber auch Bestandteil einer verbandsunabh\u00e4ngigen Projektmanagement-Community, die sich im Rahmen der PM-Camp-Bewegung<\/a> gefunden hat. Hinter openPM steckt ein gemeinn\u00fctziger Tr\u00e4gerverein<\/a>, der mittlerweile nicht nur das Wiki betreibt, sondern bei einigen PM-Camps auch als Veranstalter auftritt (M\u00fcnchen, Stuttgart, Karlsruhe) und auch die PM-Camp-Internet-Domain verwaltet. Bei all meinem pers\u00f6nlichen Enthusiasmus f\u00fcr openPM, legt der Canvas gleich den Finger in die Wunden dieser Community: Bei Identity und Structure k\u00f6nnen wir einen Haken setzen, hier ist die Aufstellung vorbildlich. Kritisch wird es in einzelnen Expierience Feldern. Dem Wiki mangelt es teilweise an Inhalt (Content). Offenbar werden die Erfahrungen (Shared Expierience) nicht in dem Umfang geteilt wie erhofft. Einen m\u00f6glichen Ansatzpunkt liefert der Canvas gleich mit: Die Etablierung von Ritualen. Das k\u00f6nnte im Konkreten ein noch weitergehendes Engagement in der PM-Camp-Bewegung und auf PM-Camps sein, aber vielleicht auch die Etablierung weiterer Austausch- und Diskussionsformate.<\/p>\n\n\n\n

Beispiel 2 hatten wir bereits eingangs erw\u00e4hnt: Freiwilligen-Arbeit mangelt es mitunter an Effizienz, die sich auch nicht „einklagen“ l\u00e4sst. Im Canvas bewegen wir uns auch hier in den Expierience Feldern. Einen L\u00f6sungsansatz k\u00f6nnten Rules, Rituals und Roles bieten.<\/p>\n\n\n\n

Sind Communities grunds\u00e4tzlich im gemeinn\u00fctzigen Bereich angesiedelt? Nein, es gibt auch andere Beispiele, die aber ebenfalls unter den Restriktionen der „Freiwilligkeit“ leiden – man denke nur an Barcamps und Open Space-Veranstaltungen, Supervision oder WOL-Circle. Aber auch firmenintern lassen sich Beispiele finden, wie unser Beispiel 3: Eine Community von IT-Experten einer bestimmten Software in einem Konzern. Gemeinsam helfen sich die Kollegen mit Know How und Tools aus. Die Gemeinschaft w\u00e4chst schnell und ihr Aktivit\u00e4tsradius nimmt zu, weil alle profitieren, allerdings bleibt die Community informell, womit sich selbst zugesagte Leistungen kaum einfordern lassen. Bei Gemeinschaftsprojekten knirscht es. M\u00f6glicherweise stehen einzelne IT-Abteilungen auch im Konkurrenzkampf: Abteilung A k\u00f6nnte System und Aufgaben von Abteilung B \u00fcbernehmen). Defizite liegen zum Einen im Bereich Structure (Organization, Governance und Financing), aber auch beim Miteinander (Shared Expieriences) fehlt es an Rules und Roles.<\/p>\n\n\n\n

Die 3 Beispiele zeigen bereits eindrucksvoll St\u00e4rken des Canvas. Allerdings sehe ich auch ein strukturelles Defizit: Der Canvas unterstellt eine Homogenit\u00e4t der Teilnehmer der Community. Heterogenit\u00e4t (z.B. rivalisierende Positionen) lassen sich schwer im Schema verankern. Das k\u00f6nnte z.B. durch eine begleitende Stakeholder-Analyse kompensiert werden. Aber nichtsdestotrotz: das ist Kritik\/Jammern auf hohem Niveau. Der Community Canvas stellt eine hervorragende Bereicherung in der Auseinandersetzung mit Communities und Community Projekten dar.<\/p>\n

<\/div>