Erweitern der Contenido API

[xmurrix]

Eine weitere Umfrage bezüglich der Möglichkeiten zur Weiterentwicklung von Contenido.

Das CMS hat eine reichhaltige API, aus der sich Modul-/ und Pluginentwickler bedienen können. Dennoch kommt man hin und wieder an die Grenzen der API und man wünscht sich etwas mehr Flexibilität und weitere Features.

Eine Lösung dazu möchte ich hier vorstellen, gleichzeitig soll die Umfrage einen Hinweis auf die Vorstellungen/Wünsche der Community geben:

PHPLib:
Die verwendete PHPLib lässt sich sehr gut modifizieren. Sie ist sozusagen der Urvater aller PHP-Frameworks, die es heutzutage gibt. Auch wenn die neuen Frameworks in mancher Hinsicht viel mehr können, ist die PHPLib immer noch brauchbar. Sie bietet DB-Abstraktion (im Großen und Ganzen), Authentifiszierung, Session Handling, usw...
Diese Feautres der PHPLib lassen sich auch etwas Modifizieren/Erweitern, so dass man an die Anforderungen der heutigen Zeit näher kommt.

Erweitern der API:
Die API könnte um ein paar neue Features erweitert werden. Ich denke dabei an eine einigermaßen saubere Behandlung der globalen Variablen, Schnittstellen für Konfiguration, Request-Handling, Response-Handling, Erweitertes Templatesystem, uvm.
Dadurch hätten Modul-/Pluginentwickler eine Sammlung von weiteren Werkzeugen. die einem die Arbeit mit Contenido erleichtern/verbessern.

Es geht hierbei um die Erweiterung der API, nicht um ein komplettes Redesign des Core. Dennoch muss man mit ein paar Kompatibilitätsproblemen rechnen, vor allem wenn die neue Version mit alten Third Party Modulen/Plugins laufen soll.

Grüße
xmurrix

[thepoet]

Hier ein paar Gedanken/Wünsche, die meinereiner zu der Thematik hat:

Framework:

• Ich habe gegen ein Framwork gestimmt, weil es erfahrungsgemäß die Lernkurve für viele noch mal erhöht - um wirklich effektiv mit Contenido zu arbeiten, wird dann auch ein gutes Beherrschen des Frameworks notwendig - und meiner Meinung der Benutzeranzahl auf lange Frist abträglich ist

• Framework-Integration bedeutet ein beinah komplettes Rewrite des bestehenden Codes, um die Features des jeweiligen Frameworks effektiv nutzen zu können, und das bindet unheimlich viele Resourcen und würde die funktionale Weiterentwicklung von Contenido für die nächsten 12 Monate (Daumen mal Pi) stoppen

• Zudem unterwirft man sich mit zu starker Framework-Bindung auch dem Innovationstempo des Framework-Herstellers, im schlimmsten Fall muss man entweder zwei Versionen für inkompatible Framework-Versionen pflegen oder die Benutzerbasis verärgern

PHPLib:

• Das Session Handling sollte IMHO mal überarbeitet und transparenter gestaltet werden

• Für die Authentifizierung würde ich mir eine flexible Plugin-API wünschen

API:

• Ganz oben auf der Liste steht für mich eine gut dokumentierte, flexible Ajax-Unterstützung inklusive JSON(P)

• Doku, Doku, Doku - Contenido könnte mit vernünftiger Dokumentation viel weiter verbreitet sein

• Ein einfaches Plugin-Installationssystem und mit dessen Einführung auch ein Plugin-Repository

• Aufräumen mit inkonsistenten Ein- und Ausgabewerten von Funktionen und Ausputzen von functions.con.php & Konsorten würde den Code einiges übersichtlicher machen

• In dem Rahmen könnte man auch kürzere Funktions-(bzw. mit mehr OO Methoden-)namen einführen

• Die Rückwärtskompatibilität kann man nicht ewig behalten, ohne einen riesigen Haufen Altlasten mitzuziehen, wo sie mit einem Update verloren geht sollten allerdings dokumentierte Beispiele vorhanden sein

Generell:

• Was fehlt ist ein öffentliches zugängliches Quelltext-Repository das auf aktuellem Stand gehalten wird und nach Möglichkeit eilige Bugfixes auch ausserhalb von Releases bereitstellt, und anhand dessen man auch einen Diff zu installierten oder Vorgänger-Versionen machen kann. Die bisherigen eher mageren Ansätze sind meiner Meinung nach kein Grund, das Prinzip an sich zu verteufeln.

[xmurrix]

Hallo zusammen,

die Abstimmung ist soweit durch, vielen dank an alle, die mitgemacht haben.

Hatte leider wenig Zeit, mit um dieses Thema zu kümmern, nun möchte ich es wieder man angreifen.

Das Ergebnis ist sehr knapp ausgefallen, die Framework-"Sympatisanten" haben mit einer Stimme mehr gegenüber den "Anhängern" der Erweiterung des Core gesiegt. Nicht zu vergessen, das "Kompatibilitäts"-Lager, das auch ein paar Stimmen hat.

Nun, das Ergebnis ist nicht eindeutig, aber die Richtung ist ungefähr klar. Viele würde es begrüßen, wenn Contenido ein Framework (oder Teile davon) verwendet, dennoch sollten die Änderungen größtenteils kompatibel bleiben, wenn möglich vollständig kompatibel.

Meine Meinung dazu ist folgende:


Framework:
Habe nichts dagegen, tendiere sogar eher in diese Richtung, da wir unmengen an Features verwenden könnten, sofern wir uns auf eines der Frameworks entscheiden. Aus Zend Framework wären z. B. folgende Komponenten sehr interassant:
- Zend_Cache für das Cachen von Ausgaben oder Ergebnissen
- Zend_Config für etwaige Konfigurationen
- Zend_DB für DB-Zugriff
- Zend_Session für die Sessionbehandlung
- uvm.
Habe als Beispiel das Zend Framework genommen, da es meiner Meinung nach ideal ist. Man sollte sich nicht von der Gesamtgröße des ZF-Paketes erschrecken lassen. Dieser enthält alle Komponenten, wir müssen ja nicht alle einsetzen. Es kann auch ein anderes Framework sein - das können wir hier gerne diskutieren...


Erweitern der PHPLib:
Bin auch dafür offen, dazu habe ich auch im Startbeitrag etwas geschrieben.


API:
Die Punkte, die thepoet zur API genannt hat, sind auch sehr wichtig. Code dokumentieren, bereinigen und vereinheitlichen.
Eigentlich sollten diese Punkte im ersten Schritt gemacht werden, sozusagen als Inventur des Core. Währenddessen werden sicherlich einige Punkte auffallen, an die keiner von uns gedacht hat und wir wären dabei mit sehr hoher Wahrscheinlichkeit immer noch kompatibel.


Es wurden im Forum ein paar neue Features angesprochen, wie z. B. die Erstellung einer Pluginschnittstelle um Plugins einfacher zu Verwalten. Ich bin der Meinung, dass das andauernde Hinzufügen von Erweiterungen, keine gute Idee ist, solange wir keine optimierte Basis haben. Die Basis von Contenido ist nicht schlecht, immerhin funktioniert es bis Dato doch gut. Dennoch ist es an der zeit, das wir hier weiter voranschreiten und nicht stehen bleiben. Das Ziel ist nicht die Erstellung einer High-End Enterprise Lösung, sondern das Anpassen/Optimieren des Core.


Wie sind eure Meinungen dazu?

Grüße
xmurrix

[idea-tec]

Hallo Gemeinde, Hallo Murat
dir möchte ich zuerst einmal für deinen unermüdlichen Einsatz danken (das sollte auch einmal sein!).

Für diejenigen die mich kennen ist mir klar, dass ich nicht gerade ein "Sympath" bin, weil ich nun einmal ausspreche was Sache ist und das die meisten Menschen einfach nicht abkönnen. Für die anderen bin ich jemand der Contenido bereits sehr sehr lange kennt und schon gute Dinge damit ins Web gestellt hat.

Ich bin der Meinung, dass das andauernde Hinzufügen von Erweiterungen, keine gute Idee ist, solange wir keine optimierte Basis haben.

Dem Stimme ich absolut zu, weil das ungefähr so wäre als würde man zu einem Haufen Altpapier immer noch mehr Altpapier dazu legen, nur diesmal schöner gestapelt

Die Basis von Contenido ist nicht schlecht, immerhin funktioniert es bis Dato doch gut. Dennoch ist es an der zeit, das wir hier weiter voranschreiten und nicht stehen bleiben. Das Ziel ist nicht die Erstellung einer High-End Enterprise Lösung, sondern das Anpassen/Optimieren des Core.

Auch hier stimme ich absolut zu. Contenido ist das am einfachsten zu handhabende CMS das mir je untergekommen ist und es ist, sofern man weiß was man tut/tun muss, einfach grenzenlos. Denn es hat alles was man braucht: Module mit denen man umsetzen kann was man will, Plugins die man sich selbst integrieren kann und mit denen man wiederum grenzenlos in der Umsetzung wird.

Und nun kommen wir zum Punkt => Es sollte unbedingt mit Zend-Framework weiter gemacht werden!

my2cent

[Oldperl]

Hallo,

bin zwar etwas im WM-Streß , möchte aber auch ganz kurz meine Meinung sagen.
Auch ich bin begeistert von Contenido und seinen Möglichkeiten, was sich durch meine langjährige Arbeit rund um Contenido ausdrückt.
Ich persönlich bin nicht begeistert vom Gedanken ein Framework zu nehmen. Contenido ist in vielem seine eigenen Wege gegangen in der Vergangenheit, und ich denke es sollte das auch in diesem Fall machen.
Was beim Einsatz eines Frameworks passieren kann, welches im Script nicht vernünftig gepflegt wird, bzw. welches evtl. mal irgendwann nicht mehr betreut wird, kann man bei Contenido sowohl mit der PHPLib als auch mit dem PEAR-Paket sehen.

Die PHPLib, damals das non-plus-ultra zu PHP3 Zeiten und eine innovative Lösung, ist heute nicht mehr kompatibel und erhält keinerlei Support. Das PEAR-Paket wurde damals nur halbherzig eingesetzt und dann wurde, durch Änderungen und Einbauten in den PEAR-Corefiles, ein Update/Upgrade derselben erschwert, ja eigentlich fast unmöglich gemacht, sieht man den Zeitaufwand dafür. Auch sicherlich ein Grund warum sich niemand so wirklich an eine Änderung bzw. Verbesserung wagt.

Eigentlich finde ich den Ansatz mit den Klassen Item und ItemCollection sehr sympathisch. Beide Klassen setzen direkt auf den DB-Layer auf, und wenn man von diesen Klassen ableitet und deren Methoden entsprechend einsetzt, kann man Contenido ohne Rücksicht auf den darunterliegenden DB-Layer weiter entwickeln.
Setzt man bei diesen beiden Klassen und dem DB-Layer (PHPLib) an, kann man einen Grundstock für ein schnelles und resourcenschonendes System bauen, welches über kurz oder lang eines der marktführenden Systeme im OpenSource-Bereich werden kann.

Hier muss dann aber Vieles besser umgesetzt werden. So ist es eine Pflicht sowohl Inline- als auch Anwenderdokumentationen zu erstellen, und nicht nur irgendwelchen Code mal schnell zusammenzuschreiben, von dem in 1 oder 2 Jahren keiner mehr so genau weiß, wie, warum oder weshalb das Eine so und das Andere so gemacht wurde. Und Derjenige der mal die Idee hatte und die Umsetzung gemacht hat, arbeitet schon längst woanders oder an was Anderem und hat mit Contenido nichts mehr am Hut.

Bitte nicht missverstehen, ich bin Pro Contenido, aber ich kenne den Corecode inzwischen wie meine Westentasche und ich denke ich sehe den Unterschied wo was gut läuft und wo was in die falsche Richtung geht. Und bei Contenido gab und gibt es viele Baustellen, Ansätze und/oder Versuche, die heute noch mitgeschleppt werden, um die sich aber nicht mehr gekümmert wird, oder die aus mangelnden oder fehlenden Hintergrundinfos nicht mehr verfolgt werden. Es zeugt beispielsweise nicht von einer guten Planung im Vorfeld, wenn es 2 Klassen mit dem selben Namen für komplett unterschiedliche Anwendung gibt. So in Contenido zu finden bei der Datei class.template.php, die es sowohl für die HTML-Template Verarbeitung als auch für die Seiten-Template Verarbeitung gibt. Daher rührte dann auch der Einbau von Methoden für die eine Klasse in die Datei der anderen Klasse.

Abschließend möchte ich aber auch sagen, das ich ebenfalls an einer Roadmap für Contenido interessiert bin, und daher diesen Thread für sehr gut und wichtig halte. Nur wird in meinen Augen nur ein ganzheitlicher Ansatz helfen, zu dem eine Entscheidung Pro oder Contra eines Frameworks nur ein kleines Mosaikstückchen betragen kann und wird.

Upss, nun ist es doch wieder mehr geworden.
Aber nun genug, in 1 1/2 Stunden kommt Fussball und bis dahin liegt noch was an Arbeit an.

Mit nachdenklichem Gruß aus Franken

Ortwin

[McHubi]

Doku, Doku, Doku - Contenido könnte mit vernünftiger Dokumentation viel weiter verbreitet sein

Da bin ich grade dran. Richtet sich zwar an Einsteiger, aber genau die kann Contenido brauchen.

[kummer]

Hier muss dann aber Vieles besser umgesetzt werden. So ist es eine Pflicht sowohl Inline- als auch Anwenderdokumentationen zu erstellen, und nicht nur irgendwelchen Code mal schnell zusammenzuschreiben, von dem in 1 oder 2 Jahren keiner mehr so genau weiß, wie, warum oder weshalb das Eine so und das Andere so gemacht wurde. Und Derjenige der mal die Idee hatte und die Umsetzung gemacht hat, arbeitet schon längst woanders oder an was Anderem und hat mit Contenido nichts mehr am Hut.

Dokumentieren mag wichtig sein. Klar. Aber noch vorher muss man eine gemeinsame Zielsetzung in der Entwicklung haben. Wenn jeder frisch und frei ein bisschen im Code herumfummelt, hilft auch die beste Inline-Dokumentation wenig. In dieser steht dann, was beabsichtigt war, und nicht, was und warum es schief läuft. Das wiederum würde bedeuten, dass vor der Umsetzung ein Plan bestehen würde, was wie warum genau so und nicht anders gemacht werden sollte. Wenn man sich dann anschaut, wie gross die Diversität der Meinungen in Bezug auf eine mögliche Weiterentwicklung ist, dann wird klar, dass Entscheide getroffen werden müssen, die nicht allen gefallen werden. Und hier liegt aus meiner Sicht das eigentliche Problem. Alle wollen Führung (die notabene noch nie zu erkennen war) und kaum jemand mag dann aktzeptieren, dass es nicht so läuft, wie man das gerne möchte. Entwicklungsarbeit ist kein basisdemokratischer Prozess; erfolgreiche Entwicklung ist das pure Gegenteil.

Die Frage ob und wenn ja, welches Framework einzusezten ist, ist etwas, was vernünftigerweise nicht durch eine Abstimmung entschieden werden kann. Wer auch immer für die Entwicklung verantwortlich zeichnet, wird hierzu eine Entscheidung zu treffen haben. Unklar ist bloss, wer das ist und worauf eine solche Entscheidung dann gründet. Weiss jemand, wer die Entwicklung plant? Wer die Entscheidungen trifft? Bist du das, Ortwin? Oder jemand bei 4fb? Oder Murat? Es sieht ja fast so aus, als ob eine Öffnung gegenüber der Community vorgenommen werden würde. Aber ist sichergestellt, dass 4fb die Kontrolle abgeben wird?

[xmurrix]

Abend zusammen,

freue mich darüber, dass wir dieses Thema hier diskutieren, und hoffe darauf, dass wir zu einem Ergebnis kommen, das dann auch angegangen wird, und mit der alle soweit leben können.

In diesem Thread soll nicht eine endgültige Entscheidung getroffen werden, die Idee ist einfach auszuloten, was es für Möglichkeiten für die Weiterentwicklung geben kann, und die Pros/Kontras der verschiedenen Wege sammeln. In einem Punkt sind wir alle sicher einer Meinung, Contenido sollte weiter entwickelt werden.

Letztendlich ist die Entscheidung, wie Andreas schon angemerkt hat, von den verantwortlichen Personen zu treffen.

@Ortwin:
Deine Argumentation gegen ein Framework kann ich nachvollziehen, aber lass mich versuchen, dich doch dazu zu gewinnen. Es stimmt, dass PHPLib früher die Sammlung schlechthin für PHP-Applikationen war, und leider die Entwicklung irgendwann stehen geblieben ist. Dieser könnte auch den heutigen Frameworks passieren. Als Unterschied zu PHPLib haben die Frameworks von heute eine große Community und an manchen sind sogar große/bekannte Firmen beteiligt. Daher sehe ich das als ein geringeres Risiko.

Eine Eigenentwicklung, ganz auf die eigenen (also auf Contenido) Bedürfnisse abgestimmt, wäre die beste Lösung, es muss aber nicht unbedingt die Geeignetste sein.

Geht man den Weg der Eigenentwicklung, so ist das mit erheblichem Aufwand gebunden. Die Libraries/Frameworks, die sich im Laufe der letzten Jahre etabliert haben, haben eine sehr lange Entwicklung hinter sich. Da haben sich viele schlaue Köpfe Gedanken darüber gemacht, wie man welche Probleme Lösen kann und wie man die Features flexibel/erweiterbar bekommt. Sicherlich können wir das auch schaffen, aber wird das nicht ein sehr langer Weg werden? Wir werden mit vielen Bugs konfrontiert, müssen schon entwickelte Features über Bord werfen, weil das Ergebnis eine Sackgasse war - also das volle Programm. Ist es dann nicht die bessere Lösung, wenn man sich für ein Framework entscheidet, und dieses Schritt für Schritt immer mehr in den Core integriert?

Dennoch ist es auch sinnvoll, sich mit der Erweiterung des PHPLib zu beschäftigen. Bringt doch einfach eure Vorschläge ein, was ihr da euch Vorstellt, was machbar ist, wie das Ergebnis aussehen könnte.

Grüße
Murat

[kummer]

Deine Argumentation gegen ein Framework kann ich nachvollziehen, aber lass mich versuchen, dich doch dazu zu gewinnen. Es stimmt, dass PHPLib früher die Sammlung schlechthin für PHP-Applikationen war, und leider die Entwicklung irgendwann stehen geblieben ist. Dieser könnte auch den heutigen Frameworks passieren. Als Unterschied zu PHPLib haben die Frameworks von heute eine große Community und an manchen sind sogar große/bekannte Firmen beteiligt. Daher sehe ich das als ein geringeres Risiko.

Insbesondere beim Zend-Framework - das sollte man nicht vergessen - stecken dieselben Leute dahinter, die auch PHP entwickeln. Wird es Zend nicht mehr geben, ist der Weg frei für Ruby und Co. Denn dann ist auch PHP weitgehend Geschichte. Was bei PHPLib geschehen ist, wird sich bei Zend nicht wiederholen. Auf lange First betrachtet, wird PHP vermutlich dereinst durch etwas verdängt werden, was besser ist. Aber das ist ein Umstand, der in dieser Form für ausnahmslos jede Programmiersprache gilt.

In der Vergangenheit haben die verfügbaren Ressourcen offensichtlich nicht dazu ausgereicht, den Vorsprung, den Contenido vor anderen Systemen vor einigen Jahren hatte, zu erhalten. Inzwischen ist aus dem Vorsprung ein Rückstand geworden. Kein Framework zu verwenden, bedeutet, dass der Ressourcenbedarf grösser wird. Damit muss sich die Entwicklungsgeschwindigkeit noch weiter reduzieren. Nebenbei bemerkt bringt ein Framework (mindestens ein gutes) keinerlei Nachteile mit sich. Bei Zend z.B. kann man die MVC2-Architektur nutzen. Mit Betonung auf kann. Man muss eben nicht. Will heissen, man nutzt, was als tauglich und gewinnbringend eingeschätzt wird.

Ich bin in der Vergangenheit oftmals - und wie ich meine bewusst - misinterpretiert worden. Ich stehe bei einer Weiterentwicklung von Contenido ausdrücklich nicht zur Verfügung und möchte mich in die Entscheidungsfindung auch nicht einmischen. Was jetzt kommt, ist als ernst gemeinter Tipp gedacht. Ich bin mit anderen Entwicklern aus verschiedenen Gründen eigene Wege gegangen. Aussschlaggebend dafür war nicht die fehlende Dokumentation. Auch nicht das Framework, resp. das Fehlen davon. Oder Pear oder was auch immer. Das Problem ist, es gibt weder eine Führung, noch einen Plan. Und ich spreche dabei nicht von einer Roadmap, die über mehre Jahre gehen würde. In Tat und Wahrheit ist nicht einmal das nächste Feature bekannt, bevor es kommt. Für keinen einzelnen Aspekt gibt es einen Plan, wohin man gelangen will. Und das schlägt sich dann in der Entwicklung nieder. Und es stellt ein Problem dar, wenn eine Implementierung beim Kunden vorgenommen wird. Seit der Version 4.6.x hat es keine massgebliche Entwicklung gegeben, die einen Kunden hätte dazu bewegen können, Contenido zu wollen, wenn er es nicht schon vorher für gut befunden hat. Das sind dann gut und gern 6 Jahre während derer mal ein Bug korrigiert oder mal ein neuer Datentyp hinzugekommen ist. Aber die Editierung ist noch dieselbe. Staging gibt es nicht. Versionierung genau dort, wo sie mindestens ein Redakteur nicht braucht (z.B. bei den Modulen). Aber auch Entwickler brauchen sie dort eben nicht. Dafür gibt es SNV oder was auch immer. On- und Offlinestellen ist aus SEO-Sicht ungünstig, aber das einzige Instrument, die Anzeige in Listen zu steuern. Die mitgelieferten Module sind typischerweise genau die schlechtesten, die man kriegen kann. Was aber vorhanden wäre und genutzt wird, muss man sich im Forum zusammensuchen. Das Frontend ist sehr langsam und wird durch das in Contendio verfügbare Caching erstaunlicherweise nicht schneller, sondern langsamer. Ausser man nutzt die mitglieferten Module, die so langsam sind, dass dann sogar das Caching was bringt. Plugins zu integrieren ist sogar für einen Entwickler eine Herausforderung. Und sie wieder zu entfernen kann auch mal in einer neuen Installation münden. Und will man davon etwas korrigieren, muss man sich eben einen Fork machen. Denn es ist zwar keine Führung zu erkennen, aber von irgendwo kann dann eben ein Veto kommen. Unter diesen Bedingung ist entweder Contenido eine Devotionalie, die man pflegt oder die Entwicklung und Mitwirkung ein Hobby. Geschäftlich zu entwickeln ist mit Verlaub nach meiner Einschtätzung unmöglich.

Vor der Frage Framework ja oder nein sollte nach meiner Einschätzung Transparenz geschaffen werden. Wer entscheidet was? Welche Möglichkeiten bestehen, ein Feature einzubringen? Was kann ich tun, wenn mein Kunde einen Wunsch hat, ich bereit bin, die Enwicklung vorzunehmen und mein Kunde bereit ist, dafür zu zahlen? Kriege ich eine Garantie, dass die Integration erfolgt? Muss ich damit leben, dass im Kopf meines Codes 4fb als Urheber erscheint? (Kurz: man muss nicht. Urheber ist der Urheber. Sprich: die Person, die entwickelt hat). Ist GPL bei Contenido so zu verstehen, wie das von GNU vorgesehen ist? Oder die seltsame Lesart von 4fb? Wer gehört zu den Entwicklern? Wer davon ist bei 4fb angestellt? Wer arbeitet auf eigenes Geschäft mit? Wer trägt die Entwicklungskosten? Wie werden die Entwicklungskosten finanziert? Und und und...

[DerFrank]

Hey, was soll man dazu noch sagen?!

[Halchteranerin]

Wer davon ist bei 4fb angestellt?

Das ist die einfachste Frage, weil schon seit einiger Zeit die 4fb-Mitarbeiter, die im Forum tätig sind, tragen auch das "4fb" in ihrem Namen.

[i-fekt]

^_^

[kummer]

Wer davon ist bei 4fb angestellt?

Das ist die einfachste Frage, weil schon seit einiger Zeit die 4fb-Mitarbeiter, die im Forum tätig sind, tragen auch das "4fb" in ihrem Namen.

Ich spreche nicht alleine von einem Arbeitsvertrag. Wer in Lohn und Brot steht, hat noch längst nicht notwendigerweise auch einen Arbeitsvertrag. Es geht darum, Transparenz zu schaffen. Dabei ist auch interessant, wer mit wem in welcher Form zusammenarbeitet. Und wer bei 4fb in die Entwicklung von Contenido involviert ist und in welcher Funktion ist eine ganz und gar unbekannte Grösse.

Letztlich ist es doch so, dass eine Vielzahl Entscheidungen getroffen werden. Kommt ein Feature oder kommt es nicht? Nehmen wir Code in den Kern auf oder nicht? Wartet man 1 Woche bis zum nächsten Release oder 2 Jahre? Usw. Aber es ist niemand sichtbar, der diese Entscheidung trifft. Niemand ist ansprechbar. Es gibt gerade drei Leute, die mir bekannt wären, die sich jeweils dazu äussern. Ortwin, Murat und Ingo. Und keiner der drei genannten hat ein 4fb in Namen. Und es ist eben auch völlig unbekannt, ob sie überhaupt was zu sagen haben.

Die aktuelle Abstimmung dauert ja inzwischen auch ein halbes Jahr. In dieser Zeit hat man sich offenbar nicht zu einer Entscheidung durchringen können. 10 Voten, die mit einem Klick zu machen sind, sind für diese Dauer reichlich wenig. Mich würde interessieren, wieviele davon wirklich entwickeln. Wenn jemand nämlich aktiv mitentwickelt, dann gibt er seine Stimme innerhalb einer Woche ab. 4fb spricht in Publikationen von 2000 (!) Entwicklern. Das das nicht stimmen kann, ist jedem klar, der von Softwareentwicklung eine Ahnung hat. Wieviele es wirklich sind und welche Funktion innerhalb der Organisation sie haben, stellt aus meiner Sicht eine Grundvoraussetzung dar, damit eine Entwicklung, die den Namen verdient, wieder in Gang kommen kann.

[xmurrix]

Hallo zusammen,

...Ich bin deshalb den Schritt gegangen und habe vor 2 Jahren begonnen nach und nach in meiner Freizeit ein eigenes System von Grund auf zu entwickeln...

freue mich für dich, dass du was Eigenes auf die Beine stellst. Wenn das Basis-CMS nicht den Wünschen der Community entspricht, oder die Community ist der Meinung, dass die eingebrachten Verbesserungen/Optimierungen nicht in den Core aufgenommen werden, ist das ja völlig legitim.

Du hast dein eigenes CMS, auch Kummer hat da in Zusammenarbeit mir ein paar Codern was eigenes (aitsu) gemacht, sowie Karsten mit seinem airando. Da gibt es noch einige andere, die heimlich vor sich hin ihr eigenes CMS oder Erweiterungen ausbrüten (inkl. meiner Einer)...

Warum muss das denn sein? Warum kann man nicht sich zusammen tun und gemeinsam an einem Projekt arbeiten?

Ich lese hier andauernd nur negative Bemerkungen, entweder ist die Situation wirklich so derart hoffnungslos oder wir haben hier lauter "das Glas ist halb Leer"-Denker.

So werden wir nie Fußballweltmeister

...Ortwin, Murat und Ingo. Und keiner der drei genannten hat ein 4fb in Namen. Und es ist eben auch völlig unbekannt, ob sie überhaupt was zu sagen haben...

Kann hier nur für mich sprechen. Ich habe bei Contenido als Communitymitglied viel zu sagen (Vorschläge, Tipps, Erweiterungen, Ideen, usw.), habe aber nichts zu Entscheiden - dies ist nicht in meinem Verantwortungsbereich.

Grüße
Murat

[kummer]

Warum muss das denn sein? Warum kann man nicht sich zusammen tun und gemeinsam an einem Projekt arbeiten?

Dein Wort in Gottes Ohr. Nebenbei bemerkt geschieht dies längst. Bloss nicht mehr hier. Ich bin auch der Meinung, dass man die Erfahrungen und die Ressourcen bündeln sollte. Die primäre Frage, die sich mir stellt ist: Kann eine Entwicklung glücken, wenn der Entwickler, der den grössten Beitrag leistet, nach eigener Aussage gar nichts zu entscheiden hat?

Entwickelt wird ja. Bündeln ist möglich und gefragt (einfach im Forum melden). Bloss muss dazu das Umfeld stimmen. Wenn sich dieses nicht ändert, schaffen sich die Leute ein neues. Und ist das erst geschehen, will niemand mehr zurück. Denn es gäbe da so einiges zu verlieren.