ダニエル・カズリーノ
元記事 https://www.cazzulino.com/sponsorlink-feedback.html
Translated By: DeepL Pro
SponsorLinkの紹介記事で述べたように、オープンソースの持続可能性は厄介なトピックだ。私は20年以上オープンソースをやっているので、この分野に対して全くの初心者というわけではない。私はとにかく「専門家」を信じていないので、個人的な経験や、過去に読んだり見たりした他の開発者仲間の行動などから判断しています。だから、もし十分明確でなかったら、私は自分以外の誰の代弁者でもない。私は "dotnet OSSコミュニティ "を代表しているわけでも、"OSSはどうあるべきか/どうあるべきか "や、ここでの "正しさ "や "間違い "を語っているわけでもありません。
私が得たフィードバックは、以下の部分が圧倒的に多かった：
多くの人は、私が意図的に、そして明らかに悪い理由のために、完全に悪質で邪悪なことをしているのだから、重大な信頼違反があると断固として主張した。
「明らかに極悪非道」な部分とは、6ヶ月前に私が、GitHubのスポンサーシップをバックエンド（静的なAzureのブロブストレージ）に簡単にマッピングするために、レポであなたのgitメールの一方向SHA256ハッシュを使おうとしていると説明したことだ。実際のプレーンテキストの電子メールは、電子メールアドレスを取得するために明示的な同意を必要とする GitHub アプリを明示的にインストールするまで、まったく共有されませんでした。
「もう二度と信用しない」「評判を台無しにした」「みんなのdotnet OSSを台無しにした」という意見はさておき、SHA256ハッシュがメールアドレスのプライバシーを保護するには不十分だったという主な問題提起は、妥当なものだと思います。だから、これは絶対に修正するつもりだ。特に、SHA-1とk-anonimityを使うという非常に興味深い提案と、組織全体のスポンサーシップもサポートする純粋なオフラインチェックを模索しているところだ。
注： 私がどのように私の評判を台無しにしたかを主張する人々への余談として。 私は講演やビデオ、ポッドキャスト、インタビュー、ワークショップ、トレーニング、コンサルティングなど、Moqを宣伝したことは一度もない。2009年に3.0を出荷した時や、超クールな（少なくとも私にとっては）Linq to Mocks機能を思いついた時など、昔はかろうじてブログの記事をいくつか書いただけだった。カンファレンスやMVPサミットなどでの友人や同僚とのカジュアルな会話でも、ほとんど話題にすることはなかった。
だから、私がMoqを皆に押し付けていると考えている人たちには、がっかりさせて申し訳ない。大好きな同僚でさえ、私がMoqの作者であることを知らなかったのだから：
待ってよ、どうしてあなたがMoqを書いたって知らなかったんだろう？あなただったの？素晴らしい仕事だ！使わせてもらってます！
- キリール・オセンコフ 🇺🇦 (@KirillOsenkov) 2017年7月10日
多くの人は、私がブログで書いたり、ツイッターでつぶやいたり、他の小さなプロジェクトにゆっくりとこの機能を展開していっただけでは不十分だと感じたようだ。もっと明らかに目に見える形で、プロジェクトのレポ自体で議論し、コミュニティからのフィードバックのための十分な時間を確保すべきだった、などと。たとえ、私がその機能を追加するPRをレポに送ったのが、その機能についてのユーザーからの最初のコメントと、それに続く形の、その機能を削除するPRが寄せられる4日前だったとしても。
まったく同意できないまでも、その気持ちは理解できる。なんていうか、私がせっかちなのかもしれないね。
以下のどれかだった：
- OSSは感謝されない仕事だ。それに耐えるか、やらないかだ。
- 単にあなたが商用ライセンスに切り替えるべきだ。
- 開発者が自分のポケットマネーから支払うというあなたの意図は馬鹿げているし、誰もそんなやり方はしない。それは絶対にうまくいきません。
私が深く尊敬する多くの人々からの洞察に満ちたツイートを読み、OSSの個人的な経験や、それをどのように維持できたか（あるいは維持できなかったか）を分かち合った。私はすべてのフィードバックに深く感謝しており、ひとつひとつに言及するつもりはないが、上記のことについて私の考えをまとめてみようと思う。
上記3点のどれかが妥当であり、全体が私の時間の無駄かもしれない。しかし、今回はユニークな点もいくつかあると思う：
- GitHub Sponsorsはまだ黎明期にあり、多くの企業はその存在すら知らないとコメントしている。GitHub Sponsors のモデルは他のアプローチとは大きく異なり、まず個人の開発者が他の個人の開発者をスポンサーすることを奨励しています。昨年4月、GitHubは組織によるスポンサーシップの一般提供を発表しました。私がSponsorLinkに取り組み始めた1月には、このようなことはまだありませんでした。
- ドットネットのOSSエコシステムは、私が15年以上前に最初のコミットを行ったときよりもはるかに成熟しており、プロジェクト数もユーザー数も増えている。
- コンテンツ・クリエイターであることは、多くの人々が実際に生計を立てていることであり、YouTubeをはるかに超えて、この可能性を提供するプラットフォームが増えている（つまり、Xも今！）。
多くの人は私のこの意見に賛成してくれないだろうが、私はOSSの制作もコンテンツ制作の一形態だと考えている。散発的にブログを書いたり、ツイッターでつぶやいたりしていますが、本当にやっていて楽しいのは、自分の生活を便利にする便利なツールやライブラリを作ること、あるいは単に興味深いアイデアを探求することです。そして、それらをOSSとして作るのが好きです。というのも、私がC#/.NETの旅を始めたとき、log4netは私が学ぶことのできる重要なコードベースを持つ、ほとんど唯一のOSSプロジェクトだったからです。たとえ小さなことであっても、学んだことを共有することで、恩返しをしたいと思っています。
ほとんどの人は、私が20年以上OSSをやっている中でMoqしかやったことがないと思っているだろうけど、私にはOSSのパッケージの長いリストがあるんだ。そう、今日現在で317個全部だ😅。勿論、どれもMoqほど広く知られ、使われているものではないが、それはおそらく、よりニッチなシナリオに対処しているからで、たとえそれが、いくつかのテクニックやパターンを学ぶためであったとしても、人々にとって役に立つかもしれない。例えば、ソース・ジェネレーターを作るとき、私は自分のThisAssemblyをよく見返す。
このように、OSSをコンテンツ制作の一形態と考え、従来のソフトウェアの商業化とは異なる方法でマネタイズすることを考えるのは、不合理なことではないと思う。正直なところ、ひとつのプロジェクトで会社を設立することに、それほど興奮はしていない。私のパッケージや個人的なリポジトリ、組織のリポジトリを見ればわかるように、私の興味は多様で、さまざまなことを探求するのが好きなのだ。
とはいえ、ブログの投稿やツイート、YouTubeの動画と違って、大したことのないライブラリをゼロから作ったことのある人なら誰でも、かなりの時間を投資するものだとわかるだろう。それが価値が高いとか低いとか言っているわけではないが、週末に2、3時間でできるようなものではないのだ（サンプルや小さな概念実証、実用性の証明でない限り）。
Moqをゼロから書き直すという私の試みを例にとってみよう。私がそれに取り組み始めたのは2017年のことである（当時、私が好んで命名したアニバーサリー・エディションのために：
moq アニバーサリー(10周年)エディションでランタイムプロキシを廃止。つまり、.NET標準2.0がサポートされているところならどこでもモックできるようになる！
- Daniel Cazzulino 🇦🇷 (@kzu) 2017年7月10日
その後、レポの名前をmoq/labsに変更し、2023年6月30日にアーカイブした。
私は、私が何年にもわたって.NETツールやIDEの拡張性、コード生成など、さまざまなクールなことに取り組んで蓄積してきたすべての学びを活用した、新鮮なMoqをコミュニティに提供したかったのです。拡張性と機能のコンポーザビリティにより明確に焦点を当て、探求すべき新しいアプローチがたくさんありました。そうすれば、人々はあれやこれやの機能を追加するためだけにPRを送る必要はありませんでした(Moq自体が拡張性を念頭に置いていなかったので）。何年もの間、私がいかに激しい作業のスパイクを繰り返しながら、何度も試行錯誤を繰り返してきたかがわかるだろう：
2020年末の大きなスパイクは、私が他の興味を追求するためにマイクロソフトを辞めたときで、私はそれに数ヶ月を捧げることができた。私は本当に興奮し、新しいMoqの中核となるStunts/Avatar(s)に集中的に取り組みました。Castle Coreのようにランタイム・エミットの代わりにコンパイル時のソースコード生成を活用した、まったく新しいプロキシ生成エンジンです。
Ohloのような作業ツール（昔、工数を計算するために使っていた）はもう見つからないが、私は何カ月もかけて、ほとんどフルタイムでそれに取り組んだ。それでも十分ではなかった。完全にあきらめたくなかったので、2021年1月までにGitHub Sponsorsのアカウントを立ち上げ、十分なスポンサーを集めることができれば、もっと時間を割くことができると考えた。あまり宣伝はしなかったが、何人かのスポンサーを獲得し、数ヶ月後にはクリスチャン・フィンドレーが僕にとって初めてのスポンサーになってくれた。
人々がモックのことで腹を立てる前に...。いくつかのことを考慮しよう。
まず第一に、あなたはライブラリの利用料を払っていないでしょう。雇用主に寄付を頼んでいるのか？
第二に、データの引き渡しは無料になるための代償だ...。
- クリスチャン・フィンドレー (@CFDevelop) 2023年8月9日
注： クリスチャン、本当にありがとう。
Moqのレポにスポンサーバッジを追加したのは、ほぼ1年半前のことだ。友人のキリルが他の何人かと一緒にスポンサーを始めた頃です。しかし、多くの人が指摘しているように、dotnet OSS コミュニティ（あるいは他のコミュニティ？）では、GitHub Sponsor の利用率はそれほど高くありません。
月日が流れ、より多くの時間を割くことができなくなるにつれ、私はMoqをより持続可能なものにする方法を考え始めた。私は他の多くのOSSプロジェクトを作成し、出荷し続けましたが、時々Moqのことを考え続けていました。今年の初め、2月に私はSponsorLinkの初期リリースを出荷しました。私はそれを自分の小規模で新しいプロジェクトにゆっくりと統合し始めたが、数ヶ月に渡って誰からのフィードバックも全くなかった。
6月末までに、メインのMoqレポのCIがいくつか壊れていることに気づいた。そして、moq/moq > moq/labsにリネームしてアーカイブし、moq/moq4 > moq/moqにリネームすることにした。プロキシ・フレームワークdevlooped/avatarもアーカイブした。
注： このプロジェクトは完全に無視されていたわけではない！しかし、スポンサーやフィードバックに関しても、大きな牽引力にはならなかった。
そして今月初め、壊れたところを直すのに時間をかけることにした。そして考えました。最後のチャンスを与えてみようと。細かい問題をすべて修正し、SponsorLinkを追加して、どうなるか見てみよう。まあ、期待通りにはいかなかったとだけ言っておこう。
もちろん、レポ自体でこのことを長々と伝えることもできたが、正直なところ、PRは最初のコメントよりも4日早く送られていた。プロジェクトの主要な貢献者（素晴らしいドミニク）でさえ、かなり長い間（彼の最後のマージPRは1月にさかのぼる）みんなへの反応が遅かった。
私の知る限り、このプロジェクトはほとんどゾンビ状態で、私はこのプロジェクトを完全にあきらめかけていた。
そして今、すべてが爆発した後、人々はまるでこのプロジェクトに命がかかっているかのように振る舞っている。まるで、私がこのプロジェクトに残された最後の熱意を救い出そうとしている間に、誰もこのプロジェクトを中断して次に進むことができなかったかのように。
さて、私がSponsorLinkのごく初期に発表したV1を見て、皆さんが興奮しなかったことは理解しています。確かに、多くの荒削りな部分や修正・改善すべき点があります。私は、まだあきらめるつもりはありませんし、現状でいい、このままでいいと考える人たちとは絶対に意見が違います。
これは単なる事実の表明であり、あなたが望むように受け取ってください。ただ、これはこの分かれ道で私が感じた正直な気持ちです。： SponsorLinkが人々にとって受け入れやすく機能し、（私自身だけでなく、OSSの仕事でスポンサーを得たいと願う他の人々にとっても）大きな支持を得るか、あるいは私がOSSを完全にあきらめるかのどちらかだ。
私は、OSSスポンサーシップを完全にあきらめるのではなく、ドットネットのOSSコミュニティでOSSスポンサーシップが当たり前のことになるよう、私たちの多大な頭脳力を結集することを強く望みます。
SponsorLink は、いつか自分も OSS 開発者になるかもしれない開発者仲間に、自分たちが使い、楽しんでいるプロジェクトのスポンサーになることを奨励すべきだというのが、私の当初の意図です。個人的な感謝の気持ちとして、また、単に問題を報告したり、うまくいかなかったときに文句を言ったりする以上の、個人的なつながりのレベルを達成するために。
ほとんどのOSS開発者が同意していると思うのは、この仕事をすることは感謝されない仕事のように思えるだけでなく、時には実際に敵対的な仕事のように思えるということだ。要求が多すぎるし、時には丁重に尋ねられることさえなく、実際にそれを使って満足している人たちから話を聞くこともない。これはOSSソフトウェアに限ったことではない。私がXamarinとマイクロソフト（Visual Studio）の両方に在籍していた時も、同じように感じがちだった。
もっと個人的な関係があれば（たとえ1ドルスポンサーを通じてであっても）、積極的にポケットに手を差し伸べたので、プロジェクトの背後にいる個人（複数）のことを心に留めておくでしょう。だから、問題を報告するときにも、その人のことを思い出しやすくなるし、より親切になれると思う。
OSS開発者としては、スポンサー・ラベルが付けられた問題報告を目にすることで、同様に、スポンサーがあなた個人を気にかけてくれていることを思い出し、より熱心に協力するようになるだろう。
とはいえ、特に大きな組織では、誰もが使うライブラリを選べるわけではないことも理解しています。ですから、GitHub Sponsorsによる組織全体のスポンサーシップへのサポートが高まっている今、それもサポートされるべきだと思います。
この方法は、指定された組織に所属している開発者 (つまり、org-validated ドメインと一致するメールアドレスを持つ開発者) もスポンサーとみなすというものです。
300ものOSSパッケージがSponsorLinkを使用したら、エディタに診断メッセージが表示される悪夢になるだろうし、1つ1つ1ドルでも個人的にスポンサーしなければならないとしたら、経済的に大失敗だと多くの人が指摘している。
基本的にSponsorLinkのv3+を計画するのは少し早いと思うとしても、これは正しい指摘だ。これを解決する一つの方法は、（例えば）Sponsorware組織をスポンサーし、Spotifyのような料金を徴収し、それを利用状況に応じて分配することである。
次のような経験ができるとしたらどうだろう：
- 使用しているライブラリに問題が見つかりました。
- issueをオープンし、あなたが修正したいissueに言及し、あなたがスポンサーになるXドル分の1回限りの寄付でレポをスポンサーする。(そう、あなたのissueを読んで対応するにも時間がかかるので、お金がかかるのです)
- SponsorLinkはこれをすべて自動的に検出し、issueに"$Xで提供中 "という自動タグを付けます。
- より多くの人が、最初の人と同じように、1回限りのスポンサーシップを通じて、より多くのお金でその問題に投票することができる。
- ある時点で、誰かがその課題を割り当てられ、修正に取り組む。修正されたPRがマージされると、蓄積されたお金は自動的にその貢献者に1回限りのスポンサーとして支払われる。
そして今、人々は彼らの仕事に対して報酬を得ることができ、あなたは彼らのスポンサーになることで、より早く問題を解決することができるエコシステムがある。
だから、現状でいいなんて言わないでくれ。そんなことはない。このプロジェクトに新しく参加し、何かを学ぼうとしているが、同時に何かを稼ごうとしている新参者が、自分の仕事に対して報酬を得る方法がないのは問題だ。
願わくば、私たち全員が協力して、このこと（あるいはそのいくつかのバージョン）を現実のものにしたい。