Vortrag: Wie schare ich eine Gemeinde um ein Projekt?

Event large

Brandaktuelle Schlagworte in der Linuxkernelentwicklung sind “Code of Conduct” und “Meritocracy”, beides Ansätze, um eine Qualitätserhöhung von Beiträgen durch Aussonderung in unterschiedlichen Kategorien zu erreichen. Welche technischen, menschlichen und organisatorischen Mittel, eine breit aufgestellte Benutzerbasis als Potential statt als Problem zu behandeln, kann man gewinnbringend einsetzen?

Aktuell kochen Diskussionen über den “Code of Conduct” für die
Linuxentwicklerliste: ‘traditionell’ wurde ein solcher abgelehnt und
statt dessen eine ‘Meritocracy’ postuliert, bei der Respekt nur durch
konsistent abgelieferte Codequalität erworben werden konnte.

Die damit angestrebten Ziele waren eine Reduktion der Kommunikation
und der Beiträge auf ein handhabbares Maß und die Maximierung
zielführender Beiträge konsistenter technischer Qualität. Lautstark
befürchtet wird aktuell, daß die Postulierung grundlegender
Umgangsregeln diejenigen vergraulen wird, die mit eher robustem
Kommunikationsstil die Qualität der technischen Beiträge hochzuhalten
versuchen und auch darüber eine Identifikation mit einer
Wertegemeinschaft ermöglichen.

Ob man nun Dickfelligkeit als korreliert mit technischer Brillanz
sehen möchte oder nicht: das grundlegend angegangene Problem hier ist,
die durchschnittliche Qualität von Beiträgen mit dem Mittel der
Ausdünnung zu heben. Tatsächlich würde es aber Sinn machen, die Zahl
von Zuträgern zu _erhöhen_ und für den Werdegang ihrer Beiträge eher
technische und organisatorische als menschliche Hürden zu errichten.

Weiterhin ist es eine große Verschwendung an Potential, wenn von der
Vielzahl von Anwendern eines Projektes nur eine so elitäre Minderheit
aktiv zu seiner Weiterentwicklung beitragen kann, daß
“Diversity”-Bemühungen zur Verbreiterung der Basis von
Projektmitgliedern überhaupt als eine Interessensabwägung betrachtet
werden können.

Wie sollte man also ein Projekt so strukturieren, daß es für eine
breite Basis von Beitragenden technisch und menschlich aufnahmefähig
ist? Wer technisch an der Grenze seiner Leistungsfähigkeit arbeitet,
wird selten noch die emotionale Energie aufbringen können oder wollen,
vielen anderen gegenüber offen zu sein, umso mehr, als sich bestimmte
Probleme häufig wiederholen.

In der Algorithmik ist das Prinzip der Aufspaltung in unabhängig
angegangene Einzelprobleme elementar. Die Auffächerung größerer
Programmierprojekte in Sphären, deren Größe mit dem Querschnitt des
Könnens und der Kommunikationsfähigkeiten seiner Nutzerbasis
korreliert, ist für Freiwilligenprojekte erheblich relevanter als für
Projekte, die für kommerzielle Entwicklung und Nutzung angelegt sind.

Als Beispiel für hierarchische Architektur und Entwicklung werden
Emacs, TeX/LaTeX und LilyPond genauer betrachtet. Alle zeichnen sich
dadurch aus, daß neben der Implementationssprache auf der untersten
Ebene (hier respektive C, Pascal, und C++) eine Interpretersprache
(Lisp, TeX, Scheme) zu finden ist, in der größere Mengen der
Kernapplikation (Emacs, LaTeX, LilyPond) geschrieben sind und die mit
einer gewissen Modularität erweiterbar sind. Der tatsächlich damit
erreichte Umfang an unabhängiger Entwicklung und damit erreichter
“Gemeinde” ist aber stark verschieden. Was sind die Gründe dafür?

Info

Tag: 03.11.2018
Anfang: 15:50
Dauer: 01:00
Raum: Kesselhaus
Track: Community
Sprache: de

Links:

Feedback

Uns interessiert deine Meinung! Wie fandest du diese Veranstaltung?

Concurrent Events