三年 Obsidian ——关于产品、社区与个人的思考

前言

参与社区远比想象中难，但又比想象中简单；仅以此贴纪念一下参与到社区的第二个年头，使用 Obsidian 的第三个年头；

在深度参与到社区建设以后，由于我已经从原来的只写教程逐步转变成构建工具来解决个人以及部分人群的需求的情况，我逐渐在这个过程中领悟了一些心得，根据其发展过程，我分成了以下的几点：

- 产品要至少有一个闪光点

- 产品发展感想

- 上手是最快的学习方式

- 社区孕育社区和产品

注意，我以下内容中含糊了速录软件（服务）、文档软件等各自的偏向，统一将他们都视作一类型笔记软件，只要这个产品具备标签、记录以及基本的筛选搜索功能，那么在我眼里就是一个最基本的笔记软件。
此外，通篇都不会有严格论证。

产品要有一个从一而终的闪光点

闪光点是用户是否会追随产品的基础因素

如果现在有一个新的产品开发者，希望自己能仿照 Obsidian 的闪光点，做一款大而全而且无边无际的产品，我会建议他至少让自己的产品找一个基本的闪光点，再去追求其他功能闪光点。稍微花时间去将 Obsidian 产品的闪光点拉出来，不考虑单独功能带来的效果，其至少有 基本闪光点：

- 稳定

- 快速

- 便宜（本体免费使用）

- 方便（打开就可以用）

- 易用（但上手难度曲线比一众大纲类或者块类产品高）

功能闪光点：

- 核心功能（包含文件体系、样式功能、图谱、Canvas 等）

- 插件体制

- 社群

其中 Obsidian 最初吸引我的并不是它的插件体制，毕竟我开始使用它的时候，它还只是一个非常简单的双页面预览笔记软件，而是他的稳定和快速，它几乎完美适配我那时候使用的 Typora 写出来的东西，而且解决了我使用 Typora 时候的一大痛点，那就是多个笔记之间的联系几乎是没有的。而关于它的快：

冷知识：Obsidian 开发者 Licat 曾说过自己最讨厌延迟（Lag）

也许你会认为基本闪光点不一定都是闪光点，有些时候他们只是一种基石，可以打磨成闪光的方向，例如如果你是一个非常多功能的程序服务，那你追求的可以是方便，但是易用程度的打磨往往就需要付出非常多的时间和努力。

以下会就便宜和插件体制分别提供一些我的想法：

关于便宜或者免费

完全用爱发电的开发不可持续，除非完全不接受 Feature Request | 长期不更新 个人开发者的产品或服务定价应该尽可能将免费与付费服务的权益拆分

如果你作为一个产品或者服务的开发者，在你考虑了五个常见的基本闪光点（稳定、快速、便宜、方便、易用）后，选择了便宜作为主要的定位，那你在没有其他的四个闪光点的情况下，你至少要保证及格线，

我之前常用的 Anki ——桌面端是免费的，但是它易用程度虽然并不高，但是对基础用户来说，至少会有一个最基础的快速操作步骤；与之类似的一众背卡软件或者服务，例如 Quizlet 等，虽然并不便宜，但是在易用程度上都加到了最大。

最坏的情况是，如果你的产品并没有这些基本闪光点，或者只是其中任意一个闪光点，其他闪光点都还没到及格线，说实话，这种产品在我眼里只能算得上是 Alpha 阶段的产品，甚至还不能供人使用。你不可避免地陷入，你必须创造出一个特别闪亮直至掩盖了别的缺陷的功能闪光点来吸引用户（类似早期的 Project Meta、非常早期的 Notion （但是他们至少会在稳定性上及格）等）。

当你在“便宜”这一点上做到了极致——免费。免费对于用户与你是一个约定，一旦你初期就设定了免费，那如果你要安排产品的生命周期，你是否有对自己创造的产品有一个最低回报的期望，包括但不限于：咖啡、小钱、荣誉或者引流。如果这些都没有，自己完全是用爱发电的话，用户并不确定你是否会长期维护这个产品，这个时候又出现了新的处理方案——开源。

在我看来，开源其实更多是给用户一个最低可用的保证，保证用户后续可以基于这个开源的产品进行更改来满足自己日渐变强的欲望；但对于非开发者的用户来说，这个反而超出了他们的能力范围，毕竟不是每一个人都有时间来更改一个软件。

所以，在我看来用完全开源免费来吸引希望稳定使用的用户并不可靠，这种带来的单纯是开发者个人的长期用爱发电，最后放弃产品的结果；相反地，我认为一旦设定了免费这一条道路，就一定同时要设定好另一个能支撑自己花费时间所兑换的内容的道路，而不仅仅是让人觉得你可以白嫖。

于是，Obsidian 提出了新的解法，利用社群保证人流量，从而做起卖周边的方式（在我看来，同步就是卖周边）。免费但高级服务付费，这是非常常见的 SAAS 软件商业模型，但并不是每一个笔记软件都能做好这一步，类似国内的印象笔记就陷入了这种矛盾（当然这个也是因为 Obsidian 至今还是小团队，营收压力并不大的影响）。

而我在笔记软件类别中发现的常见解法是：

- 同步、发布服务收费

- 教学课程收费

- 纯赞助收费

以上的解法依次不稳定，各个解法的软件类别都较多，甚至在双链软件类别中都有不少的分类情况。但确实是个人开发者应当考虑的发展方式。

关于插件体制

用户总是有非常多的功能请求，如果你有兴趣可以去 Obsidian 的官方论坛上查看 Feature Request 的数量，而这么多的功能请求往往是不管多大的团队都无法完全处理的；于是，这个情况下就会出现两种选择：“节制”、“ALL IN ONE”以及是否选择插件体制。

插件体制需要软件架构上的支持，因此一旦你是一款刚开发的软件，你就需要定调好自己的软件架构，例如 Obsidian 插件体制理论上是很早就布局了的：

- Roadmap 以及社区的言论中就已经肯定了 Plugins 作为主要的功能发展；

- 开发者过往的开发经历使然——Licat 早年很喜欢 Minecraft 也给他写了不少 mod；

- 开发者团队表示自己的产品更希望是一个“Unappointed”的产品，丰俭由人也是他们的想法以及实行的标准；

在我看来，Obsidian 是另一种“基岩版”的笔记软件

而这个插件体制则给 Obsidian 团队带来了 Obsidian 的发展时间以及空间，利用社区开发者补齐和别的更早开发的笔记软件之间的差距，进而逐渐增加自己的功能闪光点，从两年前传统的左右页面式布局，到后来的所见即所得以及现在的 Tab 类标签页，利用插件体制保证了生存空间和生存时间。对于一般的软件产品开发者来说，比起功能增加，如何在最开始就获得人场，显然更重要（这里就要开始提留存率等等等）。

因此，当开始有构建产品的想法以后，首要的就是确定好自己究竟是一款怎样的软件。例如尽管 Notion 早期是以 Block 为主要的宣传口号，能将所有的输入输出都以 Block 成型，构建成一个 "ALL IN ONE" 的文档（笔记）软件，但 Notion 后边也发现提供插件接口的必要性（不如说他们早期社区并不旺盛，社区大了以后发现 Feature Request 的数量实在是太多了，前期非常多的植入支持都是 Notion 方处理为主）

而反而是“节制”型软件，因为功能打磨上更为精妙，往往能够供养得起几个人的小团队，进而保证产品的生命周期不至于过短；例如，Flomo 或者早期的 Project Meta。但节制并不意味着简单，也并不意味着不能提供插件接口，Flomo 后续也是提供了 API 来增强其扩展能力。

因此，在这种情况下就会出现两种选择交叉以后的发展：

- 有人选择了“节制”+插件体制——Flomo

- 有人选择了“ALL IN ONE”+插件体制——Notion

- 有人选择了“节制”+无插件体制——Bear

- 有人选择了“ALL IN ONE”+无插件体制——印象笔记

当个人开发者想要做一款产品，我更推荐学习 Flomo 的策略，同时参考 Obsidian 的超早期就推出插件 API 的操作（如果没记错的话， Obsidian 其实是同一个时期双链笔记中最早引入插件市场和提供非常多插件 API 的笔记软件）。Obsidian 在产品运营上的成功其实是很难复制，但是如果考虑构建类似的发展路线的产品的话，早期自限加上提供扩展能力显然比不断地去应对不同用户的 Feature Request 来得精明。

小结

让产品拥有一个从一而终的闪光点，比起初期引入过多的功能导致软件服务不稳定来得更容易，而且也更容易让你的软件服务在同类别蛋糕下分得一成；但是这并不意味着除了这个闪光点以外其他的闪光点都无足轻重，注意，完美的软件虽然没有，但是好的软件至少是短板不会那么短，及格线以上的非闪光点能极大保证你的产品不会被别人用完一次就不用了。

产品发展感想

早期的用户反馈除了能快速验证想法的正确与否外，往往也能借助用户的反馈来极大增强自己开发下去的信心；或者及时更改当前的应用的发展路径以及方向

我们倾向于在制作产品的时候尽可能让工作流能明显地体现出来，在我看来，这并不足够。如果你吸引别人的闪光点并不是一个能在第一面就能展示的闪光点，那你需要花费比原来多一倍的时间来向别人展示你的优点，而用户在体验你产品的过程中，反而更容易被缺点所吸引，进而发表一些会容易让你感觉到挫败的观点。

同时，即使你的闪光点非常容易被人理解以及发现，如上文所述，闪光点是吸引用户进来使用的核心，同时也应该保证其它的基础闪光点不能有过短的短板，在这个过程中，我已经见过太多连稳定性都不能称得上及格的产品，完全不考虑留存率地进行宣传，致使最后不仅产品初期留存率低，坊间对其的印象都被污染成“会丢数据的产品”。

利用以上的思考，你就可以很快速地确定自己要做怎样一个产品，五个及格的基础闪光点和一个功能闪光点就是一个及格的产品，而在这个基础上的优化取决于你究竟想要花多长的时间在上边；甚至，你需要根据用户的反馈来决定哪些基础闪光点需要优化，以及需要增加哪些功能闪光点。

决定你在一个产品上做下去的因素除了外部因素，还有内部因素，例如成就感，一个点赞往往就是最好的驱动力，用爱发电的根源除了对产品的爱以外，还有其他用户提供的情感价值。

当你需要验证自己的想法的时候，可以让某一个功能很简陋，但是一定不能出现你可能的受众不能容忍的问题；例如如果你的受众是本来就已经习惯了 Obsidian 稳定的用户，那你创作的产品一定必须要有完善的文件处理机制或者数据保存机制，否则的话，那你不仅没办法吸引这些目标用户，还可能会让这些目标用户在评价你的产品的时候带上明显的主观看法。

这个在制作 Obsidian-Memos 的时候就出现了类似的问题，尽管 Memos 的底层都是依赖于 Obsidian 的文件操作逻辑，但是依然存在一些特殊操作能导致数据丢失，而这个就导致前期 Memos 非议远超于后期的非议程度；类似的还有 Logseq 早期。

插件也是产品

这里引入最后一个看法：

Obsidian 等有插件的软件/服务中的插件也许是一个最适合验证想法的去处。

也许你会认为依赖于别的平台的插件并不算得上是一个好的产品类别，其上限取决于平台的上限，但是对于个人开发者来说，插件往往可以视作第一优选，包括但不限于 Figma、Obsidian、Notion 等，都已经能够利用平台本身的特性来宣传自己的插件产品。

如果你疑惑的是，当数量过大的时候是否会出现难以推广的情况，在 Obsidian 社区中，你会发现后出来的 MakeMD 在短短几个月内就增长了接近十五万的下载量，然后即使是 Surfing 这种和原有的插件存在一些相似的插件，经过半年以后也抵达了一万五千的下载量。

社区对能解决问题的插件的欢迎程度是远比想象中要高的，更何况社区插件中总会有一众三四千下载量但是有十几二十个用户积极反馈的情况；暴论：而将插件视作产品，才能够快速地提高自身对待插件构建的需求水平，你如果连一个最小化的 DEMO 插件都没办法控制，那么更不可能实现一个更大的产品的构建。

小结

产品需要打磨，需要发展，也需要及时的验证，利用外部平台的特性来对其进行验证会远比完全从零开始构建一个产品要好，有些时候这甚至能成为构建第一桶金的方式。

而对于怎么构建产品——

动手永远是最快的学习方式

如果你对某一样事情有兴趣，用最快的方式做出一件事情

从使用 Obsidian 那一天起，我其实就在不断的折腾，虽然最初期的折腾都被后边的更新证明是徒劳的，而且也浪费了很多时间去折腾样式。

但得益于 Obsidian 早期的浓厚开发者社区氛围，我参与了非常多的插件 Issue 的建设，你没看错，就是单纯插件仓库的 Issue，我最早的插件 Issue 是贡献给 Natural Language Dates 的，它也是 Obsidian 最早的插件之一；而后，半年时间里面，我一直都停留在请求别人并且提出各种插件改进建议的发展进度上，每次我都不知道要怎么才能解决我自己的需求。

不过我开始想要学习 JavaScript 的心思并没有那么晚才展现，而是在我决定修改一个别人编译好的 main.js 来解决自己的功能，然后我将它发到了 Discord 上展示给别人看：

这也是我第一次因为动手制作东西被人实时鼓励了。不得不说，这个其实就是我最初去动手学的契机。

重新会看这里的发言和里面我想要实现的功能，属实是感触良多；

观点：实践性的科目如果不去动手做或者写，永远都得不到提升；

但是在这个动手的过程中，正常情况下，你都会遇到门槛，当面临门槛的时候，及时去请求别人的帮助或者去参考别人的做法远比完全自己琢磨有效得多（注意，这里的“及时”不是让你遇到问题就去问人，而是在你琢磨了一两天以后再过去寻求帮助）。

就这样结合者不断地提出建议，我逐渐发现了自己拥有一套自我成体系的产品想法，而到了 21 年的 8 月，实现一个应用的想法愈发强烈，我希望 Obsidian 中有一个查看所有事件的日历，但是因为一上来就接触 React 和 Typescript ，对于一个 Javascript 菜鸟教程都还没看完的我来说，属实是非常困难。但是这个问题又在后续不断地练习的过程中得到解决（是的，下一次练习是三个月以后的 12 月 15 日，因为我希望参加当年的最佳插件的评选）。

在完成了 Big Calendar 的基本功能开发以后，完成了第一个产品插件后的我，突然想要进一步地实现一个速录功能，也就有了后来的 Memos，在这个过程中，我发现我的知识是可以迁移的——在开发 Big Calendar 的过程中，我开发了一个解析文本中每一行的时间属性、以及任务内容，然后我发现其实可以将识别 - [ ] 的方式修改为识别 - HH:mm 从而实现速录；而且当时也正好是 Flomo 的兴起前后，我就去社区中寻求是否有人制作了类似的软件服务，于是也被我找到了 Memos 本体，后来的剧情就是我在 2022 年 1 月到 3 月的连轴转开发，直至将 Obsidian Memos 开发到了 1.9.7 版本（也是后边的稳定版本）。

从加入到 Obsidian 社区以来，我就在想，我应该去做一些什么，来回报社区成员以及开发者在我困惑时候提供的极其巨量的帮助，这种帮助和社区的前期浓郁的开发者氛围逐渐转变了我；
于是，两年前，我在给各种插件仓库写了半年多的 Issue 以后，我明白我只有依赖于自己才能做出能表达我的想法的插件，以及满足我非常独特需求的插件（例如 Gutters offset, Tab switcher, Surfing key），于是，我花了两三天的时间重拾大学写过的 NPM 安装教程博客，然后发现现在社区早就不用那么多门门道道，最后用 nvm 在我的小钢炮中装上了原始的环境；那时候刚好 PNPM 也兴起，然后又花了几天琢磨各种包管理器的区别、各种框架的区别、React/Vue/Svelte 的区别等等。

我也从完全的前端小白逐渐转变成能够理解并且贡献代码的前端新手。说实话，这些时间里面，我基本都在学习以及使用前端的各种工具、框架或者库的道路上，这些学习或多或少影响了后续我看待事物的方式以及看待个人发展的看法。

而现在再回头看一年半以前写的代码，再回头看半年过后的 Surfing，我都能发现自己在基本的代码能力上的非常显性的提升，这些提升的基础是来源于不断的动手去做。

也许你会问我这两年多是否都只是在写插件，而没有去处理个人的事务或者学习，那又未必——

不务正业？

我构建个人向插件一般是为了解决自己的问题而构建的，也就意味着我往往不会考虑别人的 Feature Request，例如非常冷门的 Tab Switcher 和 Surfing Key，这两个插件一个是为了让我可以在键盘操作的基础上直接切换不同的页面，一个是为了让我在不离开键盘的基础上点击任意的可点击元素；然后还有一众私有插件，它们或多或少都直接在我的工作上起到了实质性的帮助。例如表格生成器让我直接基于多篇笔记的 YAML 来生成一个表格，这样我就可以用 Notion 数据库的思路来编辑笔记。

然后我一边在满足个人的需求的情况下，一边又用满足个人需求的实现流程来提升自己；左手是工作，右手是代码，然后不断地用更高效的方式来解决工作中的问题，又为了追求更高效的工作而编写更多的插件（自己卷自己？）。据 Dataview 统计，在这个过程中，我陆续记录了 600+ 篇的工作笔记（喂 Chatgpt 写周报用）、200 篇的代码笔记（当 Code Snippet 用）和 1200 篇的心得笔记（当备忘录用），还有接近六千篇的资料收集笔记（这真的能称得上笔记吗？），最后，还有 690 + 个 Memos（一大半是收集来的沙雕图）。

在这个过程中，我也逐渐累积起了一套完整的笔记（产品）流——兴趣驱动实现：

- 基于兴趣深挖内容，然后记录在案；

- 基于上述记录内容，然后写作落实想法；

- 基于上述写作内容，然后写插件验证想法；

但是这个工作流程总是没办法让我在某一个方面上走到头，因为我的兴趣并不能支撑我做太久同一件事情，所以我往往会在解构兴趣带来的内容的基础上，直接花几个小时、好几天来处理它，然后将其落实成一个具体的产品或者写作内容（到自己满意为止就停下来）。

这个处理信息的方式给我带来了几个好处和几个坏处——

好处：

- 我可以非常快速地验证想法、记录想法和表达想法；

- 想法验证的过程中，可以很快速地得到反馈；

- 可以收集到非常多的反馈意见；

坏处：

- 每个产品都需要维护，需要花费非常多的心力；

- 不同的产品需要学习不同的技术，容易导致经验过于分散；

- 需要加班；

但是我发现随着我处理的插件越来越多，我构建新的插件的速度也越来越快，而且也越来越能泛化自己的经验到真正的个人项目的实现上，甚至给一些开源项目贡献。

吐槽：Obsidian——前端训练场

社区孕育社区以及产品

在我看来，给 Obsidian 写插件已经成了我验证想法以及提升个人能力的手段，我可以将在 Obsidian 写插件以及分享出去，用于考察某一个功能对用户的影响。而 Obsidian 社区中利用 Obsidian 本身的大社区进行小社区建设的人也越来越多，包括但不限于 Tasks、Makemd、Text generator、ava 以及 Fantasy group 等商业化运营或者社区化运营实例。而这些或大或小的群组又构建起了各种需求群体的百家生态。

小社区的发展引流来了更多的人，而大社区的发展又促进了小社区的壮大，最后构成了一个类似论坛中的各个群组的关系；Obsidian 本身的笔记软件的特性导致社区中的用户一般都是某一个方向的受众，这些受众又恰好会在产品初期提出更多的见解以及想法（考虑 Obsidian 早期的发展）。

随着 Obsidian 官方的 Discord 用户也超过了十万人，我现在提出一个不算成熟的想法：利用 Obsidian 进行初期的个人产品商业验证也许是一个非常低成本的方案（当然这个的前提是你的产品并不是一个传统意义上的笔记产品，而且需要一定程度上与笔记产品有挂钩）。

其优点一：在 Obsidian 中构建一个 DEMO 插件的成本非常的低，一旦有用户参与到你的产品建设流程后，再往下进行比起传统要在各大论坛上反复推广的行为，要简单得多；

其优点二：即使验证的内容不是插件，而是其他的个人服务类产品，也远比从零开始推广容易得多，因为你可以利用各种 Obsidian 的服务或者插件来构建一个独属于你的工作流；

其缺点一：难以摆脱 Obsidian 的影响，一旦 Obsidian 发生一些商业化的改变，那么只能随波逐流，或者另起炉灶；

其缺点二：Obsidian 社区并不适合做另一款笔记软件的宣传，除非做的产品和 Obsidian 能做的事情完全不相关；

其中优点一被 MakeMD 和或 Ava/Text Generator 几个插件所验证，优点二则被 Excalidraw 所验证；而其中 MakeMD 也收到了缺点二的影响（如果你仔细观察过 MakeMD 的社区的话，会发现它们依旧没办法将 MakeMD 和 Obsidian 本体的讨论所分开）

但上述提到的插件，或多或少实现了其半商业化运营，也确实验证了“社区孕育社区以及产品”的方式可行性。

要放权又要收权

如果你希望自己的产品的社区能构建起第二个、第三个子社区，那你最初期就应该寻觅适合作为你的社区管理的人员，这部分人员往往能非常忠于你所构建的产品，进而将其作为约束社区的主要原则——“不要脱离主题”；这个也是一众贴吧、Reddit 等的发展方式，要让用户半自发地围绕你的产品构建起一个爱好型社区，你可以提供相关的讨论频道、展示频道，甚至要为多语言来提供多语言频道，而管理这些频道的核心又是你找到的哪些始终愿意停留在社区中为你发声的人员，这时候你的放权远比管理更重要，一个由爱好者提升成管理的人员，其对社区的气氛的要求会远高于你从外部聘请一个没有相关的经历的人员。

但是你又要将非常多的必要的权限掌握在手中，就例如禁止用户分发一些安装包的初级权限，或者到能够处理乱发广告的人员的高级权限，这些其实都应该是在你手中。

利用合适的放权以及收权，你会进一步开始培养起来基本的社区氛围，进而会出现部分子社区壮大后又独立成立新的小社区，这种情况下只要其并不是对产品进行无理由的辱骂，那在我看来都是属于一个小社区的正常发展路径。

社区原则

基本的社区原则决定了你的社区会耗费你多少力气，早期对社区讨论内容进行管理的时候就应该有意识地控制其讨论范围应该是基于你的产品，而不是其它的产品（而和其它产品的比较往往都是由一个人或者两三个人带起，及时的提醒远比事后的暴躁地处理会更让人能够接受）。

围绕产品提出话题

将用户对 BUG 的抱怨暂时引到其对功能的展望和、或者其它相关的讨论等；早期 Obsidian 在快速修复 BUG 的同时，还引入了很多与笔记软件相关的讨论，包括但不限于 ROAM 的讨论（是的，早期你会发现有不少关于 ROAM 的工作流讨论）、纯文本写作的讨论、PKM 的讨论等。

而你如果做的是一款收集类软件，那你可以提供一些关于收集的讨论以及其它一些可行的讨论。

小结

社区的构建往往是伴随着产品的诞生就要决定是否进行的，如果你构建的只是一个一次性的工具产品，那么你可能不需要做类似的社区，但是如果你构建的是一个处理文档、保留数据的工具产品，那么一个良好的社区氛围就会极大推进你的产品的发展，甚至在你首次登上 Product Hunt 以及 Hacker News 的时候都会有很大帮助。

总结

回顾这三年，我觉得我最正确的决定是不再停留在一个用户身份，而是进一步去成为一个开发者以及社区管理者，站在开发者的角度我能看到的事情远比原来只是用户的时候多得多，而作为社区管理者，我又能从另一个角度去观察社区的发展以及生长。这段经历总会变成我珍贵的沉淀，构成 Boninall 的 all。