天下没有白来的午餐，天上不会随随便便掉馅儿饼，除非有足够的利润驱使，否则绝不可能有人投钱做这些事情，因为资本家并不是慈善家；如果让一群志愿者去做事，那么一定需要是他们感兴趣的事情，反之，就一定要有资金支持。
国内在FreeBSD上进行投资的企业，当然，我想也包括国外的企业，基本上都符合下面的几个条件：
0) 这家企业使用FreeBSD来支持其基础业务，并且这些基础业务使用FreeBSD来支撑的综合成本低于或等同于使用其它系统
1) 这家企业有足够的流动资金来支持其员工进行这方面的研发，并为其提供很好的环境来完成这些工作；这些公司也不介意其员工将所做的改进回馈给开源社区
2) 这家企业有支持 *BSD 发展的远见(换言之，做决策的人受商业广告或鼓吹手的**必将战胜***的影响很小或根本没有，而去自行作出适当的判断)，或者，至少出于“不把鸡蛋都放在同一个篮子里”的想法
国内有这样做的公司并不多。我个人认为也没有必要去要求一家企业这样做，因为东西做得好，用的人自然会逐渐增长。
选择*BSD的几大理由：
高水平的参与者
我还是要说，出现4个主要的BSD分支的原因绝不是什么BSD授权“过于宽松”导致的(这么说的人不妨去fork一个他们喜欢的，哪怕仅仅是kernel试试看，是不是一个月就得累得吐血？)，*BSD拥有大量非常高水平的开发者，有能力去fork并维持开发一个也许风格迥异的分支，去证明他们自己的实力；*BSD中也有很多同时参与多个项目的开发人员，仅从commit bit看，就有例如IAB委员Jun-ichiro \"itojun\" Hagino (OpenBSD+NetBSD+早期FreeBSD)、M. Warner Losh (FreeBSD+NetBSD)、早期TCP/IP协议栈的开发者Jeffrey Hsu (华裔、FreeBSD+DragonFly)，等等。如果仅从活跃参与看，Mach VM的主要继承和维护者Matthew Dillon(FreeBSD+DragonFly)、BSD教父级人物Marshall Kirk McKusick(所有*BSD)、著名*BSD hacker Poul-Henning Kamp(FreeBSD+NetBSD)等等，都在活跃地参与*BSD的开发。
在开发团队中，突然发现某个人竟然是IEEE/ACM委员(注意，不是IEEE Member)、教授或者某相关专业的PhD的概率非常高。这些人不仅有相关领域的广博知识，而且也对操作系统开发和架构具有丰富的经验。
FreeBSD core team成员Robert Watson曾在一次访谈中提到，尽管自己已经加入FreeBSD的committer团队5年以上，但仍然时时刻刻感觉自己依旧是一个新手，因为每天仍然能够从整个团队的那些，可能有超过20年开发经验的开发人员那里学到新的东西。任何人想要成为任何一个BSD的committer的话，开发团队都会要求有一个mentor(“导师”)来指导这个人头几个月，甚至前半年乃至一年的commit操作，而这个mentor给你写的第一封信就会简单地介绍那些非常有经验的开发者，并鼓励将涉及他们专业领域的代码在提交mentor复审之前或同时也发给他们，让他们帮忙看一看。良好的开发传统使得*BSD的开发人员品质能够不断提高。开发团队除了非常多专长于某一领域的专家之外，还有很多熟悉整个操作系统架构的，也许写过我们大学教材的人来阻止不正确的代码或设计进入系统，并在实际编写代码之前帮助完善设计。
良好的开发传统、严谨的开发习惯和正确的开发流程
开发传统和习惯对于软件的品质至关重要。所有的*BSD从项目开始的第一天开始，就从BSD上继承了良好的开发传统。没有任何一个主要的*BSD系统不使用CVS，代码的每一行是从哪来的、因为什么这样写，都可以随时在全球的数百个CVS[,up,sync,web]镜像上查阅。开发团队的每个人在每一次代码改动时都会收到通知邮件，除此之外，所有的*BSD开发团队还鼓励事前的同组复审(peer-review)和监护人复审(maintainer-review)，以便最大限度地保证代码品质。
尊重统一的代码编写习惯是所有*BSD的共识。NetBSD和OpenBSD直接继承了来自UC Berkeley的BSD KNF(\"内核代码范式\")，在FreeBSD和DragonFly上，这一规范被称作style(9)。对于代码的持续清理，使得代码的可读性和品质有了更大的改善。
更为重要的是，*BSD的开发流程有正确的交付工程步骤。从代码冻结、集中复审、测试、修正问题、交付的过程看，每一个RELEASE都会成为最近一个阶段这一分支上最为稳定可靠的版本。修正bug时，所有*BSD都鼓励编写衰退测试案例(Regression Tests)，使得交付工程组能够对新的RELEASE中是否有引入了之前发现过的问题进行集中而有效的测试。*BSD从不赶日期推出RELEASE，如果一个RELEASE有问题，甚至不惜把公告前已经发出的.iso文件全部销毁，或甚至将已经打过tag的版本取消并推出另一个版本以避免混淆。
重视安全、尊重别人的版权、高品质的代码
*BSD非常重视安全，从不故意掩盖安全问题。最近几年曾经有一次，FreeBSD的Security Officer发现有一个问题在数月前有人在重写一个函数时无意中修正了一处安全问题，结果也发布了一个安全公告。“将风险告知用户”是*BSD通行的做法，所有的*BSD的安全页面都会写上这么一句话：“[某个BSD]的Security Officer欢迎[经过一定时间延迟的]对安全问题的彻底揭露”，因为我们相信，昨天发现的一个安全弱点，在今天就会成为一个实实在在的安全威胁。在第一时间修正问题并发布安全公告，有助于帮助用户及时修补问题、规避风险。
除了“亡羊补牢”的安全公告之外，*BSD更重视未雨绸缪的安全防范。在配置方面，目前默认安装的*BSD都不开放任何有安全隐患的服务端口。在代码方面，*BSD严格的代码复审机制(在2001年前后，*BSD做了一次统一的代码复审工作；而新加入的代码则被所有人复审)，以及持续不断的安全改进，特别是来自OpenBSD的特权分离等安全措施和理念，使得*BSD得以成为最为安全的系统。2004年公布的TCP RST攻击，当所有厂商都在补漏洞和发布补丁时，只有OpenBSD按兵不动——因为那个问题早已在1999年就被这些执着的安全狂热分子修正了。
当你听说一个rsync远程漏洞的时候，在FreeBSD上面，做过非特权化，或者说，默认设置时最严重的后果是“可能让rsync服务崩溃”，而在其他系统上面，则是“靠！被人root了！！”——因为那些人即使只维护一个kernel，也是在不停地往里引入安全问题的。
和重视安全的*BSD形成鲜明对比的是，某个kernel的项目领导者，在HTT安全漏洞被发现时，竟然采取鸵鸟态度，声称“这是OpenSSL的问题”，并阻止别人修正这个问题。此前，这个人还多次悄悄修正安全漏洞，并借助那个kernel不大力公布开发过程中进行的修改，而避免公众注意到安全漏洞的存在。具有讽刺意义的是，正是由于鸵鸟政策，使得这个总在指责Windows如何不安全的团体，在每个季度出现的内核级特权提升漏洞，能够达到Windows一年全部漏洞的一半之多。
尊重别人的版权是*BSD的另一个显著的特点。早期，由AT&T的Unix系统实验室(USL，目前这个实验室在SCO，历史总是重复的 8) )对BSD的诉讼曾经使开发停滞近一年之久。然而，由于BSD严谨的开发习惯，使得它得以通过代码历史向法庭证明自己的清白，并要求对方重印所有的抄袭BSD代码而未给出适当署名的说明书，并最终达成和解：USL及其继承者永远不得起诉*BSD。
这之后*BSD更为重视尊重版权。每一个committer都有责任确保大段代码来源的纯洁性，使得使用*BSD代码成为规避知识产权风险的一项非常好的途径——只要尊重BSD授权的署名要求，就可以自由地使用代码。BSD授权通过简单的两条条件和两项声明，有效地确保了代码使用者的自由，以及确保代码不发生被窃取并只以*PL授权重新发布的问题(使用*PL授权并同时以BSD授权发布文件的双授权做法是符合授权的，但删除BSD授权并只以*PL授权发布则违反授权，有意思的是，某个kernel经常这样做，并最终导致同是大段抄袭BSD代码的SCO公司的起诉威胁)。
使用*BSD意味着能够规避信息安全和知识产权两方面的困扰。*BSD尊重使用代码并对其进行改进的人的意愿，不强迫别人开放源代码，因为*BSD的开发者认为设计要比实现更为重要，而开放不开放源代码并不能阻止他们通过测试去了解设计。
对于技术的执著追求
*BSD的开发人员很多在各大高校从事操作系统的研究工作，因此其开发具有很大的前瞻性，并不为那些并不懂技术的所谓“最终用户”随意左右。*BSD每设计一个新的结构，往往能够被广泛接受，并用上很久，而不是几个月大换血一次。为*BSD开发驱动程序，即使不开放源代码，也不必担心随*BSD的版本升级而不得不重新写一遍——当然，开放源代码意味着整个开发团队能够对这些驱动进行更好的优化——在台湾，已经有一位开发人员获得了src/ tree的commit bit，除了已经在做的WiFi工作之外，他也将作为那家硬件厂商在FreeBSD的联络人，帮助他们的硬件更好地在FreeBSD上使用；而在国外，在*BSD社区的努力下，包括Adaptec、LSI、Intel在内的许多大公司，更是鼓励员工为*BSD撰写驱动。
它是一个随你的需要和贡献而成长的系统
*BSD重视，但并不放纵开发人员。新的OpenBSD上提供了包括ProPolice、W^X等辅助手段帮助发现代码中的潜在问题和阻止缓冲区溢出攻击；新的FreeBSD上则提供了一系列帮助发现代码中潜在问题的选项，这些为内核开发人员提供了很好的“防护网”，阻止他们写出有问题的代码。
在*BSD上也提供了许许多多的开发工具和辅助的调试工具。任何人都可以为*BSD编写代码，即使这些代码最终没有被接受，也会有人告诉你为什么，甚至帮你写一份更好的版本。为*BSD开发程序，能够认识很多高水平的人，也有助于自己的学习和提高。
阅读(1983) | 评论(0) | 转发(0) |
