資金調達のメインテナー
経験に裏打ちされた
HeroDevsでは、非推奨のオープンソースソフトウェアの課題を解決するために、長年にわたってチームを支援してきました。Never-Ending Support (NES) 製品を通じて、私たちは新興企業からフォーチュン100社に至るまで、公式サポートが終了した後もレガシーコードの安全性、安定性、コンプライアンスを維持するために協力してきました。
私たちは、メンテナンスされていないコードベースにパッチを書き、誰も見ていないところで脆弱性を突き止め、急いで書き直すことなく重要なシステムを安全に稼動させてきました。この基金は、そのような活動を基盤としています。そうすることで、メンテナたちは、本当の後ろ盾を得ながら、自分たちのベストを尽くし続けることができるのです。
私たちは、メンテナンスされていないコードベースにパッチを書き、誰も見ていないところで脆弱性を突き止め、急いで書き直すことなく重要なシステムを安全に稼動させてきました。この基金は、そのような活動を基盤としています。そうすることで、メンテナたちは、本当の後ろ盾を得ながら、自分たちのベストを尽くし続けることができるのです。
私たちの基準とコミットメント
私たちのプログラム基準は、オープンソースのベストプラクティスを導き、サポートするために、エコシステムの衛生とセキュリティに焦点を当てています。私たちは、チームがこれらの基準を満たすことを支援するためにチームと提携し、オープンソースコミュニティにおける彼らの影響力をさらに強化し、維持するための資金を提供します。
リリースとバージョン管理
予測可能な、文書化されたバージョン管理（SemVer/PEP 440）を使用し、すべての公式チャンネルを通じて新しいリリースを発表し、CVE関連の修正を明確にマークする。
コミュニケーションと透明性
どのバージョンがサポート対象か、非推奨か、またはサポート終了かを明示し、プロジェクトの規模に見合ったスケジュールで、変更の事前通知を行う。
ドキュメンテーション
非推奨ポリシーを定義し、非推奨バージョンにタグを付け、サポートスケジュールを指定し、いつバージョンが完全に削除されるかを示す。
サポートと非推奨の取り扱い
明確な採用/削除のタイムラインを提供すること、クリティカルな修正をLTSのみにバックポートすること、非推奨を壊さないようにすること、変更ログやランタイムで警告を表面化すること。
プロセスと階層
問題やセキュリティ上の懸念を報告するための明確なプロセスを維持し、サポート階層（Current、LTS、EOL）を定義し、バージョンがEOLに達した場合の移行または代替サポートソリューションを奨励する。
条件別に表示する場合は選択してください：
バージョン・エンド・オブ・ライフ
リリース
- 地域社会には、リリースが発生した時点で通知される。
- すべての公式チャンネル（X/Twitter、GitHub Repo、ウェブサイト・ドキュメントなど）を通じて伝えること。
- 新しいバージョンがリリースされたときに何が起こるかを明確に定義。
- メジャーリリース、マイナーリリース、パッチリリースの影響を定義します。
- 新しいバージョンがリリースされると、コミュニティは以前のリリースの最新のサポート状況を知ることができる。
- CVEに対応したリリースは、以下のように特定される。
- バックポートパッチが既知の脆弱性を緩和しているかどうかをコミュニティに知らせる。
バージョニング
- プロジェクトでは、業界標準のバージョニング（例えば、セマンティックバージョニングやPyPiパッケージの場合はPEP 440）を使用することが推奨されます。
- プロジェクトが現在SemVerに従っていない場合、バージョン管理構造は予測可能で、直感的であり、コミュニティのために文書化されている。
アナウンス・コミュニケーションと明瞭さ
- ドキュメントには、サポート終了バージョンとサポート対象バージョンが明確に記載されている。
- リリース発表
- 多くの小規模プロジェクトは、ほとんど何の前触れもなく新しいメジャーバージョンをリリースし、すぐに旧メジャーのサポートを打ち切る傾向がある。大規模プロジェクトは、新しいリリースラインを事前に予測し、現在以前のリリースラインの長期サポート期間を明示する傾向がある。
- EOLイベントのアナウンスはタイムリーに行われる。
- 考慮すべきベンチマーク時間枠：
- 広く採用されている基礎的なライブラリ/フレームワーク：12～18カ月
- 適度に採用されたプロジェクト（1万人以上のユーザー）：6～12ヶ月
- 小規模またはニッチなプロジェクト3～6ヶ月
- 該当する場合、移行や移行のための時間を確保するため、現在より前のリリースラインにはサポート期間が設けられている。
- 考慮すべきベンチマーク時間枠：
- 終活イベントはプロジェクトの公式チャンネルに投稿される。
移住
ドキュメンテーション
- メンテナが作成した移行ガイドとコミュニティが作成した移行ガイドをユーザーに提供すべきである。
- 移行ガイドはメインサイトで簡単に見つかるはずだ。
機能変更
- 非推奨となった広く使われている機能は、文書化されている。
サポート
- 支援を希望するユーザーのためのサポートオプションは、該当する場合、文書化されている。
- 第三者のサービス提供者は、プロジェクトや財団の指針に反しない方法で言及される。提供者として掲載されるための要件は、プロジェクトにふさわしいものでなければならない。掲載される場合、プロバイダーは、掲載されたサービスの有能なプロバイダーとしての歴史と評判の両方を備えていなければならない。
サポートポリシー
プロセス
- 地域社会が問題を報告するためのプロセスがある。
- 報告された問題に対応するためのプロセスがある。
- セキュリティ違反を報告するためのプロセスがある。
サポート・ティア＆ドキュメンテーション
- バージョン・サポートの階層を定義し、コミュニティにとって明確なものにする。
- 例1：
- 現在完全なセキュリティ脆弱性とバグサポート。
- LTS：セキュリティの脆弱性のみ。
- 人生の終わり：修正なし。
- 例2
- サポート
- 人生の終わり
- 例1：
- どのバージョンがサポートされ、どのバージョンがサポートされていないかは、開発者向けの文書で明確になっている。
- 開発者が使用することを推奨する（サポートされる）バージョンと、プレリリースまたは開発バージョンとして意図されるバージョンとが、期待値として設定される。
サポートへの励まし
- EOLイベントの前に、ユーザーは移行するか、移行が現在不可能な場合はサポートソリューションを確立することが推奨される。
よくある質問
よくあるご質問にお答えします。
もちろん、お探しの答えが見つからない場合は、お気軽にお問い合わせください。
もちろん、お探しの答えが見つからない場合は、お気軽にお問い合わせください。
このプログラムの目的は何ですか？
応募資格は？
応募方法は？
応募するとどうなりますか？
資金調達額はいくらですか？
プログラムには何が必要ですか？助成金を受け取るために必要なことは何ですか？
プログラム修了時にサポートはありますか？
私は自分のプロジェクトの未来に取り組むことに興奮しているが、サポートが終了したバージョンについてはどうなのだろうか？基金はそのために何かしてくれるのでしょうか？