PTF Sprint 8: Design der Import-Seit

Info

Heute sprechen wir im Detail über die Seite zum Import bereits existierender Podcast-Episoden und welche verschiedenen Ansätze wir dabei verfolgen können.


This is a companion discussion topic for the original entry at https://podlovers.org/episode/ptf-sprint-8-design-der-import-seite

Euer Rant über WordPress war ziemlich aufschlussreich. Ich persönlich würde WordPress ja auch nur mit langen Stangen und Asbestschütze anfassen, aber Ihr habt Eure Gründe dafür ja schon an anderer Stelle dargelegt.

Was mich wundert: zwischen Software As A Service (mit all seinen Herausforderungen) und einem WordPress-Plugin muss es doch noch etwas geben, das eine hinreichend niedrige Einstiegshürde für Podcast-Schaffende und gleichzeitig eine technisch solide Basis bietet.

Ich habe mir extra nochmal die Transkription der Radiator-Episode durchgelesen. Das Projekt schien ja die technische Basis, aber nicht genug MVP gewesen zu sein. Plus die Herausforderungen, freiwillige Mitarbeit an einem OSS-Projekt mit dem Rest des Lebens zu vereinbaren.

Wie schätzt Ihr die Sache mittlerweile ein? Habt Ihr schon zu viel in WordPress investiert, um nochmal komplett auf eine neue Plattform zu wechseln? Welches Problem müsste grundsätzlich gelöst werden, um davon wegzukommen? Oder sowas wie eine One-Click Appliance, bei Hetzner, Digital Ocean, o.ä. gehostet? Mit eigenem Backend, durch das Ihr frei von WordPress seid? Discourse macht das ja ähnlich (nur mit Containern statt VMs).

Danke und weiterhin viel Erfolg.

Steffen

Ich beantworte mal rückwärts :slight_smile:

Welches Problem müsste grundsätzlich gelöst werden, um davon wegzukommen? Oder sowas wie eine One-Click Appliance, bei Hetzner, Digital Ocean, o.ä. gehostet?

Das ist der Knackpunkt: einfache Installation. WordPress gibt es überall per Klick. Es muss so einfach sein, dass ein Laie nicht schon von der Installation abgeschreckt ist. Einen Docker-Container oder Compose File bereitzustellen ist immer noch zu technisch. Ich habe gerade keinen Überblick, ob und wie man 1-Klick-Skripte bei diversen Hostern bereitstellen kann, das wäre auf jeden Fall eine Recherche wert.

Nach der Installation müssen auch Updates bedacht werden. Wie macht man eine Aktualisierung der Software möglichst reibungslos? Kein triviales Thema.

Plus die Herausforderungen, freiwillige Mitarbeit an einem OSS-Projekt mit dem Rest des Lebens zu vereinbaren.

Tja, ich habe es hier und da schon erwähnt, aber nur auf mich bezogen: Damals war ich Student und mein einziges Problem Motivation. Jetzt mit zwei Kids sieht das anders aus :slight_smile: Dafür ist das Team jetzt größer. Aber in der Regel kommen solche Projekte nur gut voran, wenn es einen sehr aktiven Entwickler gibt. Es juckt mir schon gelegentlich in den Fingern, wer weiß, vielleicht passen irgendwann mal die Umstände wieder :wink:

Ich habe mir extra nochmal die Transkription der Radiator-Episode durchgelesen. Das Projekt schien ja die technische Basis, aber nicht genug MVP gewesen zu sein.

Der Scope war zu groß und es fehlte an Projektmanagement. Wir wollten alles was der Publisher kann, plus CMS Basis, die wir mit WordPress ja “for free” haben, und am liebsten noch ein bisschen mehr. Rückblickend immer einfach zu sagen, aber das war zum Scheitern verurteilt. Und der obige Installationsaspekt war auch erst ein Gedanke, der uns auf halbem Weg kam.

zwischen Software As A Service (mit all seinen Herausforderungen) und einem WordPress-Plugin muss es doch noch etwas geben, das eine hinreichend niedrige Einstiegshürde für Podcast-Schaffende und gleichzeitig eine technisch solide Basis bietet.

SaaS mit Open Source Selbst-Hosting-Variante ist vermutlich der realistischste Weg. Den Weg gehen einige der bekannten OpenSource Projekte. z.B. auch Castopod, was zumindest eine weitere Option für Podcaster ist, die kein WordPress wollen.

Es gibt ja mittlerweile unzählige Podcast-Hoster. Aber ich denke, es wäre grundsätzlich noch Platz für eine Software in Podlove Geschmacksrichtung. Wir müssten aber sehr bewusst abgrenzen, wem die Software dienen soll und wem nicht. Worauf der Fokus liegt, und was uns nicht interessiert.

Der Publisher hatte es im Vergleich zum Radiator einfacher, weil zum einen der Leidensdruck größer war (wir hatten ja nix, früher) und zum anderen das Ziel von Beginn an klar war: die Metaebene Podcasts darauf hin umziehen. Das war beim Radiator schon weiter gesteckt. Die Menge an Metadaten, die einen Podcast ausmachen und verwaltet werden müssen, waren 2012 auch noch viel geringer. Auch ein jetzt neu gestartetes Projekt hat es schwerer, weil die Erwartungshaltung, was ein Hosting können muss, wesentlich höher ist als damals; und entsprechend das MVP bereits komplexer sein muss.

Alles nicht unüberwindbar. Wer weiß, vielleicht wenn der Leidensdruck noch ein kleines bisschen größer wird,… :wink:

1 Like