写点什么

GitHub 的野心,5600 万开发者的新社区

发布于: 2021 年 01 月 06 日
GitHub 的野心,5600 万开发者的新社区

开源社区在哪里?


今年我积累了些为 GitHub 项目建设开源社区的经验,常在思考这个问题。


最近,GitHub 推出了一项新功能,才让我确定答案:


对于 GitHub 的开源项目来说,它的社区就在 GitHub 上。


你也许觉得我在说废话。


如果你这么想,请听我细细道来。

GitHub 上的新社区

“世界各地的人们都在拥抱开源和 GitHub。GitHub 不仅是代码开发者的家,也成了各行各业的人们工作、学习、与社区互动、为开源作贡献的平台。” ——GitHub 2020 年度报告


GitHub 是全球最大的开发者平台,也是一个社区型的代码项目协作平台。


GitHub 2020 年度报告显示,GitHub 在全球范围内已有 5600 万开发者用户(中国用户数位列第二,仅次于美国),近一年内产生了 19 亿次贡献。


这些贡献的大多数,都来自开源社区。


开源,意味着同社区一起互动、学习、创造。


但 GitHub 是否适合作为开源社区的基地,组织社区成员进行互动、学习、创造?


无论你是项目的维护者还是使用者,都值得好好琢磨下这个问题。


如果你是项目的维护者,请问问自己:


  • 你如何与社区对话?

  • 社区成员如何与彼此对话?

  • 你如何组织社区成员、完成更卓越的贡献?


如果你是项目的使用者,请问问自己:


  • 你的问题如何得到快速响应和解答?

  • 你如何获知该项目的最新动态、公告或贡献指南?

  • 你如何与项目建立更紧密的连接、完成力所能及的贡献?


为了做到这些,一个开源社区至少要有以下基础设施:


  • 互动交流区

  • 官方公告栏

  • 社区知识库


此前,GitHub 只提供 Issues、Pull Requests 功能进行社区的互动交流。


这两种页面都是线性组织的,适合快速合并代码,但不适合多线程的沟通社区知识库的积累


而 GitHub 的 wiki 功能则相对较重,不适合碎片化优质内容的积累。


因此得出结论:此前,GitHub 本身并不能很好地支撑开源社区的基础设施建设。


这就导致了,围绕项目产生的社区分散在互联网各个区域


拿一个代码项目举例:


  • 项目的日常交流可能在 Gitter(一款即时聊天工具)、Slack、微信上;

  • 项目使用问题可能在 Stack Overflow、GitHub Issues 上;

  • 具体事项的讨论可能在自建的论坛或 Google Groups 上;

  • 社区相关的公告可能在 wiki、公司官网的新闻公告上……


如此“分布式”的互动,容易导致社区的松散、无组织:一方面很多优质的讨论和内容流落在外,另一方面为新成员融入社区平添了许多摩擦。


如果你也有同感,现在可以松一口气了。


因为 GitHub 近期提供了 Discussions 功能,将“流落在外”的社区重新聚集起来,带回了离源代码更近的地方——项目仓库 (repository) 本身

Discussions 功能简介

软件社区的成员不只在一起写代码。他们还能一起头脑风暴出新想法、新功能,帮助小白用户快速上手,探索使用软件的最佳实践。社区需要自己的互动空间,这就是 Discussions 的意义。——某 Hacker News 用户


Discussions 是 GitHub 今年年初推出的内测功能,当时官方选取了几个项目做内测,包括 Next.jsTailwind CSSOffice 365 CLI 等。


该功能于 2020 年 12 月 8 号正式开放公测。


目前,每个公共仓库都可以在 Settings/Options/Features/Discussions 处启用该功能。

启用 Discussions 功能的设置页面

启用后,Discussions 作为仓库的一个独立区域(下图红框位置),用于社区成员问答互动,类似于论坛。

Next.js 项目的 Discussions 首页

单个 Discussion 页面与 Issue 页面很相像,但 Discussions 还提供以下新功能:


  • 支持自定义 Discussions 的分类(比如可以有问答区、脑洞区、新项目展示区、求助区等)

  • 支持将已有的 Issues 迁移成 Discussions

  • 支持将某个回复标记为答案(类似于 Stack Overflow)

  • 支持开启对话的 thread(类似于 Slack)

  • 支持在 Discussions 首页固定最多 4 个讨论(可作为官方公告栏)

Discussions 的利与弊

对于项目维护者来说,Discussions 的好处如下:


  • 补全 GitHub 的社交性,与仓库的其他功能紧密结合,共建完整的社区


收集 bug 和功能需求用 Issues、接受贡献用 Pull Requests、项目协作及管理用 Projects 和 Kanban、代码持续集成部署用 Actions、接受社区赞助用 Sponsors、发布重要文档用 wiki,社区公告及互动用 Discussions,一条完整的社区链路似乎已然补全了 :-)


  • 把除了 bug 报告和新功能需求的 Issues 通通挪到 Discussions,进行分类管理,减少 Issues 中的噪音


一些大型仓库动辄就有上千 Issues,包括 bug 报告、新功能需求、用户的使用问题、已有功能的讨论等等。Issues 种类混乱,极易堆积,管理起来十分痛苦。如果能将部分 Issues 迁移到 Discussions,合理分类,借助社区的力量解决问题,或许能减轻项目维护者的负担。


  • Discussions 版块作为社区入口,方便新人了解项目情况、社区文化


可以在 Discussions 版块内放置项目的上手资料、贡献指南、代码规范、博客链接甚至公开 adopter 列表、数据表现等等,鼓励社区成员在离源码更近的地方学习、交流、产生连接、积累知识库。


比如下图是 next.js 项目专门建了个 Discussion 页面,鼓励社区主动完善 adopter 列表:

next.js 项目添加 adopter 列表的 Discussion 页面

Discussions 的坏处如下:


  • 对于业余项目的维护者来说,启用 Discussions 可能会加重他们的负担


Discussions 降低了互动的门槛,当更多的讨论涌入,维护者的工作就更多了。


  • 与 Issues 的区分有些不明晰,项目维护者在初期可能要耗费一些精力来教育用户,分清两种功能的定位


对于项目使用者来说,目前来看该功能有利无弊。


用户的问题解决路径原来也许是这样的:


项目使用过程中碰到问题 -> Google -> Stack Overflow 或 GitHub Issues -> 如果没有答案,则新建问题


现在也许是这样的:


项目使用过程中碰到问题 -> 搜索项目的 Discussions -> 如果没有答案,则新建 Discussion


Discussions 慢慢会变成用户第一时间寻求解决方案的地方,因为这里就是项目的专有社区。

GitHub 社区新形态展望

好的社区不仅要让贡献者持续增长和参与,还必须尽量减轻项目维护者的负担。——GitHub 2020 年度报告


有了 Discussions,未来的 GitHub 开源社区会呈现什么新形态?


这个问题目前很难回答,但我们可以看看从年初就开始内测 Discussions 功能的项目,或许能一探未来的趋势。


今年 3 月,Office 365 CLI 项目宣布解散他们的 Gitter 论坛,以后所有的讨论都迁移至 Discussions:

Office 365 CLI 解散 Gitter 论坛的官推

next.js 仓库今年 1 月开始使用 Discussions,截至 10 月,已使用超过 3000 个 Discussions 进行交流协作。在过去的一年中,向仓库做出贡献的人中几乎有一半使用了 Discussions。(数据来自 GitHub 2020 年度报告)


next.js 仓库甚至将 RFC (Request for Comments) 从 Issues 迁至了 Discussions,方便社区成员第一时间参与到新功能的讨论中(瞧瞧评论区的反响,这才叫真正的共建社区啊!):

next.js 仓库在 Discussions 版块下建的 RFC 页面

目前 next.js 仓库首页对社区的导流只有两处:一个是 GitHub Discussions,另一个是 Discord(轻量的聊天应用)。前者用于提问、分享新想法和新项目,后者用于与社区成员聊天。

next.js 仓库首页对社区的引流

从上面的例子可以看出,社区正朝着统一化的方向在发展。


统一平台的社区管理方式,不仅降低了社区成员的参与成本,也在一定程度上减轻了项目维护者的运营压力。


因此,我在这里斗胆展望下日后的开源社区形态:


All in GitHub


  • GitHub Issues:用于收集 bug 和确定要做的新功能

  • GitHub Discussions:用于发布三类信息 (1) 新功能的 RFC;(2) 帮助和公告信息,如贡献指南、代码规范、社区活动的宣传等;(3) 日常的问答与交流

  • GitHub Projects:用于追踪开发进度、社区成员可以参与协作

  • GitHub Pull Requests:用于提交代码、社区成员可以参与审校


Discussions 让项目信息的发布变得更快捷集中透明


社区成员留下的每一条问答,都是对社区知识库的贡献;社区成员在 RFC 讨论区留下的每一个👍,都真正参与到了项目的决策。


每个开源项目的作者,或许都梦想过拥有一个活跃、自治、贡献度高的开源社区,加速项目的迭代。


现在,我们离这个梦,似乎又更近了一步。

结语:GitHub 的野心

毋庸置疑,GitHub 是一款非常棒的产品。自 2018 年被微软收购后,推出了更多走心、实用的功能。


作为一名 GitHub 的产品粉,我由衷地感到欣慰,GitHub 仍在积极地重新定义产品的边界,不断推出让千万用户眼前一亮的新功能。


但在 Hacker News 上,许多开发者对 GitHub 王国的「版块扩张」表示担忧:


  • 2008 年,GitHub 推出 Pages,与诸多网站托管平台对线

  • 2016 年,GitHub 推出 Projects,与 Trello/Waffle 对线

  • 2018 年,GitHub 推出 Actions,与 Travis/CircleCI 对线

  • 2019 年,GitHub 推出 Sponsors,与 Patreon 对线

  • 2020 年,GitHub 推出 Discussions,与 Stack Overflow 对线


GitHub 在性能和 UI 方面做得很好,用户很难抗拒在同一平台上将这些事全做了。

但在长远看来,平台建立垄断性优势,对用户来说未必是件好事


这也许确实是 GitHub 的野心。


不过,站在 GitHub 的角度无可厚非,站在用户的角度有利有弊


但目前看来,对于普通的项目作者和用户,利肯定是远远大于弊的。


至于未来如何,让我们拭目以待吧。


头图:阿狍杂谈

作者:打工人 Coco

原文GitHub 的野心,5600 万开发者的新社区

来源:微信公众号 - 阿狍杂谈

转载:著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


用户头像

主要写写互联网产品/IT/开源类文章 2019.11.12 加入

公众号:阿狍杂谈,蹲在科技和人文的路口数蚂蚁

评论

发布
暂无评论
GitHub 的野心,5600 万开发者的新社区