找回密码
 立即注册
首页 业界区 安全 读开源项目成功之道05治理和托管模式

读开源项目成功之道05治理和托管模式

枢覆引 5 小时前

1. 治理和托管模式

1.1. 开源的理念源自黑客社群,他们看到了现有软件生产和使用方法中的问题
1.2. 拥有有效的治理模式是长期成功和可持续发展的关键
1.3. 开源治理旨在为社群提供类似的清晰度,并为项目的运作奠定了基础
1.4. 项目的需求和社群的文化会随着时间的推移而改变,调整治理模式以支持这些需求能够确保得到支持并提升参与度
2. 开源治理

2.1. 开源治理就是开源项目需要具备的流程和政策,以使开源项目能够正常运行

  • 2.1.1. 项目如何接受代码?
  • 2.1.2. 项目如何发布代码更新?
  • 2.1.3. 由谁决定哪些代码可以进入项目,哪些代码不可以?
  • 2.1.4. 需要做什么才能为项目贡献代码?
  • 2.1.5. 项目如何处理问题?
  • 2.1.6. 如何解决和披露安全漏洞?
  • 2.1.7. 谁可以作为项目代言人?
  • 2.1.8. 谁拥有项目的名称、作品和其他资产?
2.2. 行动至上

  • 2.2.1. 最基本的治理模式是由实际做工作的人驱动的,这通常被称为“行动至上”

    • 2.2.1.1. 精英治理

  • 2.2.2. 开源通常是由其用户和贡献者驱动的
  • 2.2.3. 许多人是有偿从事开源工作的,但他们的报酬是由那些希望看到特定项目成功的人支付的
  • 2.2.4. 行动者需要解决各自的问题,可能会存在冲
  • 2.2.5. 行动者在做事效率上有些起伏不定,导致代码仓库中的某些部分发展得更快,而其他部分则停滞不前。从外部看,​“行动至上”的项目往往
  • 2.2.6. “行动至上”的项目往往看起来像是封闭的俱乐部,这会给新加入者带来挑战
2.3. BDFL

  • 2.3.1. 终身仁慈独裁者(Benevolent Dictators for Life,BDFL)模式
  • 2.3.2. 当项目陷入冲突或困境时,我们经常看到他们回头寻求创始人的指导
  • 2.3.3. 在关键决策方面也会尊重他们的意见
  • 2.3.4. 项目的文化从一开始就与创始人的愿景一致
  • 2.3.5. BDFL可以是项目从一开始就采取的一种治理模式,也可以从前述的“行动至上”模式演变而来
  • 2.3.6. Rasmus Lerdorf于PHP,Linus Torvalds于Linux,Guido van Rossum于Python
  • 2.3.7. 在BDFL中,治理是一把双刃剑

    • 2.3.7.1. 许多成功的项目都有谦虚、包容和富有创造性的创始人领袖,他们帮助设定了社群运作的积极基调
    • 2.3.7.2. 有一些项目则存在分歧,导致项目出现分支

  • 2.3.8. 即使有最好的BDFL,仍然会面临所有决策都要通过一个人的瓶颈问题

    • 2.3.8.1. Linus也意识到了这一点,因此他在Linux中设立了几个关键维护者来分担工作,毕竟Linux内核每天都有数千行代码的改动

2.4. 技术委员会

  • 2.4.1. 创始人的角色充满挑战,问问任何一个创建过公司的人就知道了
  • 2.4.2. 创始人也很难判断何时该下放权力
  • 2.4.3. 创始人通常对公司的运营和形象塑造有着敏锐的眼光
  • 2.4.4. 创始人会意识到他们需要让其他人来处理组织中的一部分工作
  • 2.4.5. 帮助项目建立一个技术指导委员会(Technical Steering Committee,TSC)

    • 2.4.5.1. 可以作为一个团队来领导项目,而不是仅仅依赖一个人

  • 2.4.6. 如何让人们能够主动承担领导角色
  • 2.4.7. 许多技术人员更热爱技术本身,而对领导的官僚作风不太感兴趣
  • 2.4.8. 作为创始人和领导者,需要吸引更多人参与进来,通常也包括社群中那些愿意主动承担领导责任的人

    • 2.4.8.1. 也是自我任命的委员会治理的核心意义

  • 2.4.9. 技术委员会是“行动至上”理念的正式化,旨在构建一个可持续发展且没有独裁领导的项目

    • 2.4.9.1. Apache软件基金会、学院软件基金会、LF AI和Data基金会以及LF能源基金会中的许多项目都是如此
    • 2.4.9.2. 最初开发者对一个项目产生兴趣,然后挺身而出逐步领导项目

2.5. 选举

  • 2.5.1. 社群会开始寻求更加民主的方式来治理,这就引出了选举类型的治理模式
  • 2.5.2. 选举治理模式是从技术委员会模式演变而来的,其中相应角色是选举产生的而不是自我提名的
  • 2.5.3. 通常发生在项目中个人和公司之间出现利益冲突时,并且项目需要确保决策是公正和公平的,为了解决这个问题,项目成员会进行选举
  • 2.5.4. 可以用来选出领导者,他们将在一定期限内任职
  • 2.5.5. CNCF的技术监督委员会(Technical Oversight Committee,TOC)就是这样做的,并制定了正式的选举程序和时间表

    • 2.5.5.1. 确保领导者定期轮换,这不仅有助于为项目带来新的想法和观点,还有助于确保避免领导者因为觉得无法离开项目而筋疲力尽

  • 2.5.6. ApacheWay的一个关键原则之一是共识决策

    • 2.5.6.1. ApacheWay的一个关键原则之一是共识决策
    • 2.5.6.2. 通过针对一个问题征求−1、0或+1的投票来实现,如果有人投了一个−1的票,就需要他们提出一个替代解决方案,或者详细解释为什么他们投反对票
    • 2.5.6.3. 好处是它为建设性的分歧意见提供了空间,并帮助形成了一个包容各方反馈的建议

2.6. 单一供应商

  • 2.6.1. 这种治理模式根植于单个组织创建的开源项目,该项目可能是组织现有产品的衍生品,或者可能是他们想要开源发布的一些内部工具
2.7. 供应商中立的基金会

  • 2.7.1. 一个成功的开源项目也会遇到天花板

    • 2.7.1.1. 不清楚项目的资金来源或运作方式,或者人们认为它主要惠及单一供应商
    • 2.7.1.2. 没有中立的资产所有者,包括项目名称、标志、域名、社交账户和其他资产
    • 2.7.1.3. 项目的版权所有者是单一的实体,他们可以单方面更改许可证和知识产权政策,而无须社群的参与
    • 2.7.1.4. 利用该技术的供应商认为他们没有公平合作的空间,特别是当他们之间存在竞争关系时
    • 2.7.1.5. 项目的法律、信托和财务方面由一个组织管理,没有透明度或既定的流程
    • 2.7.1.6. 最好的解决方案是寻求供应商中立的基金会治理

  • 2.7.2. 建立自己的基金会

    • 2.7.2.1. Rust基金会、Python语言基金会、PHP基金会、Ruby Central和GNOME基金会

  • 2.7.3. 选择像Apache软件基金会、Eclipse基金会、Linux基金会或OASIS开放组织这样的现有基金会
3. 开源项目中的角色

3.1. 用户

  • 3.1.1. 开源项目中的每个人都是从使用项目开始的
  • 3.1.2. 用户数量增加不仅会提高用户转化为贡献者的可能性,还能提升社交方面的影响,从而向潜在贡献者展示成为贡献者的价值和机会
  • 3.1.3. 目标是至少有一些用户来帮助形成社群,这需要通过贡献来实现
3.2. 贡献者

  • 3.2.1. 当你为一个项目做了一些有益的事情时,你就成了一个贡献者
  • 3.2.2. 开源项目认为贡献者是那些直接向项目提供代码的人
  • 3.2.3. 当有贡献者能够为项目提供高标准代码时,你就可以看出他们对项目的深切投入
3.3. 维护者

  • 3.3.1. 作为一名维护者,有时也被称为提交者,既是一份承诺,也是一份信任
  • 3.3.2. 承诺来自个人对项目的持续关注和推动项目向前发展的兴趣
  • 3.3.3. 这类人认为项目对他们有价值,可以解决一些问题,并能够帮助他们完成任务
  • 3.3.4. 信任也是成为维护者的重要组成部分

    • 3.3.4.1. 维护者可以更改项目中的代码,这是巨大的信任
    • 3.3.4.2. 维护者也了解代码仓库的所有细微差别和细节,维护者知道代码哪里好,哪里还可以,哪里需要改进

  • 3.3.5. 在较小的项目中,维护者是首要角色
3.4. 领导者

  • 3.4.1. 开源社群的领导者不是独裁者
  • 3.4.2. 源项目的领导者会确立方向、解决冲突、帮助平衡优先事项,但更重要的是,他们为社群服务
  • 3.4.3. 开源项目的领导者意味着必须确保项目和社群中的每个人都能成功
  • 3.4.4. 服务型领导者,意思是成为一个为他人提供支持、资源和指导的领导者
4. 记录开源项目的治理结构

4.1. 记录治理结构很重要,因为理解过去的决策有利于在未来做出更好的决策
4.2. 可发现性

  • 4.2.1. 就是要让治理的源头容易被找到
  • 4.2.2. 从一个好的README文件开始通常是很好的方式

    • 4.2.2.1. 这个项目是什么?它能够做什么?
    • 4.2.2.2. 如何安装和使用该项目?
    • 4.2.2.3. 如果你有问题或疑问,应该去哪里寻求帮助?
    • 4.2.2.4. 如果你想为项目作出贡献,应该怎么做?
    • 4.2.2.5. 项目将走向何方(也称为路线图)​?

  • 4.2.3. 许可证(LICENSE),详细说明项目的开源许可证
  • 4.2.4. 贡献文件(CONTRIBUTING),使人们知道如何为项目贡献代码
  • 4.2.5. 发布文件(RELEASE),使人们知道新版本是如何发布的
  • 4.2.6. 支持文件(SUPPORT),使人们知道去哪里寻求支持
4.3. 简单性
4.4. 灵活性

  • 4.4.1. 为了有效地发展,开源项目需要能够随着时间的推移轻松地进行调整

    • 4.4.1.1. 这就是灵活的治理模式发挥作用的地方

  • 4.4.2. 灵活意味着理解社群,并与他们合作寻找解决方案
  • 4.4.3. 最重要的是,当有分歧时,应该理解他们的担忧并努力适应他们
5. 开源项目的财务支持

5.1. 开源的“自由如同言论自由,而不是免费啤酒”
5.2. 开源的自由部分指的是你可以自由使用代码,而不仅仅是开发或所有权的免费
5.3. 开发软件,无论是开源的还是专有的,都有经济成本,而这个成本必须由某人承担
5.4. 开源的成本往往由维护者承担,因为他们投入了时间和精力运营一个广泛使用的开源项目
5.5. 现代应用程序堆栈有很多依赖,有的依赖很快就会成为一个关键的依赖,而人们却没有意识到维护者的负担有多大
5.6. 小费

  • 5.6.1. 小费资助模式与街头艺人演奏乐器类似,他们把乐器箱打开,希望路人能投钱进去
  • 5.6.2. 模式背后的心态是:​“这是我写的一些代码,如果对你有价值,请随意捐赠。​”
  • 5.6.3. 一些项目维护者会提供PayPal或Venmo账户来接收捐款
  • 5.6.4. 小费资助模式最大的挑战是它不可持续,这意味着收入时高时低
  • 5.6.5. 另一个主要挑战是,如果你看一下支持一个用户的成本,往往可能超过他们给出的小费
  • 5.6.6. 小费资助的方法会让用户感觉他们当下的贡献是用小费来资助项目,而他们其实可以提供更有益的贡献
5.7. 众筹

  • 5.7.1. 众筹可能是一个许多人都熟悉的概念,因为它已经通过Kickstarter、Patreon和GoFundMe等网站成为我们社会的一部分
  • 5.7.2. 在开源中,众筹已经从非正式的小费资助模式过渡到更为结构化的模式
  • 5.7.3. 众筹可以为特定的开发筹集资金

    • 5.7.3.1. 一种方式是维护者为特定问题或功能发布资金请求,一旦所需的资金到位,维护者就会进行开发
      5.7.3.1.1. 这不仅是帮助维护者筹集工作资金的一种方式,还有助于维护者评估工作对社群的价值

    • 5.7.3.2. 看到捐赠者会得到一定程度的认可,就像各种剧院或艺术项目会对不同级别的捐赠者表达感谢一样
    • 5.7.3.3. 通常需要一个合法的组织来接受捐赠
      5.7.3.3.1. 许多捐赠者根据自己所在地的相关法规,希望能够享受某些税收优惠,如果项目不具有非营利性质,这可能会增加接受捐赠的间接成本


5.8. 单一组织资助

  • 5.8.1. 如果一个组织认为开源项目对他们的业务有价值,通常会寻求为其提供资金支持,可以通过捐赠、提供资金让开发者能够参加相关会议或活动,或者雇用那些关键开发者成为他们的员工,使其全职投入项目的开发与维护中
  • 5.8.2. 该组织成为确保项目继续推进的关键
5.9. 基金会

  • 5.9.1. 基金会资助模式背后的主要思想是将所有资金投入一个单一的、供应商中立的实体,并由多个利益相关者监督,由一个独立的组织管理日常财务
  • 5.9.2. Python软件基金会(Python Software Foundation,PSF),它是一家美国501(c)(3)非营利公司,是单个项目基金会的一个例子

    • 5.9.2.1. 一些员工帮助管理后端操作,并帮助筹款
    • 5.9.2.2. 还有一个管理委员会提供监督
    • 5.9.2.3. 委员会和员工都不会参与项目本身的技术开发或优先事项
    • 5.9.2.4. PSF的法人实体类型是美国501(c)(3)实体
      5.9.2.4.1. 501(c)(3)实体的捐赠通常是可以免税的


  • 5.9.3. 伞形项目基金会的一个很好的例子是LF能源(LF Energy,LFE)基金会,这是一个专门针对能源行业的开源项目家园,由Linux基金会托管

    • 5.9.3.1. 员工和委员会都不参与项目本身的技术开发或优先事项
    • 5.9.3.2. LFE的法人实体类型是美国501(c)(6)实体
    • 5.9.3.3. 501(c)(6)实体被美国国税局视为“贸易组织”​,这意味着它由会员资金驱动
      5.9.3.3.1. 向501(c)(6)实体的捐赠在美国是不可免税的


  • 5.9.4. 托管多个项目时,需要在项目之间进行一些监督和协调,同时确保每个托管项目具有自主权
  • 5.9.5. 技术咨询委员会(Technical Advisory Council,TAC)

    • 5.9.5.1. TAC拥有指导原则来帮助他们确定哪些项目适合,哪些不适合


来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
您需要登录后才可以回帖 登录 | 立即注册