成立两年用户突破1500万，全员工远程办公、以开源为首选的小团队如何颠覆社交界？

本文将带大家深入了解一家全远程办公、以开源为优先方向的科技企业，如何建立起极具市场竞争力的社交媒体平台。包括同类小型团队能够从 Bluesky 身上学到什么，又该如何超越体量桎梏、创造商业神话。

Bluesky 是一款前景光明的去中心化 Twitter 替代社交平台。该公司虽然仅仅成立两年，2021 年才从 Twitter 手中获得 1300 万美元资金，且直到今天也只拥有不足 20 名软件工程师。该公司表示，Bluesky 的全球用户数量已从 9 月份的 900 万增加至近 1500 万。

社交媒体研究员阿克塞尔·布伦斯 (Axel Bruns) 表示，该平台为 Twitter X 提供了替代方案，包括一个更有效的系统，用于屏蔽或暂停问题账户以及监管有害行为。

他说：“对于那些想要获得 Twitter 曾经提供的那种社交媒体体验，但又不想受到极右翼激进主义、错误信息、仇恨言论、机器人和其他一切影响的人来说，它已经成为一个避难所。”

“更为自由的 Twitter 社区现在确实已经逃离了那里，并且似乎已经大规模迁移到了 Bluesky。”

在本文中，我们将具体探讨 Bluesky 团队的构成与工程文化，具体包括：

• 不同寻常的起点。上市企业很少资助可能成为其竞争对手的初创公司——但 Bluesky 却做到了。

• 团队构成。其工程团队成员中拥有创业经验的比例很高（约 70% 到 80%！），且几乎都没有加入过科技大厂。

• 技术栈。Typescript、Go、ScyllaDB、SQLite、React+Expo。

希望通过本文，能帮助大家理解这十几位工程师如何构建并运营起一款为千万用户产生巨大影响且长期保持快速增长的产品。随着零利率融资红利期的结束，这种规模小但效率高的工程团队越来越受到欢迎——相信未来“高效”软件工程团队将成为整个行业的常态。

正文：

Bluesky 于 2019 年以时任 Twitter 公司 CEO 的 Jack Dorsey 发布的一条标志性推文，拉开了自己轰轰烈烈的发展序幕。

Twitter 计划资助一支不超过五位开源架构师、工程师和设计师组成的小型独立团队，旨在开发一套开放且去中心化的社交媒体标准体系。希望 Twitter 未来能够成为这套标准的使用者。

申请人们纷纷向 Jack 发出私信，其中约十余位被邀请加入 Matrix 聊天室。Jack 在那里就讨论内容给出了进一步思路，内容如下：

团队的核心长期目标是为公共对话建立一项持久且开放的协议。该协议不属于任何一家组织，而是由尽可能多的组织参与贡献。其诞生和发展应当与公共互联网遵循相同的自然演进原则。

Bluesky 公司 CEO Jay Graber 就是当初小团队中的一员，其他成员还包括：

• Jeremie Miller：可扩展通讯与表示协议（XMPP）的积极贡献者，该协议如今得到 WhatsApp、Kik Messenger 以及 Zoom 等主流应用程序的采纳。

• Matthew Hodgson：Matrix 技术联合创始人，这是一种用于去中心化、安全通信的开放协议。

• Ian Preston：Peergos 联合创始人，该平台试图构建“下一代 Web”平台，允许最终用户控制自己的数据。他也是 Twitter 中的一位元老工程师。

可以看到，这支团队由多位去中心化消息传递协议的重量级人物和旨在推进和发展 Web 技术的创业者们组成。

2020 年年中，Jay 提议撰写一份关于现有去中心化社交网络和技术生态的综述报告。随着研究工作的深入，聊天室中的人数逐渐增加到约 60 人。到 2020 年底，Twitter 在该小组中发出了建议征集请求，包括 Jay Graber 在内的多位成员做出了回应。

Twitter 在 2021 年组织了一场面试，希望选出 Bluesky 项目的负责人，并于当年 8 月宣布 Jay 成功当选：

Jay 将出任 Bluesky 团队负责人！恭喜对 Twitter 乃至全体社交媒体的去中心化探索迈出新的一步。现在我们可以着手编码，加快先进脚步了。

尽管 Jay 被任命为 Bluesky 团队负责人，但大家当时还不清楚项目到底是要做些什么。

不同于以往项目，Bluesky 是以独立组织的形式存在，而并非 Twitter 下辖的业务部门。大多数情况下，当一家企业宣布为新计划提供资金支持时，肯定会将其纳入自家麾下。但 Bluesky 的情况则恰恰相反：Bluesky 从诞生之日起，就完全独立于 Twitter 之外。

Jay 自己花钱聘请了 Daniel Holmgren，并在敲定细节的同时着手设计原型方案。他们共同完善了 Jay 于 2018 年同技术顾问 whyrusleeping 共同撰写的协议——其中的核心设计也一直延续到了 Bluesky 当中。

该项目于 2021 年 12 月 31 日获得批准，当时 Twitter 向这支新成立的团队支付了 1300 万美元巨款用以构建 AT 协议，同时批准 Bluesky 完全独立运作。实际上，当时 Twitter 其实提出过一个条件：“Twitter 对 Bluesky 的资助不受任何条件的限制，除了一个条件：Bluesky 必须研究并开发出能够实现开放及去中心化公共对话的技术。”

对于那帮花着投资者的钱、追求大胆商业愿景的风投机构来说，这样的决策并不罕见。但是对 Twitter 这样的上市企业，以几乎免费的条款资助初创组织可就相当新鲜了。这可能是由于 Jack 本人对该项目抱有浓厚兴趣，同时也跟 Jay 对于项目核心使命的坚持有关。用她自己的话来说：

“关于组织独立性，我进行了长达六个月的谈判，并认定作为 Twitter 子公司的身份殊不可行。Twitter 公司的行动速度太慢，我觉得如果因为领导层的倾向性而扭曲了 Bluesky 的理念，那么这个项目很可能会胎死腹中。历史已经反复证明了这一点。”

Jay 告诉我们，她之所以拿出六个月时间展开独立性谈判，就是不愿 Bluesky 成为 Twitter 管控下的子公司。Jay 认为 Twitter 的行动速度太慢，年轻的 Bluesky 也很有可能被 Twitter 领导层出手砍掉。现在看来她的判断极其准确——2022 年 11 月马斯克买下 Twitter，并旋即做出大刀阔斧的精简。如果 Bluesky 真的存在，肯定也会成为被精简的对象。

在美国，大多数拿了风投资金的企业都属于营利性质的有限责任公司。但 Bluesky 不是。这是一家 C 类公共利益公司（PBC），意味着其主要目标在于追求“公共利益”、而非利润。

这种差异使得 Bluesky 较之常规营利性企业拥有一定优势：他们不需要像上市企业那样想方设法为股东提供回报，也不需要直接宣传营销自己具备商业可行性的产品。相反，Bluesky 可以专注于“开发出能够支撑去中心化公开对话的技术，并推动其大规模采用。”

但这也带来了风险，因为如此一来公司就不需要在短期之内确定明确的业务策略。而众所周知，策略是保障长期成功的重要前提。

我们带着这种担忧询问了 Bluesky，毕竟如果专注于履行使命而非赚钱，那用户凭什么信任这样一项随时可能烧光投资的服务？该团队做出了如下回应：

• 采取与传统社交媒体公司不同的激励措施。由于 Bluesky 架构的开放性，用户不会被锁定。无论他们使用的的是客户端应用程序还是用于消息馈送的算法，用户都可以将 Bluesky 选为默认选项，或者随时切换至其他供应商。由于切换成本极低，因此 Bluesky 必须以能够令用户满意的方式完善自身。另外，Twitter 在 2023 年禁止了第三方客户端，理由是其无法提供广告收益。

• 探索更多增值付费服务。为了不依赖于外部资金，Bluesky 也设定了销售付费服务的商业愿景。首先是与 Namecheap 合作出售定制域名，这也是 Bluesky 业务中的重要组成部分。现在，只要有人通过 namecheap 注册一个域名，Bluesky 就能获得一小笔佣金。

传统社交媒体企业的现有货币化策略（例如出于广告宣传目的而出售用户数据）对于 Bluesky 来说也不太奏效。因此，他们需要找到新的变现方式。Bluesky 的开发者关系工程师 Emily Liu 观察到了一种有趣的现象：

“我们正利用这段 时间探索哪些服务对于用户更有价值，例如用户可以通过 Bluesky 购买和管理自定义域名。我们正在彻底颠覆社交应用的基本逻辑——与强调集中的传统社交媒体巨头，我们不会垄断用户数据，因此也不会遵循传统巨头们的业务变现路径。”

其实之前已经出现不少走公益路线并获得成功的案例，甚至不乏借此上市的公司。保险技术初创公司 Lemonada 就在 2020 年完成上市，此外教育初创公司 Coursera 和眼镜公司 Warby Parker 都属于公共利益性质的组织。

如今，Bluesky 拥有约 40 名全职员工：

• 17 人组成“核心”团队，其中 12 名是开发人员。

• 约 20 人负责支持和审核工作。

有趣的事实：早期招聘的员工中没有一人在 Twitter 工作过！（第一位任职过 Twitter 的员工到 2024 年才出现。）这着实令人意外，毕竟自 Bluesky 成立以来，Twitter 已经解雇了旗下约 75% 的员工——难以理解为什么他们不考虑加入这家同根同源的社交媒体初创公司。

在核心工程团队中，每个人都专注于 Bluesky 开发，具体划分为：

• 协议 / 后端与基础设施：5 人，主要负责 Atproto 存储库和 Indigo 存储库。分别为 Daniel Holmgren、Devin Ivy、Bryan Newbold、Matthieu 以及 Jaz。

• 前端和应用程序：5 人。他们的大部分编码工作都在应用代码仓库中完成。分别为 Paul Frazee、Eric Bailey、Dan Abramov、Hailey 以及 Samuel。

• 审核 / 标记：1 人，即 Foysal Ahamed 负责的 Ozone 服务。

• 其他：5 人，分别为 CEO Jay Graber、业务增长负责人 Rose Wang、T&S 主管 Aaron Rodericks、技术顾问 whyrusleeping 以及开发者关系 / 发展负责人 Emily Liu。

我们无需加入 Bluesky 就能理解这样一套简洁的工程结构。在对大多数公司进行深入研究时，我们往往需要求助于现任或者前任员工才能理解其团队结构，但对于 Bluesky，我们只需看看 Bluesky 代码仓库中的项目，并将 GitHub 贡献者跟他们的成果联系一下即可！Bluesky 工程师们编写的所有代码都是公开的，这样的透明度让我真心感到震惊——当然，是由衷赞赏的那种震惊。

“核心”团队中接近五分之四的成员都有过创业经历，这在初创公司中显得极不寻常。当然，初创公司确实更吸引那些喜欢在小团队里工作的人，其中有过创业经历的比例确实会更高。但是，这种特征为什么在 Bluesky 会突出到这样的程度？

通过与团队成员的交谈，答案可以归结为：

• 相信 Bluesky 提出的宏大使命。

• 希望构建去中心化 Web 体验。

Bluesky 正在构建一种可扩展的社交网络。说起如何实现这种快速可扩展性，那肯定是在大型科技巨头有过从业经历的人才，比如 2000 年代初的谷歌工程师、2000 年代中和 2010 年代初期的 Facebook 工程师，还有 2010 年代的 Netflix 工程师等等。然而，Bluesky 最初招聘的几位工程师都跟这些完全不沾边。

创始工程师 Paul Frazee 分享道：“核心团队的很多经验，实际上单纯来自之前的去中心化 Web 或者去中心化社交项目，来自大规模社交网络的经验反而很少。”

“我们在点对点网络方面拥有丰富经验，而且对区块链领域也给予了很多关注。对于不少团队初始成员来说，这已经是他们第二次、第三次甚至第四次构建去中心化网络了。”

后端几乎完全是用 Typescript 开发而成，前端和移动端应用也是一样。如此一来，软件工程师就能跨项目栈工作而无需切换语言。

为什么会选择 TypeScript？Daniel Holmgren 给出以下几点理由：

• 事实上的 Web 标准语言。“JavaScript 以及由此衍生的 TypeScript 可能是当前最接近 Web「通用语」的语言。我们认为在协议的参考实现中用它来传达核心思想是种顺理成章的选择。”

• 可实现前端与后端语言共享。“在客户端和后端之间共享实现能够带来更好的开发体验，特别是确保双方对于架构系统有着同样的理解。”

• 提供适合 AT 协议的动态数据方法。“作为一种动态语言，TypeScript 非常适合处理我们在 AT 协议生态系统中找到的动态数据。”

• 非常适合代码生成。TypeScript 拥有非常出色的代码生成生态系统。我承认 TypeScript 的官方实现只是提供了可解析为 AST 的工具，开发者可以对其进行操作并输出代码。虽然应用面不广，但对我们却有很大帮助。”

• 非常适合小团队进行原型设计。“TypeScript 是一种非常适合快速构建场景的语言。它的运行时非常强大，我们不必过多担心内存管理和并发性之类的问题。其类型系统非常符合人类思维方式和直觉，能够提供所需结构，同时很少惹出不必要的麻烦。对于体量不大的早期团队来说，选择这样一种能帮助我们快速推进原型设计的语言无疑是明智之举。”

后端的 TypeScript 代码使用 Node.js 运行时。团队担心的一个问题就是如何对其进行扩展，毕竟 Node.js 应用程序只在单个线程上运行，而不会为每条请求创建一个新线程。也就是说，相较于那些能够高效支持多线程的框架，Node.js 服务器能够处理的并行请求要少得多。

然而，该团队发现，横向扩展服务（即添加更多机器）并非难事，只需将应用程序构建为无状态形式即可。根据 Daniel 的回忆，他们通过测试证明了如下观点：

“有一次，我们有大概 192 个节点进程运行在 HAProxy 之后。这些进程全都非常「无聊」，CPU 利率率仅在 1% 左右。但关键在于，无状态 Node 服务可以轻松实现横向扩展，而这正好符合我们的需求！”

后端最初只采用 TypeScript 一种语言，但随着时间推移，他们又引入了 Go。但既然 TypeScript 已经有千万般好，为什么还要引入另一种语言呢？Daniel 的回答很简单，为了追求性能：

“一部分更贴近底层的基础设施服务，例如 Realy 还有我们内部的「Dataplane」，都对性能有着严格要求。它们往往涉及大量加密操作和底层 bit 操作，而 Go 语言明显更擅长这些用例。具体来讲，Go 拥有一款面向 Scylla（我们使用的数据库）的分片感知驱动程序，这也使其成为与数据库交互的理想选择。”

在追求性能优化的过程中，团队开始将多项服务从 TypeScript 重写为 Go 形式。目前，Go 语言编写的服务包括：

• Palomar 等搜索服务。

• 名为 Relay 的“firehose”服务，其执行大量底层操作与加密操作。

• Dataplane。此服务名为“BigSky”，也是 Bluesky 中的少数闭源服务之一。其负责管理数据，与 ScyllaDB、其他数据存储方案（如 Redis）以及团队自主编写的缓存存储一道承载通道数据。

Bluesky 最初使用 PostgreSQL 作为数据存储方案，但随着负载增加，团队意识到应当将这种灵活性出众、但可扩展性有限的解决方案替换为灵活性较弱、但可扩展性更强的平台上了。

2023 年年中，迁移工作正式开始：

• ScyllaDB powers AppViews.

• 由 ScyllaDB 支持 AppViews。

• SQLite 则成为个人数据服务器（PDSses）的首选数据库。

Lexicon 模式用于描述 HTTP 端点和网络中的所有记录类型。这种方法能够保障后端和客户端之间的各类强类型契约和协议。

这种强契约对于去中心化网络尤其重要。Bluesky 也是一套开放的微服务网络，因此需要在协议层面上施以严格约束。Paul Frazee 这样解释这个问题：

“大家可以将整个网络视为一个开放的微服务网络。在执行微服务的过程中，其实就是在尝试通过 schema 语言对其进行系统化，以确保所有不同服务场景均遵守相同的契约。这种情况在单体架构不太适用的微服务场景下其实相当常见。”

团队使用 GitHub Actions 作为 CI/CD 技术栈。目前项目已经公开运行，因此大家可以自行查看具体细节（https://github.com/bluesky-social/atproto/actions）：

Bluesky 协议代码仓库中的近期 CI/CD 运行记录。

这些 builds 本身会使用以下常见工具和技术来尽早发现质量问题：

Linting：运行静态代码检查以捕捉编码问题，并确保整个代码库的编码风格相一致。以下是 Bluesky linter 捕获的问题类型示例：

若对未使用的变量进行赋值，则会触发 linter 警告。最好不要在生产代码库中保留变量。

自动测试：运行单元、集成与快照测试。

快照测试示例：

快照测试通过检查 UI 是否符合预期（第 56 行，通过.toMatchSnapshot() 调用）以及“点赞”数量是否符合预期（第 58 行），来判断是否存在问题。

Bluesky 的一个有趣之处，在于其网站、iOS 应用乃至 Android 移动应用全都出自同一位开发者之手。从 2022 年夏季到 2023 年初，工程师 Paul Frazee 独自一人完成了这项开发工作。2023 年初，该应用开始迎来外部贡献者，同年 4 月第二位全职员工加入进来。而实现这整套技术栈的，就是 React Native 以及 Expo：

谈起为何选择 React Native，Paul Frazee 解释道：

“早在立项之初，我们就明确了覆盖所有主流平台的基本方针。再考虑到我们对于 TypeScript 的全面应用，那可行的解决方案就只剩下了一种：React Native。相比之下，如果要维持两套独立的应用程序代码库，那就相当于要维护两款独立的产品。所有的东西都要实现两次、所有的东西都要调试两次，而且结果总会略有不同。”

当然，Paul 也承认 React Native 绝不是什么神奇的“灵丹妙药”：

“这活并不困难，有时候甚至令人抓狂。很多 Web 开发者都知道面向多款浏览器搞开发是多么让人头大，那同时面向原生 iOS 和 Android 平台也是一样。不过好在实际情况永远是在「轻松解决」和「彻底卡死」之间反复横跳，但最终总能搞定。”

Expo 是一套用于对 Web、iOS 和 Android 上运行的原生应用进行开发、审查和部署的通用平台。Bluesky 于 2023 年 3 月打造出了这套平台，尽管团队在控制新依赖项的引入方面一直非常谨慎，但还是希望它能管理好 builds 并培养起 Expo 模块生态系统。

React Native 这个选择甚至让不少团队成员都感到惊讶。最初，Paul 只打算将 React Native 用于移动应用，但后来他们发现 React Native 在 Web 开发方面有着突出的管理易行性。Paul 解释道，“我们发现，有相当一部分工作量直接照搬代码就能完成。我们的共享代码在各种平台上都能运行，从后端到各种不同系统，这也是我们能依靠一支小团队打造出大规模社交媒体的一个重要原因。”

前面提到，Bluesky 的移动端应用和网站都是由同一位开发人员 Paul Frazee 用一约一年时间开发完成的。如今，有六位工程师负责该应用和网站，而协议和后端方面的负责工程师数量也大体相同。

那么，单凭一名经验丰富的工程师，是怎么打造出一款具备高可用性的社交应用程序的？下面来听听 Paul 的心得。

他从构建协议入手，而没有急于开发应用程序。在最初的 6 个月后，Paul 同 Dnaiel、Jay 携手合作，并与 Twitter 协商弄清楚了通信协议的工作原理。Bluesky 认为协议才是更重要的部分，基于好协议的应用程序一定会在市场上得到用户的认可。这个道理说起来简单，但直到 2022 年他们才下定决心。Paul 表示，“我们其实早就想着未来会构建应用程序，毕竟协议开发应该跟应用开发相结合嘛。但我们最初觉得应用程序应该只是个原型。但随着我们与 Twitter 的关系发生变化，我们才意识到除了开发底层协议之外，也必须要制作出能够上手体验的完整应用。这可以说是项目的一个小小转变吧。”

Daniel 和 Devin 的后端团队同 Paul 领导的前端 / 应用团队之间的关系，就是典型的前端 / 后端关系。他们共同制定功能规范，并讨论每位成员具体负责哪些工作。之后，他们在各自的领域内着手开发，再协调最终成果。

Daniel 回忆道，应用程序的构建给协议的改进提供了很大帮助，也让工作变得更加有趣：

“最有趣的体验，应该就是看着我们的一个个灵感通过协议在社交应用上得以实现。必须得承认，以纯抽象的方式构建 / 设计协议，确实不如亲眼见证它在实践场景下发挥作用那样成就感满满。”

原文链接：

https://newsletter.pragmaticengineer.com/p/bluesky-engineering-culture

https://www.theguardian.com/technology/2024/nov/12/us-election-bluesky-users-flee-x-twitter-trump-musk

声明：本文为 InfoQ 翻译，未经许可禁止转载。