3.30. 英文版本的“弱者道之用”

今天在Linaro BUD17上听Lwn Jonathan Corbet的演讲的时候看到的。真是个活灵活现的“弱者道之用”的构架师表述：

I have decided to fall back on the mechanism by which I ended up being maintainer in the first place. I will create a vacuum and hope somebody fills it. (Neil Brown)

某些标准组织真的有必要好好听听这个表述，你们真的是不懂。

2017-3-13补充：

这两天交流，发现还真有不少人一点感觉没有，我再解释两句。什么叫“制造真空”？你用30人维护一个开源项目，每天开发900行代码，开发一年也不过270KLoc，何况这是个极端数量，你根本不可能达到这样的开发能力，特别是在组织松散的开源组织。

所以，开源项目要发展，真正有效的方法是借力。让一同干这行的人主动把代码或者支持工作量送进来，这就是“制造真空”。成功的开源项目（的动力来源）一定不是基于“有兴趣，有志向”者的，而是基于“必须生存者”的。两者的动力根本不一样。我们企业仅仅一个硬件标准测试的团队就有上千人，这上千人是靠产品销售的毛利活着的，你一个开源项目想和这个比吗？没有这样的投资，你的开源项目代码靠什么来赢得客户实际使用时的舒适？实现随便插什么硬件板卡，内存都能正常工作？这种东西就是工作量，不是你有情怀，有能力就可以搞定的。

那么怎么制造真空呢？比如我维护一个针对专业市场A的发行版A，有5家设备提供商工作在市场A上：a，b，c，d，e。我如何维护A呢？第一种策略（一般人会选择的蠢策略，也就是我正在批评的某组织现在用的策略），强力联合[a,e]开发，从[a,e]中要人和资源，开发A和A对[a,e]的适配。这种开发需要大量的资源，需要团结，[a,e]之间还是竞争对手，这个联合组织一定程度上还是[a,e]内部团队的竞争对手，这样的组织怎么可能有力量？

第二种方法是首先联合A,a,b，开发一个平台，不用花时间在c,d,e上，用全部力量去保证平台A能解决行业A的特定关键问题。这样一来，平台A浑身毛病，但它对[a,e]有价值，有吸引力。同时A里面有“真空”，如果[c,e]加入开发，不会和A有任何竞争，因为本来就是互相帮助。

这就是真空，也就是“弱者道之用”中的“弱”。你强，牛逼哄哄的，想把别人的事情都干了，别人干什么？你何必“团结”呢？自己弄不就好了？你要团结，就要让别人有用，别人有用，你也有用，才会成为一个互补的，团结的整体，从而发挥力量。天天想着“我们的工程师是业界最牛的，我们的人越来越多”，你咋不上天呢？