週末の趣味OSSが突然バズった！ 数千人に使われて分かった「理想と現実」のギャップ

Redditに「保存」機能があるって知ってる？

知ってるし使ってるよ。でも、自分の「保存済み」コメントや投稿リストが、「とりあえず保存して放置」っていうブラックホールになってることは認めざるを得ない。

絶対読んでみるよ、勧めてくれてありがとう。

プロの独立系フルタイムメンテナという新しいモデルをテスト中。企業から業務委託として契約し、継続的なメンテナンスや専門知識の提供、プロジェクトの意思決定への参加を行うというもの。

理想的だけど、以前に成功例ってあるの？

SQLiteのメンテナがそんな感じのことやってなかったっけ？

やってるよ、そうだよ

cURLの仕組みって、だいたいそんな感じじゃない？

もう数年も運用してるし、クリティカルなプロジェクトでも確実に使えるよ。

https://words.filippo.io/geomys/

https://fallthrough.transistor.fm/episodes/building-an-open-source-maintenance-company

コンサルティングとは違って、僕らの時間の大部分（正確には測ってないけど9割以上は）はオープンソースのメンテナンス作業に費やされていて、クライアントワークはほとんどないんだ。

/u/FiloSottile リンクありがとう。https://words.filippo.io/geomys/ を更新した方がいいかも。不思議なことに、そのページ内のどこにも https://geomys.org/ へのリンクがないんだ。

修正したよ、サンクス！

https://www.pointfree.co

ここの連中はSwiftコミュニティでかなり上手くやってるよ。

しっかりとメンテナンスされたオープンソースソフトウェアを提供しつつ、月額サブスクリプションで教育ビデオを公開してるんだ。そこでは意思決定プロセスや実装の詳細、コツやテクニック、学んだことなどを自分たちがメンテナンスしてるツールを題材に解説してる。

たしかコンサルもやってるはずだけど、資金源は主に教育コンテンツだね。彼らの教育コンテンツは本当に最高で、大学の授業の大半よりもずっとためになる。ただ、すべてのプロジェクトがビルドと同じくらい教育に時間を割けるわけじゃないよね。個人的には、こういうモデルがプロジェクトを取り巻くインセンティブをより良い方向へ変えてくれると思う。

GStreamer、Webkit、LLVM、PulseAudioとか、その手のプロジェクトが健全に存続できてるのって基本これのおかげだよ。特定のプロジェクトに特化したオープンソースのコンサル会社についてググってみればわかるよ。

これで食いつないでるんだよ。

もっともらしいけど、正直それってただのコンサルティングじゃない？多くのソフトウェア企業はオープンソースのプロダクトやコンポーネントを開発して、そのサポートやコンサルで稼いでるし、個人の開発者でもやってる人はいる。それはそれで全然いいけど、新しいアプローチってほどじゃない気がする。

すべてのソリューションが斬新である必要なんてないよ。

コピーして、ペーストして、編集すればいい。

Windowsレジストリを変更するためのコマンドに依存する追加設定が必要だからだよ。

それは悲しいな、兄弟

同じだ。誰も手伝おうとはしてくれない。実際、みんなが求めていたのは、僕が自分のツールを使って彼らをサポートすることだけだった。

同じ理由でいくつかアーカイブしたり削除したりしたわ。codeplexみたいに死んだホスティング先もあるしね。今は自分のために作るだけで、あとは知ったこっちゃない。

ああ、それ俺も経験あるわ。対処法のコツとしては、スパム扱いすることだね。メールならゴミ箱へ、issueならクローズか削除でOK。相手に義理なんてないんだから。

最近、自分の小さなリポジトリにこんなissue が送られてきたよ。

見つけた指摘は明らかにタイポで、しかも（3年前にコミットしたコードの中の）とんでもなく些細なもの。正しい変数だった場合との違いは、マウスホバー時のボタン枠の白さが40%か70%か、というレベル。視覚的にそんな細かい違いに気づくなんてほぼ不可能だから、暇つぶしにコードを読んでいたんだろうと推測するしかないね。

スクリーンショットを撮って、issueを作成して、「wtf bro（おいおい何だよこれ）」って入力する時間があれば、自分で修正して終わりにする方が絶対に早かったはずだよ。

あんまり図々しいから、まだ何も対応していないんだ。本来ならissueを閉じるか削除するなりすべきなんだろうけど、もはや珍品として放置してる。一部の人間の傲慢さを象徴するモニュメントみたいなものだね。

ios_palette_off.FrameHover = light_mode ? light_mode_frame_off_hover : light_mode_frame_off_hover;

おいおい、何やってんだよ。

AIが生成したコードの厄介な点（基本的には避けるべきだし、使うとしてもかなりの注意が必要）は、深夜4時に書いたコードと見分けがつかないことが多いってことかな（深夜のコードも避けるべきだけど、あっちの方がまだ理解できるよ）

面白いのが、チーム丸ごとでコメントをスパムしたり、チームメイトが上げたリクエストに＋1（賛同）しまくってくるやつらだね。

こんなことが誰かに起きるなんて、まさにスーパーヴィランの生い立ちそのものだね。ひどすぎる。

「全ての機能追加が重要なら、結局どれも重要じゃない」ってやつだな！

クソみたいな連中

露骨に失礼な奴ら

そういうタイプの人種は、そこだけにいるわけじゃないよ。バグやIssueの報告欄にも湧いてくるしね。

バグに遭遇しただけでユーザーを侮辱するような連中さ。
(そもそも自分たちが使っているソフトウェアについて大した知識もないくせに)

(ネットにはトロールがいるからね。大規模なオープンソースプロジェクトだと、わざと煽るような有料のスタッフが紛れていることもあるし)

「Bad（禁止）」できないのが残念だね。

彼らが欲しい機能を実装しなかったからといって、

付け加えると、これはあなたのプロジェクトだよ。あなたのビジョンに従うものだ。「これは自分が目指しているスコープ外だ」といったあらゆる理由で機能を断ることは、全くもって正当だよ。

もしどうしても必要な機能があったら、自分なら自分で書くけどな。それができないなら、少なくとも文句は言わないわ。

「not」が抜けてるってことかな？

いや、彼らはただの嫌味な奴らだけど、言ってることは正しいよ。

おっと、指摘サンキュー

そもそもオープンソースってそういうものだろ。作者が何らかの理由で実装しないなら自分で実装できるし、バグを見つけたら自分で直して、パッチ（最近ならプルリクエスト）を送ってアップストリームに還元することもできる。オープンソースは、企業が中身の薄い製品から不当な方法で利益を搾り取って、賢くて意欲的な人々の活動を妨げるのを防ぐためにあるんだ。誰でも無料でビールが飲めて、そのうえ文句まで言える場所じゃないんだよ。

僕も同じような経験を何度かしたよ。そのせいでオープンソースをメンテナンスする意欲がすっかり削がれてしまった。

少数の質の悪いユーザーどころか、25%くらいがそんな感じだったよ。

あと、何の補足情報もなしにバグ報告をしてきて、魔法のように修正されるのを期待する人たちの多さには本当に呆れる。

趣味のプロジェクトで、そこそこまともなオープンソースを2ヶ月かけて作ったんだ。当時は似たような製品が200ドルくらいで売られてて、無料版もあったけどオープンソースじゃないからカスタマイズ性が低くてさ。

結局どうなったかと言うと、身勝手な要求を突きつけてくる奴がいたり、スコープ外だって言ってるのに実装しないと罵倒されたりした。ツールが役に立たないとか言って他のユーザー同士で言い争いまで始まって（同じ機能の製品が他にいくつも売られてるっていうのにだよ）。

最終的に、こんな仕打ちを受けるためにやってるんじゃないと思ってリポジトリを非公開にしたよ。

正直、今の時代オープンソースって本当に好きじゃないとやってられない。多くの開発者が膨大な時間を注ぎ込んでるのに、ユーザーは当然の権利みたいに振る舞うくせに支援は一切なし。生活もできないのに、どうやって無限に開発を続けろって言うんだよ？

また公開しようかとも考えてる。次はウイルス的なライセンスにして（MITなんてクソくらえ）、サポート一切なしでリリースするつもり。アップデートが欲しければ、自分でフォークして勝手にやってくれって感じだね。

なんで誰もPRを送ってこないんだろ？自分は関わってないプロジェクトにも結構貢献してるけどな。まあ、言っても無駄なのはわかってるけどさ :S

自分のプロジェクトはライブラリとかじゃなくてバイナリ配布だったのが問題だったんだ。GitHubからダウンロードさせることはできたし、議論もGitHub外でやり取りしたりはしてたけど、ユーザーの大半はプログラミングなんて全く知らない人たちだからね。知識がないからって権利だけは主張してくるんだからタチが悪い。

コーディングに詳しい人だって文句を言いにくるよ。みんな自分勝手な権利意識を持ってるだけさ。

機能を要求する人数と、実際に機能を実現するプルリクやパッチを送ってくる人数（LLMが生成したゴミではなく、ちゃんとテストされたもの）の比率は、だいたい1000対1くらいだね。

スコープ外でメンテナンスする気もないものに対して、相手がプルリクエストを受け入れてくれると考える理由って何？

英語は僕の第3言語なんだけど、僕のコメントからどうしてあなたが考えたような「メンテナーに対する意見」が導き出されるのか、全く理解できないよ。

スコープ外だと考えていたものを実装したくなかったから

あなたが返信していたコメントから引用したよ

バイラルライセンスを付けて（MITなんてクソ食らえ）、サポートは一切なしで公開しちゃうのがいいかも。アップデートが欲しい奴は自分でフォークして勝手にやればいい。

結局自分もその境地に達したわ。GPLv3がプロジェクトと合わないなら、金払えよって話。こっちは趣味か必要だからやってるだけで、こっちに負担がかからない範囲でタダで使わせてやってるんだから。

AGPLなら、そういった問題の多くを解決してくれるよ :-)

あなたにどうすべきかを指図するような人たちと同じことはしたくないけど、そのアプローチだと「赤子と一緒に風呂の水を捨てる」ことになりかねないよ。

プロジェクトをアーカイブ状態にするだけでも、胃を痛めるような問題からは解放されるはず。それに、迷惑な連中じゃない人たちは引き続きあなたの成果物を使えるし、あわよくば寄付してもらえる可能性だって残る（まあ、そんな人は滅多にいないけど）。それに、荒らしの連中にたわごとを書き込む場所を与えないという効果もあるし、彼らをイラつかせることもできる。

結局彼らは歪んだ考えで、あなたのプロジェクトが存在することで自分の時間が奪われるとか、自分たちの言いなりにならないとかで勝手に腹を立てているだけだ。これに能動的に対処するなら、NLPツールを使ってそういったスパムを検知し、自分のハンドルネームで煽り返すという手もあるかもね。

少しネットで探してみたけど、これといったものは見つからなかったし、自分自身で実装するほどの知識もないんだよね。

さっさとBANしちゃえよ。騒ぎ立てる奴らに情けなんて無用だろ。

確かに、BANするのは完全に正当で適切な対応だよ。でもネット上だとIDなんていくらでも作れるし、もっとタチの悪い奴らが別のアカウントで戻ってくるのを防ぐことはできない。NLP（自然言語処理）のアイデアのいいところは、トロールを退屈させて放置できることだと思う。彼らの毒々しいコメントは虚空に消えるだけで、開発者は実際の問題に集中できるからね。

確かGitHubって、1つのIPアドレスから作れるアカウント数に制限があるんじゃなかったかな（クールダウン期間があるのかも？）。以前はそうだったはずだよ。

でもネット上では、IDなんて大抵無料だしね

レピュテーションシステム（評判システム）が解決の助けになることもあるけど、それ自体にも課題はあるから万能じゃないんだよね。

そういう系のイシューは、自分ならさっさと「予定なし」でクローズして、再現手順を付けて再送するように伝えるだけだな。

自分ならリポジトリをバックアップして速攻削除するわ。そんなクソみたいな状況、閉鎖する以外に健全な対処法なんてないもん。

何ヶ月も前にチケット送ったよ。Narutoテーマが明らかに最高だって言っただろ、頼むよ

そうそう。自分のリポジトリを誰かにフォークされるのって本当に気が重いんだよね。どうせ頼んでもないプルリクが送られてきて、それをチェックして指摘して、最悪拒否しなきゃいけないって分かってるから。いいコードならレビューしてマージするだけでもかなりの手間だし、全然知らない人に「その努力はプロジェクトに合わない」とか「そもそも不要」って説明するのはもっとしんどい。相手は善意でやってるつもりだろうけど、こっちからすればただの山のような作業なんだよ。

いや、基本は自動却下ポリシーで行くのが一番。フォークしたいなら勝手にどうぞ。PRを受け取ってほしいなら、まずは著作権譲渡フォームへの記入が必須。嫌なら自分のフォークを一生メンテナンスしてればいい。簡単だろ。

人のクソみたいな態度に付き合ってるほど人生暇じゃないからね。

俺のレポジトリをフォークしたいなら勝手にどうぞ。PRをマージしてほしいって？まずは著作権譲渡フォームへのサインからだ。

ちょっと待って、今すぐ設定してくるわ。

これの何が一番興味深いって、巨大企業がどこの誰とも知れない個人のサイドプロジェクトにあれこれ要求してくることだよね。

でも、そこが稼ぎ時だよ。自分のプロジェクトに依存してる企業向けにカスタムの改修をしてあげるんだ。

そうだな…自分なら「喜んで。時給についての相談、もしくはサポート契約の購入を検討されますか？」って返すかな。

こういう時の返事は「金払え、ボケ」で決まりだよ。

もっと丁寧に「時給は900ドルです」って言うのもアリだな。

「PRを送れ（submit a PR）」

俺に何かを要求する権利があると思い込んでる人たち

リクエスター様へ

機能Xを自分で追加して、レビュー用にプルリクエストを送ってください。もしご自身で実装するのが難しい場合は、こちらで機能Xを追加する契約を結ぶことも可能ですので、お気軽にご相談ください。

よろしくお願いします！

「時給800ドルだけどね」

もし情熱を注いでいるプロジェクトの枠を超えて働いてほしいなんて言うなら、それ相応の対価を払う覚悟が必要だ。

FFmpegとGoogleの件はまさに今話題だね。このMark Atwoodの引用もぴったりだ。

オープンソース政策専門家のMark AtwoodがTwitterで指摘したように、彼はAmazonに対してFFmpegを破壊するような真似はやめるよう言い続けなければならなかった。彼は上司に説明し続けなければならなかったんだ。「彼らはベンダーじゃないし、NDAもないし、こちらには交渉材料もない。副社長は資金提供を拒否している。それに、彼らは明日メール一本で主要な3つの製品ラインを殺すことができる。だから、止めてくれ、俺の言うことを聞いてくれ……」

FOSSが「攻撃的」だと言われる理由はよくわかる。自分のやりたいことのために始めたプロジェクトなのに、大勢の人間や企業から要求が殺到すれば、誰だってそうなるよ。

返答のデフォルトは、このどちらかにしておくのが良さそうだよ：

「いいですよ、修正パッチを受け取ります。もし自分で書く時間がなければ、コンサルティング料金について相談に乗りますよ」

もしくは：

「いいえ、残念ながらそれは範囲外です。どうしても必要なら、フォークすることをおすすめします」

もっと知りたいけど、匿名でいたいという希望は尊重するよ。とはいえ、そんな目に遭うなんて本当に災難だね。

もっと知りたいけど、詳細を話すと匿名性が損なわれると考えているなら理解する、と言った彼に同意。+1するよ。

雇用主がちゃんと対応してくれたことを切に願うよ。

マジでヤバいなそれ

昔、Facebookで友達申請してきて、プロジェクトをPython 3にアップデートしろって強要してきた奴がいたわ。

Google Chatのsemantic versioningプラグインが壊れたとき、GitHubのプロフィールに書いてあった個人のメアドにメールしたことあるよ。古いカードが非推奨になって表示されなくなったのを直すPRを作ったからなんだけど。

それが適切なのか何週間も悩んで、結局送ったんだけど、その間ずっとめちゃくちゃ罪悪感でいっぱいだった。相手からは「ありがとう、他のプロジェクトからのスパムが酷くてGitHubの通知は全部無視してたんだ」って返信があって、1時間後にマージしてくれた。

今でも申し訳ない気持ちでいっぱいだ。誰かの職場に連絡するなんて、死んでもしたくないね。

雇用主は間違いなくイカれてるけど、作者に連絡するなら別の手段を使うほうが楽なこともあるよね。自分が使ってる重要なオープンソースプロジェクトの管理者が教授なんだけど、彼にはメールを送る方がずっとスムーズなんだ。

メールで連絡されたくないんだったら、そもそもGitHubのアカウントに公開なんてしてないはずだろ。

それは彼らがプロフィールに公開していると仮定した場合の話だね。みんな忘れがちだけど、コミットにはメールアドレスが含まれるからさ。

ただBANすればいいじゃん。ドラマが大好きな連中に慈悲は無用だよ。

GitHubの通知をすべて無視する

これこそが自分のやり方。公開リポジトリに対して、自分がやる気にならない限り義務なんて「一切」ないんだよ。「現状有姿（AS IS）」という言葉の意味を、みんな本当に理解していないんだよね。

文学でペンネームを使うのが当たり前なのと同じで、俺もコードを書くときはそうしてる。実在はしてるけど、あくまで「もう一人の自分」って感じで、仕事上のアイデンティティとは完全に切り離してるんだ。

ガイ・コードマン

小島監督、ご本人ですか？

Cat Branchmain（猫のブランチメイン）

Saul Hacksman

SNSでよくある話だよね。仕事や業界に関連していない限り、書き込む全てのフォーラムやブログ、SNSに自分の経歴を載せるなんて意味がないし。趣味はあくまで趣味のままでいいこともあるんだよ。

マジかよ、個人のプロジェクトのために相手の雇用先に連絡する奴がいるのか？ただ、匿名でいることへのアドバイスには一つだけ注意点があるかな。匿名だとしても、ちゃんとした明確な連絡手段を用意すべきではないかという点だ。自分は主にセキュリティリサーチをやっていて、暇な時にオープンソースソフトウェアの脆弱性を探しているという変な立場にいるんだ。それが、自分が気に入っているプロジェクトへの貢献方法だからね。脆弱性報告に対する「業界標準」の手順は、まず非公開で共有すること（関係者を限定することで悪用のリスクを減らすため）。その後、数ヶ月経ってから公開する（機密保持にも限界があるし、自分が見つけたなら他の誰かも見つけているかもしれないから）。これは、開発者が落ち着いてプロジェクトを修正する時間と、ユーザーのセキュリティを守るというバランスを取ろうとしているからなんだ。開発者が問題を真剣に受け止めないと、ユーザーのセキュリティが危険に晒されるわけだからね。これだと小規模な開発者にはかなりの負担になる。彼らは趣味でやっていることが多いのに、突然外部から「特定の期限までにソフトの大部分を変更しろ」という圧力を受けるわけだから。この状況には本当に申し訳ないと思っているよ。でも、開発者の快適さとユーザーのセキュリティを天秤にかけた時、他にいい方法がないんだ。でも、そもそもメンテナーへの連絡方法が見つからない場合がある。前述したように、公開PRで脆弱性を報告したくはないんだけど、連絡先が見つからないことが本当によくあるんだよ。かといって、適当なコントリビューターに報告するわけにもいかないし、そのせいでプロセスが非常に難しくなっている。だから、プロジェクトが完全に死んでいない限り、特にユーザーがいるなら、OSINTを駆使して連絡先を探さなきゃいけないような事態にならないよう、何らかの連絡手段を残しておいてほしい。

[念のために言っておくと、あなたが返信している相手とは別の人だよ]

素晴らしい考え方だね、シェアしてくれてありがとう。

これに対する自分の反応は、そもそも「なぜコードを公開するのか」という目的に大きく依存すると思う。履歴書に書くためとか、単なる「なんとなく」なら、セキュリティ修正も機能リクエストと同じ程度の優先順位でいいかな。気分が乗ればやるけど、約束はしない。ライセンスで許可されているなら、フォークして自分で直してくれ（気が向けばプルリク送ってくれてもいいけど）。自分のプロジェクトをベースにする前に考慮していなかったなら、それは僕のせいじゃない。

もちろん、積極的にユーザーに使ってもらうよう促しているなら話は別で、その場合は責任を感じるだろうね。ただ、自分はまだそういう状況になったことがないから、何とも言えないけど。

その点について言うと、趣味で作ったプロジェクトを公開すること自体は全く問題ないし、ユーザーに期待値を明示してさえいればいいと思う。でもGitHubにはPythonを習いたての（あるいはChatGPTを覚えたての）人たちが作った「軍事レベルのAES暗号化で安全なメッセンジャー」みたいなのを謳うプロジェクトが溢れかえってる。そういうのを見つけた人は真に受けてしまうかもしれないから、不具合を直すか、どんな期待値を抱くべきか明記しておくことには価値があるよ。

一番よくおすすめするのは、READMEに「これはお遊びプロジェクトなので安全ではありません、安全性を期待しないでください」といった一文を付け加えることだけど、ほとんどのプロジェクトはそんなことをユーザーに周知しようとすら思ってないんだ。実際にはユーザーなんていないだろうと思ってるんだろうけど、GitHubに置いた時点で公開されてるわけだし、実際に使う人が現れる可能性は十分あるからね。

セキュリティの脆弱性は他のバグとはわけが違う。普通のバグなら「思ってた動きと違う」だけで済むし、システムを破壊しない限りは世界が終わるわけじゃない。気にするならフォークするか、切り替えるか、修正されるまで待てばいい。でもセキュリティは後追いが効かないんだ。脆弱性がある状態で運用して攻撃されたら、後から「安全にしよう」なんて無理で、事前の対策が必要になる。それに、アプリケーション自体というより、銀行情報や仮想通貨のウォレット、SSHキーに関わってくることが多いからね。仮にピザのレシピ本アプリだとしても、セキュリティ脆弱性の影響はそれだけじゃ済まないことがある。だからこそ、最低限ユーザーに対してどういうスタンスなのかを明確にして、ユーザーが情報に基づいて判断できるようにする、特別な配慮が必要なんだと思うよ。

それについては意見が合わないかな。あなたの主張は「ツールが公開された時点で、セキュリティレベルを明示する義務は作者にある」という考えに基づいているようだけど、それは間違いで、義務は100%ユーザー側にあるよ。インターネットから何かをインストールするなら、それが安全であることを自分で確認しない限りは、常に侵害されていると想定するべきだ。

その分野のエキスパートが主に使う「ライブラリ」ならなおさらだね。もし会社の人間が npm add foo を実行して、その foo が安全か確認せずに何かトラブルが起きたら、それはその個人の責任だよ。以上。

はっきりさせておくと、作者側に責任が移るケースがあることには同意するよ。例えば、何かを販売するなら、買い手に対してどれくらいのセキュリティやアップデートを期待すべきかを明確に伝えるべきだ。でも、それを一般化しちゃいけない。

最後に、セキュリティ問題と機能リクエストが別物だという点には完全に同意。ただ、高い報酬でももらわない限り、セキュリティ保証を伴うコードを提供する気はないかな。それがユーザーにとって問題なら、金を払うか、別のものを使うかすればいいだけの話だ。

意見を異にさせてもらうよ。敬意を払いつつね。「意見の不一致ということで合意」で済ませたいところだけど、この問題は落ち着いてニュアンスを込めて議論する価値があると思うんだ。君を説得できないかもしれないけど、この難問に対するシンプルで納得感のある解決策を提示してみたい。

まず、僕が君に同意する点から言わせてもらうよ。FOSSを公開すること自体が贈り物であり、独立したプログラマーにとって責任という名の重荷になることは理解している。あと、MicrosoftやGoogleのような巨大企業が、自社のスタックが依存しているからといって、小さな開発者にcurlのようにライブラリを早急に修正するよう圧力をかけるような状況は本当にひどいと思う。彼らには解決策を出すなり、開発をサポートするなりする資金があるはずなのにね。セキュリティチームや開発チームが遠すぎて別会社のようなものだとしても、もっとマシな対応ができるはずだ。ユーザーもネット上ではもっと慎重になるべきだね。じゃあ、それらを知っていてなお、なぜ「責任は開発者が負うべき」と考えるのか？

核となるのは「期待値」だと思う。

なぜ販売しているときは開発者が責任を感じていいのに、無料のときはダメなのか？後者には開発資金がないから？それも一因だろうけど、小規模な開発者はほとんど稼いでいないし、趣味のプログラマーとそんなに大差はない。結局、期待値の問題だと思うんだ。何かが売られているとき、ユーザーは「買う価値がある」と期待する。だから期待外れなら詐欺だと感じる。

文脈を整理すると、君が言っているのは「製品がまともであることを期待するのではなく、ダメであることを前提に、チェックする責任は自分にあると考えるべき」ということだよね。これを検証してみよう。

まず、僕自身も無料のものをたくさん使っている。もしVLCに脆弱性が見つかって修正されず、僕のPCがハッキングされたら、僕は間違いなく開発者を責めるよ。偽善だとは思わない。理由はいくつかある。

1. VLCは「エンドプログラム」だ。ライブラリではなく、ビルドする人ではなく、エンドユーザー向けだからね。
2. エンドユーザーにダウンロードしたもののセキュリティを意味のあるレベルでチェックするよう求めるのは無理がある。
3. 「自分のバグは自分の問題」という文化的な側面もある。僕の出身地では、バグを作ったら自分の責任で、他人のせいにはしないんだ。

この文化的な話は置いておくとして、エンドユーザーの問題は別だよ。注意しろと言っても、ユーザーがVLCのセキュリティを検証するのは不可能だ。せいぜい、一番頼りになるITに詳しそうな友だち（たぶんChatGPT）に「https://www.vlclan.org/ は本物のサイトか？」と聞くくらいで、それはチェックとは呼べない。それでも脆弱性があれば全員が影響を受ける。開発者に一回修正を頼んで数百万人が助かるほうが合理的じゃないか？

極端な例だと思うかもしれないけど、数百万人が使うプログラムもライブラリも、本質は変わらないと思う。

同僚のボブが何もチェックせずに npm add foo を実行する話があったよね。

• 今度はエンドユーザーじゃなくてビルダーだ。プログラムを書ける人たち。
• エンドプログラムじゃなくてライブラリだ。

ボブにはインストール前にチェックしてほしいけど、それは可能なのか？

• まず評判やメンテナンス状況を見る。保証はあるか？
• 次にコード全体を読む。依存先が壊れたJWTライブラリを使ってたら？それも全部チェックしなきゃいけない。
• 脆弱性を見つけるのは困難だ。10年以上ソースコードの監査をしてきた僕でさえ、他人のライブラリの依存関係まで完全にセキュリティチェックできると自信を持って言えないよ。

ボブが英雄的にそれをこなしたとして、1ヶ月後に依存先が更新されて認証スタックが壊れたら？ボブは責められるべきか？

言いたいのは、責任をユーザーに押し付けるだけではセキュリティは進まないということだ。ユーザーにはできないし、ビルダーにも限界がある。 verification（検証）しても、後からバグが入るかもしれない。

ユーザーに期待しすぎるのではなく、中道を行くべきだ。期待値を明確にすればいい。「趣味のプロジェクトだからセキュリティ保証はない」とサイトやReadmeに書いておけば、ユーザーはリスクを判断できる。もしVLCがそう書いていたら、僕のおばさんは怖がってダウンロードしないかもしれないし、リスクを理解して使うかもしれない。いずれにせよ、情報に基づいた決定ができる。

開発者が「期待値」を明確にすることはそれほど難しい要求じゃないと思う。修正を約束したくないならそれでいい。でも、ユーザーを責めないでほしい。僕のようなセキュリティリサーチにとっても、プロジェクトに「保証なし」と明記してあれば、脆弱性を見つけたときに「修正する意図がない」と分かれば深入りせずに公表へ移行できる。無駄な期待をせず、お互いに時間を有効に使えるんだ。

結論として、期待値を明確にすることは全員の利益になる。開発者は時間を節約でき、ユーザーは情報と安全を得られ、リサーチは効率的に動ける。たった一行、「このプロジェクトはセキュアではない」と書くだけでね。

彼らはいくら払うつもりだったの？

1 - その通り、記事にもちゃんと書いたよ。

2 - ありがとう、友よ。

3 - それは素晴らしいアイデアだね。

nzb360ってアプリが良い例だと思うよ。予定されている機能リストがあって、目標の資金が集まったら着手して追加するっていうやり方だったはず。

それ素晴らしい例だね。

3についてだけど、信頼を損なわないためにも、理想を言えば有料機能にはプライバシーやセキュリティ関連の機能は含めないほうがいいよね。

好きにすればいいよ。それだけだ。

そう、彼らはそのツールが彼女のものだと信じ込んでるんだ。

ハハハ、それは名案だ！面倒なユーザーから身を守るのに完璧だね。

法律家でも英語ネイティブでもないから断定はできないけど、ほとんどのFOSSライセンスには保証の免責と責任の制限がすでに含まれていると思うよ。保証の免責条項は、BSD 0-clauseライセンスでも唯一残っている項目の一つだしね。

素晴らしい言葉だね、ぜひ参考にさせてもらうよ。

すごく納得できるよ、相棒。アドバイスありがとう。

アドバイスありがとう！結局、君が提案してくれた通りに実装してみたよ。プロジェクトに構造化されたIssue要件や詳細なPRテンプレート、コントリビューションガイドライン、ラベルを導入して整理したんだ。おかげで貢献のフローがかなりスムーズになったよ。本当に感謝してる！ https://github.com/kaic/win-post-install/blob/main/CONTRIBUTING.md

OPのやつはタイムラインの無効化とか、オプションの調整項目がいろいろあるみたいだね。Niniteはインストール専用で、調整機能はないから別物だよ。

これはwingetを使っているみたいだから、追加のダウンロードは不要だし、設定を変更するためのコマンドも色々揃っているよ。

クールなアイデアだね。

ただ、「サポートを保証するものではなく、あくまで意図があるだけ」という文言をどこかに添えておいたほうがいい気がするな。

このスレッドでも分かる通り、権利意識が強い人が一部いるから。「サポートするって言ったのにやってくれないのはおかしい」って訴訟を起こされても驚かないよ。

👀

最近、コントリビューションガイドやテンプレート、寄付の手段、それに厳格なIssue管理を実装したんだ（君のコメントをかなり参考にしたよ）。ヒントをくれて本当にありがとう、友よ。 https://github.com/kaic/win-post-install

はははははは、最高なコメントだな兄弟

これぞ正しいやり方だ。みんなにとって健全なバランスだね。自分もライセンスを選ぶときは似たようなアプローチをとっている。誰でも利益を得られるように公開はするけど、GPL系を選ぶようにしているんだ。大企業はそれを伝染病のように避けるからね。個人は恩恵を受けられるし、企業が必要なら自分たちでリライトするコストを払わせることができる。

だよね？投稿主は話をするっていうより質問ばかりしてる感じ。エンゲージメント目的の釣りっぽいし、このサブレの趣旨にも合ってないよ。

笑。しかも彼、「スターやIssueが急増した」とか言ってたけど、最初に確認したときは99スター（今は170）で、Issueは全部で8個（今は9個）しかなかったんだぜ！それでオピニオン記事を書いちゃうなんてね…。エンゲージメントが極端に不自然だし、ボットを使いまくってると思う。通報しておくよ。

スターとイシュー、それにアクセス数と利用状況ね

いや、君はWebサイトのトラフィックデータを公開してないだろ。君が言ってた内容に基づいて判断したんだけど：

スターが急増して、イシューが押し寄せ、予定してなかった機能を求められ、スコープやドキュメント、ユーザーの期待について迅速な判断を迫られた。

誤解しないでほしいけど、10個程度のイシューは急増とは言わないし、180個程度のスターなんて別に大した数じゃない。

全体的にめちゃくちゃボット臭いし自己宣伝っぽいんだよね。ブログ記事もあらかじめ用意されてたみたいで、大げさすぎる。Redditのコメントですら怪しいのが混ざってるよ

じゃあ、稼ぐ時間だね。

いい指摘だね。