Ich habe vorhin ein paar Versuche mit der gerade freigegebenen Beta-Version des anstehenden ownCloud-Release in Version 5 gemacht (5.0.0-beta1). Ich kenne die verbesserte Optik ja schon länger, habe unter anderem auf der FOSDEM in Brüssel erste Eindrücke der Umsetzung der Pläne sammeln dürfen. Und ich habe mich für die Portierung meiner Apps während der vergangenen Tage auch intensiv mit technischen Details dieser Änderungen auseinander gesetzt. Trotzdem bin ich natürlich gespannt wie das Release angenommen wird, wenn die Freigabe der stabilen Version erfolgt. Das wird wahrscheinlich erst im März sein, es gibt noch ein paar dokumentierte Showstopper, die noch korrigiert werden müssen. Einen neuen musste ich leider nach meinen Tests der Liste beifügen – womit der Sinn von Beta-Releases gut belegt wird… 🙂
Aber es gibt natürlich auch positives zu berichten! Bei diesen Tests hat besonders die App-Verwaltung eine nette Überraschung für mich bereit gehalten:
Der ownCloud App Store bietet eine große und ständig wachsende Auswahl interessanter und frei verfügbarer Erweiterungen für die eigene ownCloud. Alle verfügbar mit nur einem einzigen Klick: Download, Installation und Aktivierung wird automatisch im Hintergrund erledigt (klappt fast immer…).
In der langen Liste der zur Installation angeboteten Apps findet sich natürlich auch der kleine, wackere „Shorty“. Er ist explizit als ‚Recommended‘ hervor gehoben, obwohl eine 3rd-Party-App (also nicht vom ownCloud-Team selber erschaffen). Noch dazu trägt „Shorty“ diese Auszeichnung als einzige App im Angebot. Wow.
Trotzdem habe ich mich entschieden, die Pflege meiner Apps in die Hände eines größeren Kreises zu legen. Es sind inzwischen ja vier Apps, „Shorty“, „Shorty Tracking“, „Imprint“ und der neue „FluXX Compensator (Y)“. Da kommt mit Verbesserungen, Fehlerkorrekturen, Portierungen und Beantwortung von Fragen einfach einiges an Zeit zusammen. Bislang habe ich die Apps als Ein-Kopf-Team implementiert und gepflegt. Zwar habe ich einiges an (meist) positivem Feedback erhalten, es ist aber leider nicht gelungen, Mitstreiter zu finden. Also Interessierte, die selber Code beisteuern. Viele Nutzer sind gerne bereit, Tests zu machen, investieren dazu auch einiges an Zeit und Aufwand. Aber davor selber Code beizutragen schrecken doch viele zurück. Ich stelle dazu verschiedene Überlegungen an, vor allem aber würde ich gerne dafür Sorgen, dass die Apps umziehen. Nicht aus dem „App Store“, sondern auf Entwicklungsseite. Von meinem eigenen öffentlichen Repository in den zentralen ownCloud-Pool. Damit wäre vielleicht die Einstiegshürde gesenkt für Leute, die einfach mal schnell einen Fehler korrigieren wollen, der ihnen aufgefallen ist. Das wäre natürlich auch problemlos in meinem Repository möglich, aber da spielen ja bekanntlich auch eine Reihe psychologischer Gründe mit, wenn es um Beiträge zu einem Projekt geht. Und als Nebeneffekt wäre der Weg frei für weitere Übersetzungen der Apps. Derzeit biete ich nur die englischsprachige Originalversion an und eine Übersetzung ins Deutsche. Für ownCloud selber dagegen liegen bereits Pakete für mehr Sprachen vor, als man in einem interessierten Leben lernen kann…
Die Überlegungen zu einem zentralen ownCloud-Pool finde ich gut. Dies gibt es im Plone Umfeld auch, das sogenannte „collective“.
Auf Github ist das eine Organization, welche die Apps versammelt.
Ich hätte mit Quotabar auch so ein Kandidat.
Grüße,
Steffen
Hallo Steffen,
mit dem ownCloud-Pool meinte ich nur das ownCloud-eigene ‘apps’ Repository auf github. Dieses Repository existiert ja bereits und hat die gleiche Funktion wie das ‘collective’ repo im Plone-Umfeld, wenn ich das richtig verstanden habe.
Dort werden ja viele Apps entwickelt, auch die ‘internen’, was immer auch ‘intern’ hier bedeutet. Tatsächlich ist inzwischen eine Diskussion darüber in Gang gekommen, das Repository zu splitten. Das ändert aber nichts daran, dass dort der Code vieler Apps versammelt ist und Leute daran arbeiten können. Im Gegensatz zu einem eher dezentralen Ansatz, wo die Apps über verschiedene Repositories verteilt sind.
Generell senkt der zentrale Ansatz natürlich die Hemmschwelle für Beiträge. Aber ich sehe auch Nachteile dieses Ansatzes.
Stimmt, mit dem Apps Repository gibt es sowas ähnliches. Jedoch ist es ein riesen Repository, ich denke es sollte in eine Organization umgewandelt werden und jede App sollte ein eigenes Repo haben. So ist das forken einfacher. Außerdem kann man einfacher Versionen in form von git tags erstellen.
Im Plone-Umfeld funktioniert das sehr gut, man kann seine Entwicklung ins collective verschieben, damit haben sofort viele andere Entwickler Schreibzugriff. Ein gewisser Qualitäts-Standard sollte aber gegeben sein.