Omarchy 开源运营笔记

研究对象：github.com/omacom/omarchy（2026 年 8 月从 basecamp 组织迁到 omacom 组织）。数据截至 2026 年 9 月 6 日。仓库文件链接钉在提交 adcc96a（2026 年 9 月 6 日的 quattro 分支），点开看到的就是本文引用的那一行。方法和来源见文末。

一、规模与结论

Omarchy 是一个操作系统：Arch Linux 打底，Hyprland 做窗口管理，Quickshell 做桌面。仓库里有 451 个命令脚本、22 个主题、106 个迁移脚本、51 章用户手册、16 个自带桌面插件。它的开源运营和普通软件库的差别在这里：用户的机器上就装着它的全部源码和工具，所以很多“社区流程”被做成了操作系统命令，随系统一起发到每台机器上。

一句话结论：Omarchy 把“怎么报 bug、怎么调试、怎么改代码、怎么测试、怎么发 PR”全部做成了装在系统里的命令和 agent 技能，让每个用户机器上的 AI agent 都能按它的规矩办事；仓库本身几乎没有流程，没有 CI，没有机器人分诊，合并靠 DHH 一个人加他的 agent 农场。前一半是它最值得学的地方，后一半是它现在最大的欠账。

二、可借鉴

• 把贡献指南做成产品的一部分。用户的 agent 是第一道支持，那就把分流规则、诊断命令、报告清单写成技能，随产品发到用户机器上，再让初始化脚本自动挂进所有 agent 的技能目录。
• 报 bug 前的四道闸：先判断管辖范围，先搜重复，用户点头才发，机器报告必须署名。这四条可以直接搬进任何产品的 agent 技能。
• 非交互开关。每个诊断命令都给 --no-sudo --print 这样的开关，并在技能里写“ALWAYS use these flags”。agent 跑不了交互命令。
• 让用户分层做测试员：stable、rc、edge、dev 四条通道，切换是一条命令，dev 通道直接把系统指向 git 检出。
• 设计文档先过另一家模型的对抗评审，并把修订记录写在文档第三行。
• 功能需求走插件系统，主仓库只收修复和核心改动。
• 别学的部分：没有 CI、没有 PR 出口、没有社区版规。这些在 3.8 万 star 的规模上已经开始漏水。

下面是每条的依据，按效果从大到小排，每条写清要解决的问题、做法、效果、证据。

三、把贡献步骤装进操作系统：omarchy 技能

3.1 要解决的问题

一个新 Linux 发行版的支持负担，大头是“我的机器出了问题，我不知道是不是 bug，也不知道要给你什么信息”。Omarchy 的用户里有大量第一次用 Linux 的人，而且几乎每个人都在机器上装了 Claude Code、Codex 一类的 agent。问题就变成：怎么让用户的 agent 替维护者做第一轮支持和分诊。

3.2 做法：一个随系统发行、自动挂进所有 agent 的技能

仓库里 default/agents/skills/omarchy/ 是一个 agent 技能，七个文件：SKILL.md 294 行，加 contributing、hooks、plugins、theming、capture、hyprland 六份专题指南。它随 omarchy 包安装到 /usr/share/omarchy，然后由用户初始化脚本符号链接到每个 agent 的技能目录。

• bin/omarchy-provision-user#L87-L101：循环 default/agents/skills/*/，把每个技能链接到 ~/.agents/skills、~/.claude/skills、~/.codex/skills、~/.pi/agent/skills、~/.gemini/config/skills、~/.hermes/skills，以及 Hermes 每个 profile 的 skills 目录。注释写明“Loops every skill directory, so shipping a new one needs no edit here”。
• manual/17-ai.md#L57-L61：用户手册说明这个技能是干什么的，并提醒“treat this skill as experimental”，建议先用 plan mode，出问题就 omarchy reinstall configs。

SKILL.md 的关键段落：

• SKILL.md#L21-L38“When This Skill MUST Be Used”：凡是要改 ~/.config/hypr/、~/.config/omarchy/、终端配置、主题、截图、锁屏，agent 必须先读这个技能。“If you're about to edit a config file in ~/.config/ on this system, STOP and use this skill first.” 同时划清边界：改 Omarchy 源码、写迁移、跑 omarchy dev 不归它管。
• SKILL.md#L51-L62“Critical Safety Rules”：/usr/share/omarchy/ 只读，因为下次更新会覆盖；提权按“有终端用 sudo，没终端用 pkexec”。
• SKILL.md#L109-L131“Command Discovery”：教 agent 用 omarchy --all、omarchy <group>、机器可读的命令清单，以及“Read a command's source to understand it”。命令源码本身就是文档。
• SKILL.md#L230-L246“Troubleshooting”：omarchy debug --no-sudo --print，注释是“ALWAYS use these flags to avoid interactive prompts”，然后是 omarchy refresh config、omarchy reinstall configs 三级恢复。
• SKILL.md#L248-L259“Decision Framework”：先判断请求属于哪一类，再决定读哪份指南。“Report this bug to Omarchy”这一类导向 contributing.md。

3.3 做法：contributing.md 是给 agent 看的贡献指南

仓库没有 CONTRIBUTING.md。给人看的那份没有，给 agent 看的这份有，65 行，装在每台机器上：

• contributing.md#L6-L15：三条分流。已验证的 bug 去 GitHub issue，“Issues are for validated bugs only, not support requests”；功能想法去 Discussions 的 Suggestions 分类；支持和“这算不算 bug”去 Discord，“Start here when the problem isn't clearly a bug in Omarchy itself”。
• contributing.md#L17-L50“Filing a Good Bug Report”：omarchy version；omarchy debug --no-sudo --print 生成诊断日志（同时写到 /tmp/omarchy-debug.log）；交互版会把日志传到 logs.omarchy.org，24 小时过期，返回可分享的链接；用 omarchy capture screenshot 或 omarchy screenrecord 录下问题；最后 gh issue create --repo basecamp/omarchy。写明 gh 传不了媒体文件，所以把截图路径交给用户自己拖进网页表单。
• contributing.md#L52-L65“Submitting a PR”：“Never develop against /usr/share/omarchy”，用 gh repo fork basecamp/omarchy --clone；按仓库的 AGENTS.md 办，“it is the authority on contributions”；提交要原子，推送前跑 ./test/all，用 gh pr create 开 PR；修视觉问题的 PR 要带前后截图。

配套的系统命令：

• bin/omarchy-debug#L1-L20：命令元数据声明 --no-sudo 和 --print 两个开关，就是给 agent 用的非交互路径。
• bin/omarchy-upload-log#L95-L140：安装日志、本次启动日志、上次启动日志、系统信息，分别上传到 logs.omarchy.org。
• .github/ISSUE_TEMPLATE/bug.yml#L2-L8：唯一的 issue 表单，描述是“Report a validated bug -- NOT FOR SUPPORT REQUESTS”，开头一句“Remember: Omarchy is an open source gift, not a product you bought from a vendor”。
• .github/ISSUE_TEMPLATE/config.yml#L1-L8：空白 issue 关闭，Suggestion 去 Discussions，Support 去 Discord。

3.4 为什么这么设计

三条分流规则在 GitHub 表单里写了一遍，在 agent 技能里又写了一遍。前者拦的是人，后者拦的是用户的 agent。Omarchy 的用户遇到问题时，第一反应往往是问自己机器上的 agent，而这个 agent 读到的第一份材料就是 Omarchy 自己写的：先去 Discord 确认，确认了再带着 omarchy debug 的日志和截图去开 issue。维护者不用在 issue 里追问“你什么显卡、什么版本、日志呢”，因为技能已经把这些列成了清单。

3.5 效果

• issue 标签只有 bug（1,827 个）、enhancement（260 个）、support（26 个）。支持类 issue 只有 26 个，说明分流在起作用。
• 最近 100 个关闭的 issue，中位关闭时间 3.6 小时，76% 标为“已完成”，20%“不计划”，4%“重复”。抽 5 个看关闭人，全是作者自己：有的发现是重复，有的自己修好了，有的“开错了”。
• 代价：issue 打开的占 37%（1,418 个），没有分诊标签，没有机器人。分流把噪音挡在门外，但进门以后还是排队。

四、崩溃分诊技能：让 agent 先判断“是不是 Omarchy 的 bug”

4.1 要解决的问题

操作系统上什么都会崩：浏览器、文件管理器、Qt 库。用户看到“Process crashed”通知，第一反应是去 Omarchy 报 bug。绝大多数不是 Omarchy 的 bug。

4.2 做法

• bin/omarchy-agent-crash#L26-L52：崩溃通知点下去，这个命令从 coredumpctl 取出记录，拼成提示词，调用用户设定的默认 agent，指明“Use the diagnose-crash skill”。注释解释为什么方法写在技能里：“so it is edited in one place and works with whichever agent is default”。没有技能机制的 agent 就直接读技能文件。
• diagnose-crash/SKILL.md#L1-L30：“Work from evidence. The goal is an honest account of what happened, not a plausible-sounding story.” 先看 coredumpctl info 的命令行，再看 coredumpctl list 是一次性还是反复，再排除内存耗尽，“A process killed by the OOM killer is not a bug in that process”。
• diagnose-crash/reporting.md#L5-L24“Is it even Omarchy's bug?”：列出 Omarchy 的管辖范围，omarchy-* 命令、Quickshell 桌面和插件、它发的 Hyprland 和终端配置、主题、安装和迁移脚本、打包方式。“A crash in a program Omarchy merely installs is not an Omarchy bug unless Omarchy's own packaging or configuration is implicated.” 不是它的，就说清楚然后停下，不要替用户去上游报。
• reporting.md#L26-L36“Three conditions, all required”：有证据的已验证 bug；用户明确同意，“Show them the exact title and body you propose, and wait for a yes. Never file unprompted”；gh auth status 通过，没装或没登录就不要替用户装，把写好的文本交给用户自己发。
• reporting.md#L38-L55“Search before filing”：“A duplicate issue costs a maintainer more time than no report at all.”
• reporting.md#L96-L104“Signing”：issue 或评论结尾必须署名“Filed by via ”，用真实的模型和工具名，不确定就说不确定，不要编版本号。

4.3 效果

这套技能是 Quattro 4.0（2026 年 8 月 14 日）才加的，样本还少。能看到的是 issue 里出现了带署名的机器报告，以及 omarchybot 提的 PR，比如 #8549“Let a crash diagnosis mute that program's notifications”，已由 DHH 合并。设计上它把“先判断管辖、先搜重复、用户点头才发、署名”四道闸放在了用户机器上，而 OpenClaw 把同样的闸放在仓库的机器人里。

五、四条更新通道：把用户变成分层的测试员

5.1 要解决的问题

滚动发行版最怕两件事：上游 Arch 的新包把配置搞坏，自己的新版本把用户机器搞坏。测试要靠人，人要分层。

5.2 做法

• manual/30-updates.md#L11-L19：四条通道。stable 跟官方发布，配套的 Arch 镜像故意落后一个月，“so we can catch any new incompatibilities that require config changes before they cause problems for people”；edge 跟最新开发版和最新 Arch 包，“You should only do this if you're experienced with Linux”；RC 在大版本前做最终验证，“come hang out in #omarchy-release-candidates on the Discord”；dev 直接连 ~/omarchy 的源码检出，给“working directly on Omarchy, and willing to tolerate breakage”的人。
• bin/omarchy-channel-set#L12-L20 和 #L37-L39：切到 dev 通道要二次确认；确认后没有检出就 git clone，然后 omarchy-dev-link 把系统的 /usr/share/omarchy 指向这个检出。从这一刻起，用户改一行源码，系统就在跑改过的版本。
• bin/ 里的 omarchy-dev-* 命令共 11 个：omarchy-dev-status 看链接状态，omarchy-dev-pkg-test 从本地检出打包安装，omarchy-dev-ui-preview 和 omarchy-dev-theme-preview 预览界面和主题，omarchy-dev-add-migration 新建迁移。
• 迁移的规矩：agents/skills/migrations.md#L118-L129，文件名是 unix 时间戳（omarchy-dev-add-migration 用最后一次提交的时间生成），第一行 echo 说明做什么，必须幂等，严格顺序执行，失败就退出非零并停住队列，“never mark later migrations complete against state an earlier migration has not established”。仓库里现在 106 个迁移。

5.3 效果

• 一个普通用户按手册切到 edge，就成了 Arch 新包的测试员；切到 dev，就成了拿着完整开发环境的贡献者。不用装工具链，不用配路径，因为系统自带。
• 8 月的 RC 通道验证撑起了 Quattro 4.0 的发布。发布说明里按功能列作者 @，很多来自这批人。
• 代价：这套体系没有对应的公开数据，多少人在 edge、多少人在 dev 无从统计。

六、更新命令的安全网：把支持问题消灭在发生之前

6.1 要解决的问题

滚动发行版的支持工单大头是“更新以后起不来了”。

6.2 做法

bin/omarchy-update 96 行，做了这些事：

• #L12：整个更新过程用 script 录到 /tmp/omarchy-update.log。
• #L15-L16：加锁，防止两个更新同时跑。
• #L19：ERR 陷阱。任何一步出错，红字提示“Something went wrong during the update!”，然后给出 Discord 地址。支持入口写在错误信息里。
• #L36-L37：更新前先 omarchy-snapshot create 做 Btrfs 快照，快照失败只警告不阻断。坏了在启动菜单选回去（manual/30-updates.md#L31）。
• #L40-L53：固定顺序，先更新源码（dev 通道）、密钥环、系统包，再跑迁移，再跑用户的 post-update 钩子，再 AUR 包、mise、孤儿包，最后 omarchy-update-analyze-logs 扫日志找已知故障模式，比如 initramfs 生成失败就红字提醒“Review logs before restart”。
• 直接跑 pacman -Syu 会被拦下，因为会跳过快照、迁移和配置更新。设计文档 docs/update-process.md#L63“Raw pacman guard”、#L151“Path 2: direct sudo pacman -Syu attempt”写清了用户绕过时怎么处理，#L292“Closed decisions”和 #L319“Remaining concerns”记录了已定和未定的事。
• 用户自己的自动化走钩子，不用改系统文件：hooks.md#L6-L22，~/.config/omarchy/hooks/<事件>.d/，六种事件：低电量、换字体、开机后、更新后、重新同步包之前、换主题。

6.3 效果

这一节没法用仓库数据量化，但它决定了 Discord 的 #omarchy-help 里是什么问题。“更新挂了”的标准答案是“看红字，去 Discord，贴 omarchy-debug”，三样东西都是更新脚本自己给的。

七、对贡献者的具体要求

7.1 一份 AGENTS.md，CLAUDE.md 只有一行

CLAUDE.md 的全部内容是 @AGENTS.md。AGENTS.md 133 行，八节：

• #L1-L13“Task Guides”：按改动位置指到 agents/skills/ 下七份专题指南，改 bin/ 读 command-metadata，改 install/ 读 install-scripts，改 shell/ 读 shell-dev，加图标读 icon-font，写验收测试读 acceptance-tests，有视觉改动读 visual-verification，写迁移读 migrations。
• #L22-L33“Style”：markdown 不硬换行；两空格缩进；bash 5 的 [[ ]] 和 (( ))；[[ ]] 里变量不加引号、字面量加引号；数字比较用 (( count < 50 )) 不用 -lt；简单双分支写完整 if/else；shebang 统一 #!/bin/bash；install/ 和 migrations/ 下的脚本被 source，故意不写 shebang。
• #L61-L70“Runtime Environment”和“Privileged Commands”：$OMARCHY_PATH 由会话环境设定，不要从 HOME 推导；提权规则引用用户技能里的“Privilege Escalation”一节，“the repo's own scripts follow it”。同一条规则，用户的 agent 和贡献者的 agent 读的是同一段。
• #L72-L76“Git”：提交原子，一个提交一件事；提交信息简短说明改了什么。
• #L105-L122“Tests”：./test/all 跑 CLI 和 shell 两套，故意不跑图形验收；新 shell 测试放 test/shell.d/*-test.sh 自动被捡起；图形验收在一次性虚拟机里跑；“Visual changes must be verified in the running UI in addition to automated tests”。

7.2 七份专题指南

agents/skills/ 下七个文件，每份第一句都是“Read this before …”：

这些文件不进任何包，只在仓库里（docs/file-layout.md#L29-L31）。它们和第三节的用户技能是两套：用户技能教 agent 怎么用系统，贡献者指南教 agent 怎么改系统。SKILL.md 明确写了“Do NOT use this skill for Omarchy development tasks”。

7.3 为什么这么写

OpenClaw 的 26 份 AGENTS.md 是按目录分层，每个目录一份。Omarchy 的做法是一份总纲加七份按任务类型分的指南，靠总纲第一节做路由。原因是仓库结构：451 个脚本平铺在 bin/，按目录分层没有意义，按“改命令、改安装、改桌面、写迁移”分才对得上贡献者的实际动作。

7.4 门口的规矩

• .github/CODEOWNERS：“Merges to protected branches need sign-off from an org owner. * @dhh @ryanrhughes”。两个人。
• 没有 CONTRIBUTING.md，没有 PR 模板，没有 GitHub Actions 工作流（.github/ 下只有 CODEOWNERS、SECURITY.md 和两个 issue 表单文件）。GitHub 的社区健康度检查得分 50。
• 贡献者能读到的规矩，全部在 AGENTS.md、七份指南和装在系统里的 contributing.md。

7.5 效果

抽样最近 300 个合并的 PR：作者 DHH 自己 122 个（41%），omarchybot 30 个，其余 148 个来自社区。评审记录里 GitHub Copilot 的评审机器人 106 次、omarchybot 20 次、Spencer Bull 11 次、DHH 3 次；150 个是“评论”，11 个是“批准”。规矩是给 agent 写的，评审也主要是 agent 在做。

八、插件系统：把功能需求从 PR 里分流出去

8.1 要解决的问题

桌面环境的功能请求无穷无尽：天气、日历、音乐、剪贴板。每一个都做成 PR，仓库会被淹没。

8.2 做法

• shell/plugins/README.md#L1-L12：16 个第一方插件和第三方插件用同一份 manifest.json 契约，唯一区别是第一方被标 __isFirstParty: true。用户插件放 ~/.config/omarchy/plugins/<id>/。
• manual/32-shell-plugins.md：用户手册教从 git 装插件（#L32）、克隆一个内置插件来改（#L59）、自己写（#L73）、分享（#L98）。
• 装在系统里的 agent 技能 plugins.md#L1-L18：shell.json 和用户插件代码保存即热重载，agent 改完立刻能看。
• 市场：omarchy-plugin-marketplace 是社区维护的，提交走 issue 表单，要有清单、README 和许可证；上架前要“fresh exact-commit scan”和维护者的“approved-and-verified”决定；README 直说安装命令拉的是可变的上游 HEAD，“not verification-bound”，装前自己看代码。omarchy-plugin-registry 是下一步，crates.io 式的索引，Ed25519 签名，带下架开关。
• 基金会办了插件竞赛，一等奖 2,500 美元，核心团队评审。

8.3 效果

Quattro 发布三天，市场 330 个插件，现在 500 多个。这些功能没有一个变成主仓库的 PR。对比：同期主仓库每天新开 85 到 126 个 PR，8 月只合并了 241 个。插件把最容易膨胀的那一类需求接走了。

九、测试：本地两套，图形验收进虚拟机

9.1 做法

• test/all#L11-L17：跑 test/cli 和 test/shell，“Run every suite even when an earlier one fails, so a single failure can't hide whole suites behind it”。test/shell.d/ 下 229 个测试文件。
• docs/testing.md：#L9 套件地图，#L35 base-test.sh 契约，#L68 依赖合成器的测试怎么办，#L92 用 bash 单测 shell 里的 JavaScript。
• 图形验收 9 个测试在 test/acceptance.d/，在 omarchy-iso 仓库的 bin/omarchy-iso-test 里跑：无头 QEMU，通过 QMP 截屏加 OCR 读屏，模拟按键，装完系统后在虚拟机里跑验收套件。
• 没有 GitHub Actions。测试全靠贡献者本地跑，规矩写在 AGENTS.md 里，合并前靠评审 agent 和 DHH 把关。

9.2 效果

对一个操作系统来说，能用 CI 跑的只有脚本级测试，真正的验收必须装一遍系统。Omarchy 选择把验收工具做完整、把 CI 省掉。代价是 PR 页面上没有任何绿勾，贡献者也没有“通过了”的信号。

十、设计先行：plans/ 与 docs/

• plans/ 四份功能设计：backup、dots、remote、server。每份第三行标注版本和评审来源。plans/backup.md#L3：“Revision 2 incorporates adversarial review by codex (xhigh): honest threat model, secrets moved out of the backup scope and out of ~/.config, corrected timer/pause mechanics …”。plans/dots.md#L3：“Rev 2 incorporated adversarial review by codex (xhigh) and grok”。设计文档先让另一家的模型对抗评审，再动手写代码。
• docs/ 九份内部设计文档：文件布局、命令路由器、更新流程、测试、主题、菜单、通知、桌面、音频调优。docs/file-layout.md#L7-L26 写清一个仓库出两个 Arch 包，哪些目录进哪个包，为什么 omarchy-settings 必须先于 useradd 装好。
• 这两个目录都不进包，只给贡献者和 agent 看。

效果：难以量化。可见的是 DHH 在播客里的说法，Quattro“没有一行代码是我手写的”，他审的是安全相关代码和架构决定。plans/ 就是那些架构决定的落地形态。

十一、发布节奏与镜像滞后

• 发布工具在 omarchy-pkgs 仓库：omarchy-release start 4.0.2 开分支和暂存 PR，pick 多选要挑进来的已合并 PR，rc 发到 RC 通道，ship 一次完成打标签、提升 rc 到 stable、GitHub release 草稿、ISO、官网。每条命令幂等，“ship refuses to promote a commit no RC was cut from”。
• 包通道 edge 到 rc 到 stable，和用户侧的四条更新通道一一对应。stable 的 Arch 镜像 omarchy-mirror 故意落后一个月。
• 节奏：2025 年 7、8 月各 15 和 13 个版本，之后每月 1 到 6 个。大版本有名字，2.0 是 Linux 34 岁生日那天发的，Quattro 4.0 是 2026 年 8 月 14 日。4.0 的发布说明按功能逐条列作者 @，DHH 手写，没有从 PR 自动生成。

十二、谁在合并：一个人加一个 agent 农场

12.1 数据

抽样最近 300 个已合并的 PR（2026 年 7 月 21 日到 9 月 6 日）：

• 合并人：DHH 265 个（88%），Ryan Hughes 28 个，Spencer Bull 6 个。
• 从开到合并：中位数 2.9 小时，75 分位 20.5 小时，90 分位 67.6 小时。
• omarchybot 是 2026 年 8 月 15 日注册的账号，Quattro 发布的第二天。它开的 PR 有长篇正文，比如 #10176“Bound the Bluetooth panel's discovery retry”，从 BlueZ 的行为讲到修法，结尾写明“Two things this deliberately leaves alone”。它也给别人的 PR 做评审。

12.2 DHH 自己的描述

Lex Fridman 播客第 501 期：四五台迷你电脑放在壁橱里，Tailscale 连起来，用 Herdr 调度 Claude Code、Codex、OpenCode，最多 16 个 agent 并行。agent 写代码开 PR，评审 agent 过一遍，他做最后的合并或拒绝。三个月合并了 1,000 多个 PR。面对上千个待审 PR，做法是“让 agent 分诊，我从几百个没合并的 PR 里挑最好的功能”。他说宁可收 agent 写的 PR 也不想收人写的，因为拒绝起来没有负罪感。

12.3 没有被合并的那些

• 抽最近 25 个关闭未合并的 PR，查关闭事件的操作者：25 个全是作者自己关的，没有一个是维护者关的。300 个关闭未合并的样本里，59% 的作者和仓库没有任何关联，26% 关闭时一条评论都没有。
• 1,852 个开着的 PR，1,811 个来自 DHH 和 omarchybot 之外的人。抽样 300 个最新打开的 PR，246 个零评论。
• DHH 8 月底在 X 上说：Quattro 发布时待审 PR 约 200 个，现在约 1,000 个，“I promise they'll all get reviewed”，同时说连做三个月、发布后每天 16 小时，“Might just need a quick break”。

十三、治理与钱

• omarchy.org/teams：Core Team（9 月公告，成员是早期贡献者和主题作者，以个人身份）、Security Team、Rangers（8 月公告，3 人在罗马尼亚、乌拉圭、尼泊尔，职责是在 Discord 帮新人）。公告里没有决策规则、评审流程或发布权限的说明。
• Omacom Foundation，2026 年 8 月 21 日成立，持有商标、出钱养基础设施、赞助上游。12 位创始赞助人各 100 万美元，包括 Tobi Lütke、Patrick Collison、Michael Dell、Jack Dorsey、Peter Steinberger、DHH 本人。钱花在 Hyprland 独家赞助、Quickshell 和 mise 首席赞助、驻留艺术家、插件竞赛、第一个全职雇员是内核开发者。9 月 3 日起普通人也能赞助，四档 16 到 8,192 美元。
• .github/SECURITY.md#L3-L17：私下报给 [email protected]；漏洞的定义是“跨越有意义的安全边界”，只是不够健壮的代码算改进，他们仍会考虑合并并在发布说明里致谢；安全致谢页面看的是有没有确认漏洞，与严重程度无关。

十四、社区

• Discord 从 2025 年 7 月的 1,500 人到 2026 年 8 月的 35,000 人。频道按用途分：#omarchy-help、#omarchy-on-other、#omarchy-release-candidates。所有支持导向这里。没有公开的版规和版主名单。2025 年 11 月有人在 Discussions 里投诉 Discord 变得有毒，无维护者回复，2026 年 2 月关闭；2026 年 9 月有人提议加行为准则并开了 PR，社区回复“How about no?”，无维护者回复。
• GitHub Discussions 1,736 个帖子，8 个分类。最近 100 个帖子里 78 个是 Suggestions，77 个零回复，0 个被标为已回答。它的作用是功能请求的收件箱，让 issue 只留 bug。
• 线下聚会由基金会推动。

十五、没做好的地方

• 待审 PR 没有出口。39% 的 PR 开着，抽样 82% 零评论。OpenClaw 用机器人关掉 57% 的 PR，每个都留原因和重开方法；Omarchy 既不关也不答。DHH 承诺“都会看”，但当前节奏是每天新开 100 个左右、8 月合并 241 个。
• 没有 CI。贡献者拿不到“通过了”的信号，评审 agent 也拿不到测试结果。./test/all 是纯脚本测试，完全可以在 Actions 里跑。
• Discussions 里 78% 是建议，77% 零回复。收件箱没有人看，等于没有收件箱。
• Discord 3.5 万人，没有版规、版主名单和申诉渠道。投诉帖和行为准则提议都无维护者回复。
• 治理公告没有决策规则。Core Team 谁能合并、谁定方向、Ryan 和 DHH 之外谁有权限，公开材料里查不到。
• 装在系统里的技能只覆盖“用系统”和“报 bug”。贡献者指南（agents/skills/）不进包，切到 dev 通道的用户要自己去仓库里找。

十六、方法与来源

• 仓库：git clone omacom/omarchy 至提交 adcc96a78226735d6fddf5196fb3f71e8c49d584（2026 年 9 月 6 日），通读 AGENTS.md、CLAUDE.md、.github/ 全部文件、default/agents/skills/、agents/skills/、bin/omarchy-update*、bin/omarchy-dev-*、bin/omarchy-provision-user、bin/omarchy-agent-crash、bin/omarchy-debug、bin/omarchy-upload-log、manual/、docs/、plans/、test/、shell/plugins/README.md；git shortlog 统计作者；ls | wc -l 统计命令、主题、迁移、测试数量。所有行号在本地克隆上用 grep 逐条核对。
• GitHub API：仓库统计；按月的 PR、issue、合并计数；最近六天每日新开 PR；标签计数；最近 300 个合并、300 个关闭、300 个打开 PR 的抽样（GraphQL）；100 个关闭 issue 抽样；25 个关闭 PR 的关闭事件操作者；100 个合并 PR 的评审者；Discussions 计数与最近 100 个帖子；omarchybot 的 PR 和评审；工作流列表；分支规则集。
• 相关仓库：omarchy-pkgs README 与 bin/omarchy-release；omarchy-iso README 与 bin/omarchy-iso-test；omarchy-mirror；omarchy-plugin-marketplace；omarchy-plugin-registry；herdr。
• 官方：omarchy.org/teams；omarchy.org/news 2026 年 8 到 9 月各篇：基金会成立、Core Team、Rangers、聚会、插件竞赛、赞助开放。
• DHH 本人：Omarchy 2.0、A petabyte worth of Omarchy in a month；Lex Fridman 播客第 501 期（据 BigGo 的文字摘要）；X 上关于待审 PR 数量的帖子。
• 统计口径：Discord 人数来自官网和 DHH 博客的自述；“零评论”按 API 返回的评论数计；合并时长按 PR 创建到合并的时间差计。