主题：【原创】Linux是什么？ -- 请尽量

依靠用户进行测试，当然只是一个方面。很多active contributors也都有自己的test suites。每个人的兴趣不一样，侧重点也就不一样。最后在OSDL，也就是如今Linus挂靠他的“组织关系”的地方，还有专门的队伍负责对Linux内核进行测试。

但是由于操作系统内核的特殊性，无法有效地使用automated unit test等方法，绝大部分的test suites不过是负载测试而已。相当部分的quality assurance依赖于静态代码分析，包括code review。

当然，我同意测试应该是一项高度协调的任务，既要确保覆盖面，又要能够快速重复。如果有人能够协调所有的测试努力，可以更有效的利用所有的资源，得到更好的结果。

或许在这方面，其他open source操作系统如FreeBSD等可以有经验借鉴？

Linux很注重code review。其实Linus和他的副手们的很大一部分精力是花在审查其他contributors送进来的patches（不光是bug fixes，还有new features）。还有一些“外围”的contributors组织了一个活动叫Linux Kernel Janitors （http://janitor.kernelnewbies.org/），任务就是在一些老鸟的带领下，审查Linux的所有代码。

另外，象ragtime所说的，Linux的源代码是公开的，任何人都可以查看。事实上，很多人也正在这么干。例如，Stanford大学一帮人用他们的一个工具对Linux内核进行了分析，发现了不少问题。可惜地是，这个工具没有成为open source的一员（coverity.com）。Linus目前自己在写一个具有类似功能的工具，已经初见成效。

Linux的开发进度是招致了不少批评，这也是Linus和他的副手们正在努力改善的地方。但是在增加新功能和尽快稳定下来以发布新版本之间，程序员们总是倾向于前者，because they are doing it for fun.

如果一个在自己产品中使用Linux的供应商需要某个feature或bug fix，要么自己去做，要么请人来做。Open source makes this possible.

至于说到在商言商，Linux恰恰不是一个商业实体。到目前为止，Linux还是一个volunteer project，虽然商业机构的介入越来越多了。

Commerial offerings的开发进度表又有多少可信度呢？微软的Longhorn一再推迟，成了long wait，feature还越来越少。其他公司的vapourware也是一抓一大把。宣布一个进度表但是无法遵守，又有多大意义呢？