Sneak preview of Burning Board 4.0

    Ich verstehe die Entscheidung Seitens WL schon, ich allerdings ist es auch eine Art Richtungswechsel. Während man vorher angekündigt hat, die Abhängigkeiten zu vereinfachen, und das WCF somit besser für vom WBB unabhägige Projekte zu öffnen, also vor allem Drittentwickler außerhalb des eigentlichen Fokuses des Frameworks anzusprechen, stehen nun direkt vor allem die Produkte von WL im Fokus.


    Wenn ich so etwas lese:

    Zitat

    The framework serves exactly 2 purposes:
    1) Building our products
    2) Provide an extensible interface to modify our products or add new features to them
    If you think the framework is suitable for your project: Perfect, feel free to use it then. If not: Pick a multi-purpose framework instead.


    dann frage ich mich doch ernsthaft: "Warum überhaupt das ganze Open Source entwickeln?". das liest sich ja mehr oder weniger so, als sei das ganze nur Open Source, damit die Community WoltLab ein wenig Arbeit abnimmt, damit die ihre Produkte bringen können. Vom eigentlichen Geist der Offenheit für Drittentwickler bleibt in so einem Statement wenig übrig.


    Das Problem ist, das man mit WCF 2.0 eigentlich einige der selben Fehler gemacht hat, wie im WCF 1.1. Anstatt rechtzeitig auf einem hoch genügenden Abstraktionslayer die Abhängigkeiten zu entkoppeln hat man sie wieder direkt ineinander verzahnt. Die jetzige Entwicklung ist da nur eine logische Konsequenz, und eigentlich eine Kapitulation und ein Scheitern an der Realität. Siehe PorstGre Support. Hätte man rechtzeitig auf ein hoch genügendes Abstraktionslaayer gesetzt, und z.B. auf der high-Level API gar keine Eingabe von SQL Statements erlaubt, sondern nur das Zusammenbauen von einzelnen Komponenten ala "new Insert($tableName).addRow($row).addRow($row2).addRow($row2)", dann hätte das jeweilige DB-Layer (MySQl, PostGre, IBM DB2, oracle) etc daraus im Hintergrund selbständig das für die jeweilige DB optimale SQl generieren können (in diesem Falle also je nach Db entweder das ganze als eine Bulk-Operation reinschieben können, oder als mehrere einzelne INSERT statements). So ist man gezwungen, weil man Raw-SQL Statements verwendet, hier MySQL spezifische Queries zu verwenden, was letzten Endes den PostGre-Support gekillt hat, und auch Drittentwicklern die Möglichkeit nimmt, jemals andere Datenbanken vernünftig zu unterstützen (außer man verwendet sehr, sehr, sehr sehr sehr viel schwarze Magie).


    In der derzeitigen Situation ist es insofern eigentlich eher logisch, aus den de-facto abhängigen Paketen einen monolithischen Kern zu bauen. Das ergibt in der derzeitigen Situation sicherlich Sinn. Für den benutzer ist das sicherlich Sinnvoll, so hat man in der paketliste hinter WCF, WBB sowie Blog, Galerie und Kalender, sowie einige Drittanbieterpluins. Das ist wesentlich übersichtlicher als vorher.


    Aus Entwicklersicht ist es ein wenig Schade, dass das WCF 2 kein wirklich sinnvoll außerhalb von WBB zu nutzendes Framework wird. ich denke durchaus, dass man auf lange Sicht einge interessante EAs aus dem WCF 2.0 hätte rausholen können, die vielleicht ganz unabhängig vom WBB gut gelaufen wären, was aber wiederum mehr Entwickler ans WCf gebracht hätte, mehr WCF plugins, evtl. einen steigenden bekanntheitsgrad von WL und somit mehr Kunden. So wird das WCF eingeschränkt auf "Ist eh hauptsächlich nur für uns gedacht", was eigentlich Schade ist. Vor allem weil noch vor gar nicht so langer zeit im Bugtracker über die bessere Trennung der pakete geredet wurde, und weil angekündigt war, die Abhängigkeiten zu entwirren und das ganze modularer zu machen. Nun auf einmal quasi eine 180 Grad Kehrtwende (oder zumindest das offizielle Eingeständnis, dass dies wohl vollkommen in die Hose ging).


    Für mich heißt das, das ich zwar zukünftig noch WCF Plugins entwickeln werde, und für Foren weiterhin WBB nutzen werde, aber andere Anwendungenw erden sicherlich nicht mehr auf WCf Basis entstehen. Was schade ist, denn ich bin dann gezwungen mir ein anderes Framework anzueignen, was im Umkehrschluss heißt, weniger zeit für WCF plugins zu haben, und mehr Beschäftigung mit anderen Dingen. Wodurch weniger WCF Plugins als nebenprodukt entstehen werden.


    ich hab mich allerdings inzwischen ganz gut damit abgefunden, dass dies so ist. ich war gestern abend sichtlich enttäuscht von der Entwicklung, aber was solls. That's life.

    Für die Nicht-Entwickler hier bzw. unter uns wird es schwer, dir komplett folgen zu können, Netzwerg, so dass ich gerne einhaken würde, in Ordnung? :)


    Als konkrete Verbesserungen für die Nutzer/Administratoren hieß es, dass so in der Methode "all-in-one" nicht mehr das Aussortieren/Hinzufügen, lange Paketlisten und somit auch das Abhängigkeitsproblem bestehen würden. Letzteres würde für mich subjektiv nachvollziehbar, logisch und ein realer Pluspunkt sein, die ersten beiden Punkte fallen für mich unter "Ok, aber fällt nicht weiter ins Gewicht".


    Meine erste Frage lautet nun: Ist so ein monolithisches Gesamtpaket in Punkto Performanzlast tatsächlich effizienter oder macht es keinen (großen) Unterschied?


    Meine zweite Frage lautet: Kann man grob sagen, wie oft/viele Probleme und Rückmeldungen rund um Abhängigekiten seitens der reinen Nutzer im Laufe der Zeit eingetrudelt sind? Das heißt, sprechen wir von einem globalen Problem, einem Problem für max. 10% der Nutzer oder dürfte die Zahl noch geringer sein?




    Die Vereinfachung für WoltLab hast du dargelegt und als plausibel charakterisiert, gleichzeitig hast du aber auch den Hinweis zur Abkehr des modularen Systems erwähnt.


    Frage 1: Ist es deiner Meinung nach aber wirklich realistisch, dass viele Drittanbieter das WCF für weitere Projekte/EAS etc. nutzen würden? Wenn wir uns jetzt einmal ansehen was wir haben, muss ich gestehen, ich könnte vielleicht 2, 3 solcher Abwandlungen aufzählen, aber mehr auch nicht. Gut, sicher ist nicht alles im produktiven Einsatz, könnte also intern verwendet werden (?), aber es ist wiederum nicht so, als würden sich viele Entwickler und auch Nicht-WBBler um das WCF reißen, oder sehe ich das falsch?


    Frage 2: Was ist aus deiner Sicht die Hauptaufgabe von WoltLab - WBB oder WCF? Damit meine ich, rangieren das Gerüst und fertige Produkt für dich auf der selben Höhe, du würdest also erwarten, dass beides auch bis zu einem gewissen Grad individuell voneinander weiterentwickelt wird, um eben z.B. WCF weiter zu gestalten, oder ist es nicht eher so, wie Tom meinte, erst kommt WBB, das Framework selber ist aber nicht dazu gedacht (gewesen), sich weiter und vielseitig/er zu entwickeln?





    Zitat von Netzwerg

    dann frage ich mich doch ernsthaft: "Warum überhaupt das ganze Open Source entwickeln?". das liest sich ja mehr oder weniger so, als sei das ganze nur Open Source, damit die Community WoltLab ein wenig Arbeit abnimmt, damit die ihre Produkte bringen können. Vom eigentlichen Geist der Offenheit für Drittentwickler bleibt in so einem Statement wenig übrig.


    Bei diesem Gedanken dürfest du einen wunden Punkt erwischt haben, der einigen Leuten im Kopf herumgeht. Ich gebe unumwunden zu, ich habe auch nicht recht nachvollziehen können, warum man den Aufwand mit GitHub betreibt, wenn Rückmeldungen dann negativ beschieden werden (in meinem Fall mit den ganzen Sprachdateien bzw. Korrekturen/Übersetzungen). Fachliche Debatten müssen sein und es ist absolut in Ordnung, wenn man nach einem Gespräch auf den hört, der die besseren/richtigen Argumente hat, aber das hat mir leider fast komplett gefehlt.


    Auf der anderen Seite muss man vielleicht in Hinblick auf die Fairness sagen, man wird es nie allen recht machen können, eine Software kann nie wirklich für "jedermann" geschneidert werden und wenn man nur vier unterschiedliche Leute entscheiden lassen sollte, dürfte man nicht einmal dann einhellige Entscheidungen vorfinden. Insofern heißt transparent bei WoltLab wohl, sie zeigen grob die Richtung und erlauben Einblicke, nehmen Einwände/Hinweise zur Kenntnis, aber werden am Ende eben doch so entscheiden, wie sie es für richtig halten, egal, ob gefühlt die halbe WBBlerschaft aufschreit.
    Wenn wir uns selber an die Nase greifen, würden wir es denn auch immer anders machen, Netzwerg?

    /edit: Wurde länger als geplant, kann Spuren von Ranting und technischem Bla Bla enthalten


    Zitat von Gabbid

    Meine erste Frage lautet nun: Ist so ein monolithisches Gesamtpaket in Punkto Performanzlast tatsächlich effizienter oder macht es keinen (großen) Unterschied?


    Es geht mehr darum, welche Features ich brauche. Das komplette User-System wurde in den Core gemerged. D.h., wenn ich jetzt ein Projekt auf WCF Basis realisiere, habe ich automatisch die User-Profile und die Mitgliederliste mit dabei. Auch wenn ich eigentlich nur ein Frontend ohne Login-Möglichkeit und ein ACP brauche. D.h. ich muss hier wiederum EventListener auf diese Seiten setzen, um den Kram eben nicht mehr erreichbar zu machen. Allerdings fliegen dann da unbenutzte Seiten rum, deren Aufrufen den PHP Interpreter zumindest startet (es sei denn ich kicke den Kram gleich per .htaccess raus), was natürlich nicht im Sinne des Erfinders ist. Außerdem wird das ganze, wenn ich mehr dieser Dinge deaktivieren will, zu einer Sysyphusarbeit und schlecht wartbar. Außerdem, wie siehst das denn aus, wenn ich in einer Application, in der ich 15 Dateien brauche, 100+ weitere, ungebrauchte einfach rumschimmeln habe?


    Probleme mit den Abhängigkeiten haben sich in meiner Erfahrung eher selten gegeben. Zumindest nicht bei meinen Paketen.


    Zu Frage 1.) das Problem am WCF 1.1.x war ja genau, dass man eben in bestimmte Dinge reingezwungen wurde. Im WCF 1.1.x hatten wir einen wahren Abhängigkeits-Dschungel. das user-Paket war vom Message Paket abhängig, welches vom BBCode und Attachement System abhing, welche vom ... du siehst wo das ganze hinführt (irgendwo fliegt dann beim Attachement System auch noch der Image-Viewer mit rum, u.v.m) ?
    Nun wurde als es aufs WCF 2.0 zuging angekündigt, man wolle die Abhängigkeiten vereinfachen, Pakete besser trennen oder an Stellen, wo Trennungen unsinnig sind, Pakete zusammenlegen. So weit, so gut. Ich habe allerdings bereits vor 1 1/2 Jahren auf bestimmte probleme hingewiesen, z.B. darauf, dass das Message-System viel zu eng mit dem BBCode System gekoppelt ist (cf. https://github.com/WoltLab/WCF/issues/375). Dort wurde damals bereits deutlich, dass Messsage-Paket und BBCode-Paket eigentlich gar nicht trennbar sind, zumindest nicht in der derzeitigen Form.
    Vor allem wenn man mal die damalige Aussage von A. Ebert genauer betrachtet:

    Zitat

    There already was a overhaul of BBCode system by improving the existing ones (e.g. the video bbcodes). Even though we can understand your needs, it still is a lot of work with just minor improvements [1]. Please do not misunderstand me, such an improvement is always appreciated [2], but we want to focus on getting all this stuff stable for now [3].


    Feel free to submit a pull request for additional events, I will be happy to merge it! Maybe we will focus on such BBCodes with the next version (WCF 2.1), but not for now. Sorry.


    Zu [1] natürlich ist das viel Arbeit, die nicht wirklich viel für WoltLab bringt. Hätte man mir allerdings damals zu verstehen gegeben, dass eine solche Entkupplung wirklich gewünscht ist, so hätte ich bis zum heutigen Zeitpunkt locker eine Überarbeitung des Message-Systems präsentieren können, die das BBCode System komplett vom Message System entkuppelt und die Wahl des Parsers (Markdown, Wiki Style Syntax) komplett dem Administrator überlässt. Damit wäre es übrigens auch möglich gewesen, das Forum komplett auf Markdown umzustellen via Drittanbieter Plugin. Ich hatte da bereits einige vielversprechende Ideen für (und angeboten, das ganze als Pull-request umzusetzen, "If something like this is worth consideration, i will start working on that and provide a demonstration / pull requests to message and BBCode system.").
    Im Lichte der letzten Aussagen von A. Ebert muss ich mich allerdings fragen, in wie fern [2] damals wirklich ehrlich gemeint war. Und [3] ist aus heutiger Sicht der Witz schlecht hin, das war im Januar '12, jetzt ist der Mai '13 bald rum.
    Der eigentliche Punkt ist: Die mangelnde Abstraktion / Entkupplung der Pakete war bereits vor mehr als 1 1/2 Jahren so offensichtlich, dass ich da einen Issue zu aufgemacht habe. Nicht im Allgemeinen, aber hier am speziellen Beispiel Message-System/BBCode-System. Man hätte entweder damals bereits beide Pakete mergen können, oder damals noch etwas tun können und die Pakete entkuppeln können, und gleich andere Pakete auf die selben Fehler zu untersuchen. Dies ist ausgeblieben. Und nun wird einem diese Entwicklung als "Vorteil für alle" verkauft. das ist es, was mich richtig ärgert.


    Der eigentliche Punkt ist aber, dass mit dieser unzureichenden Entkupplung auch die Attraktivität des WCF 1.x für andere EAs sank. Nun wurde angekündigt, man wolle aus den Erfahrungen und Fehlern von WCF 1.x lernen. Das ist zum Teil auch wirklich großartig gelungen, zum Teil aber auch, wie man hier deutlich sieht, auf gut deutsch richtig verkackt worden.


    Nicht falsch verstehen: WCF 2.0 ist immer noch ein extrem gutes Framework. Aber es hätte besser sein können. Nur dass WL manchmal echt stur ist. Im April 2012 habe ich auf einen möglichen Design-Flaw bei den DBOs aufmerksam gemacht, denn deren State ist nicht konsistent mit der Datenbank. (Was sich im übrigen mit einer etwas anderen DB-Abstrahierung hätte lösen lassen). 7 Monate später, im November 2012, ist das ganze dann auch das erste mal furchtbar in die Hose gegangen, als sich ein Bug in der Cronjob-Ausführung eben auf jene Design-Schwäche der DBOs zurückführen ließ. Aus Plugin_Entwickler Sicht ist das ganze immer noch eine Katastrophe, denn es nimmt mir de facto Einsteigspunkte in die API. Ich kann den Status eines DBOs zwar updaten, aber dieses Update wird nicht sichtbar für den Rest der programmausführung, sondern erst beim Neuladen der Seite. Oder, im schlimmeren Falle, wenn ein plugin eine neue Instanz des DBOs aus der DB liest. Dann existieren zwei DBOs, die die selbe Spalte in der DB referenzieren, aber unterschiedliche Stati haben. Auch schön sind Komplikationen bei mehreren Plugins. Mal angenommen, ich werde den Status eines DBOs aus, und setze darauf basierend einen neuen Status. Ein anderer Plugin-Ersteller macht das selbe, nur liest der dann den inzwischen veralteten Status aus, berechnet darauf basierend seine Updates und überschreibt damit anschließend meine Updates. Wie gesagt, es können da einige Probleme auftauchen. Aber das ganze war jetzt mehr ein Exkurs... (und meine Meinung, dass es sich hier um einen Design-Flaw handelt ist nur eine Meinung, man findet sicherlich auch einige gute Gründe für die derzeitige Umsetzung).


    Zum eigentlichen Thema: Es gab einige Schwächen, die das WCF 1.x nicht so attraktiv für eigene EAs machten. Nun hoffte man aufs WCF 2.0 und freute sich darauf, besser eigene EAs schreiben zu können, aber wir landen eigentlich fast wieder beim Status Quo. Insofern denke ich eher, dass mit der derzeitigen Ausrichtung des WCF eher ein Nischenprodukt für WoltLabs Anwendungen plus ein paar damit thematisch verwandte Anwendungen bleibt, sich aber nie groß für andere Projekte eignen wird.



    Frage 2.) Das ist eine geschäftspolitische Frage, und somit fällt es Marcel Werk zu, dies zu entscheiden, nicht mir.


    Ich kann nur die unterschiedlichen Möglichkeiten und ihre Konsequenzen betrachten. Ursprünglich war der Ton als es ums WCF 2.0 ging, anders. man wollte offener werden, besser für Drittentwickler, für andere Projekte abseits WBB. So klang das oft unterschwellig durch. Was auch durchaus kein schlechter Gedankengang ist, denn wenn das WoltLab Community Framework gerade international in anderen Projekten mehr in Einsatz käme, so wäre das durchaus eine sehr gute Werbung für WoltLab und somit auch eine Möglichkeit, Kunden zu gewinnen, mal ganz abgesehen davon, mehr Entwickler, die mehr Plugins (sowohl freie als auch kommerzielle) fürs WCF anbieten (und somit auch potentiell fürs WBB). Außerdem heißt mehr Entwickler auch mehr Hilfe an möglichen Weiterentwicklungen des Frameworks.


    In letzter Zeit scheint sich das ganze aber drastisch zu ändern: Was andere mit dem Framework machen ist uns egal, wir bauen unsere Produkte damit. Nun gut, das ist natürlich einfacher, ist aus wirtschaftlicher Hinsicht kurzfristig gesehen auch sicherlich sinnvoll. Macht langfristig das WCF aber nicht gerader breiter verbreitet. Hat aber sicherlich auch den Vorteil,dass man sich mehr auf sein Kerngeschäft konzentrieren kann.



    Für mich heißt die Entwicklung, dass ich sicherlich weiter Foren mit dem WBB betreiben werde, und auch weiterhin dafür entwickeln werde. Aber ich werde andere Projekte nicht mit dem WBB realisieren. Das bedeutet in der Konsequenz, es werden weniger Plugins fürs WCF nebenbei entstehen, und es bedeutet, ich werde meinen Wissenschatz auch in anderen Gebieten ausweiten, was dann natürlich Einschnitte auf dem Gebiet WCF bedeutet - ich kann mich eben auch nicht teilen oder mehr als 24h am Tag arbeiten / coden / studieren / whatever.
    Und das ist halt schon eine herbe Enttäuschung. Ich war in letzter zeit sehr mit studieren beschäftigt, und hab die neusten Entwicklungen nicht mehr so stark mit verfolgt. Sonst wären mir einige der probleme evtl. schon eher aufgefallen, und ich hätte mich innerlich schon länger darauf vorbereiten können, dass da einiges in eine Richtung läuft, die anders als Anfangs, nun nicht mehr so mit meinen Plänen zusammenpasst.

    Sebastian trifft den Nagel so ziemlich auf den Kopf. Leider.


    Wir haben für die Umsetzung zukünftiger Projekte und Ideen fest mit dem WCF 2.0 gerechnet und ich war immer ein Verfechter des Community Frameworks. Mittlerweile schlägt meine Stimmung aber doch schon recht stark in eine andere Richtung um. Die Art und Weise wie WoltLab kommuniziert oder der generelle Umgang mit Entwicklern auf GitHub ist echt erschreckend.


    Ein kleines Beispiel: Im Laufe der Entwicklung mit dem WCF 2.0 haben wir einen Fehler bei der Aktualisierung der Anzahl der Einträge in Tabellen im ACP festgestellt. Das bedeutet: Du löscht einen Eintrag über das X-Icon und bestätigst. Nun kann es aber sein, dass aus irgendeinem Grund (Permission, fehlerhafter Link, etc.) die Löschung nicht durchgeführt wird. Der Eintrag verschwindet (optisch) trotzdem. Dazu kommt, dass bei einer erfolgreichen Löschung eines Eintrages die Anzahl nicht aktualisiert wird. Bei einem Framework was so derbe auf JavaScript setzt, ist das eigentlich ein No-Go.
    Wir haben diese Fehler behoben und per Pull-Request gepushed. Das Debuggen, Fixen, Testen und Deployen war keine Sache von 2 Minuten und es handelt sich dabei nun mal um Fehler. Ende vom Lied: Binnen 5 Minuten war der Pull-Request mit der Begründung: "...funktioniert nicht bei Zahlen >999.." geschlossen (Zahlformatierung: 1.000). Selbst meinem Vorschlag das Problem ebenfalls zu beheben, wurde keine weitere Beachtung geschenkt, für WoltLab war das damit erledigt.


    Wir haben im Übringen noch weitere schwerwiegendere Fehler festgestellt. Scheinbar wurde bereits in der Konzeption an einigen Stellen ein ziemlicher Bock geschossen. Naja, jeden aktuellen und zukünftigen Entwickler wirds freuen...



    Das Fazit der ganzen Geschichte und vorallem was ich daraus ziehe, dass wir für unseren Teil ebenfalls vermehrt auf andere Frameworks setzen werden. Natürlich wird das auch die geplante Veröffentlichung von verschiedenen Erweiterungen und Applikationen für das WCF 2.0 entwickeln. Welche und wieviele wir nun tatsächlich umsetzen und veröffentlichen werden, kann und will ich zum jetzigen Zeitpunkt noch nicht sagen. Warten wir einfach die aktuelle Entwicklung ab. Für uns als Unternehmen ist das nämlich existenziell. Die Hoffnung stirbt zu letzt.

    Irgendwie glaube ich noch immer nicht recht, dass gerade ich an dieser Gesprächsrunde teilnehme, aber wer A sagt usw. :D
    Ok, ich bemühe mich alles zu verstehen, bin aber noch dabei einzelne Details nachzuschlagen und für mich zu "übersetzen", von daher werde ich nach und nach einflechten, was ich noch zu sagen/fragen habe. Aber, ich finde es toll, dass ihr euch die Mühe macht auch solche Themen den "normalen" Nutzern begreiflich zu machen, das ist nicht selbstverständlich, habt also vielen Dank dafür! :)



    Wir haben also nun diesen Core-Paket und das wird eben auch Dinge behalten, wie man nicht immer braucht. Gleichzeitig meine ich aber gelesen zu haben, dass Herr Werk schrieb, nicht alles wäre drin, wir können doch dann davon ausgehen (?), dass z.B. neben dem Like-System noch mehr deaktivierbare Einzelmodule nicht integriert sein werden, also haben wir am Ende zwar schon ein kompaktes Endsystem, aber gleichzeitig entfallen auch Dinge. Wie realistisch ist es eurer Meinung nach, dass WoltLab nun doch hingeht und zwar bei dieser Grundidee bleibt, aber doch weitere modulare Einheiten "abkapselt"?



    Worüber ich nachdenke, ist, ob wir nicht zu viel vom WCF erwartet haben und wollen. Korrigiert mich bitte, aber dachtet ihr ernsthaft, dass ein doch recht kleines Unternehmen wie WoltLab wirklich hergehen wird, ein WCF von der Community-Ebene hin zu einer Framework-Ebene mit weiteren Modulen usw. erweitern würde, so dass WCF am Ende mit z.B. diesem Zend konkurrieren könnte? Sicher, es wäre toll und ich durfte sogar schon einmal schauen, was mit Zend möglich ist, aber WCF sehe ich nicht in der gleichen Liga, es bleibt einfach zu sehr in der nationalen Community-Ebene verhaftet. Gut, man kann spekulieren, ob sich das als Fehler herausstellen wird, ob man da nicht aufs falsche Pferd setzte und schon früher hätte zweigleisiger fahren sollen, aber dazu braucht es Leute, eine Vision und dass man eben globaler denkt (ohne WoltLab zu nahe treten zu wollen).
    Muss man dann also nicht sagen, dass eure Gedanken und Wünsche gerade als Entwickler verständlich sind, ihr aber im Vergleich zum typischen WBB-Klientel eine geringere Quote darstellt, es auch nicht anzunehmen ist, dass mit einem multifunktionaleren WCF plötzlich 200 neue Entwickler geben würde?




    Eure Erfahrungen mit den Hinweisen und Einwürfen via GitHub sind leider so, dass ich es nachvollziehen kann.
    Tom hat seine Erfahrungen in der Richtung gemacht, ich neulich eben mit den Korrekturen/Übersetzungen. Das Problem sehe ich ganz klar darin, dass ich nicht die Entscheidung zugunsten fachlich begründbarer Aussage sehe, sondern andere Gründe im Spiel sind. Ich möchte da gar nicht so weit gehen und etwas unterstellen, Alexander Ebert hat sich die Zeit genommen mir ausführlich zu antworten und das zeugt zumindest von Höflichkeit. Gleichzeitig, so Leid es mir tut, kann ich das nicht als Erklärung gelten lassen, da der fachliche Austausch fehlte.
    Eure Erfahrungen gehen in die selbe Richtung, ich kann nur spekulieren, aber mich irritiert, dass immer wieder der Zeitfaktor eingeworfen wird. Natürlich will ich nicht unverschämt erscheinen, noch dazu als Nicht-Entwicklerin, aber ich unterstelle, dass man sich bei einem Projekt von dieser Größe sehr lange vorab Gedanken macht, das nicht quasi schnell mal binnen 6 Wochen auf dem Reißbrett konzipiert und dann runterprogrammiert. Also wird man doch auch schon vorab Pros und Contras diskutiert haben, wird immer schon einen Schritt weiter gedacht haben, eben so, wie ich das bei euch Entwicklern sehe und miterlebe. Für mich passt es also nicht ins Bild, warum scheinbar "spontan" Pläne verworfen werden, es plötzlich so eilt, mal verworfen, dann zugesagt wird etc. Ich gebe es offen zu, wäre es nicht WoltLab, sondern einer von euch, würde ich sicher nachgefragt haben, ob da alles wirklich durchdacht wurde und/oder ob ihr euch nicht übernommen habt.
    Von eurer Wahrnehmung her, wo liegt für euch das Problem, warum läuft es so, wie wir das gerade erleben?





    (Hervorhebungen von mir)

    Zitat von Netzwerg

    Ich kann nur die unterschiedlichen Möglichkeiten und ihre Konsequenzen betrachten. Ursprünglich war der Ton als es ums WCF 2.0 ging, anders. man wollte offener werden, besser für Drittentwickler, für andere Projekte abseits WBB. So klang das oft unterschwellig durch. Was auch durchaus kein schlechter Gedankengang ist, denn wenn das WoltLab Community Framework gerade international in anderen Projekten mehr in Einsatz käme, so wäre das durchaus eine sehr gute Werbung für WoltLab und somit auch eine Möglichkeit, Kunden zu gewinnen, mal ganz abgesehen davon, mehr Entwickler, die mehr Plugins (sowohl freie als auch kommerzielle) fürs WCF anbieten (und somit auch potentiell fürs WBB). Außerdem heißt mehr Entwickler auch mehr Hilfe an möglichen Weiterentwicklungen des Frameworks.




    In letzter Zeit scheint sich das ganze aber drastisch zu ändern: Was andere mit dem Framework machen ist uns egal, wir bauen unsere Produkte damit. Nun gut, das ist natürlich einfacher, ist aus wirtschaftlicher Hinsicht kurzfristig gesehen auch sicherlich sinnvoll. Macht langfristig das WCF aber nicht gerader breiter verbreitet. Hat aber sicherlich auch den Vorteil,dass man sich mehr auf sein Kerngeschäft konzentrieren kann.

    Dazu würde ich diese Anmerkungen einwerfen:


    Problem 1: WBB war und ist selber nicht wirklich als internationale Software einzustufen, warum sollte ein WCF da attraktiver sein und mehr Nicht-Muttersprachler anlocken? Wir haben auch nicht allzu viel Wechsler, also Leute, die von einer anderen Software umsteigen, die Leute, die das tun, dürften sich doch in einem minimalen Spektrum bewegen, richtig?


    Problem 2: Es wäre mehr eine Art indirekte Werbung, würde ich sagen. Der Grund, die Leute nehmen zwar das fertige WCF als Produkt, aber basteln damit herum, nutzen es wiederum für sich und/oder ihre Kunden. Folge: Die Entwickler bekommen das Lob und ggf. den Profit, nicht zwangsläufig und sofort WoltLab.


    Problem 3: Die Anzahl der Entwickler innerhalb der WBB-Welt ist überschaubar, kann man sagen. Von diesen Leuten kann man recht schnell zwischen "gut" und "weniger gut" differenzieren, dann ziehen wir noch die ab, die kostenlos entwickeln und die, die kommerziell agieren. Mit diesen Aussagen im Hinterkopf - ist es da wirklich realistisch, dass ein multifunktionaleres WCF mehr reale Entwickler (wirklich Entwickler, nicht Leute, die Code zusammenfrickeln) hervorbringen würde und das noch in den Dienst der WBB-Community gestellt werden würde? Nennt mich ruhig pessimistisch, aber ich zweifle da doch leicht...


    Problem 4: Das Kerngeschäft ist und bleibt WBB, wäre das seitens WoltLab anders geplant gewesen, wäre die Software marketingtechnisch und in Punkto globalem Einsetz auch für Nicht-Deutsch schon anders angelegt worden. Das Image steht, wird sich nicht um einige Änderungen verändern und am Ende des Tages geht es dem Unternehmen nicht um die Entwickler, Designer oder Nutzer, sondern um die verkauften Lizenzen. Ja, sie stellen den PluginStore zur Verfügung, stellen bei GitHub Inhalte hinein und versuchen mit den Nutzern zu kommunizieren, aber das dient doch einem klaren Zweck. Von daher muss man wohl konstantieren, dass einige Leute mehr Weitsicht haben, mehr Potenzial sehen und auch andere Optionen, das aber seitens des Unternehmens nicht so gesehen und angegangen wird. Warum? Man müsste spekulieren, was also nichts bringt.

    Mal die andere Frage Gabi, glaubst du WoltLab ist mit dem Status Quo, also der Tatsache, hauptsächlich auf dem deutschen Markt tätig zu sein, und international eher unbekannt, zufrieden? Wenn ja, dann erübrigt sich eine weitere Diskussion, aber dann hätte man in der Vergangenheit gar nicht erst bestimmte Weichenstellungen vornehmen müssen/sollen.


    Niemand erwartet vom WCF so wie das ZF zu werden. darum gehts hier auch gar nicht. Das WCF bietet eigentlich bereits genug Funktionen, der Umfang des Frameworks an sich (d.h. Core & Zusatzpakete) ist wunderbar bemessen für viele Aufgaben und bietet eine gute Ausgangsbasis für Erweiterungen.


    Zitat

    Von eurer Wahrnehmung her, wo liegt für euch das Problem, warum läuft es so, wie wir das gerade erleben?


    Wenn ich einen Schuss ins Blaue wagen dürfte würde ich sagen, dass der Druck auf Woltlab in letzter zeit erheblich steigt (bzw. sie sich den ganzen Kram zum Druck machen), und deshalb nun extrem gepusht wird, um das WBB endlich rauszubringen. dabei bleibt Qualität auf der Strecke. dazu kommt noch, dass eben einige Fehler schon vor Jahren im Anfangsstadium gemacht wurden, und jetzt zeigen sich halt deren Konsequenzen.


    Was halt schade ist, dass sich nun halt deutlich zeigt, dass einige der großen Pläne mit denen WCF 2 angegangen wurden, nicht mehr haltbar sind, und viel Potential verschenkt wird. Warum? Nun, ich weiß es nicht so genau. Interessiert mich aber auch nicht so genau, was WL da für Beweggründe hat. ich sehe nur die Konsequezen ihres handelns.