最近随笔确实有点多，但生活其实不能只有代码，回头看看也需要将随笔分分类了。说回正题， BDFL 像是个政治名词，但实际上是用来指代某些开源软件的开发者，比如 Linus 、 Python 之父。说起开源，人们印象里会是更加民主的感觉，甚至是直接民主。但直接民主的开源是有问题的，用户提出的想法不能等同于需求，也未必合适于项目，因此筛选是必须的，而仁慈的独裁者在这其中拥有绝对的主导权。

在 How to Use Open Source and Shut the Fuck Up At the Same Time 这篇文章中， Eran Hammer 表达了对开源社区一种普遍的白嫖现象的愤怒。这是非常可以理解的，开源开发者在项目中投入了大量的精力，但使用者给他们的回报却很少，而且使用者对项目还提出了许多甚至苛刻的要求。如果你去观察任意一个大的开源社区的 issues ，你会发现大量重复的问题、重复的需求，以及各种不合适的建议。而用户却以使用者自居，仿佛自己是项目真正的拥有者一样。

在商业公司中，同样的问题也是出现的，但不同的，商业公司在软件工程的演进中出现了一个新的职位——产品经理。现在许多开源项目并没有产品经理，因为这个职位与开发者合并了，开源项目的开发者往往也是开源项目的“产品经理”，这就造成了一个问题，开发者不得不直接面对用户，这其实是危险的，因为繁杂的产品业务会把开发者从开发之中拉出来。

然而很多开源开发者并没有意识到这一点，他们将用户的位置看得太重了——事实上很多商业公司也没能摆脱这一点。而用户们自己也没有自觉，使用者与开发者自觉地站在了不对等的位置上。在这种情况下，仁慈的独裁者反倒显得必要了，他把握住了项目的主导，并强行将自己站到与使用者一样的位置，他使使用者意识到自己的僭越。

“僭越”一词在这里是否用的过于严重了，其实不是。用户的位置是使用者，而不是项目的拥有者，而以开发者自居，却不行开发之实的用户，就是骚扰与僭越。

问题讨论到这里其实很明晰了，开源社区真的需要 BDFL 吗？不一定，但核心开发者们一定要把握住项目的绝对主导权。开源项目与商业项目，究其本质都是软件工程，因其实践的相似性，而存在着可以互相借鉴的地方。商业公司对于需求的管理，是许多开源开发者所望尘莫及的。许多开源开发者是有意放弃在这方面的努力，最终，将自己被迫处于用户之下，这是往往是开发者自己造成的，需要开发者们自己努力。