Dries hat in seinem Beitrag 8 steps for Drupal 8 wieder mal gezeigt, dass es auch für ein Open Source-Projekt wichtig ist, einen Plan für die Weiterentwicklung des Projekts zu haben, und auch eine Vorstellung, wie man den Plan umsetzen will. Damit ist “unser” Projekt in einer guten Position. OK — Dries ist auch CTO seiner Firma Acquia, die mit dem Produkt “Drupal” Geld verdienen will und muss. Aber es ist m.E. eine weit größere Herausforderung, einen solchen Plan auch der verteilten Entwicklergemeinde nahezubringen und und diese Croud irgendwie zu “synchronisieren” auf ein gemeinsames Ziel einzuschwören. In dem Projekt fühle ich mich erstmal gut aufgehoben!

Mein persönlich wichtigster Punkt in seinem Blogbeitrag ist der Fünfte: “Experiment with distributed revision control systems”. Das “experiment” geht mir zu langsam. Wenn ich an die Vorgehensweise bei der verteilten Drupal-Entwicklung denke (entwickle was, mach daraus einen Patch, schreib ein Issue auf d.o und hoffe, dass es jemand rechtzeitig wahrnimmt und ein anderer Patch Deinen eigenen Patch bis zum Commit nicht zerbrechen lässt) dann klint das ziemlich unzeitgemäß. Und ist wohl auch ein grund dafür, dass zahlreiche Teilprojekte (z.B. Open Atrium) die konkrete Entwicklung nach Github und vergleichbare Plattformen verschoben haben.

Ich verstehe schon, dass viele Entwickler erstmal in ihrem derzeitigen Workflow abgeholt werden müssen und das git und andere verteilte Version Control Systems eine ganz neue Denkweise erfordern¹. Aber der zukünftige Workflow sollte sein: Erzeuge einen Fork, ändere was und melde es dem Maintainer. Und wenn Dein Fork zwischenzeitlich zerbricht, dann hol Dir die Änderungen aus dem Master in den Fork, repariere … und weiter gehts.

So will ich das haben. Auch für Contrib.* Am besten Jetzt!*

—

¹ Und dass das project.module auch noch viel Liebe braucht, um mit Git und den Forks und Workflows umzugehen.