你可能正在犯的 7 个错误

开源项目最常犯的错误以及如何避免这些错误。
607 位读者喜欢这篇文章。
red pen editing mistakes

Opensource.com

启动一个新的开源项目可能很困难。你脑海中有一个很棒的想法,但需要付出努力才能将其变成一个高效、健康且引人入胜的社区。可悲的是(似乎在几乎所有事情中都是如此),新项目一次又一次地犯同样的错误。

以下是一些开源项目最常犯的错误,以及我避免这些错误的建议。

1. 光说不做

在成千上万个启动的开源项目中,有太多项目在初期就陷入困境,原因是他们在 Slack 频道、邮件列表、问题跟踪或其他地方进行了大量讨论。讨论漫无边际,范围往往越来越大,以纳入许多各式各样的想法和考虑因素。

一个早期的开源原则——“尽早发布,频繁发布”——对我们很有帮助。与其试图解决所有挑战,不如编写代码,将其放入仓库,并开始接受拉取请求。当专注于代码时,你的项目将更快地发展、适应和改进。

2. 试图发布完美的第一个版本

领英创始人里德·霍夫曼曾说过一句名言:“如果你对你的产品的第一个版本不感到尴尬,那你发布得就太晚了。”

这在新开源项目中尤其如此。试图使你的第一个版本,甚至 1.0 版本尽可能完美是很诱人的。但事实是:大多数人不会注意到你的第一个版本,所以它真的不需要完美。

人们会在开源项目发展过程中关注、使用和参与其中。开始发布,获取反馈,进行改进,并发布这些改进。这就是你实现增长的方式。

3. 试图构建完美的基础设施

我在新开源项目中看到的一个常见模式是,他们希望确保基础设施——网站、协作平台(例如 GitHub/GitLab)、持续集成和持续部署 (CI/CD) 以及其他一切——尽可能完美。这可能导致项目创始人因为担心其他不太完善的基础设施部分看起来有点不正规,而对发布已经准备好发布的相当一部分代码感到不安。

一个典型的例子是网站。一些项目会推迟发布,直到一个功能齐全、设计精良的网站到位。不要这样做。

专注于建立足够的基础设施,以便能够协作构建软件。发布你的软件,提高知名度——这将促进你的社区发展。随着社区的发展,你将获得更多人手来帮助完善你的基础设施。

4. 不执行行为准则

近年来,关于多元化和包容性的问题浮出水面。自然而然地,我们希望确保我们的社区是多元化和包容性的。无论这是否是正确的事情,多元化的社区都能带来更好的结果。

许多社区在启动时没有考虑他们希望看到什么样的行为。对许多人来说,社区应该是快乐、有趣、引人入胜和包容的,这是理所当然的。

一些项目通过制定行为准则并将其发布在他们的网站上来正式化这一点。但这还不够。执行良好行为的方式是确保项目领导者身体力行地践行良好行为。始终将负面行为事件扼杀在萌芽状态。不要只是试图忽视不良行为,因为它会恶化。同样,如果有人犯了错误,也不要羞辱他们。通常,友好地私下说几句,要求人们更加尊重,就可以解决问题。

5. 失去焦点

我知道,我知道,现在听起来开始像工作了,对吧?但说真的,虽然开源的主要乐趣之一是无限的创造潜力,但许多项目之所以挣扎或关闭,是因为他们把自己和他们的焦点分散得太薄。

不要试图满足所有人的所有需求。随着你的项目逐渐发展壮大,将会收到来自热情用户的数百万个请求。保持专注于你的目标,但始终鼓励人们加入项目并扩展其焦点和潜力。

但重要的是,虽然“欢迎补丁!”是对愿望清单的常见回应,但不要只寻找补丁,要寻找维护者。你最不想做的事情是为别人的工作维护技术债务。

6. 在太多地方进行太多讨论

我们被大量的通信平台所包围,例如 Slack、Mattermost、邮件列表、IRC、论坛、问题跟踪、视频会议等等。为了确保每个人都参与进来,在所有这些地方都露面是很诱人的。这是一个错误。

正如我在 *关于沟通的喧嚣* 中讨论的那样,通信渠道有不同的类型,我将其大致分为结构化渠道和非结构化渠道。

我推荐以下准则

  • 所有错误和技术讨论都放在 GitHub/GitLab issues 中
  • 在 Discourse 驱动的论坛上建立一个通用的“社区俱乐部”
  • 建立一个实时聊天频道,人们可以在其中进行快速和非正式的讨论

每个频道都有不同的用途,并非所有频道都是必不可少的。Issues 最重要,其次是其他频道。

再次强调,保持专注,并将讨论保持在相对集中的位置,这将建立势头。

7. 过分严肃

最后,这一切都应该是为了乐趣。太多项目把自己看得太严肃了。始终专注于享受乐趣,在社区成员之间建立良好的关系,并互相逗乐。

开源的基石建立在积极参与、富有创新精神的社区成员之上,他们具有将新想法付诸行动的创造性天赋。始终保持这种敏捷和创新的精神。这将有助于你的项目蓬勃发展。

祝你好运,如果你对新项目应该避免的错误有其他想法和建议,请在评论中分享。

User profile image.
Jono Bacon 是一位领先的社区经理、演讲者、作家和播客主持人。他是 Jono Bacon Consulting 的创始人,该公司提供社区战略/执行、开发者工作流程和其他服务。他还曾担任 GitHub、Canonical、XPRIZE、OpenAdvantage 的社区主管,并为多家组织提供咨询和建议。

16 条评论

我很喜欢阅读你的效率提示。
感谢你的提示。

这是我的一点看法

- 记录任务、里程碑、成就、反馈等。
- 跟踪任务花费的时间和资源

也在 README 中添加项目目标。似乎较大的项目有预定义的目标,可能是因为一些用户的拉取请求与维护者的意愿方向不同。

回复 ,作者是 Yigit Kocak

做得好。
你的关于光说不做的第一点,可以通过尽早建立某种关于项目的想法、计划和范围的信息库来部分解决。随着项目的发展,这个信息库也需要发展,但这有助于约束一个变得过于宽泛且深度不足以对用户有意义的项目。
此外,这个信息库可以成为最初文档的核心,以便尽早以连贯的方式向用户和未来的贡献者解释项目是关于什么的。

针对后续文章的思想实验:对于新项目,首先应该关注哪种文档更重要:路线图和“这个很酷的东西将如何修复你的小部件!”使用文档,还是技术文档、清晰的构建脚本以及吸引潜在贡献者的东西?

也就是说,对于刚起步的新项目,你如何考虑改进用户体验,以及改进开发者体验?

如果你也写了那篇文章,请告诉我——如果没写,我就需要考虑一下了!

回复 ,作者是 Greg P

我认为,尽早地,对文档的支持和创建应该成为项目 DNA 的一部分。开始得越早,你就越能防止文档小山变成大山。还有一个反馈循环,即创建文档最终可能会揭示一些操作上的不合逻辑之处,这些不合逻辑之处需要在代码中以某种方式处理。

回复 ,作者是 Shane Curcuru

这很及时。就在昨天,我向 OpenNMS 团队发送了一条消息,关于整合我们的一些沟通渠道。

对于代码来说,这很有效:我们在 github 上管理我们的代码,并使用 Jira 管理 issues。对于“实时”通信,我们过去使用 IRC,但现在已经转向 mattermost 实例 (chat.opennms.com),并带有 IRC 网关,所以这方面已经覆盖了。

但我们仍然有邮件列表和一个名为 Ask OpenNMS 的在线论坛。这些列表托管在 Sourceforge 上,我建议我们将所有内容都转移到论坛。你可以配置论坛在添加内容时给你发送电子邮件,但我知道放弃邮件列表会遇到一些阻力。

好观点。关键问题:你认为每个沟通渠道用于哪些任务?同样重要的是:哪些类型的人使用每个沟通渠道?

Apache 项目默认使用邮件列表(从我们的历史来看),这往往适用于积极参与代码开发的开发者。一些较大的项目有论坛——用于最终用户问题、配置以及如何整体使用产品。

了解不同类型的对话是否集中——或者也许尝试首先转移一组对话(可能是开发者/代码构建方面的讨论)可能会有所帮助。

回复 ,作者是 Sortova

我最近读到的一篇文章指出,“它会扩展吗?”是一个糟糕的问题,不应该在项目的早期提出。你应该使用最快编写的愚蠢算法,现在能用就行。如果你的项目足够好,将会有一个 2.0 版本,你可以在其中用树替换链表。或者对你的数据库进行分片。随便什么。但是,如果你在发布 1.0 之前试图在二十个不同的方向上进行扩展,你将无法发布。

#2(试图发布完美的第一个版本)是我大多数项目失败的原因 :(

#2 和 #3 都是工程师的症状:它还没有准备好,我不想在它完美之前发布!如果你想发展一个开源项目,你 *具体* 如何定义增长?

你想要培养的是贡献者的增长。而不是代码。所以“尽早发布,频繁发布”至关重要,因为新手通常会从下载 *发布版本* 开始,然后——如果他们感兴趣的话——开始查看代码。

大多数人对你的代码不感兴趣。他们感兴趣的是它为他们解决什么问题。拥有发布版本——即使是不完整的——是新手开始了解你的项目是否有趣(对他们而言!)的方式。

此外

错误 #0:没有 LICENSE,最好是众所周知的 LICENSE(MIT、Apache、GPL)。

错误 #... 嗯,这个没有编号,它是一个名称:没有好的 README。一个真正告诉人们你的代码做什么、如何使用它以及如何贡献的 README(或指向这些内容的 *明显* 指针!)。

额,是的,Jono,文章很棒,但是还有很多数字需要添加到里面!

2 & 3 我不太清楚...

我理解为什么做完美主义者是不好的,我离完美主义者还很远(不断学习意味着你不可能成为完美主义者,因为明天你会学到更多需要考虑的东西)。

我只是觉得没有足够好的基础设施或质量可能会造成损害。我认为另一个非常糟糕的事情是,以盈利为主要驱动力的开源(或闭源)开发。我认为这比高标准更能更快地扼杀大多数项目。

很棒的文章,我认为它简洁地表达了许多常见的陷阱。发布版本很棘手,你想制作包含所有功能的良好、稳定的版本,但它们需要是定期的,而且我同意,如果你对你的第一个版本(至少有点)不感到尴尬,那么在展示足够的希望与保持平衡之间是很困难的。这些年来,我已经学会更加放松了。

近年来,随着期望的提高,基础设施建设变得更糟了。我认为这是一件好事,但这必须与实际发布东西、向前发展相平衡,而且我想说还要确保你没有在基础设施上投入太多资源,以至于损害了新功能的发布。

写得很好,感谢你整理这篇文章!

实际上,“执行行为准则”是一个错误,它会将我们带入思想意识的回音室,在那里思想的多样性受到压制。这可能是你可能犯的最大错误。谷歌是这种行为的最新例子,他们的业务因此而遭受损失。而且,好像我们多年来没有像埃里克·S·雷蒙德这样的人对这种现象发出警告一样。

Creative Commons License本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.