資金調達のメインテナー
経験に裏打ちされた
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ヶ月
- 該当する場合、移行や移行のための時間を確保するため、現在より前のリリースラインにはサポート期間が設けられている。
- 考慮すべきベンチマーク時間枠：
- 終活イベントはプロジェクトの公式チャンネルに投稿される。
非推奨
ドキュメンテーション
- 非推奨の定義がある
- 治療方法
- バグフィックスやパッチを受けた場合
- 脆弱性がこれらのバージョンに与える影響
- タグ付けは、すべての公式文書で、非推奨となったバージョンを表記するために使われている。
- 以前のバージョンのステータスに影響を与えるような新バージョンのリリースがあった場合、どのバージョンが非推奨になるのか、あるいは使用終了になるのかについての文書がある。
- 非推奨バージョンが完全に削除される時期や、サポートが一切されなくなる時期については、具体的に言及されている。
- 該当する場合、プロジェクトはエコシステム固有のツールを活用し、非推奨を報告する。
サポート
- 地域社会が従うべき推奨スケジュールがある：
- 新機能の採用
- 非推奨機能の削除。
- 非推奨の機能をサポートする仕組みがある。例
- マイナーリリースで導入
- 次のメジャーリリースで削除
- クリティカルな脆弱性はLTSでのみバックポートされる。
- 非推奨は壊れないものでなければならない。
警告
- ランタイムの警告は、使用中にログ/コンソールに追加されます。
- 非推奨イベントは変更ログとリリースノートに表示されます。
サポートポリシー
プロセス
- 地域社会が問題を報告するためのプロセスがある。
- 報告された問題に対応するためのプロセスがある。
- セキュリティ違反を報告するためのプロセスがある。
サポート・ティア＆ドキュメンテーション
- バージョン・サポートの階層を定義し、コミュニティにとって明確なものにする。
- 例1：
- 現在完全なセキュリティ脆弱性とバグサポート。
- LTS：セキュリティの脆弱性のみ。
- EOL: 重要な場合、セキュリティの脆弱性。
- 例2
- 最新（または対応）
- 未対応
- 例1：
- どのバージョンがサポートされ、どのバージョンがサポートされていないかは、開発者向けの文書で明確になっている。
- 開発者が使用することを推奨する（サポートされる）バージョンと、プレリリースまたは開発バージョンとして意図されるバージョンとが、期待値として設定される。
サポートへの励まし
- バージョンがEOLになった場合、ユーザーは移行するか、移行が現在不可能なサポートソリューションを確立することが推奨される。
- 注：HeroDevsのサービスを通じて、移行スケジュールを確立したり、古いバージョンでサポートされていることを確認することができます。
よくある質問
よくあるご質問にお答えします。
もちろん、お探しの答えが見つからない場合は、お気軽にお問い合わせください。
もちろん、お探しの答えが見つからない場合は、お気軽にお問い合わせください。
このプログラムの目的は何ですか？
応募資格は？
応募方法は？
応募するとどうなりますか？
資金調達額はいくらですか？
プログラムには何が必要ですか？助成金を受け取るために必要なことは何ですか？
プログラム修了時にサポートはありますか？
私は自分のプロジェクトの未来に取り組むことに興奮しているが、サポートが終了したバージョンについてはどうなのだろうか？基金はそのために何かしてくれるのでしょうか？