想配资怎么找平台
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拥有指导原则来帮助他们确定哪些项目适合想配资怎么找平台，哪些不适合
信钰证券提示：文章来自网络，不代表本站观点。
