面向学校集团的 Moodle 替代方案：算运维的账，不是许可的账

Moodle 许可免费，运维不免费。对一所学校来说，只要有一位很懂它的系统管理员，这通常是笔划算的交易。对一个集团——一个学校联合体、一个学区、一家出版社、一项部级项目——账就变了，因为决定这个问题的成本是托管、版本升级、升级过程中的插件兼容、安全补丁和备份，也因为多租户不在核心产品里。与任何替代方案的诚实比较，比的是运维总成本，不是许可成本。

这些都不是批评。Moodle 是教育领域部署最广的开源 LMS，这是它应得的：真正免费、真正可自托管，而且做了很多商业产品不会去做的东西。这里算的是账，不是立场。

运行 Moodle 究竟要花什么

托管

一个 PHP 应用、一个数据库、一套文件存储，以及一个必须真的跑起来的定时任务。容量要按考试周和放榜日来算，而不是按普通的周二。还要一套与生产足够接近的预发布环境，演练才有意义——已经跑偏的预发布环境，排练的是另一出戏。

版本升级

Moodle 为每个版本公布支持终止日期。一个版本过了这个日期，安全修复就不再送达，所以保持版本更新不是日常清理——它就是你的安全态势。每一次大版本升级都包含代码步骤、数据结构步骤、一个停机窗口和事前的一次演练，而跳过一个版本只会让工作量叠加，不会省事。

插件兼容

插件目录是许多机构选择 Moodle 的原因，而每装一个插件，就多一份对别人发版节奏的依赖。于是升级变成一张矩阵：对每一个插件，目标版本有没有对应的构建、它还有没有人维护、它是否仍然能做教师围绕它安排了一整个学期的那件事。一个无人维护的插件，就能把整个站点摁在旧版本上——这正是站点跑在已停止支持的版本上最常见的路径。

安全补丁

Moodle 按固定节奏发布安全公告。自托管的话，处理它们是你的活：盯公告、判断紧急程度、打补丁、验证——有时不在计划内，有时正赶上假期，而懂这事的人不在。底下还有 PHP、数据库和操作系统，各有各的补丁流。

备份

有两样不同的东西都叫备份：课程导出，以及数据库和文件存储的基础设施备份。两者你都需要，而一份从未恢复过的备份只是一个假设。接着是让集团吃苦头的那个问题：你能不能只恢复一所学校，而不必让其余所有学校都进入维护窗口？

为什么到了集团规模，先崩的是多租户

一所学校很少碰到这个问题。集团碰到它，大约是在两所学校同一天想要不同东西的时候：不同的标志、不同的学期结构、对“谁可以看谁的数据”给出不同的答案。

一个 Moodle 站点给你的是单个组织内部的结构：可嵌套的分类、群组、可在分类层级授予的角色。这是真实的层级。但它的设计前提是一所机构一个站点——账号属于站点，管理是全站范围的，版本、插件集合和维护窗口由站点上的所有人共享。于是“每所学校有自己的管理员”在实践中往往落成“每所学校有一个我们相信不会点错东西的人”。

能暴露这道差距的问题，既无聊又具体：

• B 校能不能改自己的标志、配色和登录页，而不动到 A 校的？
• B 校的管理员能不能创建和删除只存在于 B 校的用户？
• 一位每周在两所学校各上两天班的教师，能不能只用一个账号？
• 集团能不能对每一所学校提一个问题，不用导出就得到一个答案？
• C 校退出集团时，它的数据、用户和内容能不能交接出去，然后被删除？
• 能不能只从备份恢复一所学校，而不给其余学校安排维护窗口？

在 Moodle 里，只要配置足够多、或者独立安装足够多，每一条都能做到。代价就是那些配置，或者那些安装。

三种常见的答案，以及各自的取舍

Moodle Workplace

商业版本，通过 Moodle 认证合作伙伴销售，补上了多租户。取舍在于：你现在买的是一款商业产品，中间还隔着一个合作伙伴，所以免费许可不再是你留在这里的理由——请把它和其他商业平台放在同等条件下比较，而不是当作现有产品来对待。另外要确认，学校集团的形态（年级、监护人、学期）如何映射到一款以职场培训为设计中心的产品上。

一份合作伙伴合同

认证合作伙伴负责托管、升级、打补丁并接电话。工作并没有消失，它变成了一行带 SLA 的预算，往往比招人更划算。有两个限制：它本身并不带来多租户——那仍然得靠 Workplace 或多套站点——而且成本通常随站点数和用户数增长，所以集团大致是按学校数付费。签约之前先问清楚离开是什么样子。

并行安装

一所学校一套 Moodle。是真的隔离——数据、品牌和停机各自独立——一所学校要交接，把它的站点交出去就行。取舍是一切都要乘以数量：十所学校就是十个升级窗口、十张插件矩阵、十套安全公告、十套备份机制。跨校报表变成一件导出再拼接的活，通常是一个电子表格，通常只有一个人知道它是怎么运作的。一次集团层面的改动要执行十遍，到第十一个月就开始跑偏。

集团很少是决定要用并行安装的，他们是走着走着就到了那儿——因为接入第四所学校时，新起一套站点是最快的办法。

插件里的 AI，不等于产品里的 AI

在 Moodle 部署里，大多数 AI 能力是以插件形式来的：一个供应商连接器、一个出题器、一个摘要工具。插件一直是 Moodle 生长的方式。但当一项功能是挂在平台旁边、而不是长在平台里时，有三个性质会表现得不一样。

答案的依据

答案是从哪里来的？通用连接器把提示词发给模型再把文本返回来，所以它反映的是模型的通用知识，而不是你的教学大纲或你的评分政策。有据可依，意味着在你自己的材料上做检索，并把每一句话引用回它出处的文档。在一个集团里，这首先是一个数据边界问题：A 校的文档绝不能成为给 B 校的答案的依据，而建立在单站点数据模型上的插件，根本没有租户边界可遵守。

安全性审查

谁选的模型、谁写的提示词、什么东西离开了你的基础设施、供应商会保存多久，以及请求里是否包含一个孩子写的作业。用插件的话，答案是写这个插件的人，加上你自己配置的部分——因为是开源代码，所以可审查，但审查的人是你，每个插件一次，每次升级再来一次。

审计

一个学期之后，一位家长或一位督学问起 AI 做了什么。你能不能出示：生成了什么、由谁生成、依据哪一份材料，以及在到达学员之前有人改动了什么？插件只会按自己的格式写进自己的表——如果它有记录的话。

插件不是问题所在。AI 与数据之间的边界，必须由划出其他所有边界的那套机制来划，而平台本身没有的边界，插件划不出来。

老实算这笔账

不要估算。打开工单系统和过去十二个月的变更日志，一条一条数。

annual operating hours, per Moodle site

    major upgrades        (windows per year)   x (hours per window)
  + point releases        (releases applied)   x (hours each)
  + plugin re-testing     (plugins relied on)  x (hours per upgrade)
  + security advisories   (acted on per year)  x (hours each)
  + backup restore tests  (tests per year)     x (hours each)
  + unplanned incidents   (last 12 months, from the ticket system)
  = hours per site per year

  x number of sites you run
  x loaded hourly cost of the people who do it
  + hosting, storage and bandwidth
  + partner or support contract
  = the number to compare against a licence

只计入换平台后会真正消失的工时。然后另列一份清单：今天你回答不了的集团层面的问题——本学期所有学校里有多少学员完成了儿童保护培训，以及哪些学校落后了。

什么时候 Moodle 仍然是对的答案

很多时候都是。如果有一支懂 Moodle 的内部系统团队，留下往往是最便宜、也最站得住脚的选择：完全掌控技术栈、不依赖任何厂商，还有一个覆盖了商业路线图不会优先考虑的那些教学法的插件生态。有些采购规定干脆就要求开源。而且迁移成本是实打实的——内容、题库、成绩册历史、账号，还有印在上百本手册里的旧链接。

离开的错误理由，是某一次升级搞砸了。正确的理由是结构性的：集团变大了，问题现在出在它的形态而不是软件，而运维成本是由一群本来受雇去做别的事的人在承担。

如果你真的要看看别处，该查什么

这里我们是厂商，请据此阅读。Lurno 是一个多租户平台，为上面描述的那种形态而造；学校集团正是它围绕设计的场景。下面这份清单，是我们希望被拿来核对的——核对我们，也核对你名单上的其他每一家。

• 租户模型。 要求现场演示创建嵌套组织，而不是在幻灯片上画。在 Lurno 里，一个组织之内可以包含更多组织，在这棵树的某个分支上授予的角色会沿该分支向下继承——集团的儿童保护负责人只需授权一次。
• 隔离在哪一层强制执行。 应用层的过滤离一次泄露只差一个 bug，所以要问边界是不是在数据库里。Lurno 的边界在数据库：676 次迁移中的 868 条行级安全策略，详见安全页。
• 品牌与域名。 按组织的白标品牌，以及自动签发 TLS 的自定义域名，这样每所学校的登录页都是它自己的；子组织在覆盖之前会继承母组织的品牌。
• 登录方式。 要问得精确，也请这样要求我们。Lurno 今天有的是合作方登录（静默 SSO）；SAML/OIDC 单点登录、MFA 和通行密钥在路线图上，尚未提供。如果你的学校是通过 Entra 或 Google Workspace 用 SAML 登录的，请向每一家厂商——包括我们——索要书面的时间表。
• 标准。 SCORM 1.2、SCORM 2004、xAPI 和 LTI 1.3 在 Lurno 中正在开发——已在产品中建模，运行时仍在构建。如果你手里有十年积累的 SCORM 包，这个问题请第一个问，不要放到最后。
• 商务。 今天账号通过邀请创建；自助注册、支付与结账已完成设计，尚未开发。
• 企业 LMS 没有理由去做的那些东西。 按数据类别限定范围的监护人门户、带公开核验页的证书、带证据的能力框架，以及四种产品语言，含完整 RTL 的阿拉伯语。
• 退出。 你怎么把所有东西取出来、以什么格式、要花多久？能很快回答这个问题的厂商，等于在告诉你一些事情。

我们维护着一份更完整的 Lurno 与 Moodle 逐项对比，其中直白地写明了 Moodle 对哪些人确实更合适。如果你算出来的结果是 Moodle 留下，那是个好结果——而且下一次预算会上，你手里有数字可以为它辩护。