不管开源闭源程序，总有那么意外崩溃的时候。那么程序崩溃了之后，接下来该做什么呢？且看 Fedora 中文邮件列表的一番讨论，或许能告诉你更多。
先看起因吧：
这程序的设定让我很难接受，
Ctrl+V粘贴中文 乱码，需要 无格式粘贴才正常
我费半天编辑一个DOC文档，正要保存，程序提示无法保存，
然后我保存副本，程序直接崩了
再打开先前保存的，中文全部乱码,但是打开自动保存的文件却是正常的
不知道是我人品差还是什么原因。
Xfce-cd 版本 默认带的奇葩软件还有midori 这个浏览器，标榜lightweight，但是打开网页很卡，容易崩掉
我很费解Xfce-live-cd这种默认自带的软件为什么不选择质量高，难道就是为了表示有，并且方便截个图
之后 Qian Hong 指出说其实是报 Bug 不够：
这程序的设定让我很难接受，
Ctrl+V粘贴中文 乱码，需要 无格式粘贴才正常
我费半天编辑一个DOC文档，正要保存，程序提示无法保存，
然后我保存副本，程序直接崩了
再打开先前保存的，中文全部乱码,但是打开自动保存的文件却是正常的
不知道是我人品差还是什么原因。
不是你人品差，是上n个遇到相同bug的人没报bug，或者是有人报bug但开发者人手不足来不及修。也有可能你真的是第一个遇到这个bug的人，但这也不能说是人品问题。（画外音：其实明明就是233）
从ohloh的统计来看，abiword的开发还算活跃：https://www.ohloh.net/p/abiword
这意味着崩溃之类的严重bug，只要你能重现，报告之后应该会有人修复的。
如果你将来计划仍然使用abiword，那么建议搜bug报bug，参见
http://www.abisource.com/support/bugs/；如果你被坑过一次之后决定将来不用abiword了，那么不妨做第n+1个不报bug的人：）
如果想找其他开源替代品，可以参考：
https://www.ohloh.net/p/compare?project0=LibreOffice&project1=Apache+OpenOffice&project_2=AbiWord
从活跃开发人数，可以估计出将来遇到问题求助时得到解决的容易程度。
Xfce-cd 版本 默认带的奇葩软件还有midori 这个浏览器，标榜lightweight，但是打开网页很卡，容易崩掉
Midori的开发同样还算活跃：https://www.ohloh.net/p/midori
如果Midori对你来说是刚需，崩溃这样的严重bug值得去报。参见：http://midori-browser.org/contribute/
同样，如果不是刚需，大多数人可能没有足够的精力/动力去报bug，这时候最经济的方式可能是换一个软件，但是一旦选定了自己喜爱的开源软件，报bug才是真爱：）
我理解你感觉被坑是因为困惑/不满 Xfce-live-cd
为什么默认选择这些软件。这个问题，理论上的解决方案是，给xfce项目本身报bug，叫他们不要预装这两个软件，换成你认为更好的软件；但是这样做不会
有太大的说服力，除非你能证明大量用户给abiword/midori报过bug但是他们都不修或者修不了--于是又回到了开头的问题，要先给他们俩项目
报bug：）
从用户的角度来说，崩溃的bug几乎是最不能忍受的bug了，可是其实从软件开发的角度来说，凡是代码全开源的软件，出现能稳定重现的崩溃bug，
一般都不会太难修复，所以报告崩溃bug对于用户和开发者双方来说，时间利用上的性价比是最高的。但是崩溃的bug是那么讨厌，以致新用户直接就被吓跑
了，还没爱上就死心了，所以就不会去报bug了
：）
提问者 Szopen Xiao 表示赞同，且提出了更进一步的问题：怎么样改善汇报 Bug 的过程？
对此，Ubuntu 打包者 Felix Yin 对于依靠软件打包者汇报 Bug 有自己的看法：
其实已经有很多 Bug 是这样完成的了. 但是你也应该明白, 一个复杂到 Abiword 这样的软件, 如果没有那种需要跑较长时间的集成测试, 几乎是没什么
办法测到所有功能的 (这种测试写起来费时费力, 所以我遇到的开源项目很少会提供);而且即使有了, 也不能完全保证是没问题的, 毕竟图形显示等各种其他因素也
会影响实际体验.
作为发行版打包人, 我们一般会保证:
- 项目能跑过自己的 self-test, 如果跑不过, 至少要保证上游知道这个情况.
- 我们在打包发行之前, 自己会去用这个软件. 但是就如刚才所说, 我们是完全不能保证会用到所有功能的.
- 如果我们在测试中发现了问题(无论是项目自己的单元/集成测试, 还是自己使用体验中), 通常是肯定会向上游提交 bug 报告的. 如果涉及的 bug 比
较重大 (比如启动时 segfault 等使得软件完全无法使用的问题), 我们会暂缓发布直到上游给出解决方案, 或者我们自己有时也会尝试寻找解决方案. 这里
的解决方案包括提供 patch 给下游打上, 或者直接发布新版本.
至于"产品质量控制标准", 通常完全是由项目管理人员的喜好决定的. 有的项目比较随意, 对提交的 patch 几乎是来者不拒. 这种情况下, 如果项目本身没
有带测试, 或者测试覆盖太少, 会经常产生质量方面的问题.
用户提交BUG除非用户对这个软件十分关注并且十分熟悉BUG提交流程，并且用户十分热衷干这个事，并且用户时间比较宽，有没有什么办法改善这些问题？
有很多努力改善这个问题的方案了, 比如 Ubuntu 的 Apport 会在软件崩溃/升级失败等问题时产生相当详尽的错误报告, 并且以图形界面引导用户报告.
不过这样的方案也有比较明显的问题:
- 这类方案会大幅加大发行版 Bug Tracker 的维护难度, 因为很多用户 (包括我以前) 都会在懵懵懂懂的状态提交一个几乎只有 Apport 收集
的信息的错误报告, 而且由于自己不知道这个问题是不是和别人一样, 面对同一问题的这样的错误报告会出现很多重复. 因此 Launchpad 上有相对较多的
Bug 分类/整理人员来应付这种情况.
- 大量用户并不跟进错误报告. Qian Hong 同学曾经在某篇巨著(忘记是哪篇了 :P)里提到过, 跟进错误报告需要的时间精力比报告还要多, 而且通常
是直接决定错误报告处理速度/结果的重要因素. Apport 虽然引入了方便的报告 Bug 的流程, 但是对跟进 Bug 的流程没有做出任何帮助 (也的确是很
难帮上忙), 所以导致 Bug Tracker 上报告但不跟进的 Bug 明显变多了 (普通用户不知道/懒得跟进的还是相当多的).
不过总的来说, Apport 依然是对用户报告 Bug 困难问题的一个相当有效的解决方案.
相应的 Fedora 的打包者 Christopher 也给出了自己体会，未来的大方向将是自动化：
本来打字不太方便不想说了，不过同作为包工（Fedora），也趁机谈谈我的看法。
| 
