Hallo Alexander und willkommen bei uns!
Deine Frage ist absolut nachvollziehbar, und nach all den Erfahrungen mit WB und LEPTON ging und geht es uns genauso. Und genau deshalb haben wir irgendwann entschieden, unsere Arbeit an LEPTON 2.0 zu nehmen und daraus unseren eigenen Fork zu machen. Da wir nicht zu den Leuten gehören, die dauernd irgendwas Neues anfangen und es dann nach kurzer Zeit wieder fallen lassen, haben wir lange und gründlich darüber nachgedacht, bevor wir diese Entscheidung getroffen haben. Es war auch von Anfang an klar, daß es vorerst nur zwei aktive Entwickler geben würde, nämlich Matthias aka creativecat und mich. Ralf ist sozusagen in "beratender Position" dabei und trägt mit seinem kitFramework dazu bei, BC um wichtige und stabile Funktionen zu erweitern - das hält uns ein wenig den Rücken frei und bietet den Usern gleichzeitig eine weitere große Spielwiese, die man nicht nur nutzen, sondern auch selbst erweitern kann. Aus diesem Grund arbeiten wir sehr eng zusammen, auch wenn Ralf kein "aktiver Entwickler" im BC Core Projekt ist und umgekehrt.
Nochmal zur Vorgeschichte:
Wenn man sich WB mal genau ansieht, war auch WB eigentlich immer ein "1-person"-Ding. Ryan war allein, wurde dann von "rübenwurzel" abgelöst, bis der Verein die Rechte übernahm, und "rübenwurzel" wiederum übergab das Projekt an ein "Entwickler-Team", zu dem auch ich einige Zeit gehörte. Allerdings gab es in diesem sogenannten Team sehr unterschiedliche Ansichten - z.B. zum Thema OOP - und sehr wenig Kompromißbereitschaft, und meine Beteiligung endete schließlich damit, daß ein "Team"-Mitglied im öffentlichen Forum über mich her zog, woraufhin ein weiteres "Team"-Mitglied ebenfalls meinte, seinen Frust auf mich projizieren zu müssen. Das ist inakzeptabel. Differenzen kann man untereinander klären, aber nicht in einem öffentlichen Forum. Letztlich blieben dann schließlich auch von dem "Team" nur zwei Personen übrig, nämlich "DarkViper" und "Luisehahne". Die vor einiger Zeit veröffentlichte Stellungnahme von "DarkViper" mit der darin enthaltenen Beschreibung der Zusammenarbeit läßt mich allerdings vermuten, daß ... na, das soll jeder für sich selbst interpretieren.
LEPTON wurde ursprünglich von einer kleinen Gruppe von Leuten angegangen, zu denen als Entwickler (ich verwende hier die WB-Forennamen) "Aldus" und "Ralf (Berlin)" gehörten. Aufgrund meines guten Kontaktes zu diesen beiden - und damals auch noch "erpe" - kam ich dann während der Entwicklung von 1.0 dazu, wenn auch erst sehr spät. Etwa zur gleichen Zeit stießen dann noch "creativecat" und "FrankH" dazu.
LEPTON hatte in Version 1.0 das Hauptziel, endlich die alten Schwächen von WB auszubügeln; zudem waren wir der Meinung, der in der - damals noch in Arbeit befindlichen - Version 2.8.3 verwendete FTAN-Ansatz sei zwar von der Grundidee her nicht schlecht, von der Umsetzung jedoch schon, zumal er eine Anpassung aller Module erfordert. (Jedenfalls aller Module, die mit Formularen arbeiten.) Zudem ließ auch diese Version wie üblich auf sich warten, die aktive Beteiligung der genannten Personen war von "offizieller Seite" "nicht erwünscht". Es gab also praktisch keine andere Wahl als einen Fork, wenn man endlich eine stabile Core-Version haben wollte, die sich zudem von dem alten Ballast trennt (z.B. der alten Template-Engine) oder zumindest die Grundlagen dafür schafft.
Nach Übergang der Version 1 in die Pflege begannen wir mit der Planung der Version 2. Wir Entwickler hatten das schon damals genauso gesehen wie hier bei BC: Mit Fertigstellung einer Hauptversion geht diese in die Pflege, das heißt, es gibt nur noch Bugfixes, aber keine neuen Features. (Außer Kleinigkeiten, die sich leicht und mit wenig Aufwand integrieren lassen.) Mit Version 2 wollten wir einen großen Schritt tun: Neues Backend, basierend auf jQuery, neue Template Engine, Einführung der Helper-Klassen etc. Daher waren für Version 1.x keine größeren neuen Features mehr geplant.
Das Problem bei der Sache war, daß die einzige nicht aktiv an der Entwicklung beteiligte Person eine Art "ultimatives Veto-Recht" für sich beanspruchte. Egal, was 5 Entwickler für sinnvoll und richtig hielten - und vor allem auch für technisch machbar -, wenn diese Person das nicht wollte, hatte das auch nicht zu geschehen - basta! Das führte letztlich dann zum Bruch, von den 5 Entwicklern blieb nur einer übrig, der mittlerweile aus gesundheitlichen Gründen ebenfalls ausgeschieden ist.
Lange Zeit lagen die Quellen für LEPTON 2.0 dann brach, obwohl wir es schon bis zu einer Alpha-Version gebracht hatten. Irgendwie wurmte mich das. Es war viel Arbeit gewesen, es steckten viele gute Ideen darin, das alles einfach wegzuschmeißen war ebenso unlogisch wie schmerzhaft. Daher fragte ich dann irgendwann meine "alten Mitstreiter", ob wir nicht vielleicht doch damit weiter machen sollten. Zwei wollten nicht nochmal neu anfangen - die LEPTON-Erfahrung reichte ihnen -, dafür hat sicher jeder Verständnis, der das gleiche Spiel auf Benutzer-Seite gespielt hat. Die Enttäuschung sitzt tief, ebenso wie der Zweifel. Der dritte, nämlich Ralf, wollte (und konnte) sich wegen seines kitFrameworks nicht aktiv beteiligen - jedenfalls nicht in der "Produktion von Code" -, unterstützte aber die Idee. Schließlich entschieden wir uns, erst mal eine "LEPTON v2.0 Black Cat Edition" zu bauen und zu sehen, wohin uns das führt. Letztlich wurde dann "BlackCat CMS" daraus, was deutlich macht, daß wir das Gefühl haben, das Richtige zu tun, etwas Sinnvolles zu schaffen und vor allem auch langfristig dabei zu bleiben.
Unsere Hauptschwierigkeit liegt natürlich nach wie vor in den Ressourcen. Wir können nicht zur gleichen Zeit Code schreiben und eine Webseite pflegen, Dokus und Tutorials schreiben, die Werbetrommel rühren usw. Wir haben etliche erfreuliche Anfragen, wie etwa die eines großen deutschen Providers, der gerne eine APS-Version haben wollte (für Parallels, siehe
http://apsstandard.org/), aber wir haben nicht die "Man"-Power, um selber proaktiv Werbung zu machen etc. Drum halten wir ganz bewußt "den Ball flach", wie man so schön sagt, zumal BlackCat 1.x auch noch ein paar Altlasten mit sich rum schleppt, die ich gern erst abgestellt haben möchte. Der größte Punkt ist hierbei das Berechtigungssystem, das muß komplett neu gemacht werden.
Bezüglich des von Dir verlinkten Beitrags im WB-Forum kann ich sagen, daß es "bei uns" ziemlich genau so läuft, wie dort von Dir gefordert. Das war auch schon bei LEPTON so, das Problem und der Grund für die Trennung war, wie gesagt, eine Person außerhalb des aktiven Entwicklerteams. Wir haben zwar streng genommen keinen "Leader", allenfalls eine Art "Moderator", das wäre dann wohl ich.
Wir besprechen einfach die anstehenden Themen und überlegen uns gemeinsam eine Lösung, manchmal führt dann auch Ausprobieren zu einer Entscheidung, gelegentlich vereinbart man einen Kompromiß. Am Ende steht ein "So machen wir das!", und dann wird das so umgesetzt. Grundsätzlich ist zu sagen, daß wir zielorientiert arbeiten, was unter anderem auch bedeutet, daß man sich auf Lösungen konzentriert, nicht auf persönliche Befindlichkeiten oder Präferenzen. Sicherlich ist auch hilfreich, daß wir recht gefestigte Persönlichkeiten sind, die sich zwar gelegentlich auch mal richtig zoffen, aber problemlos auch wieder vertragen können.
Wobei ich mich nur an einen richtigen Zoff erinnere, der lange zurück liegt und sicherlich zum Teil auch der damaligen Situation bei LEPTON geschuldet war. Es ist halt auch sehr vorteilhaft, wenn das Projekt weder Lebensinhalt noch Profilierungsobjekt ist. Wir müssen uns gegenseitig nichts beweisen, wir wissen, daß der jeweils andere weiß, wovon er spricht. Es ist daher auch niemandem peinlich, wenn z.B. ein anderer ein Stück Code entdeckt, wo man Unfug gemacht hat. *g*
Problematisch könnte es werden, wenn das Team wächst - allerdings habe ich von jeher die Auffassung vertreten, daß die Zusammenarbeit am besten funktioniert, wenn man sich vertraut und dementsprechend den Leuten ihre Freiheiten läßt. Ich habe kein Interesse daran, andere Teammitglieder zu kontrollieren oder zu beaufsichtigen. Wenn einer sagt "ich mach das", dann verlasse ich mich darauf, daß das dann auch gemacht wird. Wenn dann nichts passiert, frage ich ein paar mal nach, danach nehme ich an, daß kein Interesse mehr besteht. Damit ist das dann auch erledigt. Es gibt z.B. ein paar Leute, die Tutorials schreiben woll(t)en, daher habe ich das Wiki eingerichtet. Entweder tun sie es, oder sie tun es nicht. Druck mache ich keinen, das hilft eh nicht. "Nach fest kommt ab", sagt mein Kollege immer.
Was eine konstruktive Beteiligung außerhalb der Programmierung angeht, gibt es eine Vielzahl an Möglichkeiten. Am wichtigsten ist mir persönlich die schlichte Rückmeldung zum Objekt: Wie ist die Bedienbarkeit? Wo hakt es? Was fehlt? Wo gibt es Typos, Übersetzungsfehler, mißverständliche Formulierungen? Wir hatten hier auch schon Rückmeldungen von Leuten, die entschieden haben, nicht zu BC zu wechseln. Das finde ich super - nicht, daß sie nicht wechseln wollen, sondern daß sie uns sagen, wieso nicht. Dann können wir daran arbeiten, und in einem Jahr fällt dann die Entscheidung vielleicht anders aus. Darum haben wir ja auch ein Extra-Forum, wo man uns sagen kann, warum CMS XY besser ist als unseres. Es ist immer gut, über den Tellerrand zu schauen - und ja, natürlich schauen wir auch im WB-Forum, was für Wünsche dort geäußert werden, und schauen, ob wir sie in BC erfüllen können. (Z.B. das Modifikationsdatum zusätzlich pro Modul statt nur pro Seite zu speichern. Keine große Sache, trotzdem wird es in WB nicht berücksichtigt.) Ansonsten fehlt es ja hauptsächlich an nichttechnischen Dokus, ein paar YouTube-Videos wären auch klasse, schlicht das, was eine Community halt so macht.
Zum Thema Migrationspfad: Wir haben keinen eigenen gemacht, weil das sehr wahrscheinlich mit Hilfe von Ralfs SyncData möglich ist, bisher hatten wir aber kein Testobjekt. Das Kernproblem liegt natürlich wie immer bei den verwendeten Modulen. Wir haben einige getestet, manche laufen mit BC, andere nicht oder nur eingeschränkt. So hat z.B. Bakery leider ein deutsch-englisches Mischmasch-Backend, was an der Einbindung der Sprachdateien durch Bakery liegt. Das kann man lösen, aber man muß dafür das Modul selbst anpassen. Topics wurde von Ralf so angepaßt, daß die Layoutfehler im Backend von BC behoben werden, da das Modul jetzt aber wieder von "chio" gepflegt wird, wird der Patch vermutlich entschwunden sein.
Grundsätzlich sollte eine Migration nach der Anleitung "Serverwechsel" von WB möglich sein, durchgespielt habe ich es allerdings noch nicht. Mein einziges eigenes Migrationsprojekt wäre mein Modulverzeichnis, das basiert aber in der Hauptsache auf wbProfiles, weswegen das als Testobjekt witzlos ist - wbProfiles läuft problemlos unter BC, und die paar WYSIWYG-Seiten dürften auch keine Herausforderung sein. Wenn Du eine Liste von Modulen hast, die Du "flächendeckend" verwendest, könnten wir zumindest schon mal gucken, ob die für BC schon getestet wurden und mit welchem Ergebnis. Mit einer Komplettsicherung eines solchen Webauftritts spiele ich das auch gern mal für Dich durch, sofern Du kein Problem damit hast, mir diese Daten zur Verfügung zu stellen. (Evtl. vorher die Benutzerkonten entfernen.) Wichtig ist, daß das Berechtigungssystem in unserer Version 1.x ziemlich "buggy" ist, weil wir nicht viel Aufmerksamkeit darauf verwendet haben - es wird ja, wie gesagt, komplett neu gemacht. Mit der anstehenden Version 1.0.3 kommen hierfür etliche Korrekturen, aber ich bezweifle, daß ich alle Fehler gefunden habe. *hüstel* Wenn Du also komplexe Rechte vergeben hast, könnte das ein Fallstrick sein.
So, viel Text, der hoffentlich erhellend war.
