Ich schrieb: > Wir haben es jetzt mehr als acht Jahre auf "unsere" Art und Weise > versucht, und konnten die Zahl der Entwickler, die aktiv an > unserer > Codebasis arbeiten nicht erh"ohen (wohl aber die Anzahl > Codezeilen, > die es zu pflegen, und die Anzahl Bugs, die es zu fixen gilt). Ich > finde es daher durchaus angebracht, das System als Ganzes zu > hinterfragen - und was k"onnten wir besseres tun, als uns von > Projekten leiten zu lassen, die diesbez"uglich erfolgreicher > waren? >
So, nun endlich meine Gedanken zum Thema Entwicklercommunity. Zun"achst mal ein paar allgemeine Fakten: - ca. 8 Millionen Zeilen Code (je nach Z"ahlweise) - gr"osstenteils C++ (ca. 90%, je nach Z"ahlweise) - ziemlich alter Code - ein grosser Prozentsatz hat sich seit dem initialen OpenSourcen (im wesentlichen) nicht ge"andert, Stil und Techniken sind daher "ofters antiquiert und f"ur Einsteiger schwer zu verstehen. - Deutsche Code-Kommentare sind speziell in den alten Codeteilen noch die Regel - sehr ungew"ohnliches Buildsystem, Konzepte wie Module, delivern, solver, build.pl und eigenes Make-Utility sind vorsichtig ausgedr"uckt sehr ungewohnt f"ur neue Entwickler. - nicht nur beim Buildsystem, auch in anderen Bereichen hat OOo hat f"ur vieles eigene L"osungen entwickelt: GUI-Lib, System-Abstraktion, Komponentensystem, Konfiguration, Strings & UI-Ressourcen, Testsystem, um nur einige zu nennen - OOo setzt sehr viele Tools auf dem System voraus, auf dem man entwickeln will. Die sogenannten build-preconditions sind vermutlich mit die h"ochsten im ganzen FLOSS-Zirkus. Das Konfigurationsskript, dass man vor dem Compilieren startet, fragt die meisten davon ab, testet aber beileibe nicht alles - Hacker-Support: der klassische Hackersupport geschieht "uber IRC; leider sind die wenigsten OOo-Coreentwickler dort zugegen. - fast keine unit-Tests im Code Daraus folgen sofort ein paar Dinge: - alles, was OOo betrifft, dauert sehr lange. Quelltexte runterladen oder auschecken, den Code "ubersetzen, etwas im Quelltext finden, sich im Code zurecht finden, nach einer Code"anderung neu "ubersetzen, ein Teilsystem umbauen usf. - Das Compilieren des Codes geht, gerade f"ur Anf"anger, sehr h"aufig schief. Manchmal ist schon die Version im SCM kaputt (da HH nicht immer alles baut), manchmal hat das Konfigurationsskript eine Voraussetzung nicht richtig gepr"uft. - Das "Einlesen" in den Code f"allt schwer (aufgrund der vielen OOo-eigenen Konzepte. Aufgrund deutscher/ungenauer/falscher/ fehlender Kommentare). Aufgrund der vielen Eigenl"osungen - Hacker, die in anderen FLOSS-Projekten bereits Erfahrungen gesammelt haben, k"onnen davon in OOo so gut wie nichts weiterverwenden. - das Fehlerbeheben ist riskant, da fehlende Unittests einem keine Sicherheit geben Das bedeutet, die technischen Einstiegsh"urden f"ur potentielle OOo-Hacker sind maximal hoch, vermutlich die h"ochsten im ganzen FLOSS-Zirkus. Falls jemand den Einstieg wagt, verst"osst schon das Build-System gegen eine eherne FLOSS-Regel: "Fail fast" - wenn etwas nicht funktioniert, muss der Hacker es *schnell* erfahren, nicht erst nach einem Tag Bauen. Mal angenommen, er hat diese erste H"urde genommen (was erfahrungsgem"ass unter Linux mindestens einen Tag, unter Windows auch mal eine Woche dauern kann). Will er dann von seinen Erfahrungen berichten, muss er sich auf der Hauptseite, dem Wiki, und vielleicht noch im Userforum jeweils separat anmelden. Hat er eine spezielle Frage, wird ziemlich sicher der entsprechende Entwickler nicht im IRC sein, also muss auf einer Mailingliste gefragt werden - bis mit dem "ublichen Frage-Antwort-Gegenfrage-Pingpong eine L"osung gefunden ist, vergeht manchmal soviel Zeit, dass der Hacker entnervt aufgibt. Auch noch so ein Punkt: OOo hat sehr viele Spezialisten, aber wenige Generalisten, wenn es um "Ubersicht im Code geht. Das alles sind, wenn man so will, intrinsische Gr"unde, warum sehr wenige Hacker "uberhaupt bis zum ersten Bugfix kommen. Dann fallen mir noch ein paar extrinsische ein: - SCA. Nicht jeder Hacker kann sich mit sowas anfreunden - Die meisten Hacker benutzen OOo nicht, oder nur in Ausnahmef"allen. D.h. der typische "scratch my itch"-Fall tritt bei OOo seltener ein als beispielsweise beim Linux-Kernel. Insgesamt ist der Zulauf von Freiwilligen geringer, je n"aher ein Projekt am Benutzer ist. Im allgemeinen haben Serverprojekte mehr Zulauf als Applikationen. - OOo gilt nicht gerade als cool. Viele Hacker stempeln es als "Bloatware" ab. Das ist vermutlich eine Frage des Marketings (aber bitte nicht im klassischen Sinne, Hacker sind diesbez"uglich sehr allergisch!), z.B. sind beim Linux-Kernel eine ganze Reihe Leute beteiligt, die in Hackerkreisen eine extrem hohe Reputation geniessen - bei solchen Leuten, in solchen Projekten macht man gerne mit. - c++ ist als Sprache eher auf dem absteigenden Ast, ich habe mal ohloh bem"uht: http://www.ohloh.net/languages/compare?commit=Update&l0=c&l1=cpp&l2=html&l3=java&l4=php&l5=python&l6=-1&measure=contributors&percent= http://www.ohloh.net/languages/compare?commit=Update&l0=c&l1=cpp&l2=html&l3=java&l4=php&l5=python&l6=-1&measure=projects&percent= - OOo ist mit anderen FLOSS-Projekten so gut wie nicht vernetzt, da es einerseits keine Basisbibliotheken mit anderen Projekten "teilt" (nur tonnenweise welche benutzt, Fixes aus OOo werden aber eher langsam beim origin"aren Projekt abgegeben), andererseits viele OOo-Entwickler nur f"ur OOo entwickeln, und nicht auch f"ur andere FLOSS-Projekte. Zusammenfassend gesagt: von den paar Hackern, die "uberhaupt bei OOo vorbeischauen, verlieren wir dann noch viel zu viele bei den ersten Schritten. Die Folge ist, dass OOo nur eine extrem kleine Gruppe von freiwilligen Entwicklern hat. Insgesamt geht, nicht nur nach Michaels Statistik, die Anzahl der OOo-Entwickler zur"uck. Wieder Ohloh: http://www.ohloh.net/p/compare?metric=Contributors&project_0=OpenOffice.org&project_1=Linux+Kernel+2.6 Das Projekt befindet sich damit, was die Entwicklerseite angeht, in allen angesprochenen Bereichen in der Problemzone. Schauen wir uns daher jetzt mal die andere Seite an, was sind die Anforderungen: - insgesamt ca. 22000 offene Issues, davon ~3000 auf 3.x, ~8000 auf "OOo later", und ~9000 ohne Target (die meisten vermutlich "unconfirmed") - ein sich ziemlich schnell "anderndes Umfeld - mobile internet devices, neue Platformkonzepte (aqua, android, iPhone), g"anzlich andere UI-Konzepte, anderes Nutzungsverhalten ("collaboration") - Neue UI & eine ganze Reihe neuer Features bei MSO; neuere Mitspieler im Markt (iWork, Web Offices). Und dann gibt es da leider auch noch ein paar ung"unstige R"uckkopplungsschleifen: - wenige Freiwillige heisst wenig Leute, die neu in den Code einsteigen & Dinge "andern wollen, die einen eben nerven, wenn man neu einsteigt -> vieles bleibt beim alten, man hat sich ja dran gew"ohnt -> weniger Freiwillige, weil der Einstieg so schwerf"allt. - wenige Entwickler f"uhrt zu "Uberlastung, "Uberlastung zu schnellen Fixes, schnelle Fixes zu fragilerem und schlechter zu durchschauendem Code. Was wiederum neue Entwickler abschreckt. - viel Arbeit an neuen Features f"uhrt zu weniger Arbeit an existierendem Code (Code braucht Pflege. Man muss ihn hier und da mal "olen, oder verschlissene Teile auswechseln). Wenig Pflege am Code f"uhrt zu mehr Aufwand bei neuen Features. Was zu noch weniger Zeit f"ur Pflege f"uhrt. Tja. Mehr Bugs, mehr Code, aber weniger Entwickler, und vielleicht Verst"arkungstendenzen. Was kann man tun? Die genannten Probleme l"osen, nat"urlich. Mehr Firmen dazu kriegen, dass sie OOo-Entwickler sponsorn. Wenn Firmen sich am SCA st"oren, mal Kosten und Nutzen abw"agen. Weiterhin macht es aber m.E. auch Sinn, sich mal die Eigenschaften von FLOSS-Projekten anzuschauen, die erfolgreich viele freiwillige Entwickler rekrutieren konnten (ich z"ahl mal hier bloss noch die auf, die meiner Meinung nach OOo nicht hat, und die oben noch nicht genannt wurden): - Entwicklung im Bazaar-Stil. Hacker stehen auf ein gewisses Chaos, und lassen sich vor allem ungern sagen, was sie tun sollen - Meritocracy - Hacker haben eine nat"urliche Aversion gegen Authorit"at, solange sie nicht sozusagen von ihnen selbst gestiftet wurde - release early, release often - user-driven testing - Community first - Fail fast (ok, hatten wir schon. Kann ich aber nicht genug betonen) - Mach niemals einen Fehler zweimal (im Code -> (unit) tests) - Mach den Einstieg so leicht wie m"oglich - Mozilla hat nur eine sehr kleine c++-Core, und Rumspielen mit JavaScript ist trivial; Linux Kernel hat Tutorials und gute B"ucher. Ein paar Schlagworte: - Nimm das, was die meisten anderen FLOSS-Projekte auch benutzen (bei Buildsystem, GUI-Lib, System-Abstraktion, Komponentensystem, Konfiguration, Strings & UI-Ressourcen, Testsystem usf.) - Sorge daf"ur, dass OOo-Code auch anderswo benutzt wird - wenn Hacker die Office-Suite nicht benutzen, packe Teile des Codes in Server oder Kommandozeilentools! Vieles von dem genannten ist langwierig; speziell in den letzten Abschnitten sind Punkte genannt, die geradezu unrealistisch sind. Ich m"ochte sie trotzdem als Vision genannt wissen, auf die man hinarbeiten kann (wenn man sie vielleicht auch nie erreicht). Und ein paar Worte seien mir noch erlaubt bez"uglich des recht emotional diskutierten Themas Entwickler gegen den Rest der Community: Mathias Bauer schreibt: > Wer ist hier "die Community"? Sind es nur die Entwickler, wie es > Michael Meeks gerne hätte, oder auch andere? > Michael Meeks schrieb dagegen: > Instead put the developers (all of them), and those actively > contributing into the driving seat. > Auf deutsch: "Sorgt daf"ur, dass die Entwickler (alle), und diejenigen, die aktiv etwas beitragen bestimmen." Also ganz bestimmt kein "nur die Entwickler". Sondern eher ein: "nehmt die Project-Leads, die sich seit Jahren auf ihren eigenen Mailinglisten nicht mehr gemeldet haben, aus den Entscheidungsgremien raus". Es wird, wie von Martin gesagt, immer Interessenskonflikte zwischen Entwicklern, QA, "Ubersetzung, Hilfe etc. geben. Der allereinfachste Weg, diese Reibereien zu minimieren ist eine "unstable"-Codelinie, die nicht irgendwann zwangsweise zur Release reifen muss - sondern aus der man sich selektiv fertige Features oder Fixes rauspicken kann, um damit die n"achste Release zu best"ucken. Gibt den Entwicklern schnelles Feedback & mehr Freiheit, und nimmt den Druck von QA und "Ubersetzung. So, und morgen sammel' ich dann nochmal die in den diversen Ver"astelungen dieses Monsterthreads liegengebliebenen offenen Fragen zusammen, die eine oder andere Sache m"ochte ich denn doch noch klarstellen. Viele Gr"usse, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
