切换到 iOS 不见得会解决问题，如果不是更糟。
正如这个 issue 下的回复一样，实际情况是逼迫用户在 social death 和放弃使用选择一项。还没有人能正面反驳这个问题。这自然说不上你圈所谓“生态”的多光荣的现状，所以要拒绝也自然只能曲线救国了。
换 Apple 的产品其实有个类似的问题：不管你自己想不想用，周围人或多或少会逼你用——甚至从来不用也一样。（而且因为定制起来对开发者都更麻烦，问题可能更大。）你长辈要你安装个 app ，你是十动然拒，还是厚脸皮说“不会”然后被婊“白养了你个×的”？或者直接因为这种破事撕破脸？
真要这样就太二了。无论哪种情形，明显鞭策便于接受用户需求变更的厂商是跟低头不见抬头见的周围人闹翻相比更具有现实性的捏软柿子的手段。
当然这里已经排除了个更硬的选项——自己撸个替代品。不过就 Android 这么一坨坨的玩意儿， fork 的成本和全部重新造轮子都快相差无几了。看了一下，回复里还真有个“ make a fork of Android since it is open source ”的，该说是套路么？
一定意义上这应该就是 RMS 不用这俩货的理由。不过对于其他大部分用户而言，用一坨破烂更省事，问题还是不会解决。
@
patx 你的话柄比原问题报告者落得更明显。
首先，如何定义“正常工作”，什么叫“合理”？在没有和客户约定死支持范围的情况下拒绝因为预期行为不一致而产生的请求是合理的？（当然，有没有义务是另一回事。）
如果想说这种用户理解的 force 不是项目成员理解的 force ，或者想说不是项目范围内应该解决的问题，那么 ok ，先澄清支持特性集的边界。直接劈脸 intended 是什么鬼？怎么不说 by design ？
第二，“不是 bug ，当然是 won't fix ”是一种什么精神？你正好搞反了，正因为 issue tracker 跟踪的是 issue 而不仅是 bug ，所以处理时更不应该不是 bug 就 won't fix 。（人家 bugzilla 还处理 feture request 呢。）
回复的估计都没敢这样想。
当然这里处理的具体做法（直接的回复）有个明显的槽点，就是报告者都没明确咬定这个 issue 是 bug 的时候（虽然报告者在方案里用了 fix 这个词——其实对实质问题来讲是错的，撑死叫 workaround ），直接就一坨更次等的 fallback workaround 覆盖需求变更了，包括传话的回复在内，显得十足的不专业。
更合理的反映是先明确定性，回复这个 feature enhancement request （或者随便什么别的，总之也不会自认就是 bug ）的 issue 因为 blah blah blah 原因不能修复，然后就不用多废话了。现在呢？被 switch to iPhone 噎回去吐不出象牙很好玩？
2
Select Language