Aufruf an Entwickler – Jellyfin
(jellyfin.org)- Jellyfin will zum 10-jährigen Jubiläum von Hacktoberfest im Oktober 2023 seine stagnierende Basis an Mitwirkenden erweitern und das Tempo bei Verbesserungen an Server, Web UI und Clients erhöhen
- Das Projekt hält an einem halbkommerziellen Freiwilligenmodell fest; Spenden werden nur für Infrastrukturkosten und selten benötigte Client-Hardware für die Entwicklung verwendet
- Die Kerngruppe der Mitwirkenden umfasst über Server, Web UI und alle Clients hinweg höchstens etwa 30 Personen und ist in den letzten 3 Jahren kaum gewachsen; einige Apps werden von 1–2 Personen in ihrer Freizeit gepflegt
- Die Unzufriedenheit der Nutzer konzentriert sich auf mangelnde Client-Unterstützung und fehlende Ausgereiftheit; selbst stark nachgefragte Funktionen oder Clients wie Chromecast hatten zeitweise keinen Entwicklungsantrieb
- Benötigt wird alles von kleinen Bugfixes über Dokumentationsverbesserungen, UI/UX und Übersetzungen bis hin zur Entwicklung kompletter Clients; wer kontinuierlich hochwertige Beiträge leistet, kann auch dem offiziellen Team beitreten
Warum Jellyfin jetzt Mitwirkende sucht
- Jellyfin betrachtet zum 10-jährigen Jubiläum von DigitalOceans Hacktoberfest den Zustrom neuer Mitwirkender als wichtige Aufgabe
- Immer wenn es Kontroversen rund um Plex gibt, wird Jellyfin als Alternative genannt; in der Community werden jedoch auch fehlende Clients, das Fehlen bestimmter Funktionen und mangelnde Ausgereiftheit immer wieder angesprochen
- Um diese Lücken zu schließen, müssen sich mehr Menschen an Code-Verbesserungen, der Entwicklung neuer Funktionen und der Pflege der Dokumentation beteiligen
Einschränkungen eines auf Freiwilligen basierenden Projekts
- Jellyfin wird als FLOSS-Projekt betrieben, das selbst innerhalb von FLOSS ungewöhnlich halbkommerziell ist
- Entwickler, Übersetzer, Community-Moderatoren und Mitglieder, die bei der Problemlösung helfen, sind allesamt Freiwillige
- Niemand wird für die Arbeit an Jellyfin bezahlt, und es gibt auch keine Unterstützung durch ein Unternehmen oder eine separate Organisation
- Es gibt keine Pläne zur Monetarisierung, und Bug-Bounties werden bewusst vermieden
- Spenden werden nur für Infrastrukturkosten und bei Bedarf für selten gekaufte Client-Hardware zur Entwicklung verwendet
- Spenden werden nicht verwendet, um Entwickler zu bezahlen, und diese Haltung soll auch künftig beibehalten werden
- Mit dieser Entscheidung will man vermeiden, den Weg anderer Medien-Streaming-Projekte zu gehen, die als FLOSS begonnen haben, dann aus Profitgründen nutzerfeindliche Funktionen hinzugefügt und auf Closed Source umgestellt wurden
Die Last, mit einem kleinen Team einen breiten Umfang zu pflegen
- Die aktuelle Kerngruppe der Mitwirkenden umfasst über Server, Web UI und alle Clients hinweg höchstens etwa 30 Personen
- In den letzten 3 Jahren ist die Gesamtgröße kaum gewachsen
- Einige Bereiche, insbesondere einzelne Apps, werden von 1–2 Personen unbezahlt in ihrer Freizeit betreut
- Selbst bei stark nachgefragten Funktionen oder Clients kann der Fortschritt ins Stocken geraten, wenn niemand da ist, der die Entwicklung beginnt oder unterstützt
- Chromecast musste zeitweise aufgegeben werden, doch in den letzten Wochen ist wieder Bewegung hineingekommen
Wie man mitmachen kann und wie der Weg ins offizielle Team aussieht
- Wer loslegen möchte, kann über die Mitwirkungsanleitung, die Matrix/IRC/Discord-Kanäle und das Forum Hilfe bekommen
- Das Spektrum an Beiträgen reicht von kleinen Bugfixes über Dokumentationsverbesserungen bis zur Entwicklung kompletter Clients
- Für Menschen, die hochwertige Beiträge leisten und Bereitschaft zur Mitarbeit zeigen, gibt es auch ein Verfahren zur Nominierung neuer Teammitglieder, über das ein Beitritt zum offiziellen Team möglich ist
1 Kommentare
Meinungen auf Hacker News
Ich wusste nicht, dass Jellyfin auf C# basiert.
Ich habe meine Karriere als C#-Entwickler begonnen, nutze inzwischen aber nur noch C++ und habe die ganze Zeit nach einem Projekt gesucht, bei dem ich wieder C# verwenden könnte.
Ich habe eine Liste mit Dingen, die mich an Jellyfin gestört haben, und jetzt, da ich weiß, dass es C# ist, bekomme ich Lust, sie selbst zu beheben.
Die Sprache hat sich stark weiterentwickelt; besonders Pattern Matching, using-Anweisungen und entwicklerfreundliche Features wie performanceorientierte Basistypen sind besser geworden.
Ich habe Anfang des Jahres wieder angefangen, C# Vollzeit zu nutzen, und bin sehr zufrieden.
Es wäre gut, wenn das Jellyfin-Team solche Aufrufe zur Mitarbeit auch dort sichtbar macht, wo Nutzer Features anfragen.
Beim Beispiel aus dem Blogbeitrag, der Chromecast-Unterstützung, hatte ich in diesem Issue gefragt, wie ich bei der Umsetzung helfen könnte: https://github.com/jellyfin/Swiftfin/issues/271#issuecomment...
Selbst wenn es tatsächlich nichts gegeben hätte, womit ich produktiv zu diesem Feature hätte beitragen können, hätte ich mir eine Einstiegshilfe definitiv angesehen.
Wenn man in Issues, in denen Leute fragen, ob sie helfen können, schnell auf den Blogbeitrag und Einstiegsmaterial verweist, dürfte die Conversion ziemlich gut sein.
Danke an alle, die zu Jellyfin beitragen, und ich weiß auch, dass Entwickler-Onboarding oft eine größere Aufgabe wird; es ist nur ein Vorschlag, dass das eine gute Stelle für einen Call-to-Action-Link wäre.
Ich hatte versucht, eine früher oft gewünschte und scheinbar nicht schwer umzusetzende Funktion für eine tagbasierte Allowlist hinzuzufügen, und hatte auch herausgefunden, wo sie im Server-Code hingehören würde.
Aber dann wurde mir klar, dass ich, um das Feature auszuliefern, PRs über mindestens zwei Repositories hinweg betreuen und für Integrationstests zwischen beiden Repositories hin- und herwechseln müsste, also habe ich aufgegeben.
Bei eng gekoppeltem Code ist ein einzelnes Repository wirklich praktisch.
Vielleicht schaue ich es mir noch einmal an.
Nebenbei: Allowlist-basierte Kindersicherung ist eines der besten Werkzeuge, aber es ist frustrierend, dass sie praktisch nirgends unterstützt wird.
Vermutlich bist du nicht die einzige Person mit diesem Problem.
Für das Projekt ist das wahrscheinlich ebenfalls unbequem, aber vielleicht haben sie sich an diese Unbequemlichkeit gewöhnt und sie vergessen.
Wenn PRs über Repositories hinweg unterstützt würden, könnte man solche Abläufe vereinfachen; ich wünsche mir so eine Funktion seit fast zehn Jahren.
Ich habe eingestellt, dass Kinderkonten nur Dinge sehen können, die mit bestimmten Tags versehen sind, und Plex-Tags sind ziemlich granular, sodass man ganze Filme oder TV-Serien, Teile von TV-Serien oder nur einzelne Episoden erlauben kann.
Inzwischen haben sie Zugriff auf ziemlich viele Inhalte, aber neue Inhalte werden nicht automatisch freigeschaltet.
Wenn ich etwa neue Bluey-Folgen bekomme, will meine Frau sie vorher ansehen, und bei Kindersendungen gibt es selten wirklich etwas Problematisches, daher genehmigen wir fast immer, aber es beruhigt.
Ich erinnere mich nicht mehr genau an die Begriffe, aber es gibt sowohl Tags als auch Labels, darauf muss man achten.
Früher hatte ich es mit der falschen Seite versucht; im Grunde erstellt man ein Label und stellt dann ein, dass das Kinderkonto nur Inhalte mit diesem Label sehen darf.
Das ist gut, weil man die meisten Filme über die Altersfreigabe sperren und einzelne Filme separat erlauben kann.
Als Entwickler, der nur auf Linux-Systemen arbeitet, frage ich mich, wie die C#-Entwicklungsumgebung ist.
Ich dachte, Mono gebe es noch und das sei die Runtime, die C#-Projekte beim Ausführen verwenden.
In Nicht-Windows-Umgebungen fand ich C# immer etwas befremdlich, aber vielleicht lag ich da die ganze Zeit falsch.
Da ich es beruflich nie einsetzen konnte oder musste, weiß ich nicht wirklich, wie gut die Tools auf Mac oder Linux sind und wie es in der Praxis funktioniert.
Andererseits habe ich mehrfach gelesen, es sei wie ein besseres Java, und hier scheint F# auch recht beliebt zu sein.
Das C#-Plugin funktioniert in VSCodium nicht.
Ähnlich wie bei Java setzt auch das Design der Sprache C# ziemlich stark voraus, dass man eine IDE verwendet.
Für Webanwendungen ist es ansonsten aber in Ordnung.
Man muss bei der SDK-Installation etwas aufpassen und einige System-APIs verhalten sich leicht anders, aber insgesamt ist es nur so, dass ich Windows ganz leicht bevorzuge.
Mono existiert noch, aber seit etwa 2015 wird C# unter Linux nativ unterstützt, und meines Wissens nutzt heute kaum noch jemand Mono wirklich.
Der Hauptanwendungsfall ist eher das Ausführen von .NET-Framework-Apps, nicht .NET Core.
Mono ist noch vorhanden und wird für einige Spezialfälle wie WASM oder Interpreter genutzt.
Soweit ich weiß, wird es auch bei Azure oft bevorzugt, es auf Linux-Maschinen laufen zu lassen, und dort, wo ich arbeite, ist es ebenfalls so.
Die Performance ist meiner Meinung nach gleich gut oder sogar besser.
Inzwischen arbeiten viele C#-Entwickler, vielleicht sogar die Mehrheit, auf Nicht-Windows-Maschinen, und Unterstützung für die neue Mac-Architektur wurde ebenfalls sehr schnell ergänzt.
Kurz gesagt: Die C#-Sprache selbst ist heutzutage in Nicht-Windows-Umgebungen gleich gut oder besser.
Ich habe kurz ins GitHub-Repository geschaut: Im Haupt-Repository gibt es über 90 offene PRs, und einige haben seit über 8 Monaten kein Feedback erhalten
Wenn das aktuelle Team nicht einmal die bestehenden PRs abarbeiten kann, weiß ich nicht, welchen Sinn dieser Aufruf zur Mitarbeit hat
In diesem Zustand helfen dem Projekt noch mehr PRs nicht
Ein ziemlich einfacher PR dafür ist seit Februar 2023 offen und liegt ohne umsetzbares Feedback unverändert herum: https://github.com/jellyfin/jellyfin/pull/9291
Ich wusste gar nicht, dass Jellyfin Entwickler sucht
Ich bin zwar ein intensiver Plex-Nutzer, arbeite aber als C#-Entwickler, also habe ich das Server- und Web-Projekt geklont und mich an mein erstes Issue gemacht
Ich mag Jellyfin wirklich sehr und nutze es seit drei Jahren
Bei Hacktoberfest werde ich auf jeden Fall mitmachen
Ich würde Jellyfin gern nutzen, aber es gibt keinen offiziellen Apple-TV-Client
Ich nutze ihn, und er ist ganz okay
Er ist auch in Jellyfin integriert
[0] https://firecore.com/infuse
[1] https://jellyfin.org/posts/client-infuse/
Als ich vor ein paar Jahren einen ausprobiert habe, hatte ich mit dem Jellyfin-Client keine besonderen Probleme
Dass ich Jellyfin nicht mehr genutzt habe, lag daran, dass Locast eingestellt wurde, und das war mein Hauptanwendungsfall
Sortier- und Filteroptionen fehlen weitgehend, es ruckelt, etwa wenn Filmkarten beim zu schnellen Scrollen an der falschen Stelle geladen werden, und manchmal aktualisiert sich die Fortschrittsleiste nach dem Pausieren für den Rest des Films nicht mehr
Benutzbar ist es aber trotzdem
Die Entwicklung ist etwas unregelmäßig, aber als ich es früher brauchte, hat es ordentlich funktioniert
Ich wollte Jellyfin wirklich nutzen und bin früher umgestiegen, bin dann aber zu Plex zurück, als ich sah, dass es viele nicht authentifizierte APIs gibt, einschließlich Videostreams
Jellyfin ins Web zu stellen wirkte mir zu riskant
https://github.com/jellyfin/jellyfin/issues/5415
Ich würde mich freuen, wenn die Chromecast-Funktion in Jellyfin iOS endlich entwickelt würde
Buchstäblich nur wegen dieser einen Funktion nutze ich Plex statt Jellyfin
Es wäre schön, wenn jemand dazukäme, der sich mit der Chromecast API gut auskennt und dem Team hilft