OpenSeaMap: Kooperation, Kommunikation, Doku Entwicklertreffen Fühjahr 2015 OpenSeaMap – Kooperation, Kommunikation, Doku Aspekte von Strukturen „offener“ Projekte Werkzeuge Prinzipien Workflow Beispiel Primärer Kommunikationskanal Wiki Umgang mit konkurrierenden Entwürfen Weiteres

OpenSeaMap: Aspekte von Strukturen „offener“ Projekte Entwicklertreffen Fühjahr 2015 Aspekte von Strukturen „offener“ Projekte Übersicht Maintainer Modell Lose Strukturen Kernteam Zwiebelförmige Struktur Do-ocracy, Demokratie und Meritokratie Stiftungen nach: Frauke Lehmann: Entwickler Freier Software als soziale Formation. MagisterarbeitEntwickler Freier Software als soziale Formation

OpenSeaMap: Aspekte von Strukturen „offener“ Projekte Entwicklertreffen Fühjahr 2015 Maintainer Modell Eine Person trägt die Hauptverantwortung und fällt im Zweifelsfall auch die Entscheidungen. Besteht ein Projekt neben dem Maintainter auch noch aus einem Team, kann es zu Differenzen kommen. Können die Differenzen nicht einvernehmlich ausgeräumt werden, kommt es in der Praxis immer wieder zu einem aufsplitten der Projekte („forking“). Forking mag bei der Entwicklung von Software noch Sinn machen, für andere offene Projekte wie „Wikipedia“ wäre dies durch die Bereitstellung der Infrastruktur weder realistisch noch wünschenswert.

OpenSeaMap: Aspekte von Strukturen „offener“ Projekte Entwicklertreffen Fühjahr 2015 Lose Strukturen: Alle Entscheidungen werden z.B. via IRC- Kommunikation abgestimmt (Eisfair). Kernteam: Ein Team von Maintainern wird gewählt (NetBSD: UNIX) oder findet sich. Das bestehende Kernteam kann auch neue Mitglieder aufnehmen (Netfilter). Zwiebelförmige Struktur: Neben dem Kernteam oder Maintainer gibt es Bereichsverantwortliche (Linux- Kernel).

OpenSeaMap: Aspekte von Strukturen „offener“ Projekte Entwicklertreffen Fühjahr 2015 Do-ocracy, Demokratie und Meritokratie: Unter Do-ocracy wird eine Organisationsform verstanden in der sich die Individuen sebständig ihre Aufgaben suchen und auch die entsprechende Entscheidungen treffen. Die Legitimation erfolgt durch das Handeln und nicht durch Wahlen. In offenen Projekten gibt es beide Varianten. Bei ersterer Variante können Bereichsverantwortliche dabei selbst ein neues Teilprojekt gründen (der Standard in offenen Projekten) oder von einem Maintainer dafür benannt werden. Im letzteren Falle wird auch von einer Meritokratie gesprochen. Aufgrund seiner Leistung wird der Maintainer dazu „berufen“ (Apache Software Foundation). Daneben gibt es aber auch Projekte in denen Wahlen stattfinden (Wikipedia, Debian).

OpenSeaMap: Aspekte von Strukturen „offener“ Projekte Entwicklertreffen Fühjahr 2015 Stiftungen: Foundations gibt es für viele größere Projekte. Beispiele sind Apache, Wikipedia, oder auch OpenStreetMap. Die Entstehung der Kluft zwischen Hauptberuflichen und Community macht einigen Projekten das Leben schwer (Wikipedia).

OpenSeaMap: Aspekte von Strukturen „offener“ Projekte Entwicklertreffen Fühjahr 2015 Fazit: „Das Feld zeichnet sich durch eine Homogenität der Kultur und Heterogenität der Struktur aus.“ (Frauke Lehmann: Entwickler Freier Software als soziale Formation. Magisterarbeit)Entwickler Freier Software als soziale Formation Die Definition von Prinzipien bezüglich offener Daten und Inhalte ist relativ klar (opendefinition.og). Die Struktur muss sich ein jedes offenes Projekt selber geben. Es fehlt leider eine allgmeingültige Definition des Begriffes „offenes Projekt“.

OpenSeaMap: Werkzeuge Entwicklertreffen Fühjahr 2015 Werkzeuge interner Kommunikation: -Offen: - Listen -Foren -Chat-Rooms -Tracker -Newsgroups -SVN / GitHUB / & Co -Persönlich One-to-One -Chat -Mail -Telefon

OpenSeaMap: Prinzipien Entwicklertreffen Fühjahr 2015 Prinzipien offener Projekte: Transparenz “Transparency of processes, including communications, promotes participation, respect, honesty and trust.” (opencompute.org) „Die Entscheidungsstrukturen bei Open-Source-Projekten sind transparent. Sie lassen sichüber die Diskussionen in den Developer MailingListen nachvollziehen.“ (Joachim Heintz, Auditive Perspektiven) “The three principles of transparency, participation, and collaboration form the cornerstone of an open government.” (opengovdata.io) Aus dem Feedback zu diesem Thema läßt sich entnehmen, dass dieses Prinzip einen hohen Stellenwert im Projekt hat. Die Früchte des offenen Projektes sind frei verfügbar bzw. unter einer freien bzw. offenen Lizenz.

OpenSeaMap: Workflow Beispiel Entwicklertreffen Fühjahr 2015 Um für uns ein einvernehmliches praktikables Vorgehen zu finden sollten wir an einem Beispiel einen Workflow für ein Unterprojekt erarbeiten. Die Vorgaben können dann helfen transparente Arbeitsabläufe zu schaffen mit denen wir alle zufrieden sind.

OpenSeaMap: Workflow Beispiel Entwicklertreffen Fühjahr 2015

OpenSeaMap: Workflow Beispiel Entwicklertreffen Fühjahr 2015

OpenSeaMap: Primärer Kommunikationskanal Entwicklertreffen Fühjahr 2015 Primärer Kommunikationskanal im Beispiel wäre die Dev-Liste. Der primäre Dokumentationsort das Wiki. Ist dies für alle so akzeptabel? Was gehört nicht auf die Liste und in das Wiki: -konkrete Sicherheitslücken -??? - Sollen weitere Betreff Varianten ([depth], [general],..) verwendet werden um die Liste zu strukturieren? -Sollen in die Mail direkt die Angaben an was die Person als Schwerpunkt arbeitet um deren Expertise einschätzen zu können? - Aussagekräftige Mail Adressen für die Mainatiner der Unterprojekte etc.)

OpenSeaMap: Umgang mit konkurrierenden Entwürfen Entwicklertreffen Fühjahr 2015 Wie soll mit mehreren konkurrierenden Entwürfen umgegangen werden, wenn sich nicht geeinigt werden kann? Wahlen?

OpenSeaMap: Weiters Entwicklertreffen Fühjahr 2015 Weiteres Fehlende Transparenz bei folgenden Punkten: Wie werden die Mails verarbeitet Gründe warum das Archiv nicht öffentlich ist