NetBSD的未来（The future of NetBSD)

不开花

虽然这已经是旧闻了，但是对于了解NetBSD所存在的问题和其未来的趋势还是有一定的借鉴意义的。

如同我的歌里所唱“我是一朵不开花的花，尚未学会开放就已习惯于凋零......”，似乎NetBSD也是一朵不开花。

这篇文章在*BSD社区引起了很大的反响，在本文发表大概半个月后（2006年9月14号），意大利Linux&C杂志BSD板块的Federico Biancuzzi（作为自由撰稿人，他为ONLamp,LinuxDevCenter和安全焦点写文章）采访了CMH，采访很长，在ONLamp BSDDevCenter上可以看到这个采访，文章名为《Confessions of a Recovering NetBSD Zealot

》。CMH主要谈论了项目的改革，基金会的管理，许可证问题和硬件文档，和厂商的联系，先前的当前的错误和要从Linux开发过程学习的东西。

这里我翻译一下最后支持人问的最后一个问题。

问：在你提交邮件到每个BSD项目（包括OpenSolaris)后，都发生了些什么，你认为在不久的将来会发生什么？

Charles M. Hannum：我私下所收到的雪花般的反馈都是正面的。我听说以前抛弃NetBSD的用户和开发者就是因为我列举那些的问题。甚至是FreeBSD和Linux社区的一些说明也是坑定的。读起来很有趣。有少数人要求分出一个新的项目，甚至提供帮助。那时我并没有声明这个想法。 不出所料，在NetBSD邮件列表有一点亢奋－－多数人努力站在他们的立场并争辩说没有事情是有错的。我认为最有趣的部分是一些用户明确的声明“不知道［这个组织］错在那里”，

至少这部分归咎于我；我呆了一会，并等着看在没有我的情况下这个混乱状况如何进展。我所能说的是这是十足的训练有素的破坏者－－他们不停的霸占更多的威权并把别人从各种位置上赶走，

迫使人们签署苛刻的协定，几乎所有的事情都是秘密进行的，并且没能实际提升这个项目。我感到很难想象一个开源项目有如此糟糕的管理。

题目:NetBSD的未来
到: None <netbsd-users@netbsd.org>
来自: Charles M. Hannum <mycroft@MIT.EDU>
列表: netbsd-users
日期: 2006年8月30号 19:27:23

        NetBSD项目在细枝末叶上停滞了。到了总结这个项目的缺点而不是优点的时候了。我将尝试解释这些是怎么发生的，事情的当前状况，和为了修正这种情况所需要做的事情。
做为NetBSD的四位创始人之一，我处在独特的位置上。我是唯一的仍然参与和/或看着这个项目的整个历史过程的人。
        期间发生和很多变故，并且同时很多事情依然如故－－包括我们早期的错误。
我想说的是我是个幻想家，我预见了整个OSS市场，但实际是BS。当我们启动这个项目的时候，Linux和386BSD还仅是爱好者的系统，还都有很多问题，并且它们都还缺乏很多硬件支持。我们大多数都想当然的认为:没有完整的386BSD和相应的补丁来使其可运行在更多系统上并修正bug，并且没有迹象表明Bill Jolitz将要重出江湖和做某些事情。
        由于我们早期遇到的问题，很多项目结构已经进化。也许我们最好的选择是立马使用中央版本控制；这允许可广泛的浏览代码历史并且（最终）使大量远程开发者易于协作。我们敷衍应付了一些别的事情；例如，Chris厌倦了一个人处理所有的事情，并且也将从大学毕业，所以我们创建了“核心组”。尽管这个web很新，我们很早就建立了一个web站点来宣传这个项目的信息和我们的版本。
        这个早期结构（CVS,web站点,规划等等）的很多部分是照抄很多别的开源（这时期还没广泛使用）项目－－甚至是项目名称和组的“核心”。随后这变成新开始的开源项目的模板。
        不幸的是，我们在这里犯了一些错误。从这些年看来，Linux最成功的其中一点是它有很具号召力的领导者，他设定了目标和方向，并且能够使人们做他所期望的－－或是找别人来做。后面的部分也是一个主要因素；没有任何人“拥有”Linux的任何一部分（尽管某些部分产生实际的“所有权”）；如果你不产出，那么Linus会用别人的代码。如果你希望人们使用你的代码，你必须要不断进步。
        NetBSD没有这些。部分是由于缺人，部分是因为体制问题，项目经常“冻结”。某人也许会说他们在做某个项目,别人都要提交给他们。这种项目通常会停滞，或是从没进展。如果他们真的这么做了，项目进展的促进因素会很缺乏。结果，很多重要的项目像冰川移动那样进展，或是从未实现。
        很抱歉我帮助制造了这个问题，那些大多数在NetBSD之后模仿其模式的项目（大概是NetBSD在1993和1994年太流行了）也遇到类似的问题。例如，FreeBSD和XFree86，基于类似原因，都产生了派生项目（龙飞和X.org)
        不幸的是，今天这些问题仍旧存在于NetBSD项目并且没有做任何修正。
        在此，我不是要把责任归咎于任何特定的人，而是说其中一些明显是我的过错。只是回顾我清楚的看到需要一个有影响力的领导。我10年前从事这个，事情可能已经大不同了。这就是生活。但我们还是谈论今天的状况。
        今天，项目由不同的社团运作。这是发生于2000－2001年的一个猝然改变，期间NetBSD基金会由指导委员会一个欺骗性的更改所接管。（注意:遗憾的是，由于太晚了我没能对此进行有效的修正）尽管”NetBSD项目”和“NetBSD基金会”最初规划为不同的实体－－不久代理了先前的支撑框架－－这个区别实际已经模糊，因此当前的TNF“委员会”已经紧紧控制了TNP的各个方面。
        如果TNF有一群好的领导，这种情况也许还可以接受－－尽管某些不是完美的。问题是，在这点上没有一个领导。发行版本的“目标”不是基于用户的反馈或是对未来需求的展望，而是独自根据那些浮上水面的看起来可以可能按时完成的目标。没有战略方向；如果你问“关于线程是怎样的”或“会有flash友好文件系统吗”，你最可能得到的回答是“我们够会有的”－－但是没有招募人们来编写这些东西的工作，或是鼓励现有的开发者来做这些工作。
这个空白实际上促成了这个项目当前的停滞。确实，NetBSD远远落后于太多的重要项目。线程不能真正跨多CPU运行－－甚至是在单CPU上也有bug。没有好的flash文件系统。没有日志文件系统(除了LFS,还是带有某些实验性质)。尽管已做了一些暂停支持的工作，但还是不完整的。电源管理很原始，等等。甚至NetBSD再也没有发起新硬件支持的工作；这由FreeBSD和OpenBSD来开发了，并且加快了。（我认为最近唯一例外有意义的是蓝牙支持）
        由于这样那样的原因,这个项目接近于停滞的边缘。(一些人也许想分辩说还没达到那一步，但是我尝试做到宽宏大量)这很不幸，特别是从NetBSD的使用看来--特别是在嵌入式范围内--在2000和2001年增长到一个很好的比例，即在前述的猝然改变之前。
        在这点上大多数的读者也许疑惑我是否只是给NetBSD项目写挽歌。从某方面来说，我很清楚当前存在的这个项目已经没有未来。它将继续远远的落后,并且变得更不合适。对于一个开始时有着光明前景的项目，这是一个悲惨的结束。
        我承认在这一点我可能是错的，但是我认为所有的曾经对NetBSD有贡献的人，和/或继续对NetBSD做贡献的人，不希望看到这个项目像那样堕落下去。所以我会概述我所认为的走出困境的唯一方法:
1) 必须有个有号召力的领导者,并且不是现在的这个。领导者必须真诚希望NetBSD成为领先者，引领潮流趋势的世界级系统。领导者必须制定战略目标，并且行动起来招募成员来完成它们。
2) 必须不再“冻结”项目。 只是因为人们应该从事于某个工作，这不意味着你不应当（冻结）。如果它们没有想法或是不是很理想，最好冻结！ 如果没有进展就跳过，而不要等任何人。
3) 这个项目必须任人唯贤，而不是吃大锅饭。现在，行使权力的通常是产出最少的那些人。确实，它们通常错误多余贡献，并且经常坏事。
4) 说到这里，需要负反馈来阻止人们的破坏活动。对于某些“开发者”这（搞破坏）是持续了十年的问题。
5) NetBSD架构的一批特色已终成幻影。领导人需要组织人们来重新做这些事情。其中包括：
   * 如先前提到的，线程结构的严重问题(包括用户－内核接口);
   * 很糟糕的内核模块支持;
   * 糟糕的令人讨厌的32/64位兼容性,32位应用程序在64位内核上通常不能正常工作; and
   * 由于不合适和大量使用有歧义的各种表和芯片相关的表造成的无止境的维护工作；例如在SCSI，ATAPI，IDE，ACPI和高速支持。（我实际做了不少SCSI方面的工作，但是当前还不能提交）u

6) 现在的NetBSD基金会必须解散，并由一个致力于其最初目的的组织来取代: 只处理行政问题，而不是事无巨细全揽下。额外的委员会，大多不做任何事，必须解散－－他们只会使事情更糟糕。所有事情都恢复到最初单独的实体，NetBSD项目，要由有技术特长的人来管理。基金会里必须没有可见的魅惑；必须由那些专注于这个项目和想对项目有所帮助的人组成。
(这不是由怨恨所产生的攻讦。保持NetBSD项目不拉帮结派实际上是保护了它。)
译者注：从CMH的一个专访来看，NetBSD项目里确实存在“党内有党”的问题，相互排挤，官僚主义等也是有的。）
7) 核心组必须由可胜任和贡献足够批评建议的人来担当，他们接受反馈，并作出好的决定。除此之外，核心组必须只在需要时才行动－－大多数的技术决定要由社区讨论决定；不能阻止社区开发更好的解决方案。（这就是大多数项目成长期核心组的作用）
8) 必须有一些提交标准－－例如在什么时间段内否则不接受不改变功能性的修改；多次的修补必须一次提交；等等。现在很难甄别优劣。此外，还必须有评价标准。
我要重复我之前说过的一点。当前的项目“管理”既不能修正项目的问题，也不能领导项目的解放。他们将会维持项目之前的状态，除此之外别无其它。如果这个项目拾起以前的旧烟头，“管理”必须要散伙并完全替换掉。那就没辙了。
--
我要对某些人致以歉意。现在还有NetBSD的开发者在做着很棒的工作。我很欣赏和感谢那些工作在内核锁和UVM问题的人们；无线支持；蓝牙；G5；和对ARM支持的改进。这些都是很好的工作。从大处着眼，这个项目还有很多事情要做。
--
- Charles Hannum - 昔日的创建者,开发者, NetBSD项目和NetBSD的基金会的会长和理事;NetBSD 团体的唯一所有人;NetBSD CD项目的所有人。

[我已经把本文发到FreeBSD和OpenBSD列表以和*BSD社区共享, 而不是煽动战争。我希望本文的读者能够机智地尊重它们的伙伴，并且考虑其中一些问题，也许自己也能用到]