流れを把握するために主なイベントを列挙します。私が詳細を把握しているのは不具合発生時に遡って調査をするためです。

Jpsonicでは当初、パッチ処理で日本語対応が可能かどうかの技術調査が行われていました。その方法では無理があり、またAirsonicの開発方針では日本語処理が上流に機能追加しにくいことが明確になった頃から徐々にリブランドを行っています。

AirsonicとJpsonicは特に敵対関係にあったわけではありません。Jpsonicの開発中に致命的な問題が見つかれば、Subsonic/Airsonic/Jpsonicのうちどこの不具合か調べフィードバックしていました(そのため私のGithubのアカウントにAirsonicメンテナのマークが表示され、AirsonicのContributorsには私のアイコンが表示される)。図ではかなり早期のうちからAirsonicとJpsonicが分化していますが、並行開発期間が3年程あり、その間Airsonicが開発を終了する直前までの上流の修正は、Jpsonicへ取り込まれています。

Jono Baconさんが書かれているのは、事業化されていてとにかく維持するタイプのプロジェクトのお話です。中小規模の開発で上記の記事にあるような問題が発生した場合、オーナーは第三者のブロック(fire)ではなく、逆視点の防護策により穏便に事態を収束させることがしばしばあります。自分が離脱する、コアメンバーを隔離する、プロジェクトを凍結するなどです。

開発規模とコミュニテイの技量の総量バランス的に、バザール開発でのリスクが高いレンジというのはあるのかもしれません。あるいはそれとは別に、特に誰が悪い訳でもなくバザール開発の難易度自体が年々上がっている疑いもあります。

最終局面でプロジェクトの生殺与奪を握っているのは参加者ではなくプロダクトオーナーです。「派生を作らずメインストリームに貢献すべき」という一般論には異論はありませんが、それはもちろん上流の体制が盤石な場合もしくは盤石な期間だけです。Jpsonicが早期に派生を作成していたのは、再度上流の開発が停滞しても自前で開発を継続するためでもありました。

投げ銭自体はなかなかによくできた仕組みです。ユーザの意志がダイレクトに反映され公平性があるようにも見えます。ただし、とある国では規制をかけるほどアイドルに大量の投げ銭が集まることがある一方　ソフトウェアに投げ銭する人はほぼいないということです。

オープンソースといってもOSやDB、開発ツールのようなコミュニティは訓練を積んだ人が主体となります。一方メディアサーバの場合は「誰でも参加」の典型例です。コミュニティから技術的にも金銭的にもフィードバックが期待できずスポンサーもない場合、オーナーは一方的にコミュニケーションコストのみを負担することになります。現状こういった問題を解決する方法のひとつがプロプライエタリ移行だったりします。

「クローズドソース＝考えが閉鎖的」のような捉え方は短絡的かもしれません。

日本語でブラウジングや検索できるサーバをあらかじめ使用しておけば、管理運用は効率的になります。また海外サーバに迎合してしまうと、自国で音声入力やスクリーンリーダとの親和性を一向に改善できないという問題もあります。これは音楽サーバに限った問題ではありません。

これもJpsonicが早くからAirsonicから分派した原因のひとつです。Airsonicでの対応が遅かったり、しばしばデグレードが発生していたためです。開発を阻害しないようJpsonicのライブラリ更新は非常に速いスパンで行われます。

特に意見を募集せず、代わりに定期的に国内音楽市場の動向に関する統計資料を見ています。ネットに転がっています。

• 10年以上前の海外サーバと現代日本のニーズとのミスマッチは自明です。機能改廃にあまり議論の余地がありません
  • まずはスマホアプリで再現可能な機能改善を優先するのが合理的、といった指針の根拠になります
  • 他国より使われていないスマートスピーカのために、ベンダー製APIをサポートする重要性は低いでしょう
  • 今どきの現実的なオーディオ構成にも留意が必要。サーバのサウンドカード叩く機能は使われなくなっています
  • Xperiaが国内Androidシェア1位。それならLDACを活用可能な機能やSONY仕様を意識するのが妥当 …etc
• おそらくストリーミングサーバに必須となる機能は無限に増えず、また急激に変化したりしません
  • 時代と共に使われなくなる機能が少しあります
  • 時代と共に使われるようになる機能が少しあります
  • スマホアプリで再現できない機能や、スマホアプリで実現できている機能の追加は無駄である可能性があります
• 必要な修正を優先し、やみくもな機能追加には慎重です
  • この世の全ての人の意見全てを受け入れればよいものができるかというと、それほど単純ではありません
  • 意見自体は、類似プロダクトで何十年分の蓄積が見れます(これをする人がどれだけいるのか)
  • 実はOSSのコミュニティでの意見は、たまたまそこに居合わせた人の意見でしかありません
  • 実はユーザの意見に画期的なものはほぼなく、どこかで見たことのあるものが多くなります

いわゆるトップダウン型アプローチです。バザール型でボトムアップ形式の開発を否定しているわけではなく、それを実現するために条件をすぐに揃えるのはなかなか難しいかなと。不十分な体制で形だけを真似るとプロジェクトは迷走し、コミュニティによってはノイズが優勢になる場合もあります。というわけで現状はこの方式を取っています。

手あたり次第は非効率なため「探す」「聴く」に関わる不具合が常に優先されます。幸いこれらの大部分が回収済みです。

リスキーな機能追加よりも既存の問題の修正が優先されます。この分野で実力を発揮できる方の参画は歓迎です。レガシーサーバをレストアできる技能は即戦力です(これできる人は最新技術も比較的簡単にキャッチアップできるので)。