交完代码不等于交完差🔥😵很多人看到 Grant 项目的仓库上线就开始庆祝，觉得“成了”。
但我读 @Dusk_Foundation Grants Program 的要求时，视线被最后一个 milestone 牢牢钉住了：申请人必须写进一年的维护计划。
一年。不是“有问题可以提 issue”，是白纸黑字写进交付清单的硬性要求。
Dusk 还要求配套文档、测试、可复现的安装运行步骤。翻译成人话就是：拿到支持的团队，不能只在演示日把功能点亮，你得让后来的人接得住、修得动。
demo 容易，维护才贵
对申请方来说，短期内做个能跑的 demo 真不算难。代码写出来能亮，演示日过了就行。
但真正贵的是一年后——依赖升级了，有人提 issue 了，文档里的命令跑不通了。这时候团队还愿不愿意回头处理？愿意的话，谁来做？预算里有没有这部分的工时？
很多项目第一个版本做出来之后，核心成员就转去忙别的了。仓库还在，用户来了，装不上，问没人答。成本不会消失，只会转嫁给生态里的下一个开发者——那个人可能是你，也可能是我。
这条要求，是一道筛选
我不觉得 Dusk 有了这条要求，就能保证每个项目都长期活跃。说实话，光靠一份申请书保证不了任何事情。
但它至少做对了一件事：把“维护”这笔成本，提前摆到申请书上。
愿意把一年维护写进预算的团队，更像是要交付基础设施，而不是完成一次性的作业。这个区别，申请的时候看不出来，一年后翻仓库状态的时候，一目了然。
$DUSK 后面值得看的是，@Dusk 会不会把这些项目的维护进度和仓库状态公开出来——看得见的数据，比任何承诺都诚实。让 #dusk 的生态增长，有迹可循，而不是只剩一堆上线即沉寂的仓库😖。
但我读 @Dusk_Foundation Grants Program 的要求时，视线被最后一个 milestone 牢牢钉住了：申请人必须写进一年的维护计划。
一年。不是“有问题可以提 issue”，是白纸黑字写进交付清单的硬性要求。
Dusk 还要求配套文档、测试、可复现的安装运行步骤。翻译成人话就是：拿到支持的团队，不能只在演示日把功能点亮，你得让后来的人接得住、修得动。
demo 容易，维护才贵
对申请方来说，短期内做个能跑的 demo 真不算难。代码写出来能亮，演示日过了就行。
但真正贵的是一年后——依赖升级了，有人提 issue 了，文档里的命令跑不通了。这时候团队还愿不愿意回头处理？愿意的话，谁来做？预算里有没有这部分的工时？
很多项目第一个版本做出来之后，核心成员就转去忙别的了。仓库还在，用户来了，装不上，问没人答。成本不会消失，只会转嫁给生态里的下一个开发者——那个人可能是你，也可能是我。
这条要求，是一道筛选
我不觉得 Dusk 有了这条要求，就能保证每个项目都长期活跃。说实话，光靠一份申请书保证不了任何事情。
但它至少做对了一件事：把“维护”这笔成本，提前摆到申请书上。
愿意把一年维护写进预算的团队，更像是要交付基础设施，而不是完成一次性的作业。这个区别，申请的时候看不出来，一年后翻仓库状态的时候，一目了然。
$DUSK 后面值得看的是，@Dusk 会不会把这些项目的维护进度和仓库状态公开出来——看得见的数据，比任何承诺都诚实。让 #dusk 的生态增长，有迹可循，而不是只剩一堆上线即沉寂的仓库😖。