ARTICLE · 1229097
Puter开源全家桶3423星:51个app只有6个协议标了MIT,我劝你别急着替换Office
"
51个 app 目录，协议栏我逐个点开：28个是空的，法务一票否决；星数是社区投票，协议才是法律文件。
📌 本文看点
01
51个app的协议分布底数
02
10分钟跑通与两个坑
03
按风险分三层的盯法
一个开源仓库，51个 app 目录，把 Excel、Word、Photoshop、AutoCAD 全列成「替代目标」，4 天冲上 GitHub 热榜。我去把 51 个 package.json 逐个点开查了一遍协议，结果是：MIT 只有 6 个，AGPL 明确写了的 6 个，剩下 28 个协议字段是空的。
这就是我的翻车现场。本来想给团队找一套可以自托管的办公替代，查完协议我决定先不动手。今天把查数过程、跑通过程、还有为什么我劝你别急，一次讲完。
先说结论：当成试玩和学习项目，值得花一个晚上；当成生产替换方案，现在不行。空协议那一栏，法务过不去。
BASELINE
先看底数：一个接口拉出来的 51 个目录
查数口径：GitHub API 拉仓库目录树，逐个读 src 目录下的 package.json，2026 年 10 月 22 日凌晨。数字我自己核了一遍，因为「28 个空协议」这个数开头我也不信。
看第二行。最核心的几个办公 app，Excel 替代的 spreadsheet、笔记 notes、演示 presentation，全是 AGPL。这词什么意思？你的修改如果对外提供服务，源码要公开。拿去做内部部署问题不大，拿去做 SaaS 二次开发，商业路线直接断掉。
再看第三行，28 个空协议才是我真正停手的原因。空不等于 MIT，空等于「作者还没选」。作者随时可以补一个协议进去，补什么你控制不了。企业采购的法务审核，这一栏空着就是红灯。
STARS
4天3423星，这个数我怎么拆
星数增长确实猛：10 月 13 日创建，到 10 月 22 日凌晨 3,423 星，9 天。同期创建的项目里这个速度排得进前面。
但星数不解决协议问题，也不解决成熟度问题。我把仓库翻了一遍，几个细节值得记：
🔍 51 个目录不等于 51 个能用
🔍 每个 app 是独立的 vite
🔍 12 个 open issue。
🔍 Node.js 22.12+ 才
这里有个往下看的理由：我一开始以为跑起来会很难，结果部分 app 的启动速度出乎意料地快。但快有快的代价，后面第四节讲。
RUN
10分钟跑通一个 app：spreadsheet
不吹不黑，跑通过程很简单。按 README 的四步走：
git clone https://github.com/HeyPuter/everything.git
cd everything/src/spreadsheet
npm install
npm run dev
我机器上 node 是 22.12 以上，npm install 用了一分半，npm run dev 起来不到 10 秒。浏览器打开就是表格界面，公式能算，单元格格式能改。
头一个坑在这：它的定位是「跑在 Puter 云上的表格」。本地 dev 起来的是界面，数据存储、账户体系走的是 Puter 的服务。你要的是纯本地自托管的话，这一步要额外做工作，README 没有专门章节讲这个。
第二个坑更隐蔽。我跑 vitest 测试的时候留意到测试脚本是配好的，说明工程化做得认真，但「认真」和「能上生产」之间隔着的是维护承诺。一个 9 天大的 mono-repo，51 个 app 同时推进，每个 app 的深度能有多少，你自己掂量。
这里还得提一个文档层面的问题。README 把 51 个 app 全列了出来，但点进几个 app 的子目录，发现有的连独立 README 都没有，入口就是 package.json 加源码。你评估一个 app 能不能用，至少要知道它支持哪些文件格式、导入导出成不成。这一层信息现在是缺的，只能跑起来自己摸。
我摸 spreadsheet 的时候顺手试了导出。能用，但格式支持到哪一步、复杂表格会不会丢样式，README 里一个字都没写。这种「跑起来才知道」的项目，评估成本比成熟项目高一截，这笔时间得算进选型账里。
还有个细节值得记。我跑第二个 app 的时候，把 npm install 的输出翻了一遍：依赖树不算庞大，但锁文件的写法、构建脚本的复杂度，各个 app 之间并不统一。spreadsheet 连 worker 构建都单独配了一个 vite 配置，而有些 app 就是一个光秃秃的 dev 脚本。同一个 mono-repo 里的工程质量不均匀，这在多团队协作的仓库里很常见，但对你评估「哪个 app 能先用」很关键：先挑工程化做得好的那批。
TIER
把 51 个 app 按风险分层
广度是这个项目最大的卖点，也是最大的风险源。我按协议和依赖把它们分成三层，方便决定盯哪些：
这个分层不是永久的。作者只要把协议栏补全，分层就得重算。这也是我建议派半个人兼职盯的原因之一：变动会很频繁。
另外一个细节：这些 app 之间的共享代码在仓库根部，根协议写的是 MIT，子包写的是 AGPL 或空。一个 app 的代码到底适用哪个协议，边界在哪，README 没有解释。这种模糊状态在企业采购里就是一张催办单，得写邮件问作者。我不反对问，但你要知道这一步的存在。
我的账是这么算的：
OPPOSE
我反对什么：别把星数当采购依据
明确表态：我反对任何团队现在就把办公栈迁到这个仓库上。
理由三条，都能被单独拎出来反驳：
⚠️ 协议不确定是硬伤。 28 个空
⚠️ 9 天的项目没有运维史。 你不
⚠️ 服务端依赖没有交代清楚。 数据
但我也反对另一个极端：说这是纯炒作。51 个 app 的工程组织、统一的 vite 架构、真实的启动速度，这些是真的。它现在适合的身份是「技术预研素材」，不是「采购候选」。
WHEN
什么情况下可以用
判断标准三条：
🔍 内部学习和原型验证。 想看看现代
🔍 非生产环境的试玩。 给团队演示「
⚠️ 生产替换：等三件事。 协议栏全
再补一句实操建议：就算只是试玩，也别在有真实数据的环境里跑。9 天大的代码，数据导出链路哪天变了你都不知道。试玩归试玩，别拿真文档当试验品。
REVIEW
选型会上我怎么用这个仓库
它对我来说其实是个很好的教学样本。下次团队里有人拿星数说事，我就把这个仓库翻给他看：
🔍 广度不等于可用。 51 个目录摆
🔍 热度不等于合规。 3,423 星
🔍 演示不等于交付。 10 秒启动的
这三条推而广之也成立。我评估任何新开源项目，先看协议、再看 issue 区有没有真实用户在踩、最后才看功能清单。顺序反了，就会被 README 牵着走。
COST
管理成本这笔账
真要盯着这个项目的成熟度，占人多少时间？我按自己的习惯拆了一下：
🔍 盯更新： 每周看一次 relea
🔍 跑通验证： 每个新冒出来的 ap
🔍 协议复核： 每次作者动了 pac
三项加起来，我的结论是：派半个人兼职跟，别投全职。
真要写个跟踪命令的话，我用的就是最土的一条，每周跑一次看 diff：
# 每周盯协议变动，空协议变多或变少都要知道
curl -s https://raw.githubusercontent.com/HeyPuter/everything/main/src/spreadsheet/package.json | grep license
别笑它简单。协议这种东西，靠记忆盯不住，靠一条定时命令反而靠谱。哪个子包的 license 字段动了，下周的跟踪列表就多一条。
THE END
这篇给不了什么
我没法告诉你它三个月后什么样，9 天大的项目谁也预测不了。你们团队有在找 Office 自托管替代的吗？最关心哪个 app 的成熟度？评论区点名，我下次挑一个深挖。
51 个 app 里，你现在离不开、又说不上来的那个是什么？
评论区报个名，我下一期接着挖它的开源替代。
THANKS FOR READING
