コードを出したからといって、差し込み（納品）まで終わりとは限らない🔥😵多くの人が Grant プロジェクトのリポジトリが公開されたのを見て祝って、「できた」と思ってしまいます。
でも私は @Dusk Grants Program の要件を読んでいて、最後の milestone に視線を釘付けにされました。応募者は1年分のメンテナンス計画を書かなければならない。
1年です。「問題があれば issue を出してね」ではなく、白黒はっきり納品リストに記載する“必須”条件。
Dusk には、付随するドキュメントやテスト、再現可能なインストール・実行手順も求められます。翻訳すると、こういうことです：サポートしてくれるチームは確保できたけど、デモの日だけ機能を点ければ終わりじゃダメ。あとから来る人が受け継げて、直せる状態にしないと。
demo は簡単、メンテが高い
応募側にとっては、短期で動く demo を作るのは大して難しくありません。コードを書いて灯せば、デモ日を越えるだけ。
でも本当に高いのは1年後です。依存関係が更新されて、issue が出て、ドキュメントのコマンドが通らなくなる。このとき、そのチームは振り返って対応する気があるのか？ あるなら、誰がやるの？ 予算にその工数は入っているの？
多くのプロジェクトは最初のバージョンを作り終えると、主要メンバーが別の仕事に転んでしまいます。リポジトリは残る。ユーザーは来る。けどインストールできない。聞いても答えてくれる人がいない。コストは消えません。エコシステム内の次の開発者に“付け替え”られるだけ——それがあなたか、私かもしれない。
この要件は、ふるい分けのためのもの
Dusk にこの要件があったとして、すべてのプロジェクトが長期的に活き続けることが保証されるとは思いません。正直なところ、応募書類だけで何かを保証するのは無理です。
ただ、少なくとも1つは正しくやっています。「メンテ」というコストを、前もって応募書類の中に置いたこと。
1年分のメンテナンスを予算に書くチームは、単発の作業を終えるためというより、インフラを納品するつもりに近い。その違いは、応募時には見えません。でも1年後にリポジトリの状況を確認すれば、一目瞭然です。
$DUSK の次に注目すべきは、@Dusk がこれらのプロジェクトのメンテ進捗とリポジトリの状態を公開するかどうか——見えるデータは、どんな約束よりも正直です。#dusk のエコシステムの成長に、根拠を与える。リポジトリを公開してすぐ沈黙するものだらけ、みたいにはならない😖。