• 修复admin鉴权问题导致无法正常操作的严重bug
• 修复admin图表配色问题
• 修复移动端获取服务器自定义名称时无法正确获取到内容的错误

我开发了一款 IM 项目 Tailchat，终于在2023年6月28日凌晨达到了 1k star 的里程碑。我感到非常激动。当然，对于许多知名开源项目来说，这只需要几天就可以完成，但对于我来说仍然非常重要。因此，我非常想分享一下我作为一个开源爱好者是如何运营开源项目的。

首先，我必须承认我是一个非常典型且纯粹的程序员。我没有背景，没有资源，也不擅长沟通，可以说是比较社恐的人。对于像我这样的人来说，困难并不在于如何开发一款应用，而是在开发完成或者达到一定阶段后如何推广我的应用，并让大家能够理解我的理念。

曾经，我天真地认为开源只是将源代码分享出去，让大家能够看到我的代码。然而，我逐渐意识到开源更像是一个企业，不仅需要开发自己的产品，还需要想办法将产品销售出去。

一个好的官网非常重要​

官网是一个应用的门面，对于许多库来说，README就是它们的官网。然而，对于相对庞大、复杂的项目来说，简单的README可能无法提供足够多的信息，这时一个独立的官网页面就变得非常重要。

一个优秀的官网能够增加用户对项目的信任感。通常情况下，我对开源项目的基本信任感来自于以下几个方面：是否有README或官网、是否有足够多的star以及使用量/下载量如何。

举个例子，Tailchat的官网 https://tailchat.msgbyte.com/ 经过几次迭代后变得相当出色。首屏几乎占满整个页面，并展示了桌面端和移动端的预览图，这意味着我的项目同时支持桌面端和移动端。然后简洁明了地列出了我认为重要的特点，这些特点也是我希望我的产品与其他类似项目区分开来的关键点。

官网是产品思考的体现。通过官网向用户传达自己的想法，让用户理解你的设计哲学，明白你为什么要做出这样一个产品。

另一方面，官网也为用户在使用过程中提供指导。除非你的产品不需要用户做任何操作，只需打开即可使用（比如各种小游戏），否则一个完整的文档对用户的帮助远远超出你的想象。

不要认为只因为开源了源码就可以不去做这些事情，代码本身就是文档。回想一下自己的开发经历，在使用一个库时，除非万不得已，否则我们不会选择去查看源码。对于库来说都如此，更何况是一个完整的项目呢？

对于开源项目来说，一个完整且兼容多平台的部署方式是最基本的底线。

注重差异化​

对于开源项目来说，向其他人介绍自己的产品的时候最简单的方式就是 xxxx 的开源替代品, 这里的 xxxx 一般是你耳熟能详的商业应用。这样可以非常快速的让用户对你的产品有一个很基本的概念。你也能通过大家的共识快速建立起一个基本的概念。

比如你想做个在线商城，那么你就可以说自己做了个淘宝的替代品。比如你想做一个论坛那你可以说你是要做一个discuz的替代品。

但是，在说自己的项目是 xxxx 的替代品的同时需要时刻明确自己与对方的差异点，而不是在不断复刻其他项目的功能。比如我在与其他人介绍、推广我的项目的时候我会说我是一个IM，是discord/slack的开源替代品。但与此同时我也会强调不仅仅是一个IM。我会与对方谈论为什么我们需要插件系统，以及插件系统可以给我们带来什么，为什么我会花2年时间来做底层架构、打磨体系来完成这套架构，以及为什么我觉得我的产品是优于其他的项目的。

这是一件非常困难的事情。因为大部分的用户并不会在乎你的差异。对于大部分用户来说只会用到最基本的功能，而且用户更加关注的是是否能满足自己的需求。一件非常悲伤的事情是不论做什么你都会有很多的同行与你竞争，让用户决定是否用你的产品的理由并不是因为你的功能多么强大，而在于你的功能是否能满足需求 —— 当然如果你的功能足够多，多到所有能想象到的需求都能满足也行。但是那是企业做的事情，如果你是个人开源者更要学会专注，专注于打差异化。

重视国际化市场​

多国语言是非常必要的一件事。虽然中国有很大的市场，但是我们把目光放远一些，中国市场也不过是全球 1/5 的市场。特别是在开源领域，你作为开发者更加不必在乎语言的边界。因为你不受控于各地的法律法规隐私政策的差异。作为开发者只需要做好你的产品就行了。

因此，支持多国语言非常重要。至少支持英语，能很大程度扩展你的受众范围。如果你对自己的英语水平不够自信，请善用翻译软件。

另外，你可以多多去海外的平台宣传自己的应用，不仅仅是局限于国内的平台。如 Reddit、Hackernews、medium 等。因为海外的用户对开源的接受度、理解度更加高，如果这些用户能够认可你的项目的话在开源领域会比国内用户带来的帮助更加多。一个很悲伤的事实是，国内开发者天天996根本没有时间再去为开源做贡献，特别是个人开源的项目。

通过完善的文档、自动化测试给用户带来信任感​

虽然一本厚厚的说明手册并不会给产品本身带来任何的实际价值，但至少会让在这个产品上投入关注的用户感到安心。

安全感是一个很玄学的事情。作为开发者你可以说自己的项目非常简单易上手，根本不需要任何文档。但是哪怕不去看这些文档，这些文档存在的本身会给使用者一种信任，至少能表示你对自己的项目投入了足够多的关注。

类似的还有自动化的测试脚本，前者是给普通用户的，后者是给开发者的。

作为开发者，我们都知道CICD的重要性。CICD是保证项目的代码质量的重要方式，也意味着一个项目的底线。如果一个没有任何CICD工作流或者都是失败的工作流。那么我会非常对此非常具备不信任感。

开源项目天然的就相比商业项目是缺乏信任感的，因为后者是拿来牟利的，且是能够用来支持起企业的运作的，意味着至少不会有什么问题。而开源项目往往起源于兴趣，天然的就给人不靠谱的感觉。特别是在前期star数比较低的时候更是如此。

怎么打破这种不信任感也是作为开源的维护者想要让自己的项目起来的重要因素。

将你的内容串在一起，减少探索成本​

一个非常不好的例子在于把相关的内容放的到处都是，让用户能看到所有的内容非常困难。

将重要的内容在一个地方被索引是非常重要的事情。比如你的社交媒体、你的文档、你的功能手册、你的演示环境、你的各种技术博客….

减少用户的探索成本，因为如果成本过高用户很有可能选择放弃。这就是为什么大多数网站都会在页脚留有各个关键

如果你仅README文件，那就把所有的链接都添加到文档中，让用户能够清除知道有什么内容，这些内容是干什么的。

另外，不只是你的各种内容，你的项目本身也要牢记这一点。比如上来就是一个手机号注册就很容易让人劝退，而适当的公开内容体验可以更好的让用户体验到产品的魅力从而长期留存。在 Tailchat 中我是这么做的, 用户可以使用临时账号登录，只需要填入一个昵称即可体验到完整的功能。当用户决定长期保留你的账号时，你可以走注册流程认领该临时账号。如果想要让用户加入到你的社群中，你甚至可以把入口直接换成邀请链接。

类似的，如果你的项目包含了多个子项目。monorepo会是比多个仓库更好的选择，我曾经写了一篇博客就是从技术角度说的这个，谈论从把多项目合并成一个项目中获得的收益 。

从开源运营的角度来说，多个项目仓库不但更难让用户看清全貌，也会打击开源贡献者的信心，因为谁都期望大项目的贡献者上有自己头像，哪怕仅仅是改了文档的一个错别字。

重视社区的运营，重视生态​

社区的运营是开源项目中非常重要的一环，只有来自社区的不断反馈才能拉起开源项目的正循环。最简单的社区就是建立一个微信群或者discord群。我早期在运营的时候想着既然我自己是做IM的，为什么要到其他的IM平台上去运营我的社区呢？然而这是错误的，因为作为开发者，应当去迁就用户而不是让用户迁就你。如果用户更加喜欢用微信，那么你就应当选择使用微信。如果用户更多使用discord，那么你就应该在discord建立自己的社群。保持社群的活跃才是第一要素。

我非常喜欢Notion的大使文化与社区文化。建立良好的社区驱动的生态是一个成功的开源项目必不可少的基本素质。虽然我的项目还远远达不到这个阶段，但我研究过很多成功的开源项目无一例外。简单的说开源是理想主义者的狂欢，一个好的开源项目则是一群理想主义者的狂欢。让用户认可你的项目，并自发的宣传，这是一件非常困难的一件事，但是是有必要去做的，一群人前进会比一个人前进轻松很多。

另外一方面，需要关注开发者价值。什么是开发者价值呢？就是你的项目对开发者能够带来什么。在推广Tailchat的时候我往往会与vscode进行类比。vscode就是插件化的文本编辑器。其本体就是一个拓展中心 + monaco 编辑器，其价值在于良好的开发者生态。让不同的开发者能够通过vscode的插件系统来实现自己的想法，集成不同的语言支持。不知道是否还有人记得在github还没被微软收购的时候 github有一款自己的编辑器 atom。我也非常喜欢用，自从微软收购了github后atom就被弃用了。我相信微软也是看到了插件系统的巨大潜力。而Tailchat也是以插件系统作为设计之初的底层能力。我很喜欢的一句话是: 得开发者得天下。这也是生态的力量，当生态起来了以后，你的产品就很难被其他同类应用替代了。

恰当的时候回访你的早期用户​

在早期维系种子用户是非常重要的，适时的回访你的早期用户，让你的用户感受到自己被重视，这个产品的积极性，这将会大大增加你的用户转变到社区贡献者的可能性。

很多技术人会觉得，只有代码贡献才是贡献。其实了解代码的毕竟是少数，更何况要匹配你的项目的技术栈的话就更加少了，很多人如果能提提建议，打打下手做个国际化翻译我觉得对于一个开源项目来说就非常不错了。最重要的是这些东西会成为你前进的东西。人想要不断前进要么靠金钱，要么靠兴趣，而社区就是持续不断为你的兴趣充能的加油站。

在我接触到的早期创业者，都会很喜欢与自己的用户约个会，聊一下自己项目的发展以及用户的看法。如果你觉得自己做不到这一点，用文字问候一下也是可以的。相信我，收获会比想象中的更加大。

积极写博客，写技术文章​

我很反感像广告机器人一样在各种技术社区中通过不断的、重复的发送自己项目的介绍来推广自己的项目。虽然看起来好像有点读书人的清高和不食肉糜，但是我依旧觉得这种行为是非常影响其他人的体验的。有的人可能会说，相比有人黑总比没有人知道好，但这是牺牲其他人的体验而成就自己的自私行为。

我作为技术人的选择是，多写博客，多写技术文档。在技术文章中推广自己的项目。我期望这应当是一个双赢的行为：作为读者的你收获到了知识、作为作者的我收获了曝光。

同时，写文章也是对自己思路的一个整理，这点和写技术文档是差不多的。曾经的我非常反感写技术文档，因为直接写代码就能写完的东西还需要写技术文档来约束自己。一般来说写技术文档的时间和写代码的时间是差不多的，因为要写出一个正确的技术文档往往需要确定方案的可能性，基本上确定方案的可行性大部分的代码就写的差不多了。而现在我会理解写技术文档的必要性，更多的是为了整理自己的思路。写代码是简单的，写代码让人能够理解是困难的，写了代码以后让人能够理解并且后期好维护是最难的。曾经的我是依赖自己的经验来实现后期易于维护，而技术文档就是在我依赖经验的基础上追加了一层CICD来约束行为。写技术文章也是一样的，在闷头写代码的同时要把东西整理出来形成方法论。这也是一种对自己能力的提升。

总结​

开源的到底是坎坷的，而且大概率是最后没有实际收益的。这也是为什么我会说开源是理想主义者的狂欢。

开源项目往往不追求盈利，付出又多，除了写代码还要投入精力去宣传，去运营。对于大部分人来说都是一件吃力不讨好的事情。

当然，我这里说的是真正的、需要长期付出的开源项目。如果仅仅是为了star高，来用于求职或者其他目的的话其实有很多方式，很多项目代码没几行，但是star数都是几十k这样的蹭热点的项目在github上还是有不少的。

相反的，我的选题无疑是红海中的红海，在C端十几年前就有早早占领了市场的巨头，在B端也有很多强大的竞品进行竞争。同样在开源也有无数的同类产品相互竞争。我之所以依旧选择IM作为我的开源项目方向，并且为止付出了数年的努力。我也相信我的设计理念会在一堆同质化严重的同类竞品中脱颖而出，当然不可否认的是会有失败的可能，可能这就是理想主义者，我愿意为我的理想付出心血。

我相信，世界往往是被理想主义者所改变的。如果可以选择，我更喜欢与一群理想主义者一起共事。相信看到最后的你也一定是一位热爱着开源的人，共勉，一起走下去。

• 增加第三方登录插件(com.msgbyte.iam)，目前支持github登录, 相关部署文档见 iam - Third party login
• 收件箱支持markdown格式的内容
• 增加系统消息发送能力，目前支持单人发送与所有人发送markdown格式的通知。可以在admin后台看到该功能入口
  • 所有人根据服务器注册用户数量发送，如果人数过多不保证能实时收到。
• 增加了注册时允许修改昵称，强化用户修改昵称意识
• 增加了com.msgbyte.env.electron插件，为桌面端做准备
• 美化仪表盘图表颜色
• 美化github star提示，增加emoji
• 修复一些已知问题

另外，桌面端将于不久之后会发布第一个内测版本

• 新版admin已经正式上线替换旧版admin系统
  • 如果还是期望使用旧版的admin系统可以使用admin-old.yml, 在后续版本中镜像将不会继续构建旧版admin，如果你有什么需求是需要旧版admin但是新版admin没有支持的，请尽快开启issue告知我们
• 优化了聊天页面的字体，美化在windows平台上的字体表现
• 修复了在用户名包含空格时@功能的用户名称无法正常显示的bug
• 修复了临时用户可以验证邮箱的bug
• 增加了admin文件路径的预处理
• 增加了群组独立页面，现在可以把群组页面单独抽离出来了
• admin增加批量删除
• admin增加用户字段显示逻辑
• cli增加了smtp test命令，你现在可以通过cli工具快速发送测试邮件来验证整条链路
• cli增加了各类压测命令，用于测试用户在线人数
• health接口增加了更多上下文，包括实例id，进程信息
• 发布了压测报告，你可以在这里看到压测报告内容: Tailchat 压测报告新鲜出炉，万人消息广播完全接受只需1.2秒

作为一个即时通讯应用，Tailchat 天然就需要具备能够处理高并发多人在线能力的需求。

为了衡量Tailchat在处理大批量用户上的处理能力，给予我们的客户有足够的信心，我们决定花时间来测试在实际生产环境中实际表现。

因为为了面对来自不同程度与需求的用户的规模要求，Tailchat 的底层设计是基于分布式架构，这意味着我们可以通过水平扩容来承载不同的规模的业务需求。

但是分布式的缺点也在于花费了更多的资源在数据的通讯与转发上，在小规模的运行中比不上传统的集中式架构来的快。

这看上去是一个鱼和熊掌不可兼得的矛盾，但是为了同时获得两者的优势，Tailchat 在单实例部署上做了一些特殊的优化，即最短路径原则。这意味着在微服务之间相互调用中如果有且只有自身可以消费则跳过转发阶段直接把请求发送给自身。

这使得如果性能足够的情况下，单机的能力会优于集群。而当单机无法支撑足够的业务需求时，切换为集群部署用多个实例一起来承载高需求的业务规模。

压测方式​

为了衡量 Tailchat 在多人在线情况下表现，我们选择了消息发送与接收能力作为衡量标准。

即: 当一个群组中有若干人同时在线时，一条消息从发送开始到所有在线用户都接收到消息的转发这条完整链路所需要耗费的时间

因为对于IM项目来说，传统的90分位/99分位数据是无意义的，只有所有用户都能接收到广播的消息、不丢失才是最基本的能力表现。因此对于Tailchat的要求也是只看消息传播耗时的100分位数据

同时，测试在多人在线时，常驻cpu与内存的增长表现

本次测试由 sealos 提供集群服务支持。sealos 真的很方便！

压测方式主要分为三个步骤:

1. 批量注册用户，并把注册后系统返回的凭着(Token)记录到本地文件
2. 加载上一步存储的token，并按照token进行登录并建立长连接。当所有用户登录完毕后，记录常驻资源增长。
3. 当所有用户登录完毕后，选定一用户连接并发送消息到指定群组的指定频道，同时记录开始时间。当所有的连接都接收到这条消息后，记录结束时间。此时记录结束时间，计算中间耗时。该方法统计数次得到多组数据以消除误差。

压测概述​

本次压测分别测试了 100用户、500用户、1000用户、2000用户、5000用户、10000用户同时在线且在同一个群组的性能表现。

为了尽可能压榨 Tailchat 的性能，我把选择使用最低限度的配置上限，来测试尽可能多的服务。在3实例的case中最高支撑到800人就出现问题了，拓展到5实例后成功支撑起1000用户，但是当用户同时在线人数上升到1300左右的时候又出现了瓶颈。此时我猜测可能是因为linux系统自带的ulimit导致的，毕竟在此之前没有做好相关的定向优化。此时我觉得集群测试可能要暂时告一段落了，我转移到window平台。

果然不负我的期待，在windows平台没有相关的限制，成功让 Tailchat 的在线人数突破到 2k、5k，乃至10k的限制。此时我认为我们本次的压测工作已经符合一开始的期待了。毕竟万人同群已经达到的同等行业的上限。当然我认为其上限远不止于此，因为还有很多的优化空间。

在最高的 10000 用户用例中，我们测试了5次从消息发送到所有用户接受到消息的耗时。最终我们发现 Tailchat 给出的答卷是1.2秒, 即1.2秒内一条消息会发送到所有的用户。这个数据我认为还是比较理想的，毕竟有1万人同时在线的群往往实际人数会达到10万人以上。当然在后续对大量用户的情况会进行进一步优化，这个数据只会是一个起点而不是一个终点。

完整报告​

具体的压测报告可见: 压测报告