# 1. GitHub Sponsors、Open Collective 的真实工程价值 A 两个平台完全一样 B 赞助无需项目价值 C 赞助是开源的主要收入 D GitHub Sponsors 简单直接、Open Collective 透明财务，两者为开源提供资金支持与可持续 ✓ 正确答案
# 2. 赞助者关系（Sponsor Relationship）的真实维护 A 赞助者关系维护靠感谢认可、沟通透明、回报价值、尊重回应与长期经营，形成双赢 ✓ 正确答案 B 赞助者只需感谢一次 C 赞助关系无需回报 D 赞助关系是一次性的
# 3. Copyleft 在企业内部的真实传染风险 A Copyleft 会传染整个软件 B Copyleft 与衍生作品无关 C 内部使用 Copyleft 一定安全 D Copyleft 传染取决于使用方式、是否分发与是否衍生，需评估、隔离并合规处理 ✓ 正确答案
# 4. MIT、Apache 2.0、GPL、AGPL、LGPL 的真实工程边界 A 所有许可证都差不多 B 许可证与工程选型无关 C AGPL 与 MIT 无差别 D MIT/Apache 宽松商业友好，GPL/AGPL 强传染，LGPL 弱传染，按使用方式与分发判断合规 ✓ 正确答案
# 5. 上游漏洞（Upstream Vulnerability）的真实响应 A 上游漏洞只能等上游修复 B 上游漏洞无需评估影响 C 所有上游漏洞都需立即升级 D 上游漏洞响应应评估影响、升级修复、缓解降级、监控沟通，分级及时处理 ✓ 正确答案
# 6. 开源商业化（Open Source Commercialization）的真实路径 A 开源商业化路径有 Open Core、SaaS、服务、双许可等，需平衡开源与商业、明确定价价值 ✓ 正确答案 B 开源项目不能商业化 C 商业化必须牺牲开源 D 开源商业化只有一种方式
# 7. 核心依赖（Critical Dependency）的真实风险管理 A 核心依赖无需管理 B 核心依赖风险在单点、故障、消失与安全，需备份、监控、冗余、降级预案并慎重引入 ✓ 正确答案 C 核心依赖越多越好 D 核心依赖只能被动接受
# 8. 维护者消失（Bus Factor）的真实风险评估 A Bus Factor 衡量关键人离开导致停滞的风险，评估看关键人数量与知识集中，降低靠多维护者与知识文档化 ✓ 正确答案 B Bus Factor 只与代码量有关 C Bus Factor=1 是最健康的 D Bus Factor 无法降低
# 9. Dual Licensing 商业模式的真实边界 A 双许可无需贡献者授权 B 双许可无需区分许可 C 双许可通过开源+商业许可实现收费，需 CLA 支撑、清晰许可边界与合规，适合库/组件 ✓ 正确答案 D 双许可与社区无关
# 10. Open Core 模型的真实工程边界 A Open Core 应把核心功能全部付费 B Open Core 核心价值开源、高级功能付费，需合理划分、价值清晰、平衡社区与商业 ✓ 正确答案 C Open Core 无需考虑社区 D Open Core 核心越弱越好
# 11. 依赖升级（Dependency Upgrade）的真实策略 A 依赖应永不升级 B 依赖升级应安全优先、分级、测试验证、渐进、持续小步，避免侥幸与盲目升级 ✓ 正确答案 C 依赖升级可一次跨多版本 D 依赖升级无需测试
# 12. 依赖备份（Dependency Backup）的真实工程边界 A 依赖备份用 fork、镜像、缓存、lockfile 防"消失"，重点备份关键依赖、定期更新、权衡成本 ✓ 正确答案 B 应备份所有依赖 C 依赖备份无需更新 D 备份无需考虑许可
# 13. Security Advisory 的真实工程编写 A Security Advisory 应概述、影响、严重度、修复、披露协调与致谢，清晰、分级、可行动 ✓ 正确答案 B 安全公告只需一句"有漏洞" C 安全漏洞应立即公开 D 安全公告无需严重度分级
# 14. 社区成员不当行为（Misconduct）的真实处理 A 不当行为无需处理 B 不当行为处理靠行为准则、举报渠道、处理程序、公正后果与透明及时，预防优先、程序公正 ✓ 正确答案 C 处理只需封禁 D 不当行为与社区健康无关
# 15. 许可证兼容性（License Compatibility）的真实评估 A 所有许可证都兼容 B 许可证兼容性需评估组合方式、传染与冲突，宽松许可兼容好，Copyleft 传染需判断 ✓ 正确答案 C GPL 与任何许可都兼容 D 许可证兼容性无需评估
# 16. 个人贡献者许可证（Contributor License）的真实签署 A CLA 无需理解即可签署 B 员工贡献公司代码无需雇主授权 C CLA 与 DCO 相同 D 签署 CLA 是贡献前提，需理解授权内容、区分 CLA/DCO、处理雇主授权 ✓ 正确答案
# 17. 新依赖引入时如何把直接许可、传递许可、专利条款、分发场景四步检查固化到 CI 门禁与依赖审批流程？ A 依赖引入无需许可检查 B 传递依赖无需检查 C 新依赖应做直接、传递、专利、分发四步检查，并用 CI 门禁、审批流程与白黑名单固化 ✓ 正确答案 D 许可检查无法自动化
# 18. Fork 决策的真实工程边界 A Fork 用于上游不可用、需定制或风险控制，能贡献上游就优先贡献，评估维护成本与同步 ✓ 正确答案 B 任何情况都优先 fork C Fork 后无需同步上游 D Fork 无维护成本
# 19. 公开漏洞（Public Disclosure）的真实时机判断 A 公开漏洞应"修复后披露、协调窗口、负责任披露"，避免公开漏洞被利用 ✓ 正确答案 B 发现漏洞应立即公开 C 漏洞应永远保密 D 公开时机与风险无关
# 20. 社区决策（Decision-Making）的真实机制 A 社区决策是共识优先、投票兜底、透明、参与、层级与记录，平衡效率与参与 ✓ 正确答案 B 社区决策由一人独断 C 社区决策无需透明 D 社区决策与成员无关
# 21. 反馈文化（Feedback Culture）的真实跨文化差异 A 所有文化反馈方式相同 B 跨文化团队用单一反馈方式 C 反馈文化在直接/间接、公开/私下、负面态度与层级上有差异，应理解差异、调整方式、保持建设性 ✓ 正确答案 D 反馈方式与文化无关
# 22. 异步决策（Async Decision）的真实结构 A 异步决策无需时限 B 异步决策只能靠实时会议 C 异步决策无需记录 D 异步决策结构是提案、讨论、表决、记录，关键在清晰、时限、透明与角色明确 ✓ 正确答案
# 23. 文化差异（Cultural Difference）在工程团队的真实影响 A 文化差异影响沟通、决策、反馈与冲突，协作靠理解包容、建立机制、明确规范与尊重 ✓ 正确答案 B 文化差异不影响团队 C 跨文化团队无需机制 D 文化差异是永远无法逾越的障碍
# 24. 文档先行（Doc-First）如何让设计与评审前置，文档与实现的同步成本如何控制？ A Doc-First 会增加返工 B Doc-First 让设计评审前置、减少返工，同步成本靠文档精简、贴近代码、实现时更新控制 ✓ 正确答案 C 文档越详细越好 D 文档无需与代码同步
# 25. 权力距离（Power Distance）真实团队沟通影响 A 权力距离影响层级、反馈、决策与直言，适应靠理解差异、创造安全、尊重层级与双向沟通 ✓ 正确答案 B 高权力距离团队沟通更开放 C 权力距离与沟通无关 D 所有团队都该忽视权力距离
# 26. 英语沟通（English Communication）的真实工程边界 A 英语是工程通用语言，非母语者边界在读写听说差距与表达，提升靠读写优先与沉浸实践 ✓ 正确答案 B 英语只影响读文档 C 非母语者无法用英语交流 D 英语沟通与开源无关
# 27. Notion/Confluence 的页面结构与权限如何支撑异步协作，知识库的维护与检索成本如何治理？ A 知识库只需堆文档 B 知识库无需权限 C 用页面结构、模板、链接与权限支撑异步协作，知识库治理靠维护责任与定期清理控制成本 ✓ 正确答案 D 知识库无需维护
# 28. 决策日志（Decision Log）的真实使用 A 决策日志只需记录结论 B 决策日志应结构化记录背景、选项、理由与后果，记"为什么"，及时更新、可追溯 ✓ 正确答案 C 决策日志无需复盘 D 决策日志事后补也准确
# 29. 节假日冲突（Holiday Conflict）的真实协调 A 节假日应统一取消 B 节假日协调靠共享日历、提前规划、尊重差异、公平轮换与异步协作 ✓ 正确答案 C 节假日无需协调 D 应强迫其他地区成员配合
# 30. 邮件与即时通讯在信息密度、异步性与可检索性上的取舍，团队沟通矩阵如何制定？ A 所有沟通都用 IM B 邮件密度高、异步、可检索，IM 即时、碎片、难检索，应制定沟通矩阵按场景选渠道 ✓ 正确答案 C 所有沟通都用邮件 D 重要信息用 IM 即可
# 31. Linear / Jira 在异步协作的真实边界 A 工具能替代所有沟通 B 工具能自动解决沟通问题 C 任务越多协作用越好 D Linear/Jira 支撑任务管理与异步协作，但工具只是载体，流程与沟通才是关键，避免形式主义 ✓ 正确答案
# 33. 跨文化培训如何减少协作摩擦，培训内容与效果的评估怎么做？ A 跨文化培训只需上一次课 B 培训只需讲理论 C 培训效果无需评估 D 跨文化培训内容在文化差异意识与沟通技巧，评估用反应、学习、行为、结果四层，核心看行为改变 ✓ 正确答案
# 34. 值班（On-call）跨时区的真实公平性设计 A 值班负担应集中给少数人 B 跨时区值班公平靠轮换、时区考虑、跨时区接力、透明与支持，公平分担、时区智能 ✓ 正确答案 C 值班无需考虑时区 D 值班公平与轮换无关
# 35. 核心重叠时间（Core Overlap Hours）的真实设计 A 重叠时间越长越好 B 核心重叠时间应公平安排、时长适中、用于实时同步，其余靠异步协作 ✓ 正确答案 C 重叠时间应让某时区总熬夜 D 重叠时间无需公平
# 36. World Time Buddy / Every Time Zone 在跨时区的真实使用 A 时区工具是多余的 B 时区工具无法找重叠 C 时区靠记忆即可 D 时区工具用于找重叠、排会议、换算与可视化，核心是直观、准确、标注时区避免错误 ✓ 正确答案
# 37. 会议时间轮换如何让跨时区团队公平分担，轮换的排班与通知机制如何设计？ A 会议时间应固定给某时区 B 轮换只需轮流 C 轮换无需提前通知 D 会议时间轮换靠公平排班、提前通知、时区换算、记录与补偿，公平分担不便 ✓ 正确答案
# 38. 时区感知工具（Time Zone Tool）的真实使用 A 时区感知工具用日历换算、世界时钟、排程工具与标注时区，准确、体贴、减少时区错配 ✓ 正确答案 B 时区感知只靠记忆 C 时区标注无关紧要 D 时区工具无法提升协作
# 39. 24/7 团队的值班轮换真实经验 A 值班应固定给少数人 B 值班交接无关紧要 C 夜班无需补偿 D 24/7 值班靠班次/接力覆盖、公平轮换、清晰交接、健康优先与工具支撑，核心是覆盖、公平、可持续 ✓ 正确答案
# 40. 时区与节假日（Holiday）真实协调 A 只需考虑时区，忽略节假日 B 节假日不影响协作 C 时区与节假日需共享日历、提前规划、尊重差异、公平灵活与异步兜底综合协调 ✓ 正确答案 D 应强迫各地配合
# 41. 许可证合规（License Compliance）工具的真实边界 A 工具能完全替代人工判断许可证合规 B 合规工具只能处理直接依赖，无法识别传递依赖 C 工具可自动扫描依赖树并持续监控，但语义与使用场景判断仍需人工结合流程 ✓ 正确答案 D 使用合规工具后无需再建立依赖审批流程
# 42. CVE（Common Vulnerabilities and Exposures）申请的真实流程 A 申请 CVE 只需直接提交，无需先复现确认漏洞 B 申请 CVE 后应立即公开，无需与维护者协调 C CVE 编号是奖励发现者的一种荣誉 D CVE 申请需先确认漏洞、联系 CNA 提交描述，并遵循先协调后公开的披露流程 ✓ 正确答案
# 43. 漏洞奖励（Bug Bounty）的真实范围设定 A 范围应覆盖全部资产，越多越好 B 漏洞奖励范围越模糊，研究者越容易发挥 C 范围需明确资产、漏洞类型、奖励标准与例外条款，聚焦真实风险并控制成本 ✓ 正确答案 D 设定奖励标准时无需考虑漏洞严重程度
# 44. 行为准则（Code of Conduct）的真实执行 A 行为准则需明确负责人、透明流程与分级处理，并平衡开放与安全边界 ✓ 正确答案 B 制定行为准则后社区冲突自然减少 C 行为准则执行得越严格，社区发展越好 D 行为准则只需模板化，无需与项目价值观匹配
# 45. 开源项目的 CLA 与 DCO 选择、签名流程，以及员工开源贡献的雇主授权如何治理？ A CLA 与 DCO 完全等价，可随意互换 B 员工贡献无需处理雇主授权 C 需按权利清晰度与社区友好度选择 CLA 或 DCO，并通过自动化签名与雇主授权管理落地 ✓ 正确答案 D 签名流程应完全人工，避免自动化
# 46. 负责任披露（Responsible Disclosure）的真实时间窗口 A 发现漏洞应立即公开，无需协调 B 时间窗口通常为 30-90 天，按严重度调整，给维护者修复空间并防止无限拖延 ✓ 正确答案 C 时间窗口越长越好，无需设置上限 D 公开披露时无需提供受影响版本与缓解措施
# 47. PR 描述（Description）的真实写作原则 A PR 描述应说明问题、方案、影响与测试，结构清晰并关联 Issue，以降低评审成本 ✓ 正确答案 B PR 描述只需写一句"修复了 bug" C PR 描述越长越好，无需聚焦变更 D PR 描述是给作者自己看的，无需考虑评审者
# 48. 异步会议（Async Meeting）的真实可行性边界 A 所有会议都应改为异步会议 B 异步会议完全无法用于跨时区团队 C 异步会议无需文档支撑 D 信息同步、评审、跨时区议题适合异步，而头脑风暴、冲突决策等需同步协作 ✓ 正确答案
# 49. SaaS 化开源的真实合规边界 A 所有开源软件 SaaS 化都要求开源服务端代码 B GPL 与 AGPL 在 SaaS 场景下完全等价 C SaaS 化完全无需考虑许可证合规 D 需区分许可证类型与分发场景，AGPL 在通过网络提供服务时通常触发开源义务 ✓ 正确答案
# 50. 专利条款（Patent Clause）的真实法律风险 A 开源许可证完全免除使用者的专利侵权责任 B 专利条款涉及许可证的专利授权与报复机制，Apache 2.0/GPL v3 含专利授权但起诉贡献者可能触发授权终止 ✓ 正确答案 C 所有开源许可证都包含相同的专利授权条款 D 专利授权与版权授权是完全相同的一回事
# 51. 内部 Fork 的真实长期成本 A 内部 Fork 没有任何额外成本 B 内部 Fork 与上游永远保持一致 C 内部 Fork 只需一次修改，无需维护 D 内部 Fork 会带来同步、安全、人力、分叉漂移与社区损失等长期成本，应优先考虑回传上游 ✓ 正确答案
# 52. 源代码可用（Source Available）与开源的真实差异 A 源代码可用与开源完全等价 B 只要代码公开就算开源 C 开源符合 OSI 标准允许自由使用、修改与分发，Source Available 仅代码可见但使用与分发受限 ✓ 正确答案 D Source Available 允许无限制的商业化
# 53. 全职开源（Full-Time OSS）的真实可行性 A 全职开源只需写代码，收入稳定无需经营 B 全职开源需依托赞助、商业支持、雇佣或商业产品等收入来源，并管理收入波动与精力分配 ✓ 正确答案 C 全职开源完全靠情怀即可持续 D 全职开源与普通上班一样稳定
# 54. 漏洞修复的向后兼容（Backward Compatibility）真实边界 A 向后兼容永远优先于安全修复 B 所有漏洞修复都必须破坏向后兼容 C 危险漏洞修复应优先安全，但用默认安全、弃用迁移与版本控制降低兼容冲击 ✓ 正确答案 D 修复漏洞无需考虑用户影响
# 55. 漏洞分级（Severity Scoring）的真实使用 A CVSS 基础分即可完全决定处置优先级 B 漏洞分级需结合 CVSS 基础分、环境分与业务影响，并据此设定修复 SLA ✓ 正确答案 C 高危漏洞无需关注是否暴露在攻击面 D 漏洞分级是静态的，无需随利用情况调整
# 56. 一份高质量 RFC 从初稿到评审通过需要多少轮迭代，如何用模板与评审清单压缩写作周期？ A 高质量 RFC 只需一次初稿即可通过 B RFC 写作与评审无关，无需多人参与 C 模板和评审清单会增加 RFC 迭代轮次 D RFC 通常需 3-5 轮迭代，可用模板、评审清单与先对齐再写来压缩周期 ✓ 正确答案
# 57. 语言误读（Miscommunication）的真实案例 A 语言误读只发生在不同母语之间 B 语言误读无法避免，只能接受 C 异步书面沟通永远不会被误读 D 语言误读源于语气、措辞、文化、时区与书面沟通的模糊性，应通过主动确认、清晰表达与书面跟进避免 ✓ 正确答案
