过去一年，英特尔像在执行一份清单——逐个归档自家维护的开源项目。Clear Linux、Software Defined Silicon、Optane Memory 相关软件项目，以及开放生态社区建设与推广工作，先后被标记为"不再维护"，GitHub 仓库设为 archived，issue 和 PR 全部关闭。
这不是偶尔的修剪，而是持续的动作。最近一批项目再次被归档，节奏稳定得让人不安。
哪些项目被砍，影响多大
被归档的项目里，有些本就处于停滞状态，社区几乎无人使用，停掉只是正式确认现实。但几款知名项目的终止，影响面不小：
- Clear Linux——英特尔自家的性能优化 Linux 发行版，曾以极快的启动速度和激进裁剪策略在容器/云场景中有一批用户。归档后，安全补丁和内核更新不再跟进，仍在跑的生产环境面临风险。
- Software Defined Silicon（SDSi）——通过许可证解锁 CPU 额外功能的机制，对应内核模块和工具链一并停更。如果你在数据中心用了这个特性，升级路径断了。
- Optane Memory 相关软件——持久内存的驱动和管理工具不再更新。Optane 硬件本身已停产，软件归档只是收尾，但依赖 pmem API 的应用需要提前迁移。
更值得注意的是，英特尔连开放生态社区运营这类"软基础设施"也一并撤出。这意味着不只是代码停更，文档、论坛、会议等支撑体系也在收缩。
大厂归档背后的逻辑
企业开源项目被归档，通常不是"做不好"，而是"不再值得做"。几个常见触发条件：
- 战略转向——业务重心变了，项目不再服务核心路线。英特尔从 CPU 单一赛道转向 GPU/AI，Clear Linux 这类面向自家 CPU 优化的发行版自然边缘化。
- 投入产出失衡——维护者成本持续，但用户增长停滞或社区贡献不足，内部 ROI 审查时被砍。
- 硬件退场——Optane 和 SDSi 都绑定特定硬件，硬件停产后软件没有独立生存空间。
对开发者来说，关键问题不是"英特尔为什么这么做"，而是"我依赖的项目会不会也这样"。
实操：检测你的依赖是否已被归档
与其等项目归档后手忙脚乱，不如主动扫描。下面是一个 Python 脚本，检查你 requirements.txt 或 package.json 里列出的 GitHub 仓库是否已被 archived：
#!/usr/bin/env python3
"""扫描依赖列表，检测上游 GitHub 仓库是否已归档。"""
import json
import subprocess
import sys
from pathlib import Path
def get_repo_url_from_pip(pkg_name: str) -> str | None:
"""用 pip show 获取包的 Home-page 或 Project-urls，提取 GitHub 链接。"""
try:
result = subprocess.run(
["pip", "show", pkg_name],
capture_output=True, text=True, timeout=10,
)
for line in result.stdout.splitlines():
if "github.com" in line.lower():
# 取出完整 URL
parts = line.split()
for p in parts:
if "github.com" in p:
return p.rstrip("/")
except Exception:
pass
return None
def check_archived(repo_url: str) -> dict:
"""调用 GitHub API 检查仓库是否归档。"""
# 从 URL 提取 owner/repo
# 支持 https://github.com/owner/repo 各种格式
stripped = repo_url.replace("https://github.com/", "").replace("http://github.com/", "")
# 去掉尾部 /anything（如 /issues、/tree/main）
owner_repo = stripped.split("/")[0] + "/" + stripped.split("/")[1] if len(stripped.split("/")) >= 2 else stripped
api_url = f"https://api.github.com/repos/{owner_repo}"
try:
result = subprocess.run(
["curl", "-s", api_url],
capture_output=True, text=True, timeout=15,
)
data = json.loads(result.stdout)
return {
"repo": owner_repo,
"archived": data.get("archived", False),
"description": data.get("description", ""),
"last_push": data.get("pushed_at", ""),
}
except Exception as e:
return {"repo": owner_repo, "error": str(e)}
def scan_requirements(req_file: Path):
"""扫描 requirements.txt 中的包。"""
with open(req_file) as f:
for line in f:
line = line.strip()
if not line or line.startswith("#"):
continue
# 提取包名（去掉版本 specifier）
pkg = line.split("==")[0].split(">=")[0].split("<=")[0].split("~=")[0].split("[")[0].strip()
repo_url = get_repo_url_from_pip(pkg)
if repo_url:
info = check_archived(repo_url)
status = "⚠️ 已归档" if info.get("archived") else "✅ 正常"
print(f"{pkg}: {status} ({info.get('repo', '')})")
if info.get("last_push"):
print(f" 最后推送: {info['last_push']}")
else:
print(f"{pkg}: 无法定位 GitHub 仓库")
if __name__ == "__main__":
req_path = Path(sys.argv[1]) if len(sys.argv) > 1 else Path("requirements.txt")
if not req_path.exists():
print(f"文件不存在: {req_path}")
sys.exit(1)
scan_requirements(req_path)
运行方式：
# 先安装依赖环境，然后扫描
python3 check_archived_deps.py requirements.txt
输出示例：
numpy: ✅ 正常 (numpy/numpy)
最后推送: 2025-06-10T12:00:00Z
intel-openpmem: ⚠️ 已归档 (intel/pmem)
最后推送: 2023-11-01T08:30:00Z
脚本逻辑很简单：从 pip show 拿到包的 GitHub 地址，再调 GitHub REST API 看 archived 字段。如果上游已归档，你就该考虑替代方案或自行 fork 了。
归档之后怎么办
项目被归档不等于代码消失，仓库还在，只是不再接受变更。你有三条路：
1. 找替代项目
Clear Linux 用户可考虑 Fedora 或 Ubuntu 的性能优化版本；Optane pmem API 用户可迁移到 memkind（已被英特尔移交给社区维护）。替代方案要提前验证兼容性，不要等到安全漏洞出现才动手。
2. 自行 fork 维护
# fork 一个已归档的仓库到自己的账号
gh repo fork intel/pmem --clone=false
# 克隆你的 fork
git clone https://github.com/你的用户名/pmem.git
cd pmem
# 确认 CI 和测试还能跑
make test
fork 之后你就是维护者，安全补丁、兼容性更新都得自己扛。评估一下你团队是否有这个长期投入。
3. 逐步移除依赖
如果项目功能在你的场景中已不关键，直接剔除是最干净的方案。用 pipdeptree 查清楚依赖链，确认没有间接引用后再删：
pipdeptree -p intel-package-name
依赖健康检查清单
英特尔的归档潮是一个信号：大厂开源项目的生命周期由商业决策驱动，而非社区需求。不管你用的是谁的仓库，都值得定期做一次依赖健康检查：
- ☐ 上游仓库是否已 archived 或超过 6 个月无 commit？
- ☐ issue 列表是否长期无人响应？
- ☐ 安全漏洞是否有未修复的 open issue？
- ☐ 是否有活跃的替代项目或社区 fork？
- ☐ 你的代码中对该项目的依赖是否可以替换或移除？
- ☐ 是否有内部 fork 和补丁维护的长期计划？
把这项检查纳入季度技术评审，比事后救火成本低得多。英特尔的归档不会是最后一次，下一波可能来自任何一家调整战略的大厂。