2026 年 3 月，Font Awesome 团队在 Kickstarter 上发起了 Build Awesome 项目，目标金额在一天内即达成。这个项目实际上是 Eleventy（又称 11ty）的品牌重塑版本，然而它并未像预期那样受到原有用户社区的热烈欢迎。相反，这一转型被广泛视为 Eleventy 作为独立开源项目的终结。这一事件不仅是一个项目的个案，更折射出整个 Jamstack 生态系统在商业化与可持续性之间的深层矛盾。
Eleventy 的技术定位与生态价值
Eleventy 由 Zach Leatherman 于 2017 年创建，灵感直接来源于 Jekyll，但旨在利用蓬勃发展的 Node.js 生态系统，同时避免 imposing 一个笨重的客户端 JavaScript 框架 [1]。它的核心优势在于三点：灵活性、充分利用 JavaScript，以及刻意回避成为另一个 JavaScript 框架。Eleventy 支持多种模板引擎，包括 Liquid、Nunjucks、Markdown、Handlebars 和 EJS，允许开发者在单一项目中混用这些引擎，极大地降低了从其他静态站点生成器迁移的成本。
在技术采用层面，Eleventy 获得了令人瞩目的用户群体。NASA、CERN、TC39 委员会、W3C、Google、Microsoft、Mozilla、Apache、freeCodeCamp 等机构和企业均采用 Eleventy 构建其官方网站 [1]。这种广泛采用本身就证明了其技术的可靠性和稳定性。值得注意的是，A11y Project 的开发者在 2021 年使用 Eleventy 1.0 构建网站后，曾指出近三年后该站点仍能从冷启动状态顺利安装和运行，无需任何复杂配置。这种 “开箱即用” 的体验正是 Eleventy 设计哲学的体现 —— 专注于构建时的简单性，而非运行时 的复杂性。
从 Netlify 到 Font Awesome 的归属变迁
Eleventy 的发展历程中经历了两次重要的归属变更。最初，Leatherman 受雇于 Netlify 全职开发 Eleventy，这段合作为 Eleventy 带来了显著的曝光度和社区增长。然而，2024 年 9 月，Eleventy 项目迁移至 Font Awesome，Leatherman 加入了 Font Awesome 团队 [1]。这一变更在当时并未引起广泛关注，但却是后续品牌重塑的伏笔。
2026 年初，Font Awesome 推出了 Build Awesome 项目，明确将其定位为 Eleventy 的继任者和商业化产品。Kickstarter 页面显示，Build Awesome Pro 将提供协作可视化编辑、浏览器内构建、Premium 模板和托管导入工具等高级功能 [1]。这些功能本质上是在尝试将静态站点生成器转变为类似于 WordPress 的内容管理系统，只是披上了现代化的外衣。
社区的反应呈现出明显的分化。部分长期用户表达了对品牌重命名本身的不适感，认为 “11ty” 这个简短易记的名字具有历史意义，而 “Build Awesome” 显得过于 corporate。更深层的担忧在于，许多开发者担心 11ty 将 “被吸收并以我不愿意使用的形式消失”。这种担忧并非空穴来风 —— 此前 Gatsby、Stackbit 等静态站点相关项目都经历了类似的从开源到商业化再到关停的周期。
Jamstack 生态系统的商业化困局
理解 Eleventy 转型事件，必须将其置于更广阔的 Jamstack 生态系统中审视。Jamstack（JavaScript、APIs、Markup）概念由 Netlify CEO Matt Biilmann 推广，旨在论证将前端与后端解耦、在构建时预渲染静态 HTML、通过 API 连接服务的架构，是现代 Web 的正确方向 [1]。这一架构确实带来了显著的性能、安全性和可扩展性优势。
然而，商业化的道路远比预期崎岖。Gatsby 是这一领域最典型的案例 —— 它获得了约 4600 万美元的风险投资，通过 Gatsby Cloud 平台尝试 monetize 其开源框架，但最终未能实现预期的增长曲线 [1]。2023 年 2 月，Netlify 收购了 Gatsby Inc.，随后关闭了 Gatsby Cloud，而 Gatsby 本身也在社区讨论中确认不再维护。Stackbit 曾试图成为各种静态站点生成器的 “网站构建器”，简化工作流程，但在支持多种 SSG 和 Headless CMS 组合的复杂性面前败下阵来，最终被 Netlify 收购并转化为 Netlify Create，随后悄然停运 [1]。
这些案例揭示了一个根本性的悖论：静态站点生成器的核心用户群体恰恰是那些宁愿使用免费本地 IDE 和终端的开发者，而非愿意为可视化构建工具付费的非技术人员。当商业化尝试试图面向 “更广泛的受众” 时，往往会疏远那些已经在使用该技术的忠实用户。Build Awesome 试图解决的问题 —— 即 “如何从中盈利”—— 实际上是一个至今无解的难题。
开源项目的生命周期启示
Leatherman 本人曾在播客中坦言，维护一个被广泛采用且成为关键基础设施的开源项目，需要面对巨大的个人牺牲和资源限制 [1]。这种 "BDFL"（Benevolent Dictator For Life）模式在开源生态中并不罕见，但当项目达到 Eleventy 这样的规模时，单一维护者的局限性就愈发明显。
从工程实践角度看，Eleventy 用户面临的核心问题是：如果 Build Awesome 成为唯一受支持的版本，现有项目将何去何从？值得庆幸的是，Eleventy 作为开源项目，其代码仓库仍然可用。开发者可以选择锁定在某个特定版本，或者探索社区衍生的分支版本。这种 “分叉” 在开源世界中是一种合法的生存策略 —— 当上游项目方向与用户需求产生分歧时，社区有能力维护一个满足自身需求的版本。
对于工程团队而言，这一事件提供了几点可操作的启示。首先，在选择静态站点生成器时，应评估项目的治理结构和商业支持模式，而非仅仅关注功能特性。其次，对于已在生产环境中依赖 Eleventy 的团队，建议锁定依赖版本并建立内部文档，以应对上游可能的变更。第三，关注社区动态 —— 如 GitHub 上的 issue 讨论、分离的 fork 项目，以及其他静态站点生成器（如 Hugo、Zola、Astro）的发展动态，都是合理的风险对冲策略。