OSPOlogy + OSPO Summit China 2026 将于 2026 年 9 月 7 日在上海举行。活动是 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 同期议程的一部分。对于正在建设开源项目办公室（OSPO）、维护企业开源项目，或处理开源合规与社区协作的团队来说，这类活动的价值不只是听演讲，更在于带着真实问题找到可复用的组织经验。
为什么值得 OSPO 团队关注
OSPO 的工作往往横跨研发、法务、安全、采购和开发者关系。真正棘手的问题通常也不属于某一个部门：如何建立依赖审查流程、怎样衡量开源贡献、何时应该将内部项目开放，以及如何让治理规则不拖慢研发。
这次活动与云原生、OpenInfra 和 PyTorch 相关会议同期举行，意味着参与者可以把 OSPO 议题放进更具体的技术环境中讨论。例如，一个抽象的开源治理制度，最终需要落实到容器镜像、Python 依赖、模型许可证、贡献者协议和软件物料清单上。
由于来源摘要没有给出完整议程、报名方式或参会资格，计划参加前应以主办方最新公告为准，不要根据往届流程推断本届安排。
不要只带名片，带一份可讨论的问题清单
高质量交流需要足够具体的上下文。与其询问“如何做好 OSPO”，不如提前整理三个维度：当前流程、已经出现的阻塞，以及希望比较的方案。
可以围绕这些问题准备材料：
- 公司是否有统一的开源使用与贡献政策？
- 依赖许可证、漏洞和 SBOM 由谁负责检查？
- 员工向外部项目贡献代码时，需要经过哪些审批？
- 内部项目开源时，谁负责维护承诺和社区响应？
- OSPO 的效果通过风险下降、贡献增长，还是研发效率来衡量？
每个问题最好附带一个匿名化案例。例如，不要只说审批慢，而要说明一次普通贡献需要经过多少角色、耗时多久，以及最常见的退回原因。这样，其他参会者才能给出可比较的做法。
可以这样实践：生成一份参会讨论简报
下面是一个最小化的准备项目。这里明确做一个假设：你希望用结构化文件记录问题，再生成便于团队评审的 Markdown 简报。示例不代表活动官方流程。
先保存以下配置为 ospo-brief.json，按实际情况修改组织名、负责人和问题：
{
"organization": "Example Corp",
"owner": "Open Source Program Office",
"topics": [
{
"area": "Outbound contributions",
"current_state": "Every contribution requires manual approval",
"evidence": "Median review time is five working days",
"question": "How do other OSPOs apply risk-based approval?"
},
{
"area": "SBOM ownership",
"current_state": "Product teams generate SBOMs independently",
"evidence": "Formats and release gates differ across teams",
"question": "Which responsibilities should be centralized?"
}
]
}
然后保存并运行下面的 build_brief.py。它只使用 Python 标准库，无需安装额外依赖：
#!/usr/bin/env python3
import json
from pathlib import Path
source = Path("ospo-brief.json")
data = json.loads(source.read_text(encoding="utf-8"))
lines = [
f"# OSPO Discussion Brief: {data['organization']}",
"",
f"Owner: {data['owner']}",
""
]
for index, topic in enumerate(data["topics"], start=1):
lines.extend([
f"## {index}. {topic['area']}",
"",
f"- Current state: {topic['current_state']}",
f"- Evidence: {topic['evidence']}",
f"- Discussion question: {topic['question']}",
""
])
Path("discussion-brief.md").write_text("\n".join(lines), encoding="utf-8")
print("Generated discussion-brief.md")
执行命令：
python3 build_brief.py
生成的 discussion-brief.md 可以在参会前交给研发、法务和安全负责人审阅。团队应删去客户名称、未披露漏洞、合同条款和内部仓库地址，只保留足够支持讨论的匿名化事实。
把一天的交流转化为后续行动
参会前应为每个问题指定内部负责人，并定义希望带回来的结果：一项政策样例、一个工具选择依据、一位后续交流对象，或者一个需要验证的流程实验。会后再把结论拆成有负责人和截止日期的任务，避免会议笔记停留在文档里。
一个务实的参会检查表包括：确认 2026 年 9 月 7 日的行程与官方参与要求；筛选最多三个优先问题；准备经过脱敏的真实案例；提前协调研发、法务和安全观点；会后两周内评审行动项。OSPO 交流最有价值的结果，不是复制另一家公司的制度，而是找到适合自身风险、团队规模和工程节奏的治理方式。