- Apple開発者コミュニティで Feedback Assistantボイコット が提案され、問題が解決するまで公式バグ報告システムに新しいバグを提出しないという行動計画が出ている
- 参加方法は、まずFeedback Assistant自体の問題を報告したうえで、新しいFeedbackの提出を止め、既存の依頼には ボイコット中 と返答する流れとなっている
- 不満は、再現可否の非公開、通知なしの終了、再オープン不可、過度な
sysdiagnose要求、Web提出の停止、検索不可など、バグ報告システムの運用方法 に集中している
- WebKit、GitHub上のAppleオープンソースプロジェクト、ソーシャルメディア・ブログ・ポッドキャストでのバグ共有はボイコット対象から除外される
- 目的は、Appleが外部開発者の無償QA労働に依存していることを明らかにし、開発者たちがFeedback Assistantなしでも業務と生計を続けられることを確認することにある
ボイコットへの参加方法
- AppleのFeedback Assistantのボイコットを直ちに開始し、すべてのApple開発者に参加を勧める
- 提案された手順は3段階で構成される
- Feedback Assistantの Developer Tools & Resources 項目に新しいFeedbackを提出し、問題一覧とともに、解決までボイコットすると伝える
- Appleが問題を解決するまで、他の新しいFeedbackは提出しない
- Appleが既存のFeedbackについて応答を求めてきたら、ボイコット中だと返答し、最初の段階で提出したFeedback番号を参照する
- 最初の段階のFeedbackは、できるだけ各自が固有の内容で作成するのがよいとされる
- 目的は、Appleにボイコット関連のFeedbackを処理させ、開発者たちが本気で行動していることを認識させることにある
ボイコットの範囲と除外対象
- ボイコット対象は Feedback Assistant に限定される
- バグをソーシャルメディア、ブログ、ポッドキャストで取り上げることは引き続き可能
- Appleの他の公開バグ報告システムは対象外
- 他のバグ報告システムは、さまざまな面でFeedback Assistantより優れていると評価されている
- 第1の目標は、これまで見た中で最も バグ報告者に敵対的 だと批判されるFeedback Assistant自体を変えることにある
Feedback Assistantで繰り返される問題
- Appleは正確な再現手順やサンプルXcodeプロジェクトを受け取っても、報告されたバグを 再現できるかどうか を知らせなかったり、公開を拒否したりする
- 開発者は、AppleがFeedbackを真剣に扱っているのか、官僚的に時間を引き延ばしているのか判断しづらい
- 追加情報の要求や終了通知なしに、
Investigation complete - Unable to diagnose with current information 状態でFeedbackが閉じられる
- 提出者の同意なしにFeedbackが閉じられ、現在ではApple社員であっても閉じたFeedbackを再オープンできないのがシステムの「機能」のように見える
- Appleがまだ修正されていないバグのFeedbackを誤って閉じた場合、同じバグについてAppleが新しいFeedbackを作成して番号を知らせるのではなく、開発者に新規で開き直すよう求める
- バグを修正したり、修正・再現を試みたりしていない段階でも、最新ベータでFeedbackを verify するよう求める
- 開発者がverifyしないと、そのFeedbackを閉じる
- この過程は開発者の時間を大きく浪費するものとみなされている
- 重複として閉じられたFeedbackでは、元のFeedbackの状態変更が常に伝えられるわけではない
- Appleは侵襲的な sysdiagnose レポートを頻繁に要求し、提出しなければFeedbackを見ようとしない
- 多くの開発者は個人のデバイスで作業している
sysdiagnoseは、Apple自身が基本的人権だと述べるプライバシーを大きく侵害すると見なされている- Appleは、より小規模で標的を絞った、より侵襲性の低い情報収集・診断方法を作らなかった、または諦めたと批判されている
- 最近では、WebからFeedbackを提出できなくなった
- macOSまたはiOSのネイティブFeedback Assistantアプリからのみ提出するよう求められる
- Webアプリで何年もFeedbackを提出してきており、最後のWeb提出は10月26日だったと述べている
- 開発者はFeedback Assistant内でバグを検索できない
- Apple社員はデータベースを検索できるが、外部開発者は自分が提出したFeedbackしか見られない
- 一部のFeedbackは秘密に保つ必要があるが、多くのFeedbackはそうではなく、オプトイン型の検索可能なバグデータベースは外部開発者とAppleプラットフォームソフトウェアの品質向上に役立つと見られている
「Appleにも時間がない」という反論への答え
- AppleにFeedbackへ適切に応答する時間がないという擁護論には同意しない
- 優先順位、スケジュール、人員配置は会社のリーダーシップの決定で決まる
- Appleは外部開発者の時間より自社の時間を重視し、開発者の時間を際限なく浪費することに罪悪感がないように見えると批判されている
- AppleがFeedbackに応答する時間がないと決められるなら、開発者もFeedbackを提出する時間がないと決められる
- 長年のAppleユーザーの立場からは、毎年繰り返されるOSアップデートが必須とは思えず、Mac OS X Snow Leopard時代のように約2年ごとの更新のほうがバグ修正の時間をより確保できたと振り返る
個々のエンジニアではなくシステムを標的にする
- このボイコットは個別のAppleエンジニアを標的にするものではない
- 多くのAppleエンジニアもFeedback Assistantの改善を望んでいると考えられている
- Feedback Assistantの改善は、Appleエンジニアと外部開発者の関係を損なうのではなく、むしろ強化しうる
- ボイコットの対象は バグ報告システム であり、Appleの経営陣に継続的な問題を認識させ、対応を促すことが目的である
無償QA労働と開発者の選択
- このボイコットは 労働ストライキ と呼ぶこともできる
- Appleは開発者を大規模な無償QA労働に活用している
- 1件のFeedbackに何時間、あるいは何日もの労力がかかることもある
- Appleも開発者も、開発者がAppleソフトウェアと製品をテストし、磨き上げるうえで重要な役割を果たしていることを理解している
- Appleは開発者のFeedbackを当然の権利のように扱いながら、バグ報告システムでは開発者に敬意や基本的な礼儀を示していないと批判されている
- 開発者たちは、プラットフォームのためにFeedbackを提出するのが義務だと信じ込まされてきたが、Appleプラットフォームは慈善の対象ではない
- AppleプラットフォームはAppleを世界で最も収益性の高い企業にしたのであり、外部開発者はApple社員ではない以上、無償労働が当然視されるべきではない
ボイコットの2つの目標
- 1つ目の目標は、開発者のバグ報告がAppleにとって必要であり、それがなければAppleが損をすることを示して、Feedback Assistantの改善を促すことにある
- 2つ目の目標は、開発者自身がAppleにバグを報告する必要は実際にはないのだと確認することにある
- 提出されたバグの多くは結局修正されず、修正されたとしても、その影響を回避するには遅すぎる場合が多いと見られている
- Appleのバグがアプリに影響を与えるのは事実だが、Appleが適時に修正すると期待しにくいため、開発者は通常アプリに 回避策 を入れて配布する
- 回避策が入った後は、Appleがそのバグを修正すべき緊急性は下がり、バグ報告は必須というより慈善行為に近くなる
Feedback Assistantの役割の再定義
- Feedback Assistantは開発者に顧客サービスを提供するシステムではないとみなされている
- むしろ、これまで開発者がFeedback Assistantにサービスを提供してきたのであり、システムが改善されるまでそのサービスを保留するという選択をしている
- AppleがFeedback Assistantの問題を解決することは望んでいるが、改善が来なければ恒久的にボイコットする意向がある
- Appleが前向きに反応するかどうかにかかわらず、多くの開発者が参加し、Feedback Assistantが業務や生計に不可欠ではないことを確認できれば、ボイコットは成功と見なされる
2023年11月7日の追記事項
- Feedback Assistantボイコットには公式Webページができた
- そのページにはメールアドレス、RSSフィード、Mastodonアカウントも掲載されている
- ボイコット参加者の公開リストも編集中で、詳細はそのページで確認できる
1件のコメント
Hacker Newsのコメント
Feedback Assistantで送った報告のうち、返信や確認を受け取ったのは10%程度だと見積もっている
iOSで100%再現するバグで、隔離されたサンプルプロジェクトまで提供した。慎重で詳細なバグレポートを作るには時間がかかるのに、何の返答もないと本当にがっかりするし、この記事には強く共感する
テストし、再現し、文書化するには時間と労力がかかる。何かを求めていたわけではなく、ただ修正されてほしかっただけで、自分の子どもたちもiPhoneを使っている
他社も大きくは変わらない。Ciscoにリモートコード実行の脆弱性を送ったら、すでに把握しているが製品がサポート終了に近いので修正しない、と返答された
何年もの間に多くの脆弱性に遭遇してきたが、お金をもらって探しているのでなければ、たいていはそのまま無視するようになる。苛立つだけの価値はない
再現手順、自分で調査した内容、詳細情報を備えたきちんとしたバグレポートを提出しても音沙汰なし。アプリがバグをそのまま
/dev/nullへ送っているように感じるボイコットやストライキは、大多数、あるいはほぼ全員が参加してこそ効果がある。ほぼ全員が参加すると確信できるときにだけ、自分も参加するからだ
このブログ記事で開発者の0.1%だけがストライキすることになっても、Appleは気にも留めないだろう
開発者ストライキというアイデア自体は素晴らしいが、Jeff Johnsonひとりの行動呼びかけから始めると、通常は行動変容を生み出すのは難しいと思う
組織化するには、まず知名度があり尊敬されている主要な開発者50〜200人に直接連絡し、共同署名を集めたうえで公開書簡を出すべきだ。そうすれば誰もが、これはひとりの願望ではなく、事情をよく知る人たちによる真剣なストライキだと分かる
主要な技術メディアにも取り上げてもらい、Appleと開発者の双方に見えるようにする必要がある
そしてその書簡は、不満の一覧ではなく、ストライキを終わらせるためにAppleが取るべき具体的で検証可能な措置を示すべきだ。終わりのない要求になってはいけないし、今すぐ全部直せという願望ではなく、日付とマイルストーンのある現実的な進展であるべきだ
ストライキをするなら、実際に組織化しなければならない。「すべてのApple開発者に参加を勧める」というブログ記事は組織化ではないし、ストライキすると書いたからといって、誰かが魔法のように代わりに組織してくれるわけではない
筆者が本文の下のほうで述べているように、購入をやめるボイコットというより無料労働の提供をやめるものなので、ここではストライキと呼んでいる
これは、収入を増やすための闘いのように明白に重要な問題ではない。このストライキの利点は、記事前半の1〜3段階が誰にとっても低い労力しか求めないため、望めば簡単に参加できる点にある
記事の最後でも述べているように、目標のひとつは、実は私たちにFeedback Assistantはなくてもよいのだと自分たちに証明することだ。失うものはほとんどなく、バグ報告システムへの参加は私たちにとって必須でもなく、ただ離れればよい
このストライキは、何が何でも勝たなければならない死活問題ではない。Feedback Assistantがどれほどしつこくひどくて腹立たしいものでも、職業上の優先順位としては低いはずだ
むしろこの態度こそがAppleに対するレバレッジになると思う。私たちは劣悪なボランティアの「機会」から降りるボランティアにすぎないが、Appleは商用製品のために私たちの無料労働に依存しており、それを置き換えるには実際に従業員をもっと雇って給料を払わなければならない
Feedback Assistantの利用をやめても、給料を手放す人はいない。このストライキに参加するコストは非常に低く、多くの人にとっては参加しないより参加するほうがコストが低いかもしれない
だから、伝統的な労使紛争では難しい形で、時間とともに影響力のあるストライキへ成長する可能性が見える
たとえそうだとしても、Appleには処理すべき他の報告や機能が十分にあるので、外部からのバグ報告がすべて消えても大きな影響はないかもしれない
Appleのバグ管理のやり方が変わってほしい。バグを再現し、自分が受け取りたいレベルのバグレポートと最小テストケースまで作成したのに、何年も音沙汰がなく、やがてクローズされたり、まだ問題か確認しろとさらに作業を求めるメッセージが届いたりすると、本当にやる気を削がれる
Appleに近い規模で、これをうまくやっている会社があるのか気になる
これが難しい問題である理由もいろいろ思い浮かぶし、人員配置が難しいことも理解している。だがAppleはこの問題を解決する対価を得ており、解決できていない
だからバグを報告するときは、作業を少なめにするほうがよいと概ね考えている。ただし、入れる内容は慎重で明確であるべきだ
共感する。Apple内部でRadarを提出しても、似たような扱いを受けることが多い。ただしRadarのステータスを見ることはできる
バグ修正、微調整、コードベースを庭の手入れのように管理する人たちのことだ
行動は言葉より重い。Appleは開発者をどう考えているかを行動で示している。
Appleの行動を変えるには、かなり大きな騒ぎを起こす必要があるだろう。山のような現金の上に座っている状況では、Appleが変わるインセンティブはほとんどない。
Appleは外部開発者を一種の害虫のように見ているように思える。開発者に強いるシステムや手続きは、積極的に彼らのやる気を削ぐよう設計されているように見える。
以前の投稿: https://news.ycombinator.com/item?id=3947903
今ものすごく年を取った気分だ。
追記: ようやく完全な定型書簡を見つけた [1]。当時そのコピーを提出したが、今でもFeedback Assistantで放置されたままに見える。
[1]: https://gist.github.com/mysteriouspants/1989061
Feedback Assistant経由のバグ報告が必要な場合もある。Apple社内の開発者を見つけ、その人がバグを直すと言っていて、社内の作業報告用にフィードバック番号だけが必要な場合だ。
求められていないバグレポートを提出するのは、単なる時間の無駄だ。特にFeedback Assistantを「ボイコット」しているというより、有用なことをまったくしてくれないので使うのをやめた。
開発者として、Appleとはどんな形でも関わることを完全に拒否している。理由は年100ドルの手数料だ。
こういうことが明るみに出るたびに、自分の判断が特に正当化された気分になる。
世界で最も裕福な企業が、自社プラットフォームに貢献できる特権に対して金を取ることを想像してみてほしい。
完全に狂っているし、どんな言葉でも私の考えは変わらない。
それでもGoogleのように一回限りにできるし、もっと安くもできる。
待って、もうWebからフィードバックを送信できないということ？ 本当にとんでもなく馬鹿げている。
Feedbackアプリ自体も半分壊れているので、Appleが望んだとしても私の報告は受け取れない気がする。
以前、AppleがSafariに関してWeb開発者をどれほど軽視しているかをブログに書いたことがある [1]。
これを見ると、Appleは他の開発者も軽視しているようで、正直驚きはない。
[1] https://www.construct.net/en/blogs/ashleys-blog-2/safari-rel...
Appleは先端機能だけでなく、基本機能も定期的に多く壊す。テストの慣行があまり優れていないように思える。