取材: Eugen Rochkoが語る分散SNSの運営と成長

Mastodon/person
概要

Mastodon著者のEugen Rochkoに分散SNSの運営と成長に関する取材があったので紹介します。

私が認知できている範囲では2023-01-23の「取材: Mastodon著者Eugen RochkoのElon Muskへのメッセージ | GNU social JP」が最後の取材だったので、2か月振りの取材でした。

2023-03-28の以下の投稿で公開されていました。

Can Mastodon seize the moment from Twitter? – The Verge」が取材記事です。TwitterのMastodon公式アカウントが再投稿していて認知しました。

内容はMastodonの始まり、現在の運営体制、収益化、サーバー運営などで、文量が多く、やや踏み込んだ内容もありました。量が多いので特に気になった点を以下に示します。

注目点
  • 元々Twitterヘビーユーザー (Misskey著者しゅいろと同様)
  • 2021年にMastodonの法人設立
  • 意思決定の組織化モデルの構想
  • mastoson.socialの一般登録再開
  • 今後のMastodon本体への有料化機能の検討
  • 一般公開サーバーのたいへんさ
  • モデレーション自体は頻発せずそこまでたいへんではない
  • グループ機能が次の目玉機能

取材の英文を概要・抜粋で独自に解釈して翻訳したものを以下に掲載します。

体制

Q. Mastodonとは?

A. 2016年に取り組み始めたのは、Twitterのような重要なものを特定企業に委ねるべきではないと考えたから。当時はかなりのヘビーユーザーだった。10代だった2008年頃に使い始め、Twitterは人生の重要な部分だった。ただ、2016年頃にTwitterの会社としての運営、方向、コミュニティー、嫌がらせにうんざりしていて、別の方法を検討したのがきっかけだった。

Q. MastodonはOSSだが、そのCEOというのは実際には何のCEOになるのか?

A. 少しややこしいが、Mastodonを開発しているMastodonという名前の会社のCEO。2016年の大学生時代に開始。卒業後、当初は月額5 USDのPatreonを開始。その後、月額200、600 USDなどに増加。この時点で既に生活に十分だったのでフルタイムで取り組んだ。当初は個人事業主だった (日本でいう屋号がMastodonだったと思われる)。2021年にMastodonの別の法人を設立。時間を経て貢献者が増え、GitHubには700名以上が貢献してくれた。その他、委託業者など従業員もいる。

現在の体制。フルタイムの正社員 (開発者) としてCEOの自分自身と、Claire。契約ベースのパートナーにCFOと、採用担当者、フルタイム開発者としてさらに3名を採用活動中。委託業者として、iOSアプリ2名、Android1名の開発者。契約ベースパートナーにUXデザインエージェンシー (おそらく「Mastodon公式サイトのリニューアル | GNU social JP」で登場したOakというデザインスタジオ)。

整理すると現状の体制は以下の模様。

  • フルタイム開発者: Eugen Rochko/Claire
  • 契約ベース: CFO/採用担当
  • 業務委託: iOSアプリ開発者2名/Android開発者1名
  • 採用中: フルタイム開発者3名
  • 代理店: Oak

正社員2名、採用中3名、業務委託5名、代理店1社。

Q. 今後どう会社を運営していくか?

A. 11月以来かなりたいへんだった。今まではプロジェクトへのプレッシャーがはるかに低かった。2017年4月に「A beginner’s guide to Mastodon, the hot new open-source Twitter clone – The Verge」で取り上げられて、バズって普及した。今と比べると当時はかなり低いプレッシャーだった。今ははるかに高いプレッシャーがあり、自分一人で対応しきれないので、従事者を増やして委任していく必要がある。

11月以来、初めて採用を始めた。採用検討が社内全体の継続プロジェクトとなった。私一人から多くの人に拡大していくにあたって、優先的に確保が必要な重要な役割は何かの検討に時間を費やしている。

11月にはPatreonの寄付が月額7000 USDから3万 USDに増大した。予算は増えたが、それでも限られているので優先順位を考える必要がある。

考えた結果、24時間年中無休、運営と技術課題を解決に従事できないため、DevOps担当者が必要と判断した (サーバー運営者?)。加えて、自分以外にClaireと一緒に作業できる開発者。そして、プロダクトデザイナー。今までは自分でユーザビリティーやUXを考えてきたが、元々それに適切だったわけではない。Mastodonを最高の製品にするために、適切な設計担当者もほしい。

Q. 興味深いと思うので最初の話を伺いたい。2016年、2017年にMastodonが生まれて、Twitter買収後の2022年11月の時点で準備が整っていた。なぜ維持できた?このときを予測できたのか?

A. 予測はできなかったが、当時から遅かれ早かれ何かが起こるだろうと思っていた。SNSは流行り廃りがあります。MySpaceやApp.net、Google+Frindsterなどいろんな廃止したSNSがあった。Twitterもこうなる可能性はあると思っていた。正確な時期はわからないものの、廃止を意識して準備してきた。

統治

Q. Patreonでの収入以外の収入はあるか?

A. Patreonだけ。ただ、より上位のPatreonスポンサーがスポンサーシップとして資金提供するための追加のプラットフォームを作成した。Patreonの手数料を少し節約するためのもの。この2個がほぼ全て。

他に、NL.netから助成金を受けた。EUの分散SNSのOSSに対する助成金。これは1回限り。

1個前の質問に答えます。ビジョンを信じている。Mastodonがソーシャルメディアを行うより良い方法だと。そして実際に自分が毎日利用していて楽しんでいる。これが継続の理由。これはある種の仕事のようなものでもある。

Q. Mastodonの出口戦略はあるのか?上場企業の株式売却のような。

A. 出口戦略は始めた理由ではない。OSSとして、ここから得られるものは何もないが、プロジェクトとして成長するMastodonにはよい未来があると思う。現状の自分自身の賃金はかなり低いが、他に使うべき重要なことがあるから。いずれ、きちんとした賃金を得られる損益分岐点が訪れると願っている。

Q. 意思決定はどう行う?

A. 意思決定の枠組みは非常に重要に思う。コミュニティーの要求で決まることもあるが、自分が正しいと思うことにかかっている。将来、この意思決定のための組織化されたモデルの完成を楽しみにしている。「参加型ガバナンス」というのがキーワード。具体的なものはないが何人かに構想を話している。

というのも、機能や方向性について、コミュニティーの意見を推測するより組織化された方法がほしいから。現状は非常に混とんとしている。GitHub issueが主な意見表明の方法。ただ、この意見が多くの人が望んでいて恩恵を受けるのか、一人だけなのか、嫌われるものなんか判断が難しい。人々の代表意見を検知できる方法を見つけたい。裏付けがあるもの。

Q. OSSの統治モデルについてどう思うか? 例えば、Linuxの著者のLinus TorvaldsはLinuxの善意の終身独裁者 (BDFL: Benevolent dictator for life)となっている。

A. 「善意の終身独裁者」が今のやり方。これが効果的だと思っている。優れた製品には、長期的なビジョンと、まとまりのあるビジョンが必要。これは委員会制だと難しい。委員会制だと目の前の課題に終始してしまい、つぎはぎだらけで焦点の一部を失う。

他の分野ではわからないが、OSSではBDFLは理にかなっている。ただ、これ以外にいい方法がないとまでは思っていない。

収益

Q. 成長のために投資家からの提案はあったか?

A. VCから提案はあった。VCの動向把握のために何度か会話した。Patreonに依存しない資金調達モデルを検討していた。ただ、今のところはいいものがない、全て拒否している。

Patreonの寄付がなくなった場合に備えて、(ホスティング) サービスを数年間考えていた。ただ、この分野は多くの参入がある。自分たちに優位性はあると思うが、現時点では優先事項ではない。

ホスティングビジネスは、VC規模ではなく、リターンを約束できない。

Q. コミュニティーと製品について、現在何人のユーザーがいるのか?

A. 公式ウェブサイトの統計APIが数日間機能していないので回答できない。少なくとも月間150万人のアクティブユーザー (MAU: Monthly Active User) はいる。11月のピークは250 MAU。ただ、MAUはログイン時に集計される。その後収束する。現在も成長している。公式サイトのjoinmastodon.orgに修正を加えた。最初にメガサーバーを強調表示するように並べた。以前は小規模サーバーを強調していた。この方法だと、承認制のサーバー多くて、ユーザーフレンドリーではなかったから。

11月から取り組んできたオンボーディングの改善も効果があった。iOSとAndroidアプリで、サーバーリスト表示の前に、よい説明を表示している。

Q. サーバー運営の経済面は?運営者はお金を稼げるか?

A. Mastodonをホストするというのはお金を稼ぐことではない。Mastodonは自分のメガホンのようなもの。自分で所有できるSNS。自分や少数のグループで使う分にはそんなに高価ではない。モデレーションやコミュニティーの管理を心配する必要はない。

コミュニティー、一般向けサーバーを運営する場合は別の話になる。全く異なるレベルの責任、負担が伴う。モデレートか、モデレーターが必要になる。小規模コミュニティーなら、Webサイトから派生したもののことが多い。

Mediumがわかりやすい例。現在は、ライター向けの長編記事の公開プラットフォームになっている。Mediumに対する付加価値としてMastodonサーバーがある。

他には、収益化していないサーバーはPatreonで、サービスを高く評価する人々によって、寄付で維持されている。

mastodon.socialはMastodon社が運営するMastodonということになる。

Q. mastodon.socialの登録を停止したのはなぜ?

A. 一人で運営していると、スケーリングの問題や大規模サーバーの実行の技術的な問題が大きな負担だったから。他には、分散SNSだから、中央集権的なサーバーにさせたくなかったから。メガサーバーが登場すると、メガサーバーが物事を変更して独自の気まぐれを強制する不釣り合いが発生する。

例えば、Gmail。電子メールを自己ホストしようとすると、Gmailのスパムフィルターに引っ掛かることがある。これのせいで、Gmailや他の大手メールプロバイダーを使わざるを得なくなる。これは分散SNSで回避したい状況。

これを避けたいので、うまく分散させるようにしてきた。ただ、人々にはデフォルトが重要だというのを長年で学んだ。たくさんのサーバーから自分の登録先を選ぶのはかなり難しい。これだけ多様なサーバーがあるのは強みなのだが、これを実感するにはある程度習熟している必要がある。サーバーが多くて、複雑すぎて登録を選択できないという状況を避けたほうがいいと考え、登録を再開した。

登録を一時停止するのは、サービスの品質に影響がある場合だけ。ただ、今回会社を拡大して、専任のDevOps担当者を雇うので、今後も登録をオープンにできる。今は、最初の登録時の混乱を回避するために、アプリなどでのデフォルトサーバーのリストの中にmastodon.socialが表示されるようになっている。最初はmastodon.socialで始めてもらって、その後、他のサーバーに移動してもらうという考え。

Q. mastodon.socialのコストが高くなりすぎて、収益化が必要にならないか?

A. コストの判断は難しい。アカウント作成を有料にして、有料アカウントにするということは検討したことある。これは収益化の公正で非常に有力な方法だと思う。これは、Patreonでやっている名誉システムのようなことをソフトウェアで実現するようなもの。納得感は高い。

今後我々が有料アカウントを試すかどうかはわからない。が、他の管理者が利用できるようにして、ビジネスモデルを持続可能にしたいとは思っている。

Q. お金の質問が続いているが、これはこの規模で成功したいのであれば、実際にはエコシステムになる必要があるから。複数のビジネスモデルが存在する必要がある。個人的には好まないと思うが、どんなことに挑戦している?

A. イデオロギー的に反するのであまりよくわからない。

分散SNSにおけるビジネスモデルの多様性は良いとは思う。模索している人々が、全ての参加者に利益をもたらす。悪いビジネスは失敗し、良いビジネスモデルが成功する。オープンプロトコルのAPIベースだから、ロックダウンできない。

運営

Q. Tunblr/Flickr/Vivaldi/Mozilla/MediumなどがActivityPub参加について話していた。既存のSNSの参加をどう思うか?

A. オープンプロトコルに基づくTwitterは現状でも十分良いと思う。多くのプラットフォームが対応を発表しているとき、それがなんであってもよい開発だと思う。誰にとってもより便利になる。理想的にはオープンソースであればよいが、そうでなくてもよい状況に変わりはない。

Q. ActivityPubは汎用性が高い。TikTokのようにここから特定のフォーマットに特化したものはどうか?

A. これはすでに起こっている。ActivityPubは情報交換のためのプロトコル。投稿の種類がマッピングされる。Mastodonはマイクロブログや動画・画像などに焦点を当てている。写真に焦点を当てたPixelfedのようなものもある。PeerTubeがあり、フォローすると動画が流れてきて返信すると、コメント欄に反映される。

Q. 既存のプラットフォーマーがMastodonをフォークして、独自のネットワークを構築することへの危険性はないか?

A. こういう可能性はもちろんある。例えば、BlueskyやNostr。ActivityPubは有望な技術だが、完璧ではない。ただ、ActivityPubは拡張可能な技術だから、より良いものにすることはできる。セマンティクスを追加できる。徐々に追加しておくと、他の相互運用者がサポートを開始しようとなる。

Q. 一連のプロトコル関係の質問は、どう機能するか、機能させることについてどう考えているかに興味があったから。基本的に、「一企業がSNSを担当すべきでない」という中心概念の回答だった。他にこういう質問をする人がいなかった。続いて、コンテンツモデレーションを個人が担当することにどう思うか?誰でもサーバーを起動でき、好きなルールを決められる。Mastodonが社会的にデフォルトになるところまできて、デフォルトサーバーのコンテンツモデレーションルールの変更に負担を感じるか?

A. 現状ルールに問題を確認できていない。ユーザーは満足して、モデレーションの負荷は耐えられている。mastodon.socialのサーバーに、多数の有料モデレーターがおり、モデレーションチームは拡大している。ルール自体はそのままでいい。安全側にあるが、制限が厳しすぎるわけではない。7年の運用経験から得られたいいバランス。

Q. 規模が大きくなると制御不能になる。SNSのモデレーターの苦労話を過去に取り上げてきた。直面していないのか?自動化ツールなどあるのか?

A. 今のところサイズが小さいため、Facebookのモデレーターが必要な恐ろしい事態はない。ほとんどは単なるスパムか意地悪くらい。

自動化の前に、まず個人的なアプローチを信じているので、自動化は避けてきた。個人的なアプローチが可能なのは分散化とサイズのおかげ。分散SNSはある意味で開放的。「自分たちのルールに納得できないなら、他の場所に行くか、自分で実行できる」と言うことができる。

また、モデレーションの観点からいうと、モデレーションの負荷を分散しているともいえる。サーバー実行者をモデレーターとして数えると、9000から1万人はいる。加えて、単独サーバーなら問題ないい、20人のユーザーと1人のモデレーターだと、比率は他のSNSよりも圧倒的に高い。基本的に自分のサーバーのユーザーにだけ対処すればいいから。

Q. ただ、Mastodonで投稿すると、フォロワーや連合している何百万人もの人々に届く可能性がある。サーバーごとにルールが違うから何が起こるかわからないという不満があると思う。

A. コンテンツモデレーションは、SNSで最も難しい問題の一つだと思う。

何か問題ある投稿をすると、見ない可能性がある。例えば、ブロックやミュートワードなど。ドメインブロックは多数からのブロックと思ったらいい。

全てが完璧というわけではない。自分のサーバーのモデレーションで何が起こっているかは、登録ユーザーに透明性を持たせる必要はあると思う。管理者が他のサーバーをブロックして、それを知らずに突然大量のフォロワーを失うことは、素晴らしいことだとは思わない。何らかの通知システムは必要に思う。通知があれば、ユーザーは別のサーバーに移ったりできるので、誰も損をしない。

Q. モデレーションはSNSで最も複雑な部分。興味があるのは、サーバーのコストなどを超えて、モデレーションがコストになる点。コミュニティーの規模が大きくなると、モデレーションや法令遵守は世界最大企業以外には耐えられないコストになる。例えば、Financial TimesはMastodonサーバーを開始して数日以内に停止した。他に、ハリーポッターのコミュニティーも停止した。サーバーを始めて人気が出ると、突然管理者としてのコストが急上昇する。これを抑える方法があるのか?それとも、収益化してコスト捻出が必要ということでしょうか?

A. Financial Timesは、組織サーバーではなく、公開サーバーにしたのが失敗だったと思う。モデレーション負荷や、必要な技術も含めて全く異なる。公開サーバーで、何千ものユーザー獲得を全員に進めるつもりはない。大きな責任があるから。コストと負債を伴う責任だ。簡単ではない。

SNSをゼロから始めるのは難しい。Twitterのようなものをゼロから始めることを考えてほしい。Mastodonは同じことができる。一般向けの独自のTwitterを始められるが、公共サービスを運営するには、コスト、問題、リスクが伴う。

一般公開サーバーの場合、モデレーションコストがかかる。ただ、コストはネットワーク全体で共有されるので、単一企業が数多くのユーザーに対して行うよりかははるかに低いコスト。5000人くらいのコミュニティーで、解約がない場合、素行の悪いユーザーは停止されているので、サーバー上の人は行儀のよい人ばかり。

Q. データはあるのか?Redditを見ればわかるが、小さなコミュニティーが分裂してライバルのサブRedditになった歴史であり、これは無限に続くでしょう。

A. mastodon.socialの運営経験と、モデレーションに基づく。ほとんどの通報は登録したてのユーザーについてです。実際には、ルールに同意せずに登録して、すぐにルールを破る人々です。登録停止中は、モデレーションチームの負荷が大幅に軽減されました。ルールを破る人はすぐに姿を現し、禁止されればルール違反はいなくなります。

ユーザー数とサーバーサイズに伴う通報の量とモデレーション量を過大評価しているように感じます。ほとんど人は定期的に規則を破りません。少数の人々の、少数のケースです。ユーザーが大量に入ってきたときに増加します。それ以外は非常に扱いやすいものです。

今後

Q. mastodon.socialに登録したところ2個不満がある。1点目は遅い。

A. いつアクセスしたによる。DDoS攻撃の可能性もある。mastodon.socialのインフラは2016年に元々あった箱から発展してきた。7年の間に何回も引っ越しした。最初はDigitalOceanだったと思う。その後、Scalewayを使ったり。最終的に、ドイツのホスティング業者のHetznerに移行して今に至る。1台のPCから手動で管理する15-20台のマシンクラスターに成長した。

現在はKubernetesを使用している。これにより多くのスケーリングが大幅に簡素化される。以前は新しいマシンのセットアップに半日かかっていたが、今は数クリックと数ボタンですんでいる。以前よりもはるかに多くのトラフィックに対応できている。

Q. 以前よりもTwitterのように見えるようになったというプレッシャーを感じているか?具体的には引用投稿はできるか?反対しているのはわかっているが、考え直していないのか?

A. 引用投稿については長い話になる。Webサイトに公開ロードマップがあり、引用投稿は下の方の探索セクションにある。これは調査中を意味する。エピソードを用意できれば引用記事をお知らせする。

Q. Mastodonの次は?何に目を光らせるべきか?

A. グループ。Facebookにはグループ、Twitterにはコミュニティー、Mastodonにもグループがある。

結論

Mastodonの現在の状態でした。特に、現在の体制、採用、収益、運営などこれまでの取材よりもやや深堀された内容でした。その分量も多く、内容を確認するのに疲れました…

Mastodonのフルタイム正社員の求人募集 | GNU social JP」であった採用募集で最初にDevOpsをあげていた理由があって興味深かったです。

その他、一般公開サーバーのたいへんさと、モデレーションの複雑さの話が興味深かったです。団体サーバーで、招待制にするのが無難な運営方法のようです。

後は、機能面として、参加型ガバナンス、有料化機能、グループ機能を考えているようで、今後の実装・リリースに注目したいです。

コメント

  1. かき says:

    小規模サーバーなら管理者の自己負担で気軽に始められるのがMastodonのいいところですよね。また、mastodon.socilalのような大規模サーバーでも、今のところモデレーション面でもFacebookのように阿鼻叫喚が起こるような(実際心身にダメージを受けてFB社を訴えているモデレーターがいるとか聞いたことがある)事態には至っていない様子。
    Eugen氏がTwitterのヘビーユーザーだったというのは、ここで初めて確認できました。多分そうだったんだろうな、だから不満があってMastodonを作ったんだろうな、とは思っていましたが。とある人に「Mastodonには投稿の自動削除機能が付いている」と言ったら、「それ、開発者が過去に何かやらかしたからじゃね?」と返されたことがあったなぁ。

    • ぐぬ管 (GNU social JP管理人) says:

      以前の取材でEugen RochkoはあまりTwitter使っていなかったような記載もあった気がしました。が、それは2016年の辞める直前で、実際は2008年のリリース直後あたりから使っていたヘビーユーザーだったというのが、この取材で私もわかってよかったです。

  2. This Article was mentioned on web.gnusocial.jp

  3. This Article was mentioned on web.gnusocial.jp

Copied title and URL