[Dune] Re: Deeskalation und stay cool.

[Robert Kloefkorn]

Hallo Dune Entwickler,
hallo Peter, hallo Oliver, hallo Christian, hallo Markus,


ich möchte hiermit bekanntgeben, dass ich mich nach der Veröffentlichung 
von Dune 1.0 aus der Dune Entwicklung zurückziehen werde. Besser gesagt, 
werde ich noch bis Ende März/Anfang April einen Teil meiner Zeit dem 
Projekt zur Verfügung stellen. Danach werde ich mich ausschließlich um 
meine Dissertation kümmern. Das ist sicher der wichtigste Grund für 
diesen Entschluss, wobei allerdings bei mir bisher keine Klarheit 
darüber herschte, wie ich mich entscheiden sollte, da ich sehr viel in 
dieses Projekt investiert habe. In den letzten Wochen ging es im Projekt 
allerdings wieder so drunter und drüber, dass ich, um vor allem für mich 
Klarheit zu schaffen, in welcher Beziehung ich in Zukunft zu diesem 
Projekt stehen möchte, nun zu dieser Entscheidung komme. Ich möchte auch 
klarstellen, dass ich in dieser mail ausschließlich für mich spreche. 
Weiterhin ist diese mail nicht als "große Abrechnung" zu betrachten. Ich 
lege Wert darauf, auch weiterhin Kontakt zu allen Mitgliedern des Dune 
Entwicklerteams zu halten. Falls ich in dieser mail Formulierungen etc. 
verwende, die dem Einen oder Anderen mißfallen, bitte ich dies zu 
entschuldigen. Diese mail ist dazu gedacht, mich zu erklären, und nicht 
um noch mehr Unfrieden zu stiften.

Es entsteht sicher der Eindruck, es handelt sich um eine 
Kurzschlußaktion. Dies ist nicht so. Im letzten Jahr der Dune 
Entwicklung ist so viel schief gelaufen (aus meiner Sicht), dass dies 
nur die letzte Konsequenz einer längeren Entwicklung ist, die sicherlich 
durch meine hohen persönlichen Investitionen in dieses Projekt 
hinausgezögert wurde. Für ein besseres Verständnis meiner Entscheidung 
  führe noch kurz einige Gründe auf, die die Situation aus meiner Sicht 
darstellen und für mich Gründe sind, nach 1.0 nicht länger an der Dune 
Entwicklung teilzunehmen.

1) Kommunikationsdefizite -- Die "Eskalationen" der letzten Wochen sind 
nur ein Problem mangelnder Kommunikation, aus meiner Sicht jedenfalls. 
Diese behindern die Arbeit jedoch erheblich. Ich habe mehrfach 
Vorschläge zur Verbesserung dieses Problems gemacht, welche jedoch mehr 
oder weniger ignoriert wurden. Deshalb bin ich nicht länger bereit, 
Beeinträchtigungen meiner Arbeit aufgrund dieser Kommunikationsdefizite 
hinzunehmen.

2) Interface und Implementierungen sowie Interfaceerweiterungen -- Viele 
Diskussionen der letzten Zeit handelten meiner Ansicht nach davon, wie 
etwas zu implementieren sei, nicht aber, was eigentlich Schnittstelle 
sein soll. Angefangen von der EntityPointer Geschichte, wo sehr viel der 
Implementierung und nicht nur (wie es eigentlich sein sollte) das 
Interface vorgeschrieben wird. Auch finde ich es komisch, das zwar 
Sachen, die z.B. in Berlin oder Heidelberg als wichtig erachtet werden 
(GeometryType oder CollectiveCommunication), einfach in das Interface 
integriert werden, ohne das darüber diskutiert wird in einer Art und 
Weise, die auch auf die Konsequenzen hinweist. Auf der anderen Seite 
werden dann Sachen, die aus unserer Sicht sinnvoll sind, mit "completly 
against" usw. verhindert. Dabei haben wir uns immer sehr sorgfältig 
darum gekümmert, welche Konsequenzen auftreten können und in wieweit das 
von allen Gitterimplementierungen mitgetragen werden kann, gekümmert.
Mit anderen Worten, ich verstehe nicht wie ihr gegen etwas sein könnt, 
von dem wir 1) überzeugt sind, dass wir es benötigen, 2) uns Gedanken 
über Ort,Zweck und Konsequenz für andere Implementierungen gemacht haben 
und 3) die Implementierungsarbeit übernehmen würden. Auf dieser 
Grundlage läßt sich aus meiner Sicht nicht weiter zusammen Software 
entwickeln. Mit einer Schnittstelle, in welcher wichtige Funktionalität 
fehlt, kann ich nicht zufrieden sein. Zeit ist hier ein Problem. Ich 
möchte nicht erst in 5 Jahren fertig sein, deshalb ist es wichtig, 
gewisse Dinge in 1.0 zu haben und nicht auf die Weiterentwicklung zu 
verweisen.


3) Effizienz vs. "Schönheit" -- Ich hatte vielfach den Eindruck, an 
einem Paket für numerische Simulationen mitzuentwickeln, bei welchem 
Effizienz nicht an vorderster Stelle steht, auf jeden Fall nicht, was 
den Einsatz von man-power betrifft. Const-Konzept, Copy Konstruktoren, 
etc. schön und gut, aber nutzlos (zumindest, wenn man wie ich mit der 
Motivation, etwas effizient rechnen zu wollen, heran geht). Damit 
rechnet man nichts aus. Dune wird nicht daran gemessen, ob Iteratoren 
Copy Konstruktoren haben oder nicht. Und das der Code schöner geworden 
ist, kann man leider auch nicht behaupten. Erst jetzt, da ich seit ca. 3 
Monaten einem HiWi erklären muss, wie gewisse Sachen implementiert 
werden sollen, ist mir richtig aufgefallen, wie kompliziert der Code 
geworden ist, nur damit gewisse softwaretechnische Konzepte verwirklicht 
werden konnten, die nicht zum Endziel, etwas effizient rechnen zu 
können, beitragen. Desweiteren verstehe ich nicht, wieso wir den Aufwand 
betreiben, eine Schnittstelle zu entwickeln, die insbesondere auch 
struktuierte Gitter einbindet (effizient?), die Implementierungen dazu 
jedoch entweder langsam oder nicht Schnittstellen konform sind. Diese 
Tatsachen möchte ich nicht länger in irgendeiner Weise nach "außen" 
vertreten müssen. Dies ist jedoch nur ein Punkt aus der konvexen Hülle 
von Adaption, LocalIdSet vs. HierarchichIndexSet, SubEntitäten, 
Gitterkonstruktoren, Backup/Restore, wo ich explizit die von Dune 
(zumindest Dune HD/B) vertretene Meinung nicht teile bzw. die Diskusion 
darüber leid bin und desweiteren auch nicht bereit bin Konsequenzen, die 
sich daraus ergeben (z.B. gurkige workarounds, die enstehen, weil ich 
nicht auf die Funktionalität verzichten möchte, oder weil sich er 
offizielle Weg als uneffizient erweist), weiterhin mitzutragen.


4) Baut auf und reißt nieder, dann habt ihr Arbeit immer wieder --
Inzwischen habe ich aufgehört, die Änderungen, die ich an bestehendem 
Simulationscode durchgeführt habe, damit er __wieder__ läuft, zu zählen. 
In dieser Hinsicht lehne ich das Vorgehen, dass sich in Dune 
eingebürgert hat (wenn es die Schnittstelle schöner macht, dann hat es 
oberste Priorität), ab. Ich habe keine Lust mehr, ständig Änderungen 
druchzuziehen, die ich teilweise als nicht sinnvoll erachte, die jedoch 
meinen Code in kritischer Art und Weise betreffen und meherere Tage und 
Wochen Arbeit nach sich ziehen. Dies ist vor allem im Hinblick auf meine 
Dissertation nicht akzeptabel. Ich möchte mit Dune was rechnen und nicht 
die perfekte Schnittstelle programmieren. Ich hatte das Gefühl, das 
Andere im Projekt das anders sehen. Das ist ja kein Problem, beide Ziele 
haben ihre Berechtigung. Ich werde auf jeden Fall keine Arbeit mehr in 
die Vereinigung dieser konträren Ziele investieren.


5) Meine Gesundheit -- Ich habe mich in den letzten Monaten so viel über 
Dune geärgert, dass ich, bevor es zu gesundheitlichen Schäden 
meinerseits kommt, die Konsequenzen ziehe. Aus diesem Grund sage ich 
auch ganz klar, dass ich noch im März an Dune arbeite und helfe, das 
Release zu verwirklichen. Unabhängig vom Release Datum werde ich mich 
danach voll und ganz auf meine Dissertation konzentrieren.


So viel ein kleiner Auszug aus meiner Sicht auf die Dinge. Wie immer 
besteht viel Interpretationsspielraum, wie das bei mails halt so ist. 
Ich hoffe niemanden beleidigt zu haben oder dergleichen.

Ich werde gleich morgen mit frischer Kraft am Gelingen von Dune 1.0 
weiterarbeiten.

Ein gute Nacht wünscht:

Robert