支持 Konva
Konva 采用 MIT 许可证，商用免费，不需要付费，也不需要署名。 这一页讲的是如果你想回馈，可以做什么。
官方渠道在 GitHub Sponsors， 作者的主页是 @lavrton。
为什么这件事值得一提
Konva 是一个由个人长期维护的项目。从 CHANGELOG 能看出维护是认真的—— 10.4.0 一个版本就修了几十条问题，每条破坏性变更都写清了影响范围。 这种质量的维护需要持续投入的时间。
对使用方来说，这件事的现实含义是：issue 的响应速度取决于维护者能挤出多少时间。 一个你依赖的基础库如果维护者被迫转去做别的工作， 受影响的是你三年后的项目，而不是抽象的开源生态。
除了出钱还能做什么
对大多数人来说，下面这些比捐款更有价值，也更容易做到。
提交可复现的 issue。 带最小复现（CodeSandbox / JSFiddle）、 说明 Konva 版本与浏览器的 issue，维护者能在十分钟内定位； 只有文字描述的"我的图形不显示"，可能来回三轮还搞不清楚。 你省下的是维护者的时间，这是这个项目最稀缺的资源。
回答 StackOverflow 上的问题。 konvajs 标签下的多数问题是用法问题，
不需要维护者出面。答案会被搜索引擎索引，后来者能直接受益，
这实际上减少了重复提问的总量。
补文档。 官方文档的示例出错、说明与实现不符， 这类 PR 门槛低、合并快，而且对其他人的帮助很直接。
公开你在用它。 对个人维护者来说， "哪些公司在生产环境用这个库"是争取赞助和商业支持时最有力的材料。 在 issue 里说一句、在技术博客里提一句，成本为零。
把修复回贡上游。 如果你为了绕过某个 bug 打了 patch， 花点时间把它提成 PR。否则每次升级你都要重新打一遍， 这笔账长期看你自己也是亏的。
常见问题
商用需要付费或署名吗？
不需要。MIT 许可证允许商用、修改、闭源分发， 唯一的要求是在你的软件分发物里保留许可证声明和版权声明。
实践上，前端项目通常通过打包工具的 license 插件
（如 webpack-license-plugin）自动生成一个第三方许可证清单文件来满足这一点。
如果你的产品有"开源软件声明"页面，把 Konva 加进去就可以了。
国内怎么赞助？
GitHub Sponsors 需要绑定境外支付方式（信用卡或 PayPal）， 国内个人开发者通常不方便。这不是你的问题， 上面那些非资金的方式同样有价值，不必为此纠结。
企业侧则有几条可行路径：走开源软件采购或技术咨询的名目签一份合同、 购买作者提供的付费支持、或者把员工投入上游贡献的工时正式计入项目成本—— 最后这条往往是最容易通过审批的，因为它本来就是在解决自己的问题。
作者提供付费支持吗？
提供。深度的技术支持可以通过作者的 GitHub 主页联系。
如果你的项目重度依赖 Konva、且有"出问题必须在 24 小时内有人响应"这类要求， 买一份支持比自己养一个能读懂 Konva 源码的人便宜得多。 这在国内企业里常常可以走"技术服务费"而不是"捐赠"的科目，审批上顺畅很多。
本站接受赞助吗？
本站是 Konva 官方文档的中文翻译，不是官方项目， 也不代表 Konva 团队。如果你想支持 Konva，请直接支持上游。
国内环境注意事项
支付渠道。 GitHub Sponsors 和 OpenCollective 都需要境外支付方式。 Open Collective 支持企业开票（发票由 Open Collective 基金会开具）， 这在需要报销的场景下比 GitHub Sponsors 方便， 但开出来的是境外主体的发票，能不能入账取决于你们财务的口径—— 动手之前先问财务，不要先付款再想报销。
更现实的路径是把回馈变成工作的一部分。 国内企业对"捐赠开源"这个科目 普遍陌生，审批链条长；但"安排工程师修复我们依赖的开源库里的 bug" 是技术债偿还，属于正常研发投入，不需要额外审批。 效果上，一个被合并的 PR 对项目的价值不低于同等工时的捐款， 而且你自己的项目直接受益。
访问问题。 GitHub Sponsors 页面在国内访问不稳， 赞助流程中断可能导致重复扣款。如果中途失败， 先去 GitHub 的 Settings → Billing 确认状态，不要直接重试。