用途
本技能面向开源项目维护者，尤其是个人或没有外部资助的小团队，帮助其回答一个具体问题：别人能从你们这里买到什么，是免费用户拿不到、或无法在一个周末自行构建的东西。技能明确区分：融资公司的营收模型不属于本技能范围，应转交 devtools-business-model。技能反复强调，使用量本身不会转化为收入；捐赠很少能覆盖薪资；对现有库重新许可收入未经证实且分叉风险高。
主要能力
- 三道持续约束：时间（每种模式都会产生销售、开票、支持、内容、运维等长期工作）、所有权（历史版本永远保留在其许可下；他人以强 copyleft 贡献的代码未经同意不能另售）、信任（贡献者和用户共同构建了项目价值，变更方式比价格更决定他们留下还是分叉）。
- 访谈式评估：通过一组问题收集目标、月净收入目标与日期、每周可投入小时、买家类型、产品形态、权利状况、是否做过“永久免费”等承诺、每周愿意做的工作类型等；每则消息只问一个问题，尽量用选择题。
- 五道门槛筛选：买家门槛、受众门槛、所有权门槛（按入站许可 MIT/BSD/Apache、MPL/LGPL、GPL/AGPL 分别判断可行性）、形态门槛（托管需要真实运维痛点；嵌入式库没有可托管对象；copyleft 双许可需要软件随产品分发）、产能门槛（估算固定维护加每客户每月小时数，超出预算的方案暂缓）。
- 按效率排序：默认顺序为付费附加 > 付费内容或配套产品 > 扩展安全支持 > 支持合同 > 赞助者内容 > 下一主版本的商业许可 > 托管服务 > 重新许可现有版本；用户指定某一轴优先时改用对应排序（首次收入时间、信任保留、合规成本、持久性）。
- 访谈答案重排规则：例如“想要更少小时”直接停止并转向维护者可持续性技能；目标日期在一个季度内则提升支持合同、扩展安全支持和赞助者内容，删除托管与许可变更；买家主要是个人开发者则删除面向组织定价的方案；公司已主动询问付费则把有限支持合同作为首单。
- 付费边界划定：从大型部署需求中列出候选付费功能（多节点协调、全局限额、审计追踪、加密与合规证据、SSO、优先响应、定制法律条款等），用已具名公司验证后再写代码；付费代码放在包裹免费核心的独立包或模块中，按客户凭证私下交付；按组织定价，可设刷卡自助层与定制层；发布“始终免费清单”并遵守。
- 明确非模式：应用市场列表只是采购渠道；捐赠与赞助很少养人；出售项目或加入公司属于退出，等于把信任决策交给买家。
使用方式
以技能描述中给出的典型调用为例：
- “我的 MIT 库有 8k star，公司在用，我如何靠它谋生？”→ 走完整流程。
- “我应该改成 AGPL 再卖商业许可吗？”→ 先过第 1 步所有权门槛，再看第 4 步。
- “Pro 版应该放什么？”→ 只做第 3 步，输出始终免费清单与付费边界。
- “我快烧尽了，觉得有钱就能解决”→ 先问第 1 个问题；若真实目标是减少小时数，转向 oss-maintainer-sustainability。
若能读取仓库，技能会先自行核查许可证及变更历史、仍在代码中的外部贡献者及其入站条款、CLA/DCO、FUNDING 文件、依赖方、项目名是否注册商标，并列出在 issue 中要求支持、发票或功能的公司作为首批买家证据。
适用场景与限制
适用于个人或小型无资助团队为单个开源项目设计变现阶段；不适合融资公司制定营收模型。技能反复声明：本内容不构成法律或税务建议，许可措辞、合同与税务问题应交由专业人士；其中引用的每个案例、数字和引文及来源见 references/case-evidence.md。技能还会提醒时间预期：被引用的薪资级案例耗时数年而非数月（例如 Sidekiq 2012 年发布，2017 年报告约每月 8 万美元）。若用户的时间预算已耗尽在免费项目上，或目标是减少工时，应转向维护者可持续性技能；若主要依靠捐赠与赞助，则转向赞助与筹款技能。