可否通过开源协议来保护开发者权益

[驿窗project]

有一个感觉，远了，超前了，越范围了。

思考协议被违反后该怎么做、谁来做，我觉得这些问题有点远，也有点过于具体；在当下看来，我感觉这不适合在制定开源协议条款的时候来考虑，因为这不是开源协议的根本用途和目的。旗帜纲领的说法，我感觉更符合开源的文化精神，开源协议本身，应该是一个愿景，或者期望，而不是具体的执行指南。所以，我觉得可以先不考虑类似的具体问题，只看方向。

开源协议对于原创作者的限制问题，也许不应该是个问题，因为开源协议通常是无视对象身份的，至少目前流行的几个开源协议，都不豁免开源项目的具体原创作者。这里有一个重要原因，即开源协议本质上体现的是一种文化认同，无论开源协议是否对原创作者有限制，只要文化被认同，那么协议就会被认可。在文化认同的基础上展开和促进合作，这是开源协议的一个主要功能。所以，是否对原创作者进行限制，要看文化本质是否能被认同，如果不被认同，限制与不限制，都没有意义；反过来也是同样的道理。

开源项目在未来是否会发展壮大以及如何发展壮大，通常不应该成为开源思考的负担，或者说开源协议不需要为此负责。如果我们在开源项目开始创立时就考虑发展壮大的问题，那么这已经不是单纯的开源项目逻辑了，而是商业项目逻辑。以商业逻辑的方式来思考问题时，思考的主要方向就不应该是开源协议，而是商业规划。通过一定的商业规划，可以带来发展壮大；通过开源协议的文化认同，也可以带来发展壮大，二者并不矛盾，二者结合也没问题；不过，这里我们讨论开源协议的时候，商业逻辑和规划不妨先放一放，另外再讨论，先把开源协议处理一下，看看能不能在文化认同上找到一个共通点。(有一点需要补充说明的是，即这里提到的开源项目逻辑和商业项目逻辑并不指代哪一个更好，而只是讨论二者的存在基础和愿景。)

把开源协议比喻成一个可以种植东西的土地比较有趣：大家都可以种，能不能长成果实，确实不是开源协议能管的事情。我同时认为，能不能长成果实，开源协议不是不能管，而是就不应该管，能管也不应该管。我们讨论的开发者权益问题，有点像农夫，或者园丁；同样的土地同样的规则，看门人说他只喜欢女生来种植，这导致男性被全体禁止进入种植。土地还在，规则还在，但种植的情况发生了根本性变化，原本种植的物种是多样性的，现在有几个特别擅长种茄子的不能进去种了；还能进去种茄子的，和原来即不是一个品种，也不如原来的味道那么好吃了。这种变化不是当下能够马上看到结果的，需要很长时间沉淀；而我现在想阻止这种沉淀，那么，我们是不是可以尝试给看门人增加一个权力上的限制，让看门人只能看门防盗，但不能限制进去种植的人的性别，男性或女性。
这种权力限制，不是具体的限制方法或指南参考，而是在文化层面上进行定义，让大家从文化认同的角度了解一个事实，就是这个开源协议的合作氛围是期望开发者不会被区分对待，无论是种族、肤色、国籍、性别等等。

[yq-ysy]

所以，我觉得可以先不考虑类似的具体问题，只看方向。

在文化认同的基础上展开和促进合作，这是开源协议的一个主要功能。

这里我们讨论开源协议的时候，商业逻辑和规划不妨先放一放，另外再讨论，先把开源协议处理一下，看看能不能在文化认同上找到一个共通点。

这种权力限制，不是具体的限制方法或指南参考，而是在文化层面上进行定义，让大家从文化认同的角度了解一个事实，就是这个开源协议的合作氛围是期望开发者不会被区分对待，无论是种族、肤色、国籍、性别等等。

从这个角度说，我觉得解决方法：不是去修改开源协议，而是应该新创建一个“共同合作协议”。

因为“开源协议”虽然可以让大家免费获得源代码，但是依然无法避免“所有权”这个严重的问题，谁拥有这个开源项目运营的所有权，谁就是最高级别的管理者。一个人拥有权力了，他当然就会想让事情往他所希望的方向发展，然后就会排除不符合他预定方向的那个人。

“共同合作协议”——排除“项目的所有权”，只需确立一个目标，只要你认同这个目标，就过来和我和大家一起来努力。如果你不认同这个目标，你也可以另外建立一个目标，等待别人加入你的阵营。

“共同合作协议”与“开源协议”的不同是：
——如果你想加入某个“开源协议”下的开源项目，你要找的是“人”，是谁拥有这个项目？由他来决定是否使用我写的代码。
——如果你想加入某个“共同合作协议”下的开源项目，你要找的是“目标”，这个目标是否与我的理想相同？由“是否有利于这个目标实现”来决定是否使用我写的代码。

当然，提交上来的这段代码“是否有利于这个目标实现”，这也是需要“人”来判断的，即使组建一个专业的、民主的、纯技术的评委团队，也是会出现争执的。解决办法一是投票，二是搞分支，限定时间看后续发展再作裁定。这样也许能在一定程度上避免“独*裁”，但相对的，效率可能会低一些。

说到“发展方向”的争执，Ubuntu桌面的选择，就是一个典型的例子，当年大家都是为了Ubuntu能更好地发展，目标相同了，然后想改进桌面（根窗口管理器），更换为Unity好？还是在原本的Gnome2上改进好？后来的结果大家都看到了。但你说如果当年不这样做，情况就一定会比现在好？也不一定吧。

所以啊，要想改变命运，需要逆着树枝来寻找“根源”，这样力量才强大。如果像普通人一样顺着树枝去“攀缘”花朵果实，那就会越走越窄，枝条越来越细，力量也就越来越弱了。——夫物芸芸，各复归其根。归根曰静，静曰复命。

[yq-ysy]

所以，我觉得可以先不考虑类似的具体问题，只看方向。

在文化认同的基础上展开和促进合作，这是开源协议的一个主要功能。

这里我们讨论开源协议的时候，商业逻辑和规划不妨先放一放，另外再讨论，先把开源协议处理一下，看看能不能在文化认同上找到一个共通点。

这种权力限制，不是具体的限制方法或指南参考，而是在文化层面上进行定义，让大家从文化认同的角度了解一个事实，就是这个开源协议的合作氛围是期望开发者不会被区分对待，无论是种族、肤色、国籍、性别等等。

从这个角度说，我觉得解决方法：不是去修改开源协议，而是应该新创建一个“共同合作协议”。

“共同合作协议”——排除“项目的所有权”，只需确立一个目标，只要你认同这个目标，就过来和我和大家一起来努力。如果你不认同这个目标，你也可以另外建立一个目标，等待别人加入你的阵营。

《中国同巴西、南非、非盟共同发起“开放科学国际合作倡议” 》
消息来源：
http://www.xinhuanet.com/20241121/d6a10 ... a9d/c.html
https://www.most.gov.cn/kjbgz/202411/t2 ... 92516.html
2024-11-21

新华社北京11月21日电（记者张泉、温竞华）记者从中国科技部获悉，中国同巴西、南非、非盟共同发起“开放科学国际合作倡议”，旨在携手构建开放、公平、公正、非歧视的全球科技发展环境，推动全球科技创新成果更多惠及“全球南方”。倡议全文21日正式发布。

  倡议指出，开放、可持续的科技创新，有利于促进全球经济实现强劲、可持续、平衡、包容增长，加快落实联合国2030年议程，事关全人类共同福祉。

  倡议提出，各国政府、科学共同体、企业、非政府组织等利益攸关方，共同推动落实联合国教科文组织《开放科学建议书》，支持科技创新人员和资源等在全球范围内自由流动，确保不同利益攸关方公平参与开放科学事业、受到公正对待。科学知识应公开可用，科学实践应具有多样性、包容性、可持续性。

  倡议提出，各国政府应增加对开放科学的投入，营造有利于开放科学发展的政策环境和投资环境，推动重大科研基础设施合作共建、开放共享，厚植开放科学文化，加强开放科学人力资源开发，帮助“全球南方”加强科技能力建设。

好巧，想法不谋而合。

协议是可以有，但后续如何执行和管理，这依然绕不开“人的权力”问题。
说白了，就是看这个人有没有“包容天下”的肚量，犹如大海。

观彼巨海，有八美德：
一德、海阔深空。
二德、海定潮期。
三德、海不容腐。
四德、海怀众珍。
五德、海纳百川。
六德、海无消溢。
七德、海孕圣相。
八德、海性均中。

或许还有一个方法：用 AI 来执行和管理“共同合作协议”下的项目。
当然 AI 的最初模型也是由人来定制的，日后也会有人对 AI 进行修改，但这也让“人为干涉项目”的门槛和难度大大增加了。

[驿窗project]

——如果你想加入某个“开源协议”下的开源项目，你要找的是“人”，是谁拥有这个项目？由他来决定是否使用我写的代码。

这个情况，方便更具体说明么？

我反推了一下，结果还是文化层面的，即开源协议提供的主要是文化认同，而不是人格认同。或者说，文化认同远大于人格认同。基于此，我感觉“共同合作协议”与开源协议没有特别明显的区别。

ps:
对于所提到的“所有权”，为防止看贴的人产生误解，我这里澄清一下：开源软件从开源协议发布的第一天起，代码的所有权就已经被确定，即它已经不被某个权力人所有，而是被遵守协议的所有人拥有。后续权力人所表现出的权力，与“所有权”不是一回事，其权力主要基于以下几个因素：

1. 人事管理权：这是项目必须存在的一个角色，目前没有哪个项目可以取消此角色。而由于人事管理权通常是项目发起人天然拥有，所以导致可能有人误认为项目发起人也同时具备项目的“所有权”，其实不具备“所有权”，任何遵守协议的人都可以把项目据为己有，只不过，是否有能力和有人流量来继续推进手里的项目，需要另外考量。
2. 惯性：这是项目长期运行所带来的，比如工作习惯：项目运行规则、邮件列表、论坛、聊天室等等，所有这些，让参与的“人类”已经产生了一定的习惯，这种情况下，即使项目出现了一些文化问题，这种人类习惯也会促使项目继续运行。这种继续运行不是“所有权”带来的，是项目运行的惯性带来的。企业则不同，绝对的权力可以无视惯性从而无条件结束项目或修改项目，而开源项目通常不具备这样的绝对权力，或者不会轻易行使这样的绝对权力。
3. 认同与将就的权衡：项目出现问题时，参与者会权衡，即使不认同，也会考虑一个问题，即是否有必要new fork；因为new fork除了new以外，还要对抗原项目的运行惯性，这种对惯性的对抗需要积累和沉淀才有力量，更简单实用的是将就，而将就导致项目在有问题的情况下能够继续运行。

(原文已经对所有权三个字加了引号，这里对引号进行一下说明)

[yq-ysy]

——如果你想加入某个“开源协议”下的开源项目，你要找的是“人”，是谁拥有这个项目？由他来决定是否使用我写的代码。

这个情况，方便更具体说明么？

例如，之前我说过的，我希望我的“单手笔顺输入法”能在ibus-table上运行，所以我就在网上找ibus-table开源项目。
先在ibus输入法软件的“帮助——关于ibus”里看到了开发者的名字acevery，然后就github上找到acevery的ibus-table项目，
https://github.com/acevery/ibus-table
给他发了信息，没有回复。再看这个项目已经十几年没更新了，好吧，看来作者是放弃维护了。
但是Ubuntu一直在用ibus呀？现在是谁在维护呢？各个Linux发行版使用的这个ibus项目是谁在维护呢？
然后我就在acevery的ibus-table项目的Fork里慢慢一个一个人查看，就终于发现了mike-fabian这个人。
https://github.com/mike-fabian/ibus-table
他的ibus-table项目在频繁更新，然后给他发信息，他在百忙之中也给予了回答。只可惜他也没实现我的愿望。
那时也发现了一个ibus-table-chinese项目，也是好多年没更新了，给作者发信息也没回复。
https://github.com/definite/ibus-table-chinese

ps:
对于所提到的“所有权”，为防止看贴的人产生误解，我这里澄清一下：开源软件从开源协议发布的第一天起，代码的所有权就已经被确定，即它已经不被某个权力人所有，而是被遵守协议的所有人拥有。

这里推荐一篇来自于中华人民共和国最高人民法院官方网站的指导文章：
《开源协议适用范围及其对软件著作权侵权判定的影响》
https://ipc.court.gov.cn/zh-cn/news/view-842.html

其中最后一段明确说到：

开源不是免费的午餐，开源软件不是公共领域软件，其享有著作权并受著作权法保护，不可以任意使用。开源软件的著作权人通过开源协议将开源软件的复制权、修改权、发行权等部分权利许可给了使用人，但这种许可是附条件的，被许可人只有在遵从开源许可协议规定的前提下，才可以行使这些权利。

其中（二）开源协议的适用范围 明确说到：

从许可行为来看，开源协议有着严格限制，如GPL协议就不适用于复制、发行和修改以外的行为，因为超越了许可范围。

所以，如何管理一个开源项目，这不是开源协议的可控范围。
因此，我上一帖才建议另外搞一个“共同合作协议”，然后借用AI的自动化管理，来尽量避免偏离原定目标的人为干涉。

[guanchayuan2018]

有一个感觉，远了，超前了，越范围了。

思考协议被违反后该怎么做、谁来做，我觉得这些问题有点远，也有点过于具体；在当下看来，我感觉这不适合在制定开源协议条款的时候来考虑，因为这不是开源协议的根本用途和目的。旗帜纲领的说法，我感觉更符合开源的文化精神，开源协议本身，应该是一个愿景，或者期望，而不是具体的执行指南。所以，我觉得可以先不考虑类似的具体问题，只看方向。

开源协议对于原创作者的限制问题，也许不应该是个问题，因为开源协议通常是无视对象身份的，至少目前流行的几个开源协议，都不豁免开源项目的具体原创作者。这里有一个重要原因，即开源协议本质上体现的是一种文化认同，无论开源协议是否对原创作者有限制，只要文化被认同，那么协议就会被认可。在文化认同的基础上展开和促进合作，这是开源协议的一个主要功能。所以，是否对原创作者进行限制，要看文化本质是否能被认同，如果不被认同，限制与不限制，都没有意义；反过来也是同样的道理。

我觉得，不是超范围了，而是我们讨论问题的时候混淆了两个范围：开源协议和开源项目。

从许多开源项目都适用于同一个开源协议来看，我们必须明确，开源项目不等于开源协议。因此，某个或某些开源项目出现了问题（包括驿窗提起本题的原因）不等于开源协议出现问题，更可能是这个项目本身或者权利人/管理人出现问题。

所以，我们讨论的对象更应该是针对出问题的项目或权利人/管理人，而不是针对开源协议。

[guanchayuan2018]

为了弄清楚问题的本质，我在网上搜索了GPL协议，或者叫GNU通用公共许可证，也搜索了自由软件（free software)、开源软件（Open Source Software）以及免费软件的区别和联系。

在搜索过程中，也发现了引起本题原因的关联概念：主要贡献者名单，以及自由软件基金会的贡献者许可协议。但大概是我水平不够，没有搜索到具体内容。

下面说一说我搜索到的情况（不管多么基础，但我确实第一次看的这么清楚，因此，小白可以继续读，资深大牛请绕路 ）：

1、GPL协议中，0条款明确了“许可证条款不适用于复制，发布和修改以外的活动。”
2、GPL协议中，1条款要求软件使用者在复制、发布软件时必须“在每一幅本上明显和恰当地出版版权声明和不承担责任的声明”且“保持此许可证的声明和没有担保的声明完整无损”，以及之后多个条款提到“原许可证颁发者”“作者/捐献者”“许可证持有人”“原始版权拥有者”“版权所有者”这些名词。还有9条款“自由软件基金会可能随时出版通用公共许可证的修改版或新版。新版和当前的版本在原则上保持一致，但在提到新问题时或有关事项时，在细节上可能出现差别。”

所以，GPL协议适用范围是保护版权以及软件的自由复制、发布和修改权，不包括驿窗想要提到的“除名开发人员”，且，GPL协议的修改权在自由软件基金会，而因“新版和当前的版本在原则上保持一致”，故自由软件基金会接受修改提议的可能性不大。

至于前面提到的“所有权”，我认为它的本意是指版权，在国内叫著作权。对于软件，著作权包括人身权和财产权两个大类，其下各有许多具体权利。
对于通用公共许可证，可以理解为版权人保留署名权，之后对不特定多的人附条件许可复制权、修改权、发布权。

关于驿窗的想法，我觉得需要看自由软件基金会的贡献者许可协议有没有明确条款，或者看具体开源项目有没有自己的贡献者/开发者文件，是否有明确条款。
然后才能根据具体情况，讨论提议增加或修改条款的问题。

3、GPL协议中，10条款“我们的决定受两个主要目标的指导。这两个主要目标是：我们的自由软件的衍生作品继续保持自由状态，以及从整体上促进软件没有担保的共享和重复利用。”

所以，GPL协议针对的重点是软件，而不是人，不管是作者还是贡献者。

4、GPL协议中，8条款“如果由于专利或者由于版权的接口问题使程序在某些国家的发布和使用受到限制，将此程序置于许可证约束下的原始版权拥有者可以增加限制发布地区的条款，将这些国家明确排除在外。”

这个条款倒是针对的国家，但原因是软件在这些国家受到限制，原始版权拥有者才可以限制软件在这些国家发布，并不是因为贡献者国籍是这些国家而对其除名。

[guanchayuan2018]

——如果你想加入某个“开源协议”下的开源项目，你要找的是“人”，是谁拥有这个项目？由他来决定是否使用我写的代码。

ps:
对于所提到的“所有权”，为防止看贴的人产生误解，我这里澄清一下：开源软件从开源协议发布的第一天起，代码的所有权就已经被确定，即它已经不被某个权力人所有，而是被遵守协议的所有人拥有。后续权力人所表现出的权力，与“所有权”不是一回事，其权力主要基于以下几个因素：

1. 人事管理权：这是项目必须存在的一个角色，目前没有哪个项目可以取消此角色。而由于人事管理权通常是项目发起人天然拥有，所以导致可能有人误认为项目发起人也同时具备项目的“所有权”，其实不具备“所有权”，任何遵守协议的人都可以把项目据为己有，只不过，是否有能力和有人流量来继续推进手里的项目，需要另外考量。

我觉得你们两个讨论的问题不再一条线上 这涉及到一个权利，发布权，以及发布人。

一善鱼说“由他来局鼎是否使用我写的代码”的意思是：将“我”写的代码加入到程序中，由“他”来发布，我只是代码贡献者，不是发布人，更不是版权人（所有人）。

驿窗说“开源软件从开源协议发布的第一天起，代码的所有权就已经被确定，即它已经不被某个权力人所有，而是被遵守协议的所有人拥有”。“所有权已就经确定”这里的所有权应该指的是版权（或署名权），而“被遵守协议的所有人拥有”应该指的是占有权，或者说复制权、修改权、发布权。
注意，在我国民法理论中，所有权是绝对权，是对世权，它包含四个权能：占有、使用、收益、处分。所有权对于其他任何民事权利都有优先性。

“任何遵守协议的人都可以把项目据为己有，只不过，是否有能力和有人流量来继续推进手里的项目，需要另外考量”这里的“据为己有”指的也是占有权（复制、修改、发布），而不是所有权或版权，“是否有能力和有人流量继续推进手里的项目”就涉及到发布权了---想继续推进项目就需要发布，如果将自己写的代码加入到程序，1、以自己的名义发布，则需要符合两个声明及修改说明的要求，可以对自己修改的那部分代码享有所有权/版权，但原代码的所有权/版权仍属于版权人，这样可以看成是原程序的分支；2、不以自己的名义发布，则可以看成是对原程序版本的维护或分支，对原程序不享有所有权/版权，并且，对于版权人来说，可能连代码贡献者都算不上，因为版权人更新程序时，可能不会将这些代码加入进去。（这些都是我自己的观点，不代表事实，可能事实与我说的不一致）

所以，驿窗理解的“所有权”是不准确的。

[驿窗project]

上面的几层讨论，我基本都赞同，这里摘选一下。

开源项目不等于开源协议 所以，我们讨论的对象更应该是针对出问题的项目或权利人/管理人，而不是针对开源协议。
GPL协议针对的重点是软件，而不是人，不管是作者还是贡献者。

二者确实不等同，所以我想探索一下，看开源协议是否能限制/保护软件之外的人，而不仅仅是软件代码。

关于驿窗的想法，我觉得需要看自由软件基金会的贡献者许可协议有没有明确条款，或者看具体开源项目有没有自己的贡献者/开发者文件，是否有明确条款。
然后才能根据具体情况，讨论提议增加或修改条款的问题。

我没打算修改GPL协议。我的想法是，我们可以起草新的开源协议(或补充)，让将来的开源项目有更多的协议选择，或者说，有更多的文化选择。(这么说比较保守，因为国藉歧视有时候想想其实很严重。)

如果你想加入某个“开源协议”下的开源项目，你要找的是“人”，是谁拥有这个项目？由他来决定是否使用我写的代码。
所以，驿窗理解的“所有权”是不准确的。

确实，我只用“所有权”来描述开源项目的权利问题，有点过于简化了。更详细的表达应该是，在协议范围内不受限制地使用软件代码的权利。
我参与开源项目，多数是因为想让使用该开源软件的用户更方便，比如开源软件汉化得不好，那么我可能会想参与汉化改进汉化。诸如此类。


现在想想，天安门城楼上的“世界人民大团结万岁”，是不是只有中国才有这样的胸怀……

[yq-ysy]

《FFmpeg社区的鸡飞狗跳和生死存亡》
https://zhuanlan.zhihu.com/p/20969650273
摘录部分如下：

表面上，FFmpeg社区是按照民主的方式行事，实际上，社区还是按照一套终身仁慈独裁者的方式行事。
Michael虽然辞去了leader角色，但是FFmpeg的服务器、域名等基础设施在他手上。

另一边，社区一些成员反对Michael独断专行：
FFmpeg和libav合并的基础是按照民主的方式管理社区。社区的运行规则经过商讨、投票，写在FFmpeg代码仓库里。
Michael的行事风格，导致许多人不认可他的leader角色。

剩下的事就是吵架，吵的鸡飞狗跳。Michael这边说你们只是想夺权，另一边说我们只是要按照约定由GA行使最高决策权，互相猜疑，没法沟通。Michael的追随者Nicolas George说：“Democracy was just a bad idea, for that very reason among others, let us drop it.” ……Michael自己一方面坚持final decision的权力，一方面说要民主，让所有加入FFmpeg邮件列表的几千人有投票权。

从我个人角度来说，我不介意用终身仁慈独裁者的方式还是民主的方式管理社区：只不过几十号人，又不是上亿人。有很多开源项目，典型的如Linux，按终身仁慈独裁者的方式运行的很好。但我对Michael是否胜任leader角色存疑。……Michael对FFmpeg的贡献毋庸置疑。……但遇到非技术问题，或者非底层技术细节的事，他的表现就不太明智了。

所以形成了一个正反馈系统：反对声音越强，Michael越没有安全感，越是做出一些出格的事；出格的事越多，反对声音越强。……社区是基于信任，不管是终身仁慈独裁者的运行模式还是民主的运行模式。猜疑来猜疑去，迫害妄想症的行事风格没法让社区运行下去。

Anton一怒之下离开了社区，……另外还有两个开发者离开，Derek Buitenhuis和Paul B Mahol。……目前看不到社区恢复正常的希望。Michael对项目拥有绝对控制权，吵到最后大概是更多开发者出走，FFmpeg失去活力，只做bugfix——死而不僵。

[驿窗project]

你说的FFmpeg的这个事情，可能比较有典型意义。
技术能力强，对管理能力其实没有多少加成，所以技术能力强的人做管理时，时间久了后出现问题是常见情况，尤其对于松散组织结构的情况。
并且，技术人才通常比较敏感，而技术本身其实不太擅长处理来自管理方面的敏感事件，这导致基于技术背景来处理管理类问题，即可能出现技术外的出格的情况。

有兼具两种能力的人才是理想情况。成熟的开源组织或社区，应该充分考虑如何平衡这个问题。
(避免：一个光环加身后全面成神；反之，一个污点出现后就全面成魔)

[anth]

以linux内核 ish和sqlite这三个项目为例 项目由一个独裁者掌控远远优于民主决策 至少软件领域是这样 与其费尽心思考虑协议 不如考虑考虑自己能否成为这么一个独当一面的独裁大佬 假如不行 那么你可以选择加入你好我好大家好的团队 也可以加入大佬一言九鼎的团队 你觉得哪个团队更靠谱一些呢

[驿窗project]

独裁模式对于开源软件项目的优劣，我没有对比过，不过我大概研究过debian和红帽(IBM收购前)的模式，它们能够被很多人选择并延续下来，独裁成分的贡献相对比较少，民主成分的贡献相对比较多；或者说，"囗囗"的本质可能是以信仰的方式被具体表现出来，但这种情况下，"囗囗"在本质上是否仍然是独裁，已经不太好界定。

所以，目前我对于独裁模式的理解是，它可以用企业文化来类比，而企业文化有一个说法，就是小企业做事，大企业做人。开源项目是否需要独裁，或者选择独裁是否优于选择民主，有可能与项目本身的特性有关。从失败是成功之母的角度来说，成功的项目不应该是最广泛研究的对象，而失败的项目才应该更广泛地研究，这样能更明确地体现某个影响因素好与不好的具体原因。