Drupal für Kunden: Update / Pflegearbeiten?

am 06.06.2008 - 10:42 Uhr in
Hallo Community,
also ich bin ziemlich beeindruckt von Drupal. Habe die letzten Jahre einiges Systeme ausprobiert, um dann ein eigenes auf die Beine zu stellen. Dieses nutze ich für "normale" Kunden bisher ohne Probleme. Allerdings ist mein System wirklich kein Vergleich zu Drupal. Viele Kunden wünschen immer mehr Features und Drupal bietet ja wirklich fast alles. Daher überlege ich, in Zukunft den Kunden zu Drupal zu raten.
Allerdings geht mir eine Frage nicht aus dem Kopf:
Wie händelt Ihr die Update/Patch-Problematik?
Ich verrechne dem Kunden x-Stunden Anpassungs, Installations- und Designarbeit. Der Kunde bekommt das fertige Projekt auf seinen Server. Er ist zufrieden und happy. Peng: Die ersten Sicherheitspatches für Modul X, für Drupal etc. folgen einige Wochen / Monate später. Schließt Ihr das in den AGB aus? Erklärt Ihr dem Kunden, dass er für die Patches selbst sorgen muss, oder dies veranlassen muss?
Bin gespannt wie Ihr das organisiert, über Tipps wäre ich sehr dankbar.
Lieben Gruß,
Goisgo aka Michael
- Anmelden oder Registrieren um Kommentare zu schreiben
Gute Frage
am 06.06.2008 - 11:39 Uhr
Das ist in der Tat nicht so einfach.
Da ich für Kunden noch gar nicht so viele Drupal-Seiten aufgesetzt habe, habe ich das bis jetzt immer kostenlos gemacht und denen gar nicht davon erzählt, denn ich wollte erstmal Drupal verkaufen und nichts negatives dazwischenkommen lassen.
Am besten wäre aber, das ganz offen zu handhaben und zu sagen: Wollen Sie ein System wie Typo oder Joomla, das irgendwann einen kompletten Bruch macht und gar nicht mehr zu updaten ist oder eines wie Drupal, was zwar mehr Pflege und Updates erfordert, dafür aber zukunftssicher ist.
Dann errechne halt einen realistischen Aufwand, den es pro Jahr kosten kann, nach deinem Stundensatz. Ich persönlich mache auch einfach nicht alle Sicherheitsupdates mit. Da bin ich schmerzfrei. Ist der Kunde da paranoid, muss er es auch bezahlen.
Aber wie es auch sei: man sollte einen Weg finden, das positiv zu formulieren aber als notwendig darzustellen. Drupal Core-Updates (innerhalb einer Version, also von 5.2 auf 5.3 usw) sind auch bis jetzt bei mir immer komplett schmerzfrei verlaufen, da das Sicherheits- und Coreteam einen guten Job macht und keinerlei Funktionen ändert, sondern wirklich nur Sicherheitsupdates macht.
Schwieriger ist es da schon mit den Modulen. Da hilft allerdings eine andere Regel: Wenn die alte Version des Modules alles tut, was sie soll, warum updaten?
Richtig aufwendig ist nur das Update z.B. von 5 auf 6 usw. da ja auch die Contributed Modules erstmal portiert werden müssen und dann eine Weile brauchen, bis sie bugfrei laufen. Wartet man halt ab bis das meiste ausgereift ist, bevor man die Seiten updatet.
Von allem die beste Lösung ist noch "Carbon" und "Spokes" von Acquia http://acquia.com/projects, da es genau die angesprochene Lücke füllen will. "Spokes" empfiehlt nur noch geprüfte Updates, und "Carbon" sorgt für eine immer funktionierende Distribution.
Aber welche Lösung auch immer: der Kunde wird für die Updates bezahlen müssen, am besten führt man das schon als Posten im Angebot auf. Du kannst ja ein halbes Jahr Update-Service inklusive anbieten, und danach berechnen oder was auch immer.
Durch den extrem modularen Aufbau von Drupal ist es aber in der Tat ein Problem, dass der Dientstleister sich immer auf dem Laufenden halten muss, was sich bei den Modulen tut, die er einsetzt, um einschätzen zu können, ob ein Update lohnt oder Probleme auftreten können, wenn man es tut. Irgendwann gibt es dann als Dienstleistung "Module Scout", der sich das bezahlen lässt...
Ich habe das bis jetzt eigentlich ganz gut geschafft, aber man sollte sich immer etwas Zeit geben, wenn man ein ganz neues Modul ausprobiert. Die meisten sind zwar gut zu durchblicken, aber von Null auf Produktivstatus... na ja, das geht auch in anderen Bereichen nicht.
Drupal - too unorganised to be a system