开源解决方案推导 - 有关开源组织功能和需求的论述

概要

本文描述了我的个人思考. 分三个部分.

开源组织的需求
开源组织的功能
如何做开源组织的假想设计

开源组织的需求 - 为什么需要开源组织

最近 linux 的视频会议上, 提到了关于老一代程序员担心自己老了之后, 项目可能缺少维护的情况. 我认真思考了一下, 认为开源项目, 重在维护.

首先假定开源项目的一个目标是让更多的人更有效的使用. 并通过更多的使用反哺开源项目的发展.所以我们以几个维度评判开源项目的相对价值.

文档, 新手指导完善程度 - 使用难度
贡献者活跃程度 - 活跃度
面向解决的问题 - 应用价值

注意的是三者并不都是独立的, 而是相互作用的.

我认为是维护大致有以下原因.

开源项目, 作为代码项目一定会有 bug, 如果使用者因为 bug 而停止使用, 开源项目无人使用会间接减少活跃程度.
1. 故需要人帮助解决 bug( 如 PR)
开源项目的使用, 一定伴随着更多的问题. 我们永远都不知道客户是如何使用, 在哪一个环境下进行操作的. 自然除了代码 bug 之外, 使用错误也是开源项目需要解决的问题. 文档不够, 就需要维护人员花费人力帮助解决(体现在 github 项目的 issues 上) 然而相关工作, 作为一个开源项目. 更希望维护人员是自发的贡献者而不是开发者本身.
1. 故需要贡献者进行文档的维护.
开源项目的定制化: 作为开源项目, 不少能够直接应用在通用的场景中, 但是针对特殊使用场景, 需要定制化某开源项目,自然需要了解这个开源项目并相信遇到问题时, 如果需要可以支付报酬来得到相关人员解决. 这一点如果没有维护人员, 或者叫开源生态, 是不行的.

综上, 虽然我论述有重复的地方, 但是维护, 无疑是一个开源项目的命脉.

但是如何维护开源项目, 却是作者非常头疼的问题.
以最近的 redis 作者宣布退役 redis 维护为例.

我认为, 如果针对该维护行为, 有一个组织承担, 是更好的选择. 在开源界中, 我们通常称为社区 Community.

那么接下来, 讨论社区问题. 社区期望拥有什么功能

开源组织的功能

已经论述了关于维护的必要性, 但是维护描述的并不充分. 哪一些算维护, 哪一些属于开源社区的职能范围, 我的建议是, 先假设一部分, 进行讨论来推导.

1. 文档

我首先想到的是文档, 由于当我熟悉开源项目时, 我首要的行为是查看其官方文档. 故我第一个提出

下面我们思考开源组织在这上面的职能.

我认为, 文档包含使用说明和源码逻辑两个部分. 使用说明用于普及应用, 旨在降低使用门槛, 源码逻辑说明和设计用于降低贡献门槛(另一个, 架构设计如果有文档和图来表示, 也是学习的一部分)
开源组织的职能大致如下
如果一个开源组织希望维护文档, 我认为首要目的是降低阅读和使用门槛, 即能提供最简便的体验和使用途径. 即最重要的是使用文档. 业界可能通常以 Doc 命名.
关于使用门槛的论述: 如果使用门槛高, 那么用户基量必定减少, 而作为开源项目, 实际上设立门槛并不是一项非常有利的行为. 我们知道以公司类比, 公司招聘通常有各种门槛设立, 但是这种门槛也有概率过滤掉其迫切需要的人. 开源项目与公司不同的是, 他无迫切需要盈利, 计划盈亏的必要. 用户基量是其最优的催化剂.
故, 开发文档的简洁性最为必要, 开源组织应寻找最简化体验和方便的文档指导. 同时, 针对不同的环境, 不同的机器, 开源组织可以考虑添加不同的文档.

第二是设计文档, 如果之前说的是使用者的基量, 那么设计文档主要影响的是贡献者的基量. (贡献者通常是使用者转化来的)
如果一个开源组织希望维护设计文档, 那么需要的不止是试用然后记录操作用作操作文档的能力, 还有相应的开发能力. 设计文档不止是当前的设计, 架构当然蕴含着未来的改变, 设计文档可以是社区关于该开源项目未来价值的期望. 故我认为, 设计文档维护者, 应该是项目的核心贡献者.他们可能来自于社区, 共同商讨着项目的进一步开发与完善.
设计文档应当属于目标明确的文档, 目标明确应为明确某一项设计解决什么问题, 如此设计文档将通过问题分类将项目拆分成很多小的部分. 而这些小的部分, 正降低了开源项目的贡献门槛.
(例子, 如各大项目的 design 目标.)

2. 代码

开源社区实际上也有维护代码的能力, 我按照当前开发者分为几个阶段.

使用者通过 issues 是等方式, 查找, 复现 bug 提供给开发者.
贡献者解决部分问题通过回复 issues , 提交 pr 修复等方式
贡献者针对场景添加 feature, 或者分叉分支为新的解决方案.
贡献者持续该项目的开发, 更新项目推动实现 design 设计目标.

开源组织的假想设定

为解决基本需求, 如代码维护和文档维护问题, 开源组织的角色应该有该项目的使用者, 能维护该项目的程序员, 该开源项目的负责人.
为解决某开源项目进一步发展的设计和前瞻性, 开源组织的人员结构应有贡献者的委员会用于做决定.
为解决开源项目的日后维护问题 (由于现在的使用者今后可能由于各种原因不在使用和维护该项目, 而且我认为开源爱好者也有自由选择是否使用及维护的权利) 人员结构应该加上新生血液. 那么新生血液的培养者也是角色之一.
某个开源项目的维护者通常也是其他项目的维护者(使用者) . 应有一个处于各个开源项目小组之上的组织, 用于各小组之间交流, 人员流通, 和分享信息. 举例如 CNCF, 而开源项目小组就是其下单独项目的开源社区.

之后我认为, 继续讨论的应在于, 如何能使开源爱好者更轻松的进入该架构中, 并最轻松的做出他想, 并能做出的贡献