Get in touch
Für die speziellen Anforderungen unserer Kunden entwickeln wir regelmäßig hochwertige, maßgeschneiderte Extensions und stellen diese, in Absprache mit den Kunden, häufig der Open Source Community zur Verfügung. In unserem letzten Blogpost haben wir beschrieben, warum wir AOE Extensions der Open Source Community zur Verfügung stellen und welche Vorteile dies für die Kunden, die Community und auch uns als AOE hat.
Jedoch benötigen veröffentlichte Extensions meistens eine dezidierte Pflege und stellen uns und auch unsere Kunden vor einige Herausforderungen. Wie können entwickelte Extensions am besten veröffentlicht werden? Ohne dass die Veröffentlichung zu viel Zeitaufwand und Pflege erfordert? Und ohne dass der Fokus auf das eigentliche Entwicklungs-Projekt darunter leidet?
Viele Kunden fürchten, dass zu viel Zeit in die Pflege von offenen Extensions fließt und der Fokus auf ihre Anforderungen verloren geht. Doch es gibt hilfreiche Tools, mit denen sich die Arbeit an Open Source Projekten fast mühelos in die Umsetzung der Kundenanforderungen integrieren lässt. Darüber hinaus sollte man die folgenden Punkte für eine sinnvolle Veröffentlichung beachten.
Schon bei der Planung eines Features müssen alle Anforderungen gründlich durchdacht werden, damit die daraus resultierende Extension problemlos veröffentlicht werden kann. Abhängigkeiten zur Businesslogik des Kunden müssen vermieden werden, um Prozesse des Kunden nicht zu offenbaren und den Nutzen für die Open Source Community zu gewährleisten. Ein sauberes Schnittstellendesign ist unerlässlich, um eine Abhängigkeit von kundenspezifischen Extensions zu vermeiden.
Die Dokumentation ist eines der primären Qualitätsmerkmale offener Software. So ist beispielsweise Sphinx bei der Arbeit mit dem Content Management System TYPO3 ein gutes Tool, um sowohl die Dokumentation im Backend einzusehen als auch mit wenig Aufwand zu editieren.
Viele unserer Kunden arbeiten mit größeren Redaktionsteams, daher ist eine Dokumentation zum Umgang mit den von uns entwickelten Features unerlässlich. Die gesamte TYPO3-Community, vor allem aber unsere Kunden, profitieren von der von uns geförderten, standardkonformen Herangehensweise.
In der Praxis bedeutet dies, dass wir Templates für Dokumentationen bereitstellen. Dank der Verwendung von Sphinx befindet sich die Dokumentation innerhalb der Extension und lässt sich somit über offene Repositories von jedem Anwender pflegen.
Die Vorteile des Web2.0 werden besonders deutlich bei der Arbeit mit quelloffener Software. Über GitHub stehen wir im direkten Kontakt mit der TYPO3-Community, was uns erlaubt, unmittelbar mit unzähligen anderen Entwicklern zusammenzuarbeiten. Trotzdem bleibt das TYPO3-Extension-Repository (TER) aufgrund seiner Backend-Integration unser bevorzugter Kanal, um mit den Integratoren zu kommunizieren.
GitHub bietet einen ähnlichen Funktionalitätsumfang wie TYPO3 Forge, jedoch mit einer deutlich größeren Reichweite. Aufgrund dessen beabsichtigen wir in Zukunft, einen Schwerpunkt auf GitHub zu legen.
Zur Gewährleistung der hohen Qualität unserer Arbeit wird der Quellcode unserer Extensions einem dauerhaften Monitoring unterzogen. Dabei prüfen wir die unterschiedlichsten Qualitätsmerkmale wie z. B. checkstyles, messdetection, duplicate code und code coverage. Auf diese Weise können wir gewährleisten, dass von der Community eingefügte Ergänzungen in unseren Quellcode auch tatsächlich eine Verbesserung im Sinne unserer Kunden darstellt.
Um den Aufwand der Veröffentlichung weiter zu reduzieren haben wir den Upload ins TYPO3-Extension-Repository mit Hilfe einer offenen Library automatisiert.
Open Source-Extensions entstehen nicht von alleine – es bedarf einer aktiven Community, die Entwicklungen öffentlich zur Verfügung stellt. Mit dem bewussten Einsatz guter Tools kann durch die Veröffentlichung der Verbesserungen und Neuentwicklungen nicht zuletzt auch der Arbeitsaufwand für Anwendungen aller Art geteilt werden, was zu effizienteren, innovativen Lösungen führt.
