Einer der größten Nachteile von Contao

[Birden]

Einer der größten Nachteile von Contao, der eigentlich nichts mit Contao selbst zu tun hat, sind externe Erweiterungen, die nicht oder nur mit jahrelanger Verspätung weiterentwickelt beziehungsweise an neue Contao-Versionen angepaßt werden. Das bremst alles aus...

[mlweb]

Das ist in meinen Augen tatsächlich nur dann ein Nachteil, wenn sich niemand findet die Erweiterung oder die Funktionalität der Erweiterung gegen Bezahlung weiterzuentwickeln. Bei Open Source ist es nach meiner bisherigen Erfahrung relativ unwahrscheinlich, dass sich dazu niemand findet.

[Spooky]

Einer der größten Nachteile von Contao, der eigentlich nichts mit Contao selbst zu tun hat, sind externe Erweiterungen, die nicht oder nur mit jahrelanger Verspätung weiterentwickelt beziehungsweise an neue Contao-Versionen angepaßt werden. Das bremst alles aus...

Du kannst die Weiterentwicklung ja finanzieren, wenn du sie brauchst.

[Franko]

... der eigentlich nichts mit Contao selbst zu tun hat ...

Wie selbst erwähnt, betrifft dies wohl eher alle Open Source Strukturen :-)

[zonky]

Die Finanzierung und kontinuierliche Pflege von Erweiterungen ist eine vielschichtige Gemengelage - ein paar Punkte meinerseits dazu:

Zum einen hat sich Contao technisch gesehen weiter entwickelt und einen soliden Symfony-Unterbau - was auch gut ist. Mit dem "Spaghetti-Code" aus Zeiten von 2.x, 3.x ... kann man aber heute keinen Blumentopf mehr gewinnen und so dünnt sich die Zahl der potentiellen Entwickler schon mal aus. Die übrig bleiben, sind dann häufig die, die eh ein volles Auftragsbuch mit Kundenprojekten haben und Erweiterungen und Erweiterungen hinten an stehen.

Auf der "Gegenseite" ist die Bereitschaft auch nur "eine müde Mark" für eine Erweiterung auszugeben, häufig sehr gering - kürzlich gab es einen Thread, da waren 11€ schon zu viel.

Auch der etwas naive Gedanke, "wir haben eine Erweiterung für Projekt xy entwickelt und verkaufen diese nun an weitere Kunden/Nutzer" hat so seine Tücken. Plötzlich ist man Softwaredienstleister und die Käufer erwarten entsprechenden Support, wenn was nicht funktioniert und/oder man bekommt es verschiedenen Fragen zur Anwendung zu tun, dessen Bearbeitungszeit so nicht mit eingeplant war. Insbesondere für Agenturen kann das ein Problem werden, weil die meist ein anderes Kerngeschäft haben und sich vor dem Schritt (zu recht) scheuen.

Das bei frei zugänglichen Erweiterungen später mal Spenden eintrudeln, sollte man wohl eher nicht auf die Erwartungsliste setzen - aus eigener Erfahrung sind das Beträge im homöopathischen Bereich, wo nach Abzug von Steuern und Bearbeitungszeit für Rechnungsstellung nicht viel übrig bleibt als eine nette Geste.

Der häufig geschriebene Satz "wenn du die Erweiterung benötigst, dann musst du eben finanzieren" greift m. E. häufig zu kurz, da mit einer Finanzierung das nicht in den Kostenrahmen eines Projektes passt und das auf mehrere Schultern verteilt werden muss - kleineren Bugs oder Features mal ausgenommen.

Daher haben sich die zwei Finanzierungsvarianten mit entsprechenden Vor- und Nachteilen etabliert:

Die Variante "erst Spenden und dann wird Programmiert" - also das typische Fundraising - funktioniert aus meiner Erfahrung auch nicht besonders gut. Das ist insbesondere für viele Agenturen ein Problem, da die gar keine Position für so was haben um das bei einem aktuellen Projekt abrechnungstechnisch mit einzuflechten. Inwieweit die Variante von Isotope mit "Circle" gut funktioniert bzw. ausreicht, kann ich nicht einschätzen.

Dann gibt es noch die Variante "erst programmieren und dann Spenden" - vor dem Erreichen des Zahlungsziels ist die Erweiterung nur den Zahlenden zugänglich und wenn Zahlungsziel erreicht wird, ist die Erweiterung für alle frei. Man muss aber als Entwickler/Programmierer in Vorleistung gehen und dann hoffen, dass entsprechender "Absatz" da ist. Mit dem Prinzip wird das seit drei Versionen bei MetaModels gemacht und auch andere Erweiterungen wie Contao-Bootstrap oder Include-Info lief die Refinanzierung einzelner Versionen prima. Ich habe aber noch einige Erweiterungen - teilweise als "Vorfinanzierer" - bei denen ich noch auf die "schwarze Null" warte und meine Außenstände im vierstelligen Bereich liegen.


Da ich mich eher auf der Seite der Entwickler sehe, schlägt das Pendel mehr in Richtung des Un-Verständnisses/Unwillens von Anwendern, für gute Erweiterungen auch gutes Geld in die Hand zu nehmen.

Dabei habe ich insbesondere Agenturen im Blick, die das Thema nicht auf dem Schirm haben. In meinem Job als "technischer Telefonjoker" höre ich oft den Workflow, dass Chef ein Angebot abgegeben hat und Mitarbeiter:In dann die Umsetzung machen soll und bei Erweiterung XY auf Probleme wie ist nicht installierbar mit PHPxy/Contaoxy oder es gibt ein Bug o.ä. und wenn ich dann frage, ob Geld für Erweiterungen eingeplant wurde ein Nein kommt ... und dann sowas wie "beim nächsten Projekt spenden wir dann mal was (*1) ... o. ä." - da hab ich dann wenig Mitleid!

Es kann aber dazu führen, das "Chef" meint, bei anderen CMSen ist das alles kostenlos zu haben und Contao den Rücken kehrt

Wie das bei Pendeln so ist, gibt es auch einen anderen Part, der sich bewegen sollte - Entwickler sollten den Mut aufbringen, sich eingehender mit den Möglichkeiten einer Refinanzierung zu beschäftigen und aus diesen einen guten Weg für sich selbst entwickeln. Damit wäre sicher den Anwendern, Contao und dem Entwickler geholfen.


*1: bei den Projekten, die ich kenne, ist die Zusage nie erfüllt worden

[neelix]

Wie das bei Pendeln so ist, gibt es auch einen anderen Part, der sich bewegen sollte - Entwickler sollten den Mut aufbringen, sich eingehender mit den Möglichkeiten einer Refinanzierung zu beschäftigen und aus diesen einen guten Weg für sich selbst entwickeln. Damit wäre sicher den Anwendern, Contao und dem Entwickler geholfen.

Dann bist aber bei dem, was sich bei Wordpress zeigt: Erweiterungen, die was taugen, gibt es dann nur noch im Abo. Das bringt dann wieder neue Abrechnungsschwierigkeiten.

[Kahmoon]

Wenn es sich um ein kommerzielles Projekt handelt, hat sich das bei mir immer gut zum Kunden kommunizieren lassen. Eine Anpassung an einem Modul bringt ihm Vorteile und dieser Aufwand kostet halt bissl was. Da hatte ich bisher ehrlich gesagt nie Probleme.

Als mehrfaches Beispiel kann ich hier Codefog nennen. Ich habe übermittelt was ich an custom Features brauche und er hat mir einen KVA gemacht. 95% dieser Features sind jetzt auch in der öffentlichen Version des Moduls event-subscriptions zu finden, was mich auch nicht stört.

Ab und an muss man halt ein paar Euros in die Hand nehmen....der Entwickler macht das ja auch nicht NUR zum Spaß. Auch bei "privaten" Projekten....


Bezüglich Topic: Dennoch versuche ich generell so wenig Extensions wie möglich und dann auch von größeren Entwicklern zu verwenden um genau nicht in dieses Problem zu laufen. Mit Core-Mitteln geht mittlerweile ja auch schon echt viel!

VG

[neelix]

Wenn es sich um ein kommerzielles Projekt handelt, hat sich das bei mir immer gut zum Kunden kommunizieren lassen. Eine Anpassung an einem Modul bringt ihm Vorteile und dieser Aufwand kostet halt bissl was. Da hatte ich bisher ehrlich gesagt nie Probleme.

Klar, wenn ich vorher weiß, dass ich dieses oder jenes Modul brauche und da ein paar Anpassungen erforderlich sind, dann kann ich beim Hersteller ein Angebot einholen und dann natürlich direkt in meine Kalkulation aufnehmen. Oder dem Kunden sagen: "Pass auf, plan mal X Euro für Anpassungen ein, ggf. brauchen wir die aber auch nicht". Das geht vermutlich bei Handwerkerbetrieben u.ä.
Schwieriger wird es dann schon bei Erweiterungen, die von Privatleuten geschrieben wurden und die keine Rechnung stellen können oder wollen.

Wenn ich mal meinen Arbeitgeber hier als Beispiel nehme, dann ist die Erstellung einer (neuen) Webseite ein Werkvertrag zum Fixpreis. Der wird ausgeschrieben.
Wenn der Anbieter dann erst im nachhinein festellt, dass er Änderungen an einem Modul braucht, die er nicht selbst vornehmen kann und dafür den ursprünglichen Entwickler beauftragen muss, dann geht das zu seinen Lasten. In der Ausschreibung steht dann aber auch, dass nach Abschluss des Projekts ein Wartungs- und Softwarepflegevertrag mit einer Laufzeit von X (meist 3) Jahren abgeschlossen wird und er in dieser Zeit Updates und Fehlerkorrekturen liefern muss.

[Ainschy]

Klar, wenn ich vorher weiß, dass ich dieses oder jenes Modul brauche und da ein paar Anpassungen erforderlich sind, dann kann ich beim Hersteller ein Angebot einholen und dann natürlich direkt in meine Kalkulation aufnehmen....

Warum ein Angebot abgeben wenn die Rahmenbedingungen nicht klar definiert sind? Als Anbieter muss ich doch wissen was ich selbst leisten kann und welche Leistungen in einkaufen muss. Auf gut Glück kann das in viele Fällen gut gehen, aber eben nicht bei jedem und dann zahlt man drauf.

[neelix]

Kennst Du alle Erweiterungen und deren Grenzen?
Du wirst dich also zunächst mal auf die Funktionsbeschreibung des Herstellers verlassen (müssen). Mit etwas Glück hatte man eine Erweiterung schon mal in den Fingern und weiß, ob sie taugt oder nicht bzw. was geändert werden muss.
Ich hatte aber auch schon den Fall, dass eine Erweiterung laut Beschreibung eigentlich genau das lieferte, wonach ich gesucht hatte. Und dann stellte sich während der Umsetzung heraus, das dem doch nicht so war, z.B. weil der Entwickler leicht andere Vorstellungen von einer Funktion hatte. Dann musst du entweder selbst ran (wenn du es kannst) oder den Entwickler (sofern greifbar) oder jemand anderes beauftragen. Dessen Preis kennst Du dann aber bei der Angebotsabgabe nicht.

[Ainschy]

Kennst Du alle Erweiterungen und deren Grenzen?
Du wirst dich also zunächst mal auf die Funktionsbeschreibung des Herstellers verlassen (müssen). Mit etwas Glück hatte man eine Erweiterung schon mal in den Fingern und weiß, ob sie taugt oder nicht bzw. was geändert werden muss. ...
... Und dann stellte sich während der Umsetzung heraus, das dem doch nicht so war, z.B. weil der Entwickler leicht andere Vorstellungen von einer Funktion hatte. Dann musst du entweder selbst ran (wenn du es kannst) oder den Entwickler (sofern greifbar) oder jemand anderes beauftragen. Dessen Preis kennst Du dann aber bei der Angebotsabgabe nicht.

Ich kenne sicher nicht alle Erweiterungen, muss ich auch nicht.

Wenn ich eine Erweiterung brauche, die ich noch nicht kennen, teste ich sie vorher um keine Überraschungen zu erleben, oder frage den Anbieter ob Funktion X,Y sich damit umsetzen lässt.

Vieles löse ich mit der Erweiterung Rock Solid Custom Elements, damit lassen sich auch seltene Anforderungen erfüllen.

Alles kein Hexenwerk und eine Frage von Vorbereitung.

[mlweb]

Wenn ich mal meinen Arbeitgeber hier als Beispiel nehme, dann ist die Erstellung einer (neuen) Webseite ein Werkvertrag zum Fixpreis. Der wird ausgeschrieben.

Ich lass mich z.B. von meinen Auftraggebern nicht knebeln. Einiges gibt es zum Fixpreis, einiges aber auch nur nach Aufwand.

[zonky]

Ich lass mich z.B. von meinen Auftraggebern nicht knebeln. Einiges gibt es zum Fixpreis, einiges aber auch nur nach Aufwand.

Wenn sich der Kunde auf die "dynamische Komponente" nicht einlassen will, muss der Fixpreis eben so hoch sein, dass der die Überraschungen mit abdeckt - aus meiner Erfahrung kann man damit offen umgehen und dem Kunden die Wahl lassen, was er möchte.

[mlweb]

Ja kann man und mach ich auch gelegentlich. In der Regel verzichte ich aber auf Kunden, die mich auf einen Fixpreis festnageln wollen. Ob ich eine Leistung zum Fixpreis anbiete oder nach Aufwand berechne entscheide ausschließlich ich.

[neelix]

Auch noch, wenn das Auftragsvolumen bei 30.000 € liegt?

[zonky]

Auch noch, wenn das Auftragsvolumen bei 30.000 € liegt?

na und?!?

[mlweb]

Ja ist mir tatsächlich egal. Was nutzt mir ein fixes Volumen von 30.000 € bei dem die Gefahr besteht, dass ich für einen Gegenwert von 50.000 € arbeiten muss?
Im Gegenteil je höher das Auftragsvolumen ist, desto vorsichtiger werde ich mit irgendwelchen Fixpreisen. Bei einer kleinen Website, kann ich alles im Vorfeld wunderbar kalkulieren. Die Risiken für möglicherweise notwendigen Mehraufwand sind absolut überschaubar.
Bei größeren Aufträgen gibt es nach meiner Erfahrung deutlich mehr Gründe aus denen Mehraufwand entstehen kann.

[zonky]

sehe ich auch so - zudem kommt, dass aus meiner Erfahrung es (sehr) wenige Kunden/Auftraggeber gibt, die einen konkreten Plan bei dem Volumen haben. Eher eine vage Vorstellung wohin die Reise gehen könnte. Viele Sachen sind dann wenig bis gar nicht durchdacht und ein nicht unwesentlicher Teil muss für Projekt-Planung und -Koordination einkalkuliert werden.

Zudem sind Kunden bei 30 k€ eher geneigt zu fragen ob 20 k€ nicht auch reichen würden - bei 300 € sind die Fragen meist weniger, ob nicht auch 200€ reichen ... ein Hoch auf die Prozentrechnung ;-)

[cliffparnitzky]

Grundsätzlich ist ja jeder selbst für sein Business verantwortlich. Und wer konzeptionell auf Open Source setzt, sollte sich neben den Vorteilen auch der Nachteile bewusst sein. Das gilt dann ja auch für die Art der Angebotsabgabe.

Aber mal zurück zum Ausgangspost.

Ich denke ja, dass es jedem frei steht sein subjektives Leiden zu bekunden. Was mir hier aber fehlt ist ein "Und deshalb habe ich/werde ich ...".

[zoglo]

Auch noch, wenn das Auftragsvolumen bei 30.000 € liegt?

Wenn das Auftragsvolumen "so hoch" ist, sollte man ein Content-Management-System vorschlagen, welches man kennt.
Dazu gehört auch die Recherche in Erweiterungen, welche man einsetzen möchte.

[zonky]

Wenn das Auftragsvolumen so hoch ist,

siehe mlweb: 30k€ ist relativ und nicht per se "hoch"!

[zoglo]

siehe mlweb: 30k€ ist relativ und nicht per se "hoch"!

Hab es für dich editiert.
Was ich damit sagen will, ist, dass die Projektleitung (falls vorhanden) oder der Auftragnehmer sich darüber im Klaren sein muss, worauf sie sich einlässt.