開発者募集のお知らせ - Jellyfin

 (jellyfin.org)
2 ポイント 投稿者 GN⁺ 2023-10-04 | 1件のコメント | WhatsAppで共有
  • Jellyfinは2023年10月のHacktoberfest 10周年を機に、停滞しているコントリビュータ基盤を広げ、サーバー・Web UI・クライアント改善の速度を高めようとしている
  • プロジェクトは半商業的ではないボランティアモデルを維持しており、寄付金もインフラ費用と、まれに必要となる開発用クライアントハードウェアにのみ使用している
  • 中核コントリビュータはサーバー、Web UI、全クライアントを合わせて最大で約30人規模で、過去3年間ほとんど増えておらず、一部のアプリは1〜2人が個人の時間で保守している
  • ユーザーの不満はクライアント対応の不足と完成度不足に集中しており、Chromecastのように需要の大きい機能・クライアントでも、しばらく開発の勢いがなかったことがある
  • 小さなバグ修正、ドキュメント改善、UI/UX、翻訳、全クライアント開発まで、いずれも必要であり、継続的に質の高い貢献をする人には公式チーム参加の可能性もある

Jellyfinが今コントリビュータを探している理由

  • JellyfinはDigitalOceanのHacktoberfest10周年に合わせ、新しいコントリビュータの流入を重要課題としている
  • Plexを巡る論争が起きるたびにJellyfinが代替として言及される一方で、コミュニティではクライアント不足、特定機能の欠如、完成度不足も繰り返し話題になる
  • こうしたギャップを縮めるには、より多くの人がコード改善、新機能開発、ドキュメント整備に参加する必要がある

ボランティアベースのプロジェクトが抱える制約

  • JellyfinはFLOSSの中でも珍しい非商業的プロジェクトとして運営されている
    • 開発者、翻訳者、コミュニティ運営者、問題解決を支援するメンバーはすべてボランティアである
    • Jellyfinの作業で報酬を受け取る人はおらず、企業や別組織からの支援もない
    • 収益化の計画はなく、バグバウンティも意図的に避けている
  • 寄付金はインフラ費用と、必要なときにまれに購入する開発用クライアントハードウェアにのみ使われる
    • 寄付金で開発者に報酬を支払うことはなく、今後もそうしない方針である
  • こうした選択は、他のメディアストリーミングプロジェクトがFLOSSとして始まりながら、収益を理由にユーザーに不利な機能を追加し、クローズドソースへ移行する流れを避けるためである

小規模チームで広い範囲を維持する負担

  • 現在の中核コントリビュータ基盤は、サーバー、Web UI、すべてのクライアントを合わせて最大で約30人規模である
    • 過去3年間、全体規模はほとんど増えていない
    • 一部の領域、特に個別アプリは1〜2人が無償で個人の時間を使って作業している
  • 需要の大きい機能やクライアントでも、開発を始めたり支援したりする人がいなければ進捗が止まることがある
    • Chromecastは一時あきらめざるを得なかったが、ここ数週間で再び動きが出てきた

参加方法と公式チーム参加への道筋

関連記事

1件のコメント

 
GN⁺ 2023-10-04
Hacker News のコメント

  • Jellyfin が C# ベースだとは知らなかった
    キャリアは C# 開発者として始めたが、今は C++ しか使っておらず、C# をまた使ってみるプロジェクトをずっと探していた
    Jellyfin で不便に感じていた点のリストがあるので、C# だと分かった今、自分で直してみようという気になっている

    • しばらく C# を使っていなかったなら、かなり楽しめる可能性が高い
      言語は大きく進化していて、特に パターンマッチング、using 文、性能重視の基本型など、開発者体験が良くなっている
      今年初めから再び C# をフルタイムで使い始めたが、とても満足している

  • Jellyfin チームは、こうした参加呼びかけを、ユーザーが機能をリクエストする場所にも一緒に表示するとよさそう
    ブログ記事の例である Chromecast 対応については、この issue で機能実装をどう手伝えるか尋ねていた: https://github.com/jellyfin/Swiftfin/issues/271#issuecomment...
    実際にはその機能に生産的に貢献できることがなかったとしても、スタートガイドがあれば間違いなく見に行っていたと思う
    手伝いたいと人々が尋ねている issue に、ブログ記事と入門資料をすばやくリンクしておけば、かなりうまく転換できそう
    Jellyfin に貢献しているすべての人に感謝しているし、開発者オンボーディングがしばしばより大きな作業になることも分かっているが、行動喚起リンクを置くのに良い場所ではないかという提案

  • 以前から多く要望されていて、実装も難しくなさそうに見えた タグベースの許可リスト機能を追加しようとし、サーバーコードのどこに入れるかも把握していた
    しかし機能を届けるには少なくとも 2 つのリポジトリにまたがって PR を扱い、統合テストのために 2 つのリポジトリを行き来する必要があると気づいて諦めた
    強く結合したコードには単一リポジトリが本当に便利
    もう一度見てみるかもしれない
    付け加えると、許可リストベースのペアレンタルコントロールは最良のツールの 1 つなのに、実質的に対応しているところがほとんどなくて歯がゆい

    • 少なくとも、どこで詰まって諦めたのかフィードバックを送るとよさそう
      おそらく自分だけが経験した問題ではないはず
      プロジェクト側にとっても不便だろうが、その不便さに慣れてしまって忘れている可能性もある
    • これは git/GitHub の大きな問題
      リポジトリ横断 PR をサポートしてくれれば、こうした手順を簡素化できるはずなのに、もうほぼ 10 年その機能を望んでいる
    • 参考までに、Plex のペアレンタルコントロールは信じられないほど柔軟
      子どものアカウントは特定のタグが付いたものだけ見られるようにしてあり、Plex のタグはかなり細かいので、映画やテレビ番組全体、テレビ番組の一部、単一エピソードだけを許可することもできる
      今ではかなり多くのコンテンツにアクセスできるが、新しいコンテンツは自動では開放されない
      Bluey の新エピソードのようなものを入手すると、妻が先に見たがるし、子ども向け番組で大きく問題になるものはまれなので、ほぼいつも承認するが、安心できる
    • 長い間、許可リストで不便に感じていたが、Reddit で Plex で許可リストを作る方法を学んだ
      用語は正確には覚えていないが、タグとラベルが両方あるので注意が必要
      以前は間違った方を試していて、基本的にはラベルを作った後、子どもアカウントがそのラベル付きコンテンツだけを見るように設定すればよい
    • Plex は 許可リストとブロックリストの両方に対応している
      ほとんどの映画はレーティングでブロックしておき、一部の映画だけ個別に許可できるのが良い

  • Linux システムだけで仕事をしている開発者として、C# 開発環境がどんなものか気になる
    Mono はまだあり、C# プロジェクトが実行されるときに使うランタイムはそちらだと思っていた
    Windows ではない環境では C# は少しぎこちないといつも感じていたが、これまで誤解していたのかもしれない
    職場で使う機会や必要がないので、Mac や Linux でツールがどれほど良いのか、実際にどう動くのかよく分からない
    一方で、より良い Java のようなものだという話を何度も見たし、ここでは F# もかなり好まれているようだ

    • Arch ではインストールが少し面倒で、Mono が事実上消えた後は、IDE の選択肢が Microsoft のクローズドソースな VS Code だけという感じ
      C# プラグインは VSCodium では動作しない
      Java と同じように、C# の言語設計も IDE を使う前提がかなり多い
      それでも Web アプリケーションなら、それ以外は問題ない
    • Linux での C# は Windows より少し面倒な程度
      SDK のインストールに少し気を使う必要があり、一部のシステム API がやや異なる動きをするが、全体としては Windows をほんの少し好む程度
      Mono はまだ存在するが、2015 年ごろから C# は Linux でネイティブサポートされており、知る限り今では Mono を実際に使うケースはほとんどない
      主な用途は .NET Core ではなく .NET Framework アプリを実行すること
    • Mono はまだあるが、Jellyfin は Microsoft が提供するフリーでオープンソースのランタイムである .NET Core を使っている
    • C# 開発環境は素晴らしく、Linux でネイティブに実行される
      Mono はまだ残っていて、WASM、インタープリターのような一部の特殊用途で使われている
    • C# はかなり前から Linux でネイティブに実行されていた
      知る限り Azure でも Linux マシンで動かすことを好む場合が多く、自分の職場もそう
      性能も同等か、より速いくらいだと思う
      今では多くの C# 開発者、おそらく多数派が Windows ではないマシンで働いており、新しい Mac アーキテクチャへの対応も非常に早く追加された
      要するに、最近の C# 言語自体は Windows ではない環境でも同等かそれ以上

  • GitHub リポジトリを少し見てみたが、メインリポジトリにはオープンな PR が 90 件以上あり、その一部は8か月以上フィードバックがない
    現在のチームが既存の PR の量も処理できていないなら、この参加呼びかけにどんな意味があるのか分からない
    今の状態では PR がさらに増えてもプロジェクトの助けにはならない

  • Jellyfin が開発者を必要としているとは知らなかった
    Plex を熱心に使っているユーザーだが、仕事では C# 開発者なので、サーバーと Web プロジェクトをクローンして最初の Issue に取り組んでみた

  • Jellyfin が本当に好きで、3 年目になる
    Hacktoberfest には必ず参加するつもり

  • Jellyfin を使いたいのに Apple TV の公式クライアントがない

    • https://github.com/jellyfin/Swiftfin
      使っているが悪くない
    • Infuse メディアプレーヤー[0][1]は Apple TV / iOS / macOS クライアントが優秀
      Jellyfin とも統合されている
      [0] https://firecore.com/infuse
      [1] https://jellyfin.org/posts/client-infuse/
    • 既存のクライアントがそんなに良くないのか気になる
      数年前にひとつ使ったときは、Jellyfin クライアントに特に問題はなかった
      Jellyfin を使うのをやめたのは Locast が終了し、それが主な用途だったから
    • Apple TV を買ってから Swiftfin を使っているが、まあまあ悪くない
      並べ替えとフィルターのオプションがかなり不足していて、速くスクロールしすぎると映画カードが変な位置に読み込まれるなど動作がもたつき、一時停止後に残りの映画の間、進行バーの更新が止まることもある
      それでも使えるレベルではある
    • Swiftfin があるのでは？
      開発はやや断続的だが、以前必要だったときは問題なく動いていた

  • Jellyfin を本当に使いたくて以前乗り換えたが、認証されていない API が多く、動画ストリームまで含まれると知って Plex に戻った
    Jellyfin を Web に公開するには危険すぎるように見えた
    https://github.com/jellyfin/jellyfin/issues/5415

  • Jellyfin iOS の Chromecast 機能がついに開発されるといいのに
    文字どおりこの機能ひとつのために、Jellyfin ではなく Plex を使っている
    Chromecast API に詳しい人が加わってチームを助けてくれるといい