Home Assistant 走到 2026 年：最有力的治理信号，是正式基金会中的月度发布机制

题图选用 Open Home Foundation 发布的 Paulus Schoutsen 官方肖像。本文关注 Home Assistant 由谁持有、谁出资、谁领导，以及发布节奏是否已足够稳定，能让运维者据此安排工作。[3]

到了 2026 年，真正依赖 Home Assistant 的运维者关心的早已越过“能否多接一种设备”。项目多年前就证明了这项能力。眼下更尖锐的问题是：面对如此庞大的体量和如此快的变化，项目能否持续给出清楚的计划，让运维者据此排期。越来越多的证据给出了肯定答案。[1][2][3]

答案来自几项彼此呼应的公开事实。项目按月发布版本，在周期的最后一周开放 beta 测试；Open Home Foundation 持有项目，人员规模和经费来源均有说明。项目还会淘汰维护代价过高的安装方式，并把路线图放到公众视野中。[1][3][4][5] 这些安排合在一起，使 Home Assistant 更接近一个可按计划运作的长期项目，超出了高活跃度社区仓库的范畴。

配图说明：题图采用 Open Home Foundation 官方发布的 Paulus Schoutsen 肖像。人物照片把视线引向项目背后的制度安排。如今，Home Assistant 的可靠性同时取决于治理、人力、单个集成与界面改进。[3]

固定的月度发布节奏，是维护者给出的承诺

Home Assistant 的发布 FAQ 写得很明确：新版本在每个月的第一个星期三发布，周期的最后一周主要用于 beta 测试。[1] 简单、固定正是这份时间表的价值。使用者由此知道变化何时到来、系统何时转入稳定阶段，也知道预发布反馈该送到哪里。

当前的发布记录说明，这份时间表确实在执行。home-assistant/core 的 GitHub releases 页面显示，2026.4.0 于 2026 年 4 月 1 日发布。补丁版本 2026.4.1、2026.4.3 和 2026.4.4 分别在 4 月 3 日、4 月 17 日和 4 月 24 日发布；下一轮 beta 2026.5.0b0 则在 4 月 29 日出现。[2] 这些日期显出两套同时运转的节奏：新功能按月进入正式版，月度版本上线后，修补工作随即以更快速度跟进。

平台团队由此得到一张可用的日历：新功能何时进入正式版，回归问题何时最容易暴露，大范围升级前何时适合先等补丁。根据 FAQ 和发布记录可以推断，Home Assistant 已把稳定节奏纳入对使用者的产品承诺。[1][2]

基金会明确了项目归属和经费来源

Open Home Foundation 的组织页面清楚列出了所有权与资金来源，这类信息在许多 OSS 项目中很少如此集中地公开。页面将基金会定义为位于瑞士的 Stiftung，经费来自商业合作伙伴费用和捐赠。Apollo Automation 与 Nabu Casa 等现有合作伙伴依合同须将授权产品的大部分利润返还基金会。这笔经费支持超过 50 名全职员工参与基金会项目和协作工作。[3]

基金会首页还给出一项规模指标：Open Home Foundation 拥有并治理超过 250 个开源项目、标准、驱动与库，包括 Home Assistant、ESPHome、Music Assistant、HACS、Piper 等。[8] Home Assistant 因而有了正式归属，也与一整组相关项目共同置于基金会治理之下。这比“大型仓库再配一家关联公司”的松散组合更接近一个有稳定归属的项目群。

创始人的作用依然清晰。Paulus Schoutsen 仍是 Home Assistant 公共形象中的核心人物。Ars Technica 在 2024 年的报道很早便捕捉到这项转变，将成立基金会视为 Home Assistant 寻求牢固根基、走向更广泛采用的一步。[7] 到了今天，公开文件又把经费、法律所有权、领导职责和合作伙伴义务集中写明，信息的分量已经超出品牌定位。[3][7][8]

代码合并之外，治理过程也逐渐公开

发布时间表说明版本何时变化，项目还需要让人看清方向如何决定。Home Assistant 正在公开这部分过程。Open Home Foundation 的 State of the Open Home 2026 回顾文章写道，活动正式介绍了新的 Community 部门，重点展示 GitHub 上的公开路线图，并将 “building in the open” 解释为及早公开背景和思路，让外界看到的不只是一份打磨完毕的结果。[4]

代码合并权限只是治理的一部分。贡献者还需要知道下一步应把精力投向何处，使用者也需要在决定定型前看见其中的取舍。路线图公开以后，许多选择依旧艰难；其中的取舍却能提前摆到社区面前，减少一种常见的 OSS 挫败：方向长期藏在幕后，决定落定后才向外界显露。

如今可以从三个入口观察 Home Assistant 的治理：基金会归属、固定发布节奏，以及在不满累积前吸收社区意见的公开规划过程。[3][4]

主动收紧支持范围，也体现治理取舍

真正能说明治理能力的决定，往往要划掉某些选项。Home Assistant 在 2025 年 5 月 22 日发布的弃用公告便是清楚的例子。项目正式弃用 Home Assistant Core、Home Assistant Supervised 及几种遗留 32-bit 架构，并说明受影响系统将从 2025.6 开始收到通知，相应支持于 2025.12 结束。[5]

这份公告的分量来自明确的理由。Home Assistant 写道，Core 与 Supervised 分别只占安装量的 2.5% 和 3.3%，给社区驱动的支持体系带来的维护工作与复杂度却高得多。[5] 项目因此减少需要维护的安装方式，让志愿者和全职员工把精力用在能惠及多数用户的地方。这正是治理的日常职责，写成产品故事并不耀眼。

这类取舍常常检验 OSS 项目能否走向成熟。Home Assistant 接受覆盖面略窄的结果，换取一条更容易支持和维护的主路径。对运维者来说，这项选择通常更值得信赖。

仓库活跃度说明了治理为何重要

截至 2026-04-30T05:04:56Z UTC，GitHub API 显示 home-assistant/core 仓库有 86,865 stars、37,388 forks、3,712 个 open issues，最近一次 push 时间为 2026-04-29T21:50:38Z。[6] 这些数字不能直接证明软件质量，却说明 Home Assistant 确实拥有庞大的体量、频繁的变化和大量下游依赖。治理对它的重要性远高于小型个人项目。

小型兴趣项目可以较长时间依靠即兴处理，巨大的智能家居控制平台则需要稳定的归属、发布节奏和取舍原则。Home Assistant 如今已将这些安排公开，日常运作有了清楚的依据。[1][3][4][5][6]

这些信号如何影响实际使用

对实际运行 Home Assistant 的人来说，结论很直接。仪表盘改版和 Matter 相关改进固然有用，项目最重要的长期资产仍是逐渐可供查验的运作方式。发布时间、beta 反馈渠道、组织领导、人员经费、被淘汰的安装方式和未来工作的讨论地点，如今都有公开记录。[1][2][3][4][5]

Home Assistant 仍需要大量维护。它连接着数量庞大的集成，家庭环境中又充满不稳定的设备、厂商云服务和无线协议。治理改变了风险的分布：更多不确定性来自智能家居系统的外围，项目自身能否持续正常运作所带来的疑虑正在减少。[1][3][5]

2026 年的 Home Assistant 把更多真实运作方式置于公众视野。信息越清楚，外界越容易建立信任，也越能提出具体批评。成熟的 OSS 通常正需要这样的可见度。

cronfeed.work