Früher war ja der Hauptgrund, der gegen eine Befreiung des Codes angeführt wurde, dass das Projekt wohl sehr stark auf die Ubuntuusers-Situation zugeschnitten war und es sehr schwierig wäre, das Projekt für eigene Zwecke zu nutzen oder daran mitzuarbeiten.
Das ist ja erkennbar eine schwache Ausrede. Wenn der Code geöffnet wird kann man schlecht mitarbeiten, wenn er geschlossen bleibt gar nicht. Das spricht also nur dafür den Code zu öffnen, außer man ist generell dagegen.
Das Projekt für eigenee Zwecke anzupassen geht auch nur, wenn der Code offen ist. Auch das kann nur ein Grund sein den Code offen zu legen, es sei denn man will das gerade nicht.
Auch wenn ich diese Argumentation nicht nachvollziehen kann
Das kann auch sonst niemand.
Solange niemand den Code für ein anderes Projekt angepasst hat kann niemand sagen, wie gut er überhaupt anpassbar ist. Am ehesten erreicht man eine solche Anpassbarkeit, wenn man sie konkret erzielen will. Bjarne Stroustrup sagt, dass kein Code wiederverwendbar ist, der noch nicht wiederverwendet wurde.
Gerade wenn man zu wenig Kapazitäten hat ist auch das nur ein Grund den Code zu veröffentlichen, dann kann es der tun, der es braucht. Sonst bleibt's halt liegen wie jetzt, aber es kann nicht als Veröffentlichungshindernis mehr argumentativ aufgeführt werden. Offenbar war das aber der Zweck der Legende von der Wiedervewendbarkeit: Man veröffentlicht den Code erst, wenn er wiederverwendbar ist, aber weil das eine so geringe Priorität hat macht es niemand.
Ein zweiter Punkt, der hier durchscheint, ist, dass sich manche für die Codequalität schämen. Klar, ist sicher nicht alles "best practice", aber so schlimm kann es eigentlich dann auch nicht sein.
Wenn der Code so schlecht ist, dass man ihn nicht herzeigen kann, dann will man ihn dennoch produktiv nutzen? Da ist doch irgendwas faul.
"Inyoka wird OSS", das ist bei uns im Webteam/Serverteam schon immer eines der Ziele gewesen, es war aber nie das oberste Ziel. Unser oberstes Ziel ist nämlich das betreiben dieser Plattform, alles andere hat geringere Priorität.
Das ist ein Widerspruch. Die Plattform wird ja seit Jahren betrieben. Mit Problemen hier oder da wäre man also die ganze Zeit fertig geworden, so wie man es ja auch geworden ist.
Außerdem soll FOSS ja das Betreiben der Plattform unterstützen und verbessern. Nur wer denkt, dass FOSS schlechter geeignet ist uu.de zu betreiben kann argumentieren, dass anderes Priorität hätte.
Abgesehen von 2 Wochen, die es dauern kann, den Code in ein Repository zu packen und die Veröffentlichung umzusetzen, oder die 4 Wochen, an denen man an einem Cache-Problem arbeitet, das dringend gelöst werden muss, um verstärkter Nachfrage zu genügen. Aber nicht 4 Jahre.
Bitte beachten das ubuntuusers.de als Plattform (Software) etwas anderes ist als ubuntuusers.de als Plattform (Team,Community). Das englische Forum z.b. (ubuntuforums.org oder so) verwendet eine definitiv kommerzielle Software, wir sind immerhin schon beim Status "Nicht veröffentlichtes OpenSource" angekommen 😉
Das gibt es nicht. Es ist einfach beides Closed Source.
…dass das Projekt wohl sehr stark auf die Ubuntuusers-Situation zugeschnitten war und es sehr schwierig wäre…
Fixed, zumindest weitgehend.
Hätte man denen überlassen können, die es brauchen. Insofern widerspricht diese Aussage auch der Behauptung Priorität hätte das Betreiben der eigenen Plattform.
Ein zweiter Punkt, der hier durchscheint, ist, dass sich manche für die Codequalität schämen.
Entwickler sind Perfektionisten, wir habe mit Inyoka vieles durchgemacht und auch sehr viel gelernt. Am Anfang sollte alles Django sein, dann war (damaliger Zeitpunkt) das ORM für uns unbrauchbar und es gab RAW Queries und später dann SQLAlchemy und die Idee auf Werkzeug zu gehen. Jetzt haben wir alles bei Django (und natürlich einige andere Libraries).
Auch Blödsinn. Perfektionisten machen alles perfekt. Jemand der etwas nur auf später verschiebt und will, dass er als perfekt gilt, ohne es zu sein, ist ein Blender oder Heuchler. Unrealistische Ansprüche an sich selbst zu stellen kommt vor, aber ein Anspruch sollte auch sein verlässlich zu sein, ein anderer offen, ein dritter selbstkritisch, ein vierter pragmatisch, "getting things done".
Das größte Manko des Codes ist seit langer Zeit seine Lizenz. Priorität, wenn man dem OSS-Modell etwas zutraut, sollte sein den Code zu veröffentlichen.
Ich behaupte mal es wird ein neues Repo geben, ohne Historie. Das ist aktuell aber noch Zukunftsmusik, ich merke mir das mal als Input für den Artikel.
Ich behaupte mal, dass es keinen Menschen interessiert eine Codeschwäche irgendeiner Person anzulasten und rumzustänkern. Wer immer sowas tut soll den Code fixen und einchecken - dann sieht man ob es besser ist, und wenn es das ist, dann freut man sich was gelernt zu haben. Wenn es von einem Unsympath kam, dann hat man der Person wenigstens charakterlich was voraus - ist doch auch schön. 😉
Besteht vielleicht die Hoffnung, durch verkaufte Lizenzen viel Geld zu machen?
Derartige Planungen sind mir nicht bekannt.
Wunschträume, dass Shuttleworth den Code kauft und für mehrere, internationale Foren übernimmt - das begann ich nach einiger Zeit zu mutmaßen, nachdem sich anfängliche Behauptungen von Prioritäten als Hinhaltetaktik entpuppt haben. Es war die erste für mich nachvollziehbare Erklärung, wieso das nicht vorangeht.
mfg Stefan Betz
Pic oder didn't happen. ☺
Letzte Woche erst habe ich ein Video gesehen zu - tja, was war eigentlich das Hauptthema?
Es ging auch, meine ich, nicht um Open Source zentral - vielleicht um Code Reviews oder Pair Programming? Jedenfalls auch um die Angst des Programmierers das andere auf den Code kucken, und er ist nicht perfekt. Es war auch kein überwältigender Vortrag, aber ich dachte noch, dass man das doch bei ubuntuusers.de verlinken sollte, konnte aber erst den Vortrag nicht zu Ende sehen, und ich meine im weiteren Verlauf wurde er für mich ziemlich langweilig, und so habe ich den Link nicht gesichert, dachte aber noch, ich würde mich an genug Details erinnern um ihn problemlos wiederzufinden. Und jetzt straft mich das Leben lügen. ☺
Ich meine die Sache ist die, dass die anderen Programmierer so ähnlich auf Dich und mich reagieren, wie wir auf sie reagieren würden. Also niemand hat vor jemanden fertig zu machen. Man interessiert sich auch - so schade das auch ist - nicht für den Programmierer sondern für den Code. Oft schwanken wir zwischen Größenphantasien und Minderwertigkeitskomplexen - der beste Code den wir schreiben ist aber lange nicht so gut wie wir glauben, und das schlimmste nicht so arg wie wir denken.
Wenn jemand auf Anhieb etwas so viel besser weiß als wir, dann ist es vielleicht auch viel schneller das von ihm korrigieren zu lassen, als dass wir uns das mühsam beibringen, wenn wir die Todoliste soweit abgearbeietet haben, dass - was aber eh nie passieren wird. Auf allen diesen Listen steht ziemlich weit oben "Code dokumentieren" und der Punkt wird auch nie erreicht.
Hier kann niemand einen Entwickler rauswerfen, niemand das Gehalt kürzen oder sonstwas. Womöglich, wenn der Code offen ist, schaut ihn sich auch niemand an.
Wenn die Scham so groß ist, dann ist es übrigens auch wieder ein Grund den Code rasch zu veröffentlichen, denn dann werden die Entwickler nur noch Code einchecken, für den sie sich nicht schämen.
Da Du aber selbst sagst, die Ansprüche der Coder seien so hoch (Perfektionisten), wird es Zeit diese wirklichkeitsfremde Haltung zu zerstören, und mit einem heilsamen Schock für mehr Realitätsbewusstsein zu sorgen. Wer will kann dann ja 2 Wochen durcharbeiten, um die übelsten Baustellen zu flicken - in die Historie, was vorgestern war, schaut doch eh keiner rein, außer ein Fix führt zu neuen Problemen.
