首先，我必须承认我是一个非常典型且纯粹的程序员。我没有背景，没有资源，也不擅长沟通，可以说是比较社恐的人。对于像我这样的人来说，困难并不在于如何开发一款应用，而是在开发完成或者达到一定阶段后如何推广我的应用，并让大家能够理解我的理念。
曾经，我天真地认为开源只是将源代码分享出去，让大家能够看到我的代码。然而，我逐渐意识到开源更像是一个企业，不仅需要开发自己的产品，还需要想办法将产品销售出去。
一个好的官网非常重要
官网是一个应用的门面，对于许多库来说，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 作为我的开源项目方向，并且为止付出了数年的努力。我也相信我的设计理念会在一堆同质化严重的同类竞品中脱颖而出，当然不可否认的是会有失败的可能，可能这就是理想主义者，我愿意为我的理想付出心血。
我相信，世界往往是被理想主义者所改变的。如果可以选择，我更喜欢与一群理想主义者一起共事。相信看到最后的你也一定是一位热爱着开源的人，共勉，一起走下去。
