企业官网建设流程全解析

1. 为什么需要 openwikis：开源世界不缺项目，缺的是靠谱的指南

先聊一个现象。我经常在技术社区看到有人问"我想入门开源，该从哪里开始"，底下回帖五花八门：有人甩一个 GitHub Trending 链接，有人推荐某本书，有人说"直接搜你想用的框架"，还有人热情地把自己的收藏夹共享出来。这些回答都有道理，但拼在一起就是一团乱麻。你搜"开源"，搜出来的是碎片；你问"开源怎么参与"，得到的是一堆孤立建议。真正成体系的、能让人按图索骥的中文权威指南，少得可怜。

openwikis 这个系列，就是冲着这个空子来的。它是一个以 wiki 协作模式维护的开源知识库项目，核心目标很朴素：把"开源"这件事讲透——从许可证怎么选、项目怎么评估，到怎么提交第一个 PR、怎么建设社区、怎么理解开源商业化，全部整理成一套可检索、可追溯、可持续更新的指南。你可以把它理解成"开源世界的百科全书"，但它跟传统百科不一样的地方在于:每一条指南背后都有真实可跑的案例、可复现的操作步骤，以及一群正在实际参与开源的人持续 review 和修正。它不是某个人的观点输出，而是一个由社区共同维护的活文档。

最开始想搞这个系列，是因为我在维护自己几个开源项目的时候，发现大量用户的问题其实是重复的。今天有人问"你这个项目用的 MIT 协议，我能不能改成 GPL 再发出去"，明天又有人问"我公司想用你这个包做 SaaS，会不会有风险"，后天还有人问"我看这个项目半年没更新了，是不是凉了，还能不能用"。这些问题单独回复没问题，但回复完我就意识到：如果能有一份系统性的开源指南，把这类高频问题一次性讲明白，不是比我在 issue 里重复一百遍更有价值吗？于是 openwikis 就从一个临时想法变成了一个正式项目。

这个系列适合谁？三种人：第一种是刚接触开源、想在简历上加点东西的学生或初级开发者；第二种是想在公司里引入开源方案，但搞不清楚许可证、社区活跃度、维护风险的技术负责人；第三种是自己维护着开源项目，想学习怎么运营社区、怎么处理贡献者关系、怎么让项目活得更久的独立开发者。这三类人看起来需求不一样，但底层要补的课其实是同一套：开源世界的运行规则。

2. 许可证选型：openwikis 指南里绕不开的第一课

2.1 三个最常用的许可证，以及它们的分水岭

openwikis 里阅读量最高的章节之一，就是许可证专题。这很合理，因为许可证是开源世界里最容易被忽视、却又最容易埋雷的地方。很多新人以为"开源 = 免费 = 随便用"，这个误解能害死人。

我见过最经典的翻车现场：某公司内部项目用了某个 GPL 协议的库，后来项目要闭源商业化，法务一查，整个项目可能都需要按 GPL 开源，差点把产品线都搭进去。这就是没搞懂许可证的代价。

在 openwikis 里，我会先把最常用的几个许可证摆在桌面上讲清楚。MIT、Apache-2.0、GPL、AGPL 这四兄弟，占了开源项目的绝大多数。它们之间最粗的一条分界线，就是"要不要把衍生作品也开源"。

MIT 和 Apache-2.0 属于宽松派。MIT 就一句话：你随便用，出事了别怪我，保留版权声明就行。Apache-2.0 在 MIT 基础上多了两点：一是明确授予专利权，二是如果分发时改了代码，要在文件里说明改动。对于做商业产品的人来说，这两个是首选，因为你可以光明正大地把代码塞进自己的闭源项目里。

GPL 是 Copyleft 的代表，它的核心逻辑是"你用了我，你就得跟我一样开源"。注意，这里说的是分发（distribution）场景。如果你的产品只是内部使用不分发，那不受 GPL 传染；但只要你把产品发出去，不管卖不卖钱，整个衍生作品都得用 GPL 开源。AGPL 更狠，它把"网络服务"也算进去了——你拿 AGPL 代码做了个 SaaS 挂在网上，同样触发开源义务。

openwikis 里有一个专门的知识点，叫"许可证速查表"，我建议任何要选型的人都先看这个表：

2.2 用"能不能赚钱"来理解 Copyleft

很多新手看到"Copyleft"这个词就懵，我换个说法你就懂了。想象你开了一家奶茶店，你把自己的配方公开了，条件是：任何人用了这个配方开新店，新店的配方也必须一样公开。这就是 GPL 的逻辑。而 MIT 的玩法是：配方随便拿去用，你做出升级版偷偷藏着卖钱也行。

所以 Copyleft 不是反对商业化，它只是强制"共享回馈"。你完全可以用 GPL 代码做收费软件，前提是你得把那部分衍生代码也开源。很多公司不愿意接受这个条件，所以商业闭源项目通常绕开 GPL 全家桶，优先选 MIT 或 Apache-2.0。

在 openwikis 的指南里，我特别强调了一个容易踩的坑：许可证兼容性。GPL-3.0 代码和 Apache-2.0 代码能不能混用？答案是：Apache-2.0 的代码可以并入 GPL-3.0 项目，但反过来不行——GPL-3.0 的代码不能并入 Apache-2.0 项目，因为 GPL 的要求更严格，会把整个项目"拉"到 GPL 协议下。这个规则如果搞反了，分发出去以后几乎没办法补救。

2.3 许可证冲突：指南里最容易被忽略的坑

还有一个案例我在 openwikis 里专门做过标注。假设你想做一个新项目，打算用 MIT 协议发布，但你的代码里引用了某个 AGPL 协议的库，并且做了修改。这种情况下，你的整个项目可能都必须按 AGPL 发布，除非你能把 AGPL 部分独立成一个进程，通过 API 通信而不是代码级集成。

这类"许可证污染"问题，光靠感觉是判断不了的。我自己的经验是：每次往项目里引依赖，都顺手看一眼依赖的 LICENSE 文件，把它记在依赖清单里。这个习惯养成以后，能帮你省掉无数次法务扯皮。

提示：开源指南不是法律意见，遇到真实的商业项目一定要让法务介入。但你可以通过公开的许可证信息做第一轮筛查，把明显冲突的选项提前过滤掉。

3. 怎么判断一个开源项目值不值得入坑

3.1 五分钟快速体检法

openwikis 指南里除了讲知识，还特别强调"判断力"。原因很简单：开源世界里项目太多了，但不是每个项目都值得你用。选择一个不靠谱的项目，轻则浪费时间，重则把生产环境搞挂。

我总结了一套"五分钟体检法"，专门用来快速判断一个项目的基本健康状况。不需要把代码全部读完，五个检查点就够了。

第一，看 README 是否合格。一个用心的项目，README 会清楚地告诉你：这个项目是干什么的、解决了什么问题、和同类项目比有什么优势、怎么快速上手、怎么参与贡献。如果 README 又长又空，吹了一堆概念却没告诉你怎么安装，我建议你直接快进到下一个项目。

第二，看许可证文件是否存在。没有 LICENSE 的项目，严格来说是不能随意使用的。你用了，可能会面临法律风险。不要被"代码都公开了应该没问题"这种想法蒙蔽，代码公开不代表你可以自由使用。

第三，看最近 commits。点开 commits 页面，看最近一个月有没有持续的代码提交。如果一个项目半年没有任何 commit，不代表它一定死了，但你要有心理准备：出了问题可能没人修。反之，如果一个项目每天几十个 commit，也要注意——有可能是刷活跃度，或者项目处于极不稳定的快速迭代期。

第四，看 issue 响应速度。提一个高质量 issue，或者直接翻 issue 列表，看维护者多久回复、有没有 maintainer 出来表态。一个健康的项目，issue 里应该能见到维护者的身影，而不是只有用户自己互相抱怨。

第五，看 release 版本。正式项目应该有语义化版本号，至少有一个稳定版（没有 alpha/beta 后缀）。如果一个项目永远停留在 0.x，说明 API 随时可能变，生产环境慎用。

3.2 Star 数会骗人，但有一类数据不会

有个反直觉的事实：Star 数是开源领域最容易被注水的指标。一个项目的 Star 数跟它的代码质量之间，相关性弱得可怜。营销做得好、Demo 好看、在 Hacker News 上刷过榜的项目，Star 数可以一夜暴涨；而一些稳定运行多年的基础设施项目，Star 数可能低得吓人，但每天都在被成千上万的系统依赖。

那什么数据不会骗人？我自己的答案是：被依赖数和下游项目数量。如果你在 GitHub 上打开一个项目的页面，右侧能看到"Used by"一栏，那里显示有多少仓库依赖了这个项目。这个数字很难刷，因为它反映的是真实的生产环境采用量。一个数据库驱动库即使只有 500 个 Star，但如果有 20 万个仓库在依赖它，那它的稳定性大概率是经过极端验证的。

还有一个指标是Issue 关闭曲线。你别只看 issue 总数，要看维护者有没有持续在关闭 issue。一个积累了五千个 issue 全部open的项目，和一个有两千个 issue 但大部分都已关闭的项目，健康度完全不是一回事。前者说明维护者已经放弃了 issue 管理，后者说明项目仍在正常运转。

openwikis 里有一篇文章专门讲"开源项目的信号与噪声"，核心观点就一句话：**别盯着聚光灯下的明星项目，多看看那些被依赖但不说话的基础设施项目。**对于开源选型来说，正确地用一线工地上的锤子，永远比收藏一把展示用的金锤子有用。

3.3 文档质量，是项目健康度的X光片

我说句得罪人的话：很多开源项目的代码质量很优秀，文档却烂到让人想摔键盘。反过来，文档写得好的项目，代码质量通常差不到哪去，因为文档本身就是一种代码——它需要被持续维护、被用户反馈驱动更新。

在 openwikis 里，我把文档分成了四个等级。第一级，只有 README，且 README 里只有安装步骤（经常还是错的）。第二级，有完整的用户文档，告诉你某个功能怎么用，但遇到问题只能自己猜。第三级，用户文档 + API 文档 + 常见问题列表，大部分疑问能在文档里找到答案。第四级，在前者基础上还有贡献指南、架构说明、行为准则（Code of Conduct），甚至维护者会写一些设计决策记录（ADR）说明"当初为什么这么设计"。

你可以用这个分级标准去评估任何一个开源项目。至少要到第二级，项目才值得在非关键场景使用；如果要上生产环境，我建议选第三级及以上的项目。这不是矫情，因为文档质量直接反映了维护者对用户的态度。一个连"这是什么、怎么用它、出了问题怎么办"都讲不清楚的项目，你指望它在关键时刻响应你的 issue、修你的 bug？太难了。

4. 从读者到贡献者：开源协作的完整路径

4.1 第一次提交 PR 的正确姿势

很多人对开源贡献的第一个误解是："我的代码得足够牛，才能给大项目提 PR。"这个想法大错特错。开源社区最欢迎的不是天降大神，而是愿意从小事做起、一步一个脚印的人。openwikis 系列专门有一篇"新人第一课"，讲的不是怎么写代码，而是怎么走完一个完整的贡献流程。

第一步，找到你想贡献的项目之后，先别急着 Fork 改代码。先去项目的 CONTRIBUTING 文件（一般叫 contributing.md，可能放在 docs 目录下），读一遍。这个文件里写了项目的代码规范、提 PR 的流程、构建方式、测试要求。很多新人提的 PR 被秒关，不是因为代码不好，而是没遵守规范。

第二步，从"good first issue"标签开始。GitHub 上有这个官方标签，专门标注适合新手的任务。这类 issue 一般定位清晰、影响面小，就算搞砸了也不会伤筋动骨。找到合适的 issue 后，先在下面留个言，说一句"我想尝试解决这个问题"，等维护者确认你做了。

第三步，Fork 之后，建议在一个单独的分支上开发，分支名最好能体现你要做的事，比如 fix/typo-in-install-doc、feat/add-login-timeout。提交信息的格式也很重要，一般社区会遵循 Conventional Commits 规范：feat: 新增xxx功能、fix: 修复xxx问题、docs: 更新xxx文档。这种格式化的提交信息，在项目维护者做 release 自动生成变更日志时特别有用。

第四步是别忘了写测试。你改了逻辑，至少要把受影响的功能测一遍。如果项目有自动化测试流水线，你的 PR 会被自动跑测试，红了的话，维护者大概率不会花时间看你的实现。

4.2 文档贡献：新手友好的入口

我强烈建议第一次参与开源的人，从文档贡献开始，而不是直接改代码。原因有两点：第一，文档贡献的边界清晰、风险低、容易获得反馈，你改错一个标点项目不会崩；第二，通过读文档、改文档的机会，你能把项目的整体结构摸一遍，等下次再报 issue 或改代码时，你已经不是新人了。

openwikis 自己的项目里，相当一部分贡献就是从文档开始的。有人来提 issue 说"长期使用这个库，发现文档里有个 API 示例写错了"，然后顺手把修正版直接 PR 上来。这种贡献对项目的价值，一点不比改代码低。

写文档贡献的时候有一个技巧：你不需要等自己完全懂了一个功能才去写它。哪怕你只是照着文档跑了一遍，发现某个命令在 Windows 上跑不通、某个字段在 1.2 版本里改了名字，这些都是珍贵的反馈。你可以提一个 issue 描述你的发现，如果文档已经写了维护者可以按这个方向修，如果没写你甚至可以主动说"我来补这批文档"。这种"测试驱动文档改进"的方式，对一个项目的用户体验提升非常明显。

4.3 社区礼仪与沟通规则

开源的世界里，代码水平之外，沟通能力决定你能走多远。openwikis 里专门有一章讲社区礼仪，我把最重要的几条经验放这里。

第一条，提问之前先搜索。项目的 issue 列表、讨论区、官方文档、Stack Overflow，先搜一遍再问。问之前已经把功课做足了，是对维护者时间的基本尊重。真正做到这一点的人，收到的答案含金量会高很多。

第二条，反馈 issue 的时候，给足上下文。不要只丢一句话"这个功能坏了"，然后把维护者当算命先生。你至少要说清楚：你的环境（操作系统、语言版本、项目版本）、复现步骤、期望结果、实际结果。如果能把复现的代码段或错误堆栈贴出来，那你已经比 90% 的提 issue 者优秀了。

第三条，被拒绝或批评时，先冷静。开源社区里脾气直的人很多，维护者有时会直接说"这个设计是错的"或者"这个 PR 不需要"。这不代表他们否定你这个人，而是他们在为项目长期质量把关。我见过几个新人被拒绝一次之后，就再也不来了——这其实挺可惜的。你要做的不是争辩"我明明花了三天时间"，而是去理解维护者为什么拒绝，把意见消化掉，改好了再提一次。一个愿意根据反馈反复修改的贡献者，比一个一次就写对代码的天才更受欢迎。

5. 基础设施与工具链：开源指南里那些绕不开的实战地图

5.1 镜像站：为什么"下载慢"不是玄学而是网络架构问题

聊开源就免不了要下载依赖，而下载依赖就免不了遇到"慢"的问题。很多新人以为这是自己网不好，其实背后是完整的一套网络架构问题：当你从某个中心仓库拉包时，请求走的是国际链路，在物理链路和路由层面经过多次转发，加上跨境带宽本来就紧张，慢是正常的，突然断连也不奇怪。

开源生态对这个问题的解法是镜像站（mirror）。镜像站做的事情很简单：把上游仓库的代码和二进制包定期同步一份到本地/就近服务器，用户从镜像站拉取而不是从源站拉取，速度能提升好几个量级。像国内社区常见的高校镜像站、云厂商镜像站，本质上都是这种机制。

这套机制里有一个很关键的指标叫"同步延迟"：上游仓库更新了某个版本，镜像站多久能拉过来。不同镜像站的同步频率不一样，有的每小时一次，有的每天一次。如果你在镜像站上找不到某个刚刚发布的新版本，不是它没有，而是还没同步过来。这在 openwikis 的"开源依赖管理"章节里，是被特别拎出来叮嘱过的实战细节。

对使用者来说，把包管理器的 registry 源切到镜像站，是一个性价比极高的操作。但这儿就有一个注意事项了：镜像站是第三方同步的，虽然可靠性总体很高，但你不能假设它 100% 和服务商本身等价。在上生产环境之前，至少要在目标镜像上完整走一遍"拉包-构建-部署"的流程。另外，如果你的 CI 流水线长期依赖某个镜像站，建议在 Dockerfile 或依赖配置里把锁文件做好，保证构建可重复，而不是每一次都去试探最新版本。

5.2 从 GitHub 到 Gitee：托管平台的选择

说到开源项目的托管平台，GitHub 是绕不开的。它最大的优势不是功能多（实际上某些功能它做得并不是最顺手的），而是生态密度——几乎叫得上名字的开源项目都在上面，issue、PR、讨论、CI 工具链形成了巨大的网络效应。你在 GitHub 上找到一个项目，能顺着相关引用、同类项目、下游依赖，一路顺藤摸瓜发现一整片生态。这是任何单独的平台都很难替代的。

但这不是说只能押注一家。国内开发者常用的 Gitee（码云）在访问速度、中文社区、企业协作方面有自己独特的优势。很多国内团队会把主仓库放在 Gitee，同时把一份代码同步到 GitHub 做国际化展示。相应地，openwikis 的指南里也专门讨论了"双平台同步"的几种套路：最省事的做法是用 Git 的 remote 机制同时推送到两个地址，但要注意分支保护规则、issue 跟踪在两个平台之间不会自动同步，别搞成信息孤岛。

我的建议是：个人项目或者小型社区项目，选一个主平台深度运营就够了，另一个平台作为"镜子"存在，不用花太多心思。但无论如何，项目主页上一定要写清楚"报告 issue 去哪个平台""PR 以哪个仓库为准"，否则贡献者会不知道该往哪儿提。

5.3 自动化工具链：CI、代码扫描、版本发布

一个项目从"个人作品"走向"严肃开源项目"，标志性的事件就是引入了自动化工具链。openwikis 里有一句话被很多人引用过："如果你想证明自己是一个负责任的维护者，那就让机器替你守住底线。"人工 review 难免有疏漏，但 CI 流水线不会。

最基础的配置有三件套：持续集成、静态扫描、自动发布。持续集成（CI）负责在你每次推送代码或提 PR 的时候，自动跑一遍测试和构建。常见的云平台比如 GitHub Actions 可以直接写 workflow 文件，配置一次就能长期使用。静态扫描包括代码格式检查、lint 规则、安全漏洞扫描（比如 Dependabot 自动检查依赖里的已知漏洞）。自动发布则是把"打 tag -> 构建产物 -> 推送 release"这一套流程脚本化，减少人为操作的失误。

这三件套做下来，一个新手 PR 提交者的体验是什么样的？他 Fork、改代码、推送，CI 自动跑起来；如果有格式问题，机器人会告诉他哪里不符合规范；测试失败，他会看到具体的报错信息；一切通过后，维护者只需要 review 逻辑本身，而不是浪费时间做重复检查。这套体系一旦跑起来，项目的维护效率和贡献者体验都会有一个质的飞跃。

6. 开源的下半场：大模型、商业化与可持续

6.1 开源大模型改变了"开源"这个词的含义

如果回到 2023 年之前，"开源"几乎等价于"源代码公开"。但大模型横行之后，这个定义开始失灵了。现在很多标榜"开源"的大模型，其实只开放了模型权重（weights），训练数据、训练脚本、完整的技术报告不一定公开。这就催生了一个现象：open weights 不等于 open source。

openwikis 里面专门有一个命题是"开源大模型的许可证迷雾"。你下载了一个声称开源的模型权重，GPU 跑起来了，用来做了个商业产品，结果过几天发现它的权重使用条款里写明了"月活用户超过某个量级需要单独申请商用授权"，你的产品线当场就多了一个法律风险。这类限制，在传统的开源许可证里是不太常见的。

所以，如果要用开源大模型做产品，至少要搞清楚两件事：第一，它开放的是什么层面——是纯推理权重、可再训练的权重，还是连数据管线都开放了；第二，它用的是什么样的许可证/使用条款——是 OSI 认证的许可证，还是某个公司自定义的"老百姓看不懂但很可能有坑"的条款。这两点查清楚之后，再决定能不能上生产环境。

6.2 开源商业化不是洪水猛兽

很多开源爱好者有一个朴素的想法：开源就是应该纯免费，谈钱就是背叛。但你看数据就知道，今天世界上大多数能长期维护的开源项目，背后要么是商业公司在养，要么是基金会拿到了赞助，要么是核心维护者自己开了公司。纯粹靠"爱发电"的项目，活过五年的比例低得可怜。

openwikis 的指南里，我把开源商业化模式分成了几类。最常见的叫"开放核心"（Open Core）：项目的基础版本完全开源，但高级功能（性能优化、企业集成、管理后台）以商业版形式提供。这个模式的难点在于划定"开源边界"——哪些功能必须留在开源版里，哪些可以收费。边界划歪了，社区会用脚投票。

第二类叫"云托管服务"（SaaS / Managed Service）：代码开源，但官方提供托管的云服务，按用量收费，用户图个省心就付费订阅。这个模式很火，但和开源许可证之间有一个微妙的张力：如果项目用的是 AGPL，那别人也能拿代码自建同样的服务跟你竞争，除非你有品牌、稳定性和生态的优势。

第三类是"咨询与支持"：项目完全开源，收入靠给企业做定制开发、培训和技术支持。这种模式天花板不高，但对很多小而美的项目来说已经足够了。

我在 openwikis 里反复强调的一句话是：**开源和商业化不是对立的，而是互为前提的。**没有商业可持续性的开源项目，最终会变成维护者的负担；没有开源精神的商业项目，也很难获得社区的信任和贡献。找到适合自己项目的可持续路径，是每一个维护者都要面对的长期课题。

6.3 openwikis 自己的可持续发展设计

说回 openwikis 本身。这个系列作为开源知识库项目，同样要面对可持续性的问题。我们的策略非常朴素：内容以社区协作模式维护，任何人可以提 PR 修正或增补章节；同时项目本身接受企业和个人赞助，用于支付域名、CI、文档托管等基础设施成本，以及定期组织线上/线下的贡献者活动。

有人问过我："你们做开源指南，又不卖课又不做培训，图什么？"我的回答是：图的是生态水位抬高之后大家共同受益。如果国内有更多的人懂许可证、懂社区协作、懂项目评估，那么无论是开源项目的质量还是使用者踩坑的概率，都会往好的方向走。这条路确实慢，但它值得长期投入。openwikis 这个系列存在的意义，不是让作者成名，而是让每一个参与者，都能在贡献的过程中变成更好的开源公民。

7. openwikis 内容迭代中的实测经验与教训

7.1 我踩过的三个内容维护坑

做 openwikis 快两年，踩过的坑能写满一本小册子。挑三个最有代表性的讲。

第一个坑是"内容过时"。开源世界的变化速度非常快，今天写"Kubernetes 是容器编排的事实标准"，明天可能就冒出一个新的编排工具抢走大片生态位。你辛辛苦苦写的一篇文章，半年之后再看，里面可能有一半信息已经失效。我们的应对办法是给每篇文章加上"最后核验日期"，并建立了一个 semiannual review 机制——每年固定两次，由志愿者分批检查文章里的链接、版本号、命令是否需要更新。

第二个坑是"术语不统一"。指南是多人协作写的，不同作者对同一概念的叫法可能不一样：有人说"许可证"，有人说"协议"，有人说"License"。这个看似小问题，等文章积累到上百篇之后，检索体验会变得非常差。后来我们做了一个术语表，每个关键术语都指定一个标准中文译法和英文原文，同时约定在正文中第一次出现时给出对照解释。这之后，新文章和旧文章的术语风格才慢慢统一起来。

第三个坑是"贡献者断层"。很长一段时间里，openwikis 的内容主要靠我和另外一两个核心伙伴在写，其他人偶尔来提个 issue 就算多了。后来我们引入了一个小机制：把"待办任务"分成不同难度等级，并给每个任务写清楚背景和验收标准——类似代码库里的 good first issue。任务清单一目了然之后，愿意来贡献的人明显多了。这个经验其实是现成的开源方法论，只不过我们一开始贪快，跳过了"引导新人"这一步。

7.2 一个可持续维护的指南需要什么

如果要我用一句话总结 openwikis 这两年的经验，那就是：**指南类开源项目的护城河不在"写"，在"维护"。**写一篇文章，一个周末就够了；但让一百篇文章在三年后仍然准确、可用、有人更新，这是完全不同的工程量。

可持续的指南维护，需要三样东西。第一，明确的治理结构。哪怕再小的项目，也要说清楚谁是维护者、谁可以合并 PR、有分歧时如何裁决。模糊地带是社区冲突的温床，而治理规则是最好的润滑剂。

第二，稳定的内容发布节奏。我们不是每天更新（也没这个必要），而是保证每周至少有一个 merge，每个月至少有一个新的专题方向。稳定的节奏会让读者形成预期，也会让贡献者有持续参与的抓手。

第三，真诚的贡献者激励。不需要多 fancy 的奖励体系，一句认真的"感谢你的贡献，你修的这个 bug 已经影响到三个下游用户了"，比发一件周边 T 恤更能留住人心。在 openwikis 的贡献者名单里，有不少人就是因为第一次 PR 被维护者认真 review、认真反馈，才决定长期留下来的。

最后再分享一个小技巧。如果你也想发起一个类似 openwikis 的开源知识库项目，不要一上来就追求"权威"两个字，先把一个小专题做扎实，比如只写"许可证选型"这一个方向，把它写到同类文档里最好的水平。等这个小专题真的被很多人用起来了，再考虑扩展成"系列"。权威不是自封的，是用户一篇一篇用出来、维护者一次一次迭代出来的。