Betriebssystem-und Python-versions feld.

[/me]

Demokratur heisst das.

Für die Leute, die Dalli Dalli mit Hans Rosenthal noch kennen:
"Demokratur haben wir doppelt, das müssen wir leider einmal abziehen."

[Leonidas]

Dieses Forum soll demokratisch geführt werden, d.h. über große Änderungen wird nicht nur Disskutiert, sondern Abgestimmt.

Soviel zum Tehma keine demokratie im forum ...

Also bei diesem Thema scheint unsere Demokratur sich den demokratischen Verhältnissen anzupassen. 2 dafür 23 dagegen 2 egal, das sieht für mich ziemlich nach "mit absoluter Mehrheit abgelehnt" aus.

Py-Prog, ich weiß ja dass du dieses Feature willst, aber du bist halt in einer Minderheit, Demokratie oder Demokratur hin oder her.

[Py-Prog]

Ich weiß das ich in der minderheit bin, und somit nicht's geändert wird.
Aber wenigstens bin ich nicht allein in der minderheit.

[jens]

Kommentar zum Thema „Inyoka und das Open Source Release”: http://behind.ubuntuusers.de/2010/09/23 ... ce-release

[snafu]

Kommentar zum Thema „Inyoka und das Open Source Release”: http://behind.ubuntuusers.de/2010/09/23 ... ce-release

Ich finde es sinnvoll, den Leuten mal bewusst zu machen, wieviel bereits aus dem Projekt hervorgegangen ist. Wäre natürlich wünschenswert, wenn noch weitere Teilbereiche "outgesourced" werden. So nähert man sich dann häppchenweise dem Ziel, ohne dem Druck zu unterliegen, dass man sich übernommen hat; eben dem Fehler vom letzten Mal.

[Dav1d]

Es muss ja gernicht OpenSource werden, man könnte es dem deutschen py-forum auch zum testen geben

[derdon]

Dav1d: und dann kracht es, Datenbanken werden beschädigt und Datensätze können nicht wiederhergestellt werden. Dann muss nach Hilfe gefragt werden; darauf ist das webteam von inyoka aber einfach nicht vorbereitet, weil sie andere Sorgen / Prioritäten haben.

[lunar]

@derdon: Ich bin sicher, Du kennst die Bedeutung des Wortes „Testen“, und ich glaube, Du hältst die hiesigen Administratoren auch nicht für so dumm, eine neue und erkennbar instabile (es ist ja nicht so, als würde ubuntuusers.de wirklich stabil laufen) Software auf Produktivdaten loszulassen.

Außerdem weißt Du genauso gut wie alle anderen hier, dass wir uns in einem Python-Forum befinden (das ist ja nicht zu übersehen), und das einige der Anwesenden durchaus die Kompetenz besitzen, sich in fremden Python-Quelltext einzuarbeiten, und somit fähig sind, zumindest kleinere Fehler auch ohne Hilfe der Entwickler zu korrigieren.

Was also wolltest Du jetzt mit diesem Beitrag sagen?

[snafu]

Ich möchte mir natürlich keine Moderatorenstellung zum Thema "Inyoka" herausnehmen, aber die zwei Parteien lassen sich wohl wie folgt in ihrer Meinung zusammenfassen:

Partei 1 sind die Entwickler und Unterstützer des Kurses der Entwickler: 1. Code sollte nicht veröffentlicht werden, da zu speziell. Es existiert zudem keine Doku, usw. 2. Auch würde eine Veröffentlichung Support-Anfragen bedeuten. Man würde vermutlich schrittweise genau zu dem gedrängt werden, was man vermeiden will, da man in der Vergangenheit schlechte Erfahrungen damit gemacht hat, solch ein Projekt öffentlich einsehbar zu machen. 3. Den Anfragenden scheint es mehr oder weniger um's Prinzip zu gehen. Sie haben eh kein Interesse am produktiven Einsatz, schon gar nicht daran, sich selbst am Projekt zu beteiligen. Sie wollen teilweise einfach nur ein kostenloses und idealerweise fertiges Produkt vorgesetzt bekommen (übertrieben gesagt).

Partei 2 sind die Kritiker an der Entscheidung: 1. Codeveröffentlichung bedeutet einen Lerneffekt - einfach mal hinter die Kulissen schauen zu können, selbst wenn es nicht allgemein anwendbar ist. 2. Mit diesem Bewusstsen geht auch einher, dass man sich auf fehlende Doku - sprich: Lernen aus dem Quelltext - einstellt und auch keinen Support verlangt. 3. Die Entwickler verstoßen mit ihrer Haltung gegen bewährte Prinzipien, die eben auch das ausmachen, was von der Plattform behandelt wird: Linux bzw Ubuntu mit der entsprechenden Philosohpie. Das ganze hätte schon gewissermaßen etwas properietäres an sich. 4. Potenzielle Helfer würden vergrault und hätten niemals eine Chance, zu entscheiden, inwiefern sie helfen können, da sie den Code nicht kennen.

Insbesondere zum letzten Punkt 4 kommt dann das Angebot, dem Webteam beizutreten, wodurch die Forderungen erfüllt würden. Und genau hier verstehe ich die Kritiker ehrlich gesagt nicht: Warum nörgelt man rum, anstatt einfach mal dieses Angebot wahrzunehmen? Geht es vielleicht am Ende doch nur um's Prinzip? Bedeutet Freie Software letztlich, dass man Code, über den man einmal berichtet hat oder ihn gar zur Anwendung freigegeben hat, zwingend veröffentlichen muss, egal in welchem Status? Ist diese Denke/Anforderung dann wirklich noch als "frei" zu bezeichnen?

Ich greife an dieser Stelle nochmal Dinge auf, die bereits in der Diskussion (vornehmlich auf uu.de) angesprochen wurden: Wieviel bringt es einem Projekt gemessen an Beispielen aus der Praxis, wenn es Open Source wird? Insbesondere: Wieviel bringt es einem vermutlich noch recht unstrukturiertem Projekt? Man kennt von hier im Forum ja durchaus all die gutgemeinten (und an sich auch sinnvollen) Ratschläge in Bezug auf PEP 8 usw. Einerseits bedeuten sie eine konstruktive Kritik an der Herangehensweise, andererseits wird auch gerne bemängelt und selten eine Alternative vorgeschlagen (ok, bei PEP 8 reicht die Verlinkung, aber es gibt genügend andere Beispiele). Anders gesagt: Wieviel verwertbaren Input bringt einem sowas, um das Projekt nach vorn zu bringen? (Immer im Hinterkopf behaltend, was ohne eine Veröffentlichung wäre) Hält es nicht am Ende sogar die Entwicklung eher auf als dass es sie fördert?

Dann gibt es wiederum ein imho sehr gutes Argument *für* die Veröffentlichung: Der halbgare Code könnte von Freiwilligen dokumentiert werden. Man könnte außerdem einen Fork kreieren, der allgemein verwendbar ist. Da dies nicht passiert, ist m.E. die Vermutung, dass es gewissen etablierten Entwicklern ein bißchen peinlich ist, den Code zu veröffentlichen, nicht ganz aus der Luft gegriffen; auch wenn dies nicht mehr als Mutmaßungen sind.

Mein Fazit ist daher: Kritik (z.B. auch meine) sollte als Denkanstoß dienen, sofern sie human geäußert wird. Letztlich sollte aber die Entscheidung der Entwickler akzeptiert werden. So wie ich eine Lizenz aussuchen kann, muss ich auch entscheiden dürfen, wann ich wieviel Code veröffentliche. Ich selbst entwickle ja auch (wohl mehr schlecht als recht) an verschiedenen privaten Hobby-Projekten und würde euch - ganz offen gesprochen - dem Mittefinger zeigen, wenn jemand ankäme und verlangen würde, dass ich das, was ich bis jetzt habe, doch gefälligst als Release 0.1 (oder was weiß ich) veröffentlichen soll.

Code wird genau dann veröffentlicht, wenn man der Meinung ist, dass er als Basis dienen kann, die sich auch so schnell nicht verändern wird. Und gerade diese Veränderung passiert im Anfangsstadium ja noch recht häufig. Nichts hasse ich mehr als eine Roadmap oder Forderungen, die in die besagte Richtung einer Veröffentlichung gehen. Sicher, für den Anwender ist das super, weil er sich auf etwas greifbares - festterminiertes - einstellen kann. Wir wissen aber alle, dass termingerechte Releases häufig auch nicht so das gelbe vom Ei sind.

Von daher finde ich bei all der verständlichen Ungeduld, insbesondere für's Python-Forum, dass man Inyoka solange reifen lassen sollte, wie es nötig ist. Mir will doch wohl keiner ernsthaft erzählen, dass er sich nach Veröffentlichung der "pre-Alpha" von Inyoka ernsthaft an eine Portierung setzen wird. Wir werden halt weiterhin bei PHP bleiben müssen, außer jemand mit Ahnung und der nötigen Zeit nimmt das in die Hand, was aber derzeit nicht absehbar ist.

[jens]

Insbesondere zum letzten Punkt 4 kommt dann das Angebot, dem Webteam beizutreten, wodurch die Forderungen erfüllt würden. Und genau hier verstehe ich die Kritiker ehrlich gesagt nicht: Warum nörgelt man rum, anstatt einfach mal dieses Angebot wahrzunehmen?

Auch wenn ich mich wiederhole: Zumindest ich habe keine Lust meine wenige Freie Zeit mit einem de-facto nicht OpenSource Projekt zu widmen. Kann mir vorstellen, andere Denken ähnlich...
Soll ich ins Webteam "eintreten" nur um mal zu sehen, ob ich damit was anfangen kann? Ob ich mithelfen möchte?

Code wird genau dann veröffentlicht, wenn man der Meinung ist, dass er als Basis dienen kann, die sich auch so schnell nicht verändern wird. Und gerade diese Veränderung passiert im Anfangsstadium ja noch recht häufig. Nichts hasse ich mehr als eine Roadmap oder Forderungen, die in die besagte Richtung einer Veröffentlichung gehen.

Es kommt darauf an, ob man es mit großem tatarata veröffentlicht oder einfach nur den Sourcecode öffentlich zugänglich macht.
Erstellt man eine Webseite und erzählt was von der "ultimative Community Plattform." oder stellt einfach die Sourcen auf gihub und macht ansonsten nix weiter, schreibt sogar dabei: "nicht nutzbar", "Keine Dokumentation", "kein Support"

Ich hab auch einen Haufen Code einfach auf github gepackt: http://github.com/jedie/python-code-snippets
Mit dabei ist uralter Mist, der eigentlich für niemanden nutzbar sein dürfte, aber was solls?

[lunar]

@snafu: So einfach ist es nicht, das Angebot, dem Projekt beizutreten, kann die Möglichkeit, den Quelltext unverbindlich einzusehen, nicht unbedingt ersetzen.

Der Beitritt zu einem Projekt impliziert eine gewisse Verpflichtung, tatsächlich größeres Engagement für dieses Projekt zu zeigen, wichtige Beiträge zu leisten, und letztlich die eigene Freizeit zu opfern. Im Falle Inyokas kann man aber vorher gar nicht feststellen, ob Projekt und Quelltext überhaupt dieses Engagement wert sind. Inyoka verwehrt Entwicklern die übliche schrittweise Beteiligung von anfänglichen, kleinen und unverbindlichen Patches bis hin zum späteren Beitritt, sondern fängt gleich beim Beitritt an. Vom Entwickler verlangt das einen ordentlichen Vorschuss an Vertrauen und Interesse, den aufzubringen nicht jeder bereit ist.

inyoka ist eben wie ein Blind Date ... und so nötig habe ich es nicht. Meine begrenzte Freizeit investiere ich (wenn überhaupt) lieber in Projekte mit geringeren Hürden. So unzufrieden bin ich mit phpbb in diesem Forum auch nicht. Das nur als Erklärung, warum es für meinen Teil eben nicht dasselbe ist ...

[jbs]

@snafu: So einfach ist es nicht, das Angebot, dem Projekt beizutreten, kann die Möglichkeit, den Quelltext unverbindlich einzusehen, nicht unbedingt ersetzen.

Der Beitritt zu einem Projekt impliziert eine gewisse Verpflichtung, tatsächlich größeres Engagement für dieses Projekt zu zeigen, wichtige Beiträge zu leisten, und letztlich die eigene Freizeit zu opfern. Im Falle Inyokas kann man aber vorher gar nicht feststellen, ob Projekt und Quelltext überhaupt dieses Engagement wert sind. Inyoka verwehrt Entwicklern die übliche schrittweise Beteiligung von anfänglichen, kleinen und unverbindlichen Patches bis hin zum späteren Beitritt, sondern fängt gleich beim Beitritt an. Vom Entwickler verlangt das einen ordentlichen Vorschuss an Vertrauen und Interesse, den aufzubringen nicht jeder bereit ist.

Kann ich fast nur zustimmen.

Zudem: Die Aussichtstellung auf einen Release, den es ja gab, weckt einfach große Erwartungen.

[Hyperion]

Man sollte den Entwicklern jedoch zu gute halten, dass sie für uu.de eine schöne Lösung implementiert haben; zumindest für den Benutzer wirkt das ganze recht rund und durchdacht. Ob die Lösung nun extrem speziell ist oder nicht, vermag man eben ohne Einblick in den Quellcode nicht abzuschätzen.

Prinzipiell würde ich denken, dass es vor allem an fehlenden Templates, Style-Dateien usw. liegt, denn an "speziellem" Code. Ich würde da den Entwicklern mal genügend Erfahrung attestieren, dass es in der Software selber keinen "ubuntu"-String gibt

Für uns Python Begeisterte ist inyoka im jetzigen Zustand ehrlich gesagt fast ein Hemmschuh, eben weil es so gut wirkt, aber leider für uns nicht nutzbar ist. Ohne inyoka könnte es evtl. genügend Leute geben, die an einer Eigenentwicklung Interesse hätten; mit inyoka als eine Art positives Damoklesschwert sieht es damit eben leider mau aus.

Eigentlich schade, gab es hier doch schon einige tolle Ideen hinsichtlich der Funktionalität... ich erinnere mich da an ein Posting von sma, in dem er ein einfaches und dennoch effizientes Datenmodell beschrieben hatte, welches universell für Forenpostings, Artikel und Blogeinträge gültig sein kann und nur durch "Views" bzw. den Kontext entsprechend interpretiert wird. Das ganze kombiniert mit einer No-SQL DB a la Mongodb oder Couchdb und den entsprechenden "Web"-Libs (z.B. flask / werkzeug, wtforms, jquery, pygments, ...) und man könnte da schon was hübsches kreieren

Nuja, auch im Fiat kann man zu Audi zur Arbeit fahren; dennoch mag es den ein oder anderen "Verkauf" erschweren, wenn man mit fremden Technologien unterwegs ist.

[jens]

Und weiter geht's in Endlosschleife: Kommentar zum Thema „Inyoka und das Open Source Release” #2

Das ist IMHO auch interessant: onli blogging - Ubuntuusers: Ein Team in Geiselhaft?

[lunar]

@jens: Ich finde diesen Artikel nicht interessant, sondern reichlich lächerlich. Es ist mir vollkommen unverständlich, wie man sich über eine solche Kleinigkeit wie die Implementierung von Zeilenumbrüchen derartig echauffieren kann, dass man mit der Waffe des eigenen Austritts drohen muss.

Den Kommentar vom Webteam habe ich ehrlich gesagt gar nicht vollständig gelesen, den den ersten Absätzen nach zu urteilen, arbeitet er sich nur wieder an den ewig gleichen Argumenten ab.

[Hyperion]

@jens: Ich finde diesen Artikel nicht interessant, sondern reichlich lächerlich. Es ist mir vollkommen unverständlich, wie man sich über eine solche Kleinigkeit wie die Implementierung von Zeilenumbrüchen derartig echauffieren kann, dass man mit der Waffe des eigenen Austritts drohen muss.

Auch wenn's abgegrabbelt ist werfe ich mal das Stichwort "Inaterface-Nazis" rein. Manchmal muss man den Benutzern auch mal etwas zutrauen bzw. ihm abverlangen dürfen. Das scheint der OP so nicht zu sehen...

Den Kommentar vom Webteam habe ich ehrlich gesagt gar nicht vollständig gelesen, den den ersten Absätzen nach zu urteilen, arbeitet er sich nur wieder an den ewig gleichen Argumenten ab.

Leider ja.

[lunar]

@Hyperion: Es geht dabei wohl weniger um echte Überzeugung – eine „Ideologie“ auf Basis von Zeilenumbrüchen muss doch jedem einigermaßen lächerlich erscheinen –, sondern vor allem um allerlei persönliche Befindlichkeiten.

[Hyperion]

@Hyperion: Es geht dabei wohl weniger um echte Überzeugung – eine „Ideologie“ auf Basis von Zeilenumbrüchen muss doch jedem einigermaßen lächerlich erscheinen –, sondern vor allem um allerlei persönliche Befindlichkeiten.

Ja, ist so ein wenig "Grund oder Anlass" oder auch "Henne-Ei". Mag schon sein, dass es mehr Deckmantel ist, als Überzeugung; ich kenne mich mit den Interna im uu-Team nicht aus und kann den OP auch nicht einschätzen. Diese Vermischung der Kritik an der Nicht-Veröffentlichung zusammen mit einer technisch und sozialen Entscheidung gemixt mit persönlichen Konsequenzen empfand ich auch als eher lächerlich

[/me]

Den Kommentar vom Webteam habe ich ehrlich gesagt gar nicht vollständig gelesen, den den ersten Absätzen nach zu urteilen, arbeitet er sich nur wieder an den ewig gleichen Argumenten ab.

Sollen sie doch offen mit dem Thema umgehen: "Wir hatten nie ein richtiges Konzept und haben je nach Notwendigkeit etwas zusammengestrickt. Jetzt passt alles hinten und vorne nicht zusammen und die Dokumentation sieht damit auch entsprechend miserabel aus. Das wollen wir im Moment wirklich keinem zeigen."

Das ist zumindest das, was ich daraus lese und die Begründung würde ich sogar verstehen.

[jens]

Aber auch wenn es einen Haufen Müll ist. Was soll's. Sie sollten es dennoch auf github packen und fertig. Dann kann sich jeder selbst ein Bild von machen...

Das "Support-Anfragen" kommen werden, ist klar. Die kann man aber genauso Abbügeln, wie die jetzige immer wieder kehrende Frage, nach der Veröffentlichung der Sourcen...