SubsonicとJpsonicの違いを解説します。
言うまでもなく日本語対応の有無ですが、Subsonicはソースが非公開、Jpsonicはオープンソースというのが一番の差です。
Jpsonicではパッチリビジョン単位でのライブラリ管理が行われており、依存ライブラリはほぼ最新に保たれています。Subsonicは時が止まっているので、10年以上もの間に行われた依存ライブラリのバグフィクスやパフォーマンス改善、セキュリティパッチの恩恵が受けられません。
機能の差異
JpsonicはSubsonicとほぼ同じように使用可能です。ただし仕様の修正、機能の改廃等により異なっている部分もあります。
機能変更には様々な理由がありますが、大まかにいえばSubsonicの元々持つ機能(10年以上まえに作成された海外仕様)を、現代の日本向け仕様に変更しています。例えば日本では「Sonos」は海外ほど使用されていないため、バージョンアップせず削除されています。そのかわり、他の国々より普及している「LDAC対応のスマホやハイレゾ機器」と親和性が高くなるよういくつかの機能が追加・変更されています。
APIの差異
Subsonic APIはストリーミングサーバ黎明期に作成されたものです。要件は当時の感覚で広めに捉えて設計されています。たとえば今では下火となった音楽SNSに似た機能が定義されていたりします。Airsonic/Jpsonicでは現在では需要が低くなっているいくつかの関数は廃止されています。
AirsonicのAPI設計 同様、Subsonic API 1.15のコンパチ版です。使用頻度の低いいくつかの関数がオミットされています
Subsonic APIは1.14以降画期的な設計追加はありません。世のSubsonicアプリはほぼAPI1.14相当です
一般的なSubsonicアプリの動作に支障はありません
プランド
メソッド
レスポンス
コメント
Airsonic
getChatMessages
410
チャットが定義されているのは、SNSが今ほど一般的になる前時代の名残
Airsonic
addChatMessage
410
Airsonic
getVideoInfo
501
動画のストリーミングはこの関数を使用せずとも利用可能
Airsonic
getCaptions
501
同階層にある同名動画ファイルに字幕をオーバーラップする隠し機能は移植されていない(flash依存のため。JavaScriptでやりたくないでしょ)
Jpsonic
getNowPlaying
–
デフォルトで無効。個人設定で有効化可能。FAQ にも記載あり。名称から演奏状態を把握するための関数と誤解されそうですがほぼチャット関連機能
Jpsonic
jukeboxControl
410
[JEP 396] に関連しており、Java16以降の標準に従うため削除。音質に関わる主要なデバイスはどちらかといえばサーバ外に存在するのがトレンド
Subsonicフォークまとめ
ストリーミングサーバのライフサイクルは非常に長いため、使い始めて数年経つとウラシマさんになっている場合があります。そのような方のためにSubsonicやSubsonicの子孫がどのようになっているかヒストリをまとめておきます。
2016年に、Subsonicがクローズドソースへ移行するという大転換が行われました。その前後に、コードを維持するため派生プロダクトがいくつか生まれています。オープンSubsonicを源流とするフォークで最も知名度が高いのはAirsonicであり、JpsonicはそのAirsonicを元に作成されています。
Subsonic
クローズド移行したためバグ修正/機能追加/セキュリティ更新が不可能。実用は厳しい
Libresonic
Subsonicがクローズする際にフルフォークとブランド変更を行ったサーバ。公式リリースは一度だけ
Airsonic
Libresonicのフォーク。世界的にオープンSubsonicの後継と認知されている
Jpsonic
Airsonicのクローンで日本人向け機能を強化したサーバ
フォークポイントは各サーバのリリースタグを追うことで把握できます。まとめて図にするとこのようになります。
2015年から2017年にかけてが激動期 であり、オープンソース版としてリブランドされたLibresonicのリリース、その直後にさらにリブランドされたAirsonicのリリースと続いています。概ね市場の同意が形成されAirsonicが実質後継ポジションに収まりました。Airsonicはその後2021年に開発を終了しています。
ちなみに日本レコード協会の調べでは、ストリーミング配信がダウンロード配信の売り上げを抜いたのが2018年です。「音楽を手元に置かなくなった時代」到来と思いきや、日本はCD市場がかなり大きいです。当分需要がありそうなため2019年にJpsonicのv100.0.0が公開されました。
主な転換ポイント
流れを把握するために主なイベントを列挙します。私が詳細を把握しているのは不具合発生時に遡って調査をするためです。
2015年10月
5.3
Libresonicの開発起点
APIバージョンは1.13.0でこれ以前は平文パスなので非実用的
2016年02月
6.0.beta1
最後のオープンSubsonic
Subsonic API 1.15 の最終実装。1.13-1.14で実用アプリは作れる
2017年03月
v6.2
LibreSonic初リリース
最初で最後の公式リリースでGithub/セマンティックバージョン移行
2017年07月
v6.2.1
Airsonic始動
Libresonicのパッチリリースでブランド温存措置と公知される
2017年08月
v10.0.0
Airsonic初リリース
API1.15、Docker、外部DB連携、DLNA機能の強化など
2017年12月
v10.1.1
Jpsonic始動
初期開発は設計差分の調査目的(パッチで日本語対応可能か検討)
2019年02月
v100.0.0
Jpsonic初リリース
日本語は別プロジェクトでなければ無理筋のため正式リブランド
2021年05月
v110.0.0
Airsonicとの切り離し
pomバージョンはAirsonicのものを利用していたがここで完全に分離
2021年08月
v10.6.2
Airsonic開発終了
マージに積極的なメンテナがいなくなったためアーカイブ化
Jpsonicでは当初、パッチ処理で日本語対応が可能かどうかの技術調査が行われていました。その方法では無理があり、またAirsonicの開発方針では日本語処理が上流に機能追加しにくいことが明確になった頃から徐々にリブランドを行っています。
AirsonicとJpsonicは特に敵対関係にあったわけではありません。Jpsonicの開発中に致命的な問題が見つかれば、Subsonic/Airsonic/Jpsonicのうちどこの不具合か調べフィードバックしていました(そのため私のGithubのアカウントにAirsonicメンテナのマークが表示され、AirsonicのContributorsには私のアイコンが表示される)。図ではかなり早期のうちからAirsonicとJpsonicが分化していますが、並行開発期間が3年程あり、その間Airsonicが開発を終了する直前までの上流の修正は、Jpsonicへ取り込まれています。
なんで派生がたくさんできちゃうの?
偉い人の文章を読んだ方がためになるかもしれません。このfireは「解雇する」のfire(受験単語)。
Firing community members Jono Bacon(元Ubuntuのコミュニティーマネージャー)の記事
昔のOSS開発は人少なかったけどいいスキルセットの人が集まりやすかった
インターネットの普及で多くの人が集まるようになった
スキルの多様性も必要なんだけど価値と品質も必要だよ ← これがとても難しい問題
最終的にはコミュニケーションや人間関係の問題になるんだけど、まぁ結論のない話さ!
Jono Baconさんが書かれているのは、事業化されていてとにかく維持するタイプのプロジェクトのお話です。中小規模の開発で上記の記事にあるような問題が発生した場合、オーナーは第三者のブロック(fire)ではなく、逆視点の防護策により穏便に事態を収束させることがしばしばあります。自分が離脱する、コアメンバーを隔離する、プロジェクトを凍結するなどです。
開発規模とコミュニテイの技量の総量バランス的に、バザール開発でのリスクが高いレンジというのはあるのかもしれません。あるいはそれとは別に、特に誰が悪い訳でもなくバザール開発の難易度自体が年々上がっている疑いもあります。
最終局面でプロジェクトの生殺与奪を握っているのは参加者ではなくプロダクトオーナー です。「派生を作らずメインストリームに貢献すべき」という一般論には異論はありませんが、それはもちろん上流の体制が盤石な場合もしくは盤石な期間だけです。Jpsonicが早期に派生を作成していたのは、再度上流の開発が停滞しても自前で開発を継続するためでもありました。
Subsonic以外の事例
ちなみにこの時期にプロプライエタリ移行したメジャータイトルはSubsonicだけではありません。UPnP実装として定評のあるMinimServerは、MinimServer 2からはSubsonic同様プロプライエタリ移行しています。投げ銭方式では十分な利益はないためたたんだ、というのが理由だそうです。
投げ銭自体はなかなかによくできた仕組みです。ユーザの意志がダイレクトに反映され公平性があるようにも見えます。ただし、とある国では規制をかけるほどアイドルに大量の投げ銭が集まることがある一方 ソフトウェアに投げ銭する人はほぼいないということです。
オープンソースといってもOSやDB、開発ツールのようなコミュニティは訓練を積んだ人が主体となります。一方メディアサーバの場合は「誰でも参加」の典型例です。コミュニティから技術的にも金銭的にもフィードバックが期待できずスポンサーもない場合、オーナーは一方的にコミュニケーションコストのみを負担することになります。現状こういった問題を解決する方法のひとつがプロプライエタリ移行だったりします。
「クローズドソース=考えが閉鎖的」のような捉え方は短絡的かもしれません。
Jpsonicの方針
「聴く・探す」を優先し整備しています。今後機能追加を行う可能性はありますが、既存機能の見直しや品質向上がメインです。
リスク選好の機能追加はほぼ行われないため、海外の不具合が多いプロダクトに辟易している方にはお勧めかもしれません。
日本語を重視
どこの国の音楽市場も洋楽が半数以上ですが、日本では3割程度で残りは自国のメディアが占めます。一般的な日本人が音楽を大量管理し始めると、数千曲でフラストレーションを感じるでしょう。多くの場合そこに目を瞑るか、工夫の名のもとに俺様管理ルールを編み出し始めるかの二択になります。長期的にはあまり望ましくない解決方法です。
日本語でブラウジングや検索できるサーバをあらかじめ使用しておけば、管理運用は効率的になります。また海外サーバに迎合してしまうと、自国で音声入力やスクリーンリーダとの親和性を一向に改善できないという問題もあります。これは音楽サーバに限った問題ではありません。
ライブラリを最新に保つ
セキュリティを向上させたり不具合修正パッチを取り込むため、最新のライブラリに保つことは欠かせません。またライブラリをアップデートしたことにより、付随して実装を修正しなければならない場合もあります。こういった管理作業は本筋の開発とは別に強制的に発生します。
これもJpsonicが早くからAirsonicから分派した原因のひとつです。Airsonicでの対応が遅かったり、しばしばデグレードが発生していたためです。開発を阻害しないようJpsonicのライブラリ更新は非常に速いスパンで行われます。
機能リクエストには慎重な姿勢
特に意見を募集せず、代わりに定期的に国内音楽市場の動向に関する統計資料を見ています。ネットに転がっています。
10年以上前の海外サーバと現代日本のニーズとのミスマッチは自明です。機能改廃にあまり議論の余地がありません
まずはスマホアプリで再現可能な機能改善を優先するのが合理的、といった指針の根拠になります
他国より使われていないスマートスピーカのために、ベンダー製APIをサポートする重要性は低いでしょう
今どきの現実的なオーディオ構成にも留意が必要。サーバのサウンドカード叩く機能は使われなくなっています
Xperiaが国内Androidシェア1位。それならLDACを活用可能な機能やSONY仕様を意識するのが妥当 …etc
おそらくストリーミングサーバに必須となる機能は無限に増えず、また急激に変化したりしません
時代と共に使われなくなる機能が少しあります
時代と共に使われるようになる機能が少しあります
スマホアプリで再現できない機能や、スマホアプリで実現できている機能の追加は無駄である可能性があります
必要な修正を優先し、やみくもな機能追加には慎重です
この世の全ての人の意見全てを受け入れればよいものができるかというと、それほど単純ではありません
意見自体は、類似プロダクトで何十年分の蓄積が見れます(これをする人がどれだけいるのか)
実はOSSのコミュニティでの意見は、たまたまそこに居合わせた人の意見でしかありません
実はユーザの意見に画期的なものはほぼなく、どこかで見たことのあるものが多くなります
いわゆるトップダウン型アプローチです。バザール型でボトムアップ形式の開発を否定しているわけではなく、それを実現するために条件をすぐに揃えるのはなかなか難しいかなと。不十分な体制で形だけを真似るとプロジェクトは迷走し、コミュニティによってはノイズが優勢になる場合もあります。というわけで現状はこの方式を取っています。
「探す」「聴く」にかかわる不具合を優先的に修正
多くの目があれば問題は解決するとは言われますが、それは嘘です。ぶっちゃけると何十何百何万の目があっても戦力としてはゼロであることも多々あります。問題というものは解決するためのアクションをとらない限り解決しません。
手あたり次第は非効率なため「探す」「聴く」に関わる不具合が常に優先されます。幸いこれらの大部分が回収済みです。
リスキーな機能追加よりも既存の問題の修正が優先されます。この分野で実力を発揮できる方の参画は歓迎です。レガシーサーバをレストアできる技能は即戦力です(これできる人は最新技術も比較的簡単にキャッチアップできるので)。
9割位はバックグラウンド側の修正 になるかと思います。
Webページはどちらかといえばシンプルにする修正が行われています。あわよくばいつか優良なUI・UX/アクセシビリティを実現できればいいなと考えてもいます(ただそこまで時間がとりにくい)。現在のレイアウトは単にAirsonicのデザインを短期間で是正したものであり、ファイナルと決めているわけではありません。俺がガンダムだという方はご提案ください。
抑制または削除された機能
Jpsonicでは新しい機能の追加や改善も行われていますが、同じくらい不要な機能の削除を重視しています。Subsonic/Airsonicに存在していた機能でも、オプション化されデフォルトオフにする形で画面上から削除される場合があります。これらは後に改善され通常機能として復活するか、または現状維持(デメリットを承知で有効化して使ってもらう)か、あるいは時期を置いて削除される場合があります。
これらはWikiのSuppressed or Removed Features というページにまとめられています。
急激になんでもかんでも削除してしまう姿勢のプロジェクトには使う側も危機感を感じると思います。ですので、ある程度の理由を添えてJpsonicのメイン機能からは除外するよ、という告知をしています。
コミュニティのようなところで多数の総意をまとめあげるのがよい方法だ、と考えられがちですがそれはコミュニティが健全に機能している場合だけです。どんな人材でもとにかく人がいて、そこでなんとなく相談さえすればいい、というものでもありません。単独のメンテナが強権を行使して全てを決定するのは一見傲慢ですが、やる範囲が示されないというのも問題かと思うので現状のやり方がベターかと。
また削除された機能についても、今後このプロジェクトでは永久に実現されないことを意味しているわけでもありません。アーティストのカバーアートのように、役に立たないものを一度削除して、ほかの部分を再整備した後に、再度全く別の処理を構築するという過程の一部になることもあります。あくまで品質を押し下げている実装は削除される、というだけの話です。
既存の実装を洗練していけば生産性が高いのではないか、という考えもあるかもしれませんが、その考えありきは危険です。相応の技術者が担当すると全体が全く違う設計になったり、よりよい別のアプローチを取ることもあります。やっつけ仕事で追加された機能を始祖としてフォローアップするより仕切り直した方がよい場合、機能の削除は有益な作業になります。
更新履歴
この記事を書き換えたときに以下に追記します。
v114.0.0
「抑制された機能 (v112.1.0)」の記事はWikiのSuppressed or Removed Features に移動
「抑制された機能 (v112.1.0)」の記事は削除されるのでこの記事に導入として「抑制または削除された機能」を追加
v111.0.0
「SubsonicとJpsonicの違い(2021)」と「Subsonicフォークまとめ(2021)」を併合し、記事内容を圧縮
コメントはまだありません