ポッドキャスト: Andres AlmirayがJReleaserであらゆるソフトウェアをあらゆるOSにリリースする方法について語る

トランスクリプト オリムピウ・ポップ：皆さん、こんにちは。私は InfoQ の編集者であるオリムピウ・ポップです。私の目の前には、おそらくオープンソース空間、特に Java エコシステムにおけるベテランの一人がいます。アンドレス・アルミレイさんです。お忙しい中、お時間を割いて話してくださりありがとうございます。もしよろしければ、自己紹介をお願いします。あなたは数々の栄誉を授かっていますが、どれを選ぶべきか迷ってしまいますので、あなたが気に入ったものを選んでください。 アンドレス・アルミレイ：番組にお招きいただきありがとうございます、オリムピウさん。光栄です。先ほど申し上げた通り、私の名前はアンドレス・アルミレイで、Java Champion です。今年でオープンソースへの積極的な貢献を始めてから 20 年になります。非常に素晴らしい旅でした。ご指摘の通り、私は長い間 Java の開発に携わってきました。また、Groovy 言語における仕事でも知られています。過去 20 年間に関与したり取り組んだりしたプロジェクトがいくつかあります。それらはビルドツール、アプリケーションフレームワーク、ビルドツールのプラグインなど多岐にわたります。それぞれには小さな物語があります。オープンソースに取り組むことで、時間や国を超えて多くの人々と出会えたことは本当に素晴らしいことです。あなたのような方々ともお会いできたのはその一例です。 オリンピウ・ポップ：そのエピソードについてですが、少なくとも2つは私が知っています。1 つはサプライチェーンにおけるセキュリティに関連するものでした。これは特に欧州のサイバーレジリエンス法の影響もあって、誰もがより厳格な対応を迫られており、人々は再現可能なビルドに費やした時間について議論しています。エルヴェ・ブーテミー氏は、JReleaser で必要なツールを集めていた際に一緒に過ごした時間をいくつかお話しされていました。より一般的なエピソードはマックス・アンダーソン氏からのもので、彼は JReleaser が Java 界隈における優れた CLI ツールの一つであると指摘し、特にアジェンティック AI や生成されたその他の技術が台頭する現在、Java エコシステム全体で CLI ツールに関する取り組みをさらに強化するための呼びかけを行いました。では、成功のレシピとは何でしょうか？JReleaser を数年間開発してこられたと伺っておりますので。 JReleaser は Java だけでなく、あらゆるエコシステムでソフトウェアをリリースできます [02:53] アンドレス・アルミライ：はい。今年4月10日には、バージョン 1.0.0 のリリースからちょうど4周年を迎えます。 オリンピウ・ポップ：おお、すごいですね。まだそのペースを維持されているのですか？JReleaser のリリースサイクルについては非常に規律正しいと伺っておりますが、現在もそのペースを守っておられるのでしょうか？ Andres Almiray: はい、私たちは2 ヶ月ごとのリリースサイクルを採用しており、これによりユーザーは今後の予定を把握できます。リリースは偶数月の月末に行われます。今日は2 月18日に録音していますので、2 月の末日に次のリリースがあり、その次は4 月の末日までに公開される予定です。また、2.0 のロードマップ策定も目前に迫っており、互換性を破るような主要な変更やいくつかの機能追加を予定しています。間もなくアルファ版の公開を開始するかもしれませんが、バージョン20 までのリリースサイクルは現在のものと異なるものになる可能性があります。1.x バージョン用の現在のリリース体制については、最終的な切り替えが行われるまで維持される見込みです。 Olimpiu Pop: なるほど、2.0 の開発がまだ計画に含まれているとのこと、安心しました。あなたが以前おっしゃっていた特別な内容について伺ってもよろしいでしょうか？公開してよいかどうかは別として、その時点では「J」を削ぎ落とすという話でしたよね。それはもはやJavaエコシステムに限定されないものになるからです。 Andres Almiray: はい。私たちが言及したことのひとつに、ツールのリブランディングの可能性がありました。私はまだ、そのリブランディングを行うべきかどうかを決めかねています。このツールを知り、実際に使用している人々にとっては、もちろん名前を認識しているでしょうし、あらゆるソース言語で使用できることも知っているはずです。すでに人気のある言語向けの例も作成しています。もちろん、Rust、Go、Python、Perl、C++、C#、Ruby など、そして Odin や Nim といった多くの他の言語、あるいは Zig、Swift なども含まれます。これらを必ずしも「奇妙な」と呼ぶ必要はありませんが、リストは際限なく続きます。名前に"J"が含まれているからといって、このツールを Java のみに制限するわけではありません。しかし、Java エコシステムに新しく参入した人々や、このツールの存在を知らない人々がネイティブのリリースツールを探そうとした場合、見つからない可能性があり、「なぜ Java ベースのものを使って Rust プロジェクトをリリースしなければならないのか」と考えるかもしれません。それは理にかなっていませんよね。 私がそれを Rust にしたいのは、それが私のエコシステムの一部分であり、私が知っているツールチェーンの一部だからです。そのため、リブランディングが重要になる場面があります。つまり、ソースのエコシステムにはネイティブではないものの、代替手段が存在することを人々に示すのです。 主要なオペレーティングシステムへのリリース [05:32] オリンピウ・ポップ：それは理にかなっています。この議論の結果、新しいツールができるのか、それとも 2.0 を維持した旧来のツールなのか、楽しみに見ています。しかし、録音ボタンを押す前に話し合った通り、機能面において頭打ちになったとおっしゃっていましたね。つまり、製品が成熟期に入ったことを示唆しています。 アンドレス・アルミライ：確かに、安定したプラトー（横ばい状態）に達したようです。各リリースでまだいくつかの機能が追加されていますが、以前ほど多くはありません。パイプラインにある機能には、2.0 のロードマップで追跡しているような破壊的変更や互換性の喪失を伴うものがあります。もしかすると、2.0 へ移行せざるを得ないほどの決定的な数の機能に到達したのかもしれません。最近、追加の発表を行いました。リリースを投稿する際、メールや Slack チャンネルなど複数の配布チャネル向けの発表を作成できるようになりました。LinkedIn や Reddit での発表も可能にする機能を追加しました。そして、次のリリースでは、Twist という新しい発表チャネルにも対応します。また、複数のデジタル署名アルゴリズムを同時に使用できる機能も追加されました。 過去には、PGP または cosign のどちらか一方しか利用できませんでしたが、現在ではリリースするタイトルやアーティファクトに応じて、両方を利用できるようになりました。さらに、MiniSign という第三の署名方式も追加されています。 このツールの初期リリース段階において、一部の開発者から Windows 署名ツールを使用した署名サポートの要望がありました。Windows 署名ツールは Windows プラットフォーム上でしか動作しないため、当ツールがプラットフォームに依存しないことを目指しています。同様に、OSX での実行に関する類似の要望もありました。 そこで、JSign という別のオープンソース Java プロジェクトがあります。これはあらゆるプラットフォームで実行可能であり、Windows 互換の署名を生成するためのものです。おそらくバージョン 20 のリリースまでにこの機能を追加する予定ですが、4 月のリリースでは、すべてのプラットフォームで任意種類のデジタル署名を提供できる機能を実装できるようになることを期待しています。 Olimpiu Pop: すべての新機能の成功をお祈りします。どれも非常に興味深く、間違いなく役立つでしょう。以前から取り組まれていることのひとつに、異なるプラットフォーム間での配布チャネルの設定があります。ユーザーが頻繁に利用しているいくつかのパターンや、ユーザーの利用状況から得られた教訓についてお聞かせいただけますでしょうか？ Andres Almiray: さて、このようなツールを構築する最初の理由の一つは、誰でも簡単に利用できるように JavaFX アプリケーションをデプロイするためでした。つまり、Homebrew を使用すれば、その Homebrew を通じて JavaFX アプリケーションをインストールできます。しかし、これには私が少し Ruby を学び、このためのマニフェストを作成するための形式を理解する必要があります。また、Windows では Homebrew が機能しない人もいます。そのプラットフォームに必要なパッケージマネージャーが必要です。いくつか選択肢があります。Scoop があり、これは Homebrew と非常に似ています。もちろん、Winget や Chocolatey もあります。そして同じことが起こります。各マニフェストファイルの異なるセクションをどのように記述するかを理解する必要があります。XML、JSON、その他多くの形式があり、これらすべてを追跡する必要のあることがあまりにも多く、手作業でこれらを行うのは非常に複雑になってしまいました。そのため、このツールが生まれることになりました。 そこで、このことから、私たちは、異なるパッケージマネージャーへの公開にこのツールを使用する人々のほとんどが、まず Homebrew を選び、次に Winget を選ぶ傾向があることがわかりました。第三に、Winget ではない場合、Chocolatey または Scoop を使用して Windows ターゲットとする人々もいます。そして、Docker、Podman、あるいは Google の Jib（これもサポートしています）を使用して Docker イメージを作成したいという人々もいます。 オリンピウ・ポップ：ネイティブアプリケーションをまだ使用している人がいるようですが、Docker はすでに多くの人の標準となり、私たちが期待したほどの普及を見せ始めています。しかし、まだ疑問点があります。あなたは製品が成熟していると明確に言及されましたが、アーキテクチャ、特に基盤となるアーキテクチャについてはどうでしょうか？あなたがこれを順調に立ち上げるために多くの関心を払ったことは承知しています。また、私たちの最初の議論の一つでは、あなたが得られた成果に対して非常に満足されている様子でした。しかし、バージョン 2.x を見ると、それは破壊的変更を伴うものです。何かを変更する予定ですか？私はデータエコシステムを別の視点から眺めてみると、必要に応じて追加できるモジュールが多数あると考えています。そのようなパズルのようなアプローチはどのように構築されているのでしょうか？ Andres Almiray: 実は、バージョンを重ねるにつれて、より一般的であることが判明した異なるセットのアウンスア（注：通知機能）やパッカー（注：パッケージ作成ツール）のサポートを追加してきました。例えば、Google Chat や Gitter があり、また Teams も必要に応じて情報を送信するためにターゲットサービスへユーザー REST API をネイティブに送信すると発表しました。しかし、実際にはこれらすべてが単純な Webhook で実装可能であり、私たちは汎用的な Webhook アウンスアを持っています。その結果、内部ではこれらの明示的にカスタム作成されたアウンスアの一部が汎用 Webhook を利用するようになり、明示的な通知機能は非推奨としてマークし、バージョン 2.0 で削除しました。これが私が取り組もうとしていることのひとつです：ツール内でより一般的な機能を特定し、リファクタリングして、明示的な実装を不要にするようにしています。 これらの取り組みは、リリースを公開する際に蓄積された負荷を軽減し、より軽量な仕組みへと進化させるためのものです。これは、特に設計上の課題を解決し、DSL における命名規則など当初の設計選択を見直す必要性が生じているケースに該当します。これにより、DSL に新たな要素を追加していく過程で発見される他のルールにも適合し、より直感的な操作性を実現することを目指しています。 これらの変更点はすべて既に非推奨（デプレケーション）としてマークされています。したがって、ツールを実行する際、インターフェースが grade end であってもコマンドラインツールであっても、DSL の要素を使用するとログに警告が表示されます。これにより、その機能が将来削除されることを事前に知ることができます。警告には、いつ非推奨となったか、どのバージョンで指定されたか、そして最終的にバージョン 2.0 で完全に削除される予定である旨が明記されます。 もしツールを利用する際にこのような特別な警告、すなわち非推奨の警告が表示された場合は、ドキュメントを確認することをお勧めします。そこには、今後 DSL を使用して作業を行うための代替方法や手順が記載されています。 JReleaser の採用を検討する前に知っておくべきこと [12:20] オリンピウ・ポップ：わかりました。要するに、既存のユーザーから得たフィードバックと、これまでに JReleaser の開発を手伝ってくれたあなたや他の開発者からのフィードバックがあり、それらをすべて取り入れて製品をより堅牢で軽量なものにしているわけですね。先ほどおっしゃっていたように、製品の名称変更については、2 つのペルソナ（ユーザー像）を想定されています。1 つは既存のお客様やユーザーであり、もう 1 つはこれから導入を検討する新しい方々です。JReleaser をリリースのために使い始める際に、人々が答えなければならない質問とはどのようなものですか？ アンドレス・アルミライ：それは、その人がリリースを作成する際に何を使っているかによります。最初の質問は、「ツール、アプリケーション、あるいは任意のプロジェクトに取り組んでいるのか？」ということです。必ずしも CLI やデスクトップアプリである必要はありません。タグ付けを行い、リリースノートを作成し、それが起きたときに発表を行うことを望むあらゆる製品で構いません。では、最初の質問は「どのように行っていますか？」です。すでに何らかのレベルの自動化（automation）を済ませていますか？バッチスクリプト（batch scripts）のセットで行っているのか、それとも他のスクリプト言語を使っているのでしょうか？ターゲットは GitHub だけですか？GitHub Actions をご存知ですか、それとも GitLab を好みますか？では、GitLab CI やその仕組みをご存じでしょうか。これらすべてが「待ってください、ちょっと待って、これは情報が多すぎます。ただこれをするために専門家になる必要があったり、こんなに多くのことを学ぶ必要があるなんて知りませんでした」と思わせるようなものだと感じても、ケースによってはそうではありません。 では、JReleaser があなたにとってのツールとなるかもしれません。なぜなら、このツールはこれらのすべてを簡素化するからです。これは「設定より規約」のメカニズムに従っているため、必要な最小限の設定のみを行い、必要に応じてあらゆる動作を適用できます。このツールは特定の道筋を選ぶよう強制するものではなく、その逆です。あなたが何を望んでいるかをツールに正確に伝えるのです。次に、すでに何らかのリリースプロセスとある程度の自動化が存在している場合でも、理由のいかんにかかわらず失敗したり、再現できなかったり、自動化が困難な要素があるかもしれません。そのような状況こそがこのツールの出番であり、あなたはリリースプロセスを支援するために、ツールが提供するどの項目や動作の一部を活用するかを選べばよいのです。 オリンピウ・ポップ：そして私たちはまさに LLM（大規模言語モデル）の時代を生きており、すべてがレビューされる中で、あなたが DSL（ドメイン固有言語）について言及されたことを踏まえると、これらの LLM のいずれかにアクセスして「DSL を使って何かを書いてほしい」と頼むのはどれほど容易でしょうか？それとも、この DSL は内部のものであり、私が間違った質問をしているのでしょうか？ Andres Almiray: 実は DSL は外部にあり、どのように消費したいかによって異なるフォーマットを追加できます。CLI で使用する場合は、最も一般的なフォーマットは YAML ですが、YAML を好まない層もいる一方で特定のフォーマットを好む方もいらっしゃるため、TOML もサポートしています。Maven を使用している場合、Maven XML DSL（ドメイン固有言語）を使用して基盤を設定するためのプラグインがあります。Gradle を使用している場合は Gradle 用の基盤があり、Groovy、Kotlin、あるいは最近話題となっている宣言型の Gradle のいずれを使用するかはご自身の判断にお任せします。つまり、Grails では少なくとも 3 つの選択肢があります。最後に、JSON も用意されていますので、ご希望であればこちらをご利用いただけます。 かつて私は、異なる LLM（大規模言語モデル）が機能を発見し、情報を提供できるようにするために、ツールに明示的なメタデータを追加する必要があるのではないかと考えた時期もありました。 しかし現在では、少なくともクラウドは他の多くのツールと容易に統合できることがわかっており、MCP サーバーを追加したり、動作のために追加のメタデータを提供する必要はありません。クラウドは非常に賢く、CLI で呼び出せるさまざまなコマンドのヘルプメニューから得られる情報を解析し、ユーザーが何ができるかを正確に提案できるだけの能力を持っているようです。 オリンピウ・ポップ：はい、私もそのように観察しています。これらのツールを持つことの利点の一つは、通常文書作成に数週間かかるようなことを試すことができる能力です。例えば、私はもともとフロントエンドが苦手でしたが、今はこうした作業をずっと簡単にできるようになりました。しかし私が気づいたのは、特に JavaScript エコシステムの迅速なペースにおいて、ツールが持っている情報とリリース後にあなたが実際に持っている情報の間にギャップがあるということです。おそらくそのツールはそれらの最新の情報で訓練されていないためです。ただし、ドキュメントへの参照も促すことで大きな助けとなり、これは非常に有用です。 追加の安全性のためのドライランリリースの方法 [17:09] アンドレス・アルミレイ：LLM（大規模言語モデル）を使い始める際、試してみたいと思うでしょうし、コミットして動作するか不安に思うこともあるかもしれません。ツール JReleaser は、ドライバーモードで機能をテストすることを可能にします。つまり、ローカル環境で可能な限り実行できます。ドライブモードで実行する場合、外部から情報を消費することは可能です（ファイルをダウンロードしたりテンプレートを処理する必要がある場合など）、しかしリモートサーバーへプッシュすることはありません。したがって、Git リリースを作成したり、誤ってリモートファイルを変更したりすることはありません。何を試みたかを示しますが、実際には実行しないため、制御はあなたにあります。最近別のモードを追加しましたし、マックスの名前について言及されたのを覚えています。これはマックスが要望した機能で、yolo フラグです。 プロジェクトの要件をすべて設定していない場合でも、確認ファイルが存在する場合に何が起こるでしょうか。例えば、特定のアーティファクトを Maven Central にデプロイしたい一方で、コンテナイメージと Homebrew 用の Ruby formula も公開したいと考えているケースが考えられます。Maven Central へのデプロイに必要なシークレット（機密情報）がない場合、リリースを実行すると情報が不足しているため失敗します。しかし、Yolo フラグを追加すれば、必要なすべての処理を実行できます。何か不足していたり設定が誤っていたりする場合は、該当するセクション全体がスキップされます。ログファイルには「一部の要素が不足しています」という警告が表示されます。もちろん、シークレットの値自体は表示されませんが、「認証情報が不足しているため Maven Central へのデプロイに失敗した」といった内容が通知されます。ただし、処理が停止するのではなく、次のステップへ継続して進みます。 この場合、希望するパッケージマネージャー用のファイルが作成されますが、逆に処理を構成することも可能です。つまり、これらの設定を試行錯誤できるのです。リリースプロセスがどのように動作するかを確認するために、事前にすべての設定を行う必要はありません。 Olimpiu Pop: つまり、これはニーズに合わせて使用できるツールということですね？ Andres Almiray: はい、非常に柔軟性があります。 オープンソースプロジェクトの新たな拠点：Commonhaus 財団 [19:08] Olimpiu Pop: ありがとうございます。また、あなたが関与されている重要なプロジェクトの一つに Commonhaus 財団があります。 Andres Almiray: はい、Commonhaus Foundation は私がとても楽しんで取り組んでいる取り組みです。JReleaser は、Max 氏の JBang とともに創設プロジェクトの一つです。現在、私たちはほぼ 15 のプロジェクトに成長しました。つまり、Quarkus やいくつかのプロジェクトがあり、他の Red Hat プロジェクトには WildFly や Infinispan も含まれています。また、Rust で書かれた既知の最初の Java プロジェクトである SlateDB もあります。当初は、Commonhaus Foundation に所属する人々の多くが Java エコシステム出身なので、「Java プロジェクト向けにこれを機能させる」という考えで設立されました。しかし、異なる言語を使用するプロジェクトも歓迎しており、すべてが Java である必要はありません。SlateDB がその証明となっています。また、この財団は 2 周年を迎えようとしており、4 月 9 日がその日付です。 Olimpiu Pop: あなたはエイプリルフール企画が好きなんですね？ Andres Almiray: はい。確かに、これら 2 つのプロジェクトはエイプリルフールとしてリリースされたわけではありません。ああ、いいタイミングですね。 オリンピウ・ポップ：はい、Quarkus のことは知っていました。Red Hat から IBM への移行（レッドからブルーへ）の際に、Red Hat にいた方々と話すたびに、誰もがこれを強調していたからです。はい。しかし、Quarkus が Commonhaus Foundation の一部となったこと、そして皆がその取り組みを誇りに思っていることを知りました。おめでとうございます。基盤としての今後のアジェンダはどのようなものですか？特に、私たちがヨーロッパに拠点を置く中、マックスさん（JBang の創始者であり、JReleaser の要となる人物）もご存知の通り、Quarkus もまた欧州発です。CommonSource Foundation の視点から、特にサイバーレジリエンス法が施行されつつある現在、オープンソースの未来をどのようにお考えですか？ Andres Almiray: したがって、財団には3 つの基本的な原則があります。これが私たちの出発点です。最初の原則は低ガバナンスモデルです。これは、プロジェクトが参加しても、共通のビルド方法や作業手順が存在しないことを意味します。財団に参加するプロジェクトはすでに確立されており、その周りに良好なコミュニティが存在しています。私たちはこれらのプロジェクトの成長を支援することができます。執行委員会と呼ばれるグループがあり、各メンバープロジェクトから少なくとも2 名の主要貢献者で構成されています。このグループは、特定のプロジェクトに対してビルド方法や作業継続方法を強制することはありません。これが最初の原則である低ガバナンスです。 二つ目の原則は財務透明性です。スポンサーが参加し、財団全体または特定のプロジェクト群のスポンサーシップを決定した場合、資金がどこでどのように使われているかを明確に知ることができます。つまり、財団は資金が突然消え去り、特定のプロジェクトに流れるかどうかさえ不明瞭になるブラックホールにはなりません。 皆が状況の進行を把握できるようになります。3 つ目は継続的な継承であり、これは現在のプロジェクトメンテナーが別のプロジェクトに移ったり、完全に作業を停止したりした場合、プロジェクトは最終的に悪影響を受けることを意味します。そこで私たちが財団で目指しているのは、既存の貢献者やメンテナーが主要なメンテナーセットへと移行し、プロジェクトとの継続的な関わりを保ちながら繁栄できるよう、最小限かつ適切な構造を提供することです。 これらの点を踏まえた上で、財団は引き続きスポンサーを募っており、企業、会社、あるいは個人の方々に、時間、労力、資金を提供してすべてのプロジェクトと財団の成長を支えていただくことを求めています。また、全プロジェクトに影響を与える可能性のある共通事項を特定し、ガイドラインを作成することにも取り組んでいます。セキュリティについてはどうなるのでしょうか？ CDA が報告された場合、どうなるのでしょうか。特定のプロジェクトのメンバーやメンテナーが CVE や同様の問題に対処する方法を知っていることは確かですが、これを完了させるためには、メンバー間および執行委員会との継続的なコミュニケーションが必要です。もしかすると、財団は単なるガイドラインだけでなく、CLI などのツールセットを提示するかもしれません。これは特定のプロジェクトで役立つ可能性があります。そしてここで、他のプロジェクトとの対話を続け、「私たちはこのような取り組みを行っています。プロジェクト X では役立ちました。あなた方も同様のニーズをお持ちですか？」と尋ねることができます。では、話し合いましょう。この特定のツールセットがあなたの考え方に追加できるかどうかを確認しましょう。あるいは、特定のセキュリティ懸念の領域で何が起きているかをご存じない場合は、追加のドキュメントやリンクをお渡しすることはもちろん可能です。ただし、「こうすべきだ」という押し付けではなく、「これは選択肢の一つです」とお伝えします。私たちは他者に対して既に実施した内容を提供し、あなたには自由に選択していただくことができます。あるいは、私たちが持っているものに基づいて、他の代替案も引き続き検討していただくことも可能です。 Commonhaus Foundation からのプロジェクトへのサポートの依頼方法 [24:11] Olimpiu Pop: おっしゃる通り、スポンサーには二つのタイプがあります。時間を提供する方々、関与する方々、そして企業です。オープンソースプロジェクトをお持ちの場合、いつ Commonhaus Foundation にサポートを求めればよいのでしょうか？ Andres Almiray: さて現在、私たちはそれぞれのコミュニティにおいて確立され、よく知られたプロジェクトを探しています。もしあなたのプロジェクトが安定した課題チケットのセットを持っており、コミュニティとの関係も良好であれば、そのプロジェクトは参加する非常に良い候補となるでしょう。もしこれが趣味のプロジェクトであるか、あるいはまだ始めたばかりの場合は、将来の可能性を示すかもしれませんが、現時点では参加するには時期尚早である可能性が高いです。しかし、私たちは開発の異なる段階にあるプロジェクトも考慮する必要があります。したがって、もしあなたがまだ始めたばかりであれば、Common Files Foundation は適さない可能性があります。あなたのプロジェクトがすでに確立され成長しているなら、これが理想的なタイミングとなります。しかし、あなたのプロジェクトがすでに成熟しており、コミュニティが何らかのかたちで関与していても、メンテナーがもうあまり時間を割けない場合です。 プロジェクトがメンテナンスモードに入り、おそらくゾンビモードに近づいている場合、財団はケースバイケースで見直しを行うことになります。これは財団の定義において早期に行われる議論の一つで、すでにサステナンス期に近い特定の段階にあるプロジェクトについてどうなるかという点です。私たちが目指しているのは、動物保護施設のような「アイデアアカウント」の創設です。維持者がプロジェクトを財団に寄付し、スタッフかどうかにかかわらず一定の人々が製品を引き継ぎ、次のプロジェクトを引き受けてくれる維持者を見つけることができるようにします。もしそのような仕組みがなければ、プロジェクトは完全に終了せざるを得ないと宣言することになります。 したがって、私たちはこれを優雅に実現する方法を見つけます。要約すると、製品が非常に新しい場合は、今すぐ参加する時期ではないかもしれませんが、最適なタイミングを見守ることはできます。十代または成熟期に近い段階であれば、それが適切な時期です。そして、晩年期にある場合でも、私たちに来てください。話し合いを行い、何が実現できるかを見ていきましょう。 Olimpiu Pop: 確かに非常に有用ですね。また、その分野に関わる方々についていくつかアイデアがありますので、私から連絡を取ってみます。もしかすると良いマッチングが見つかり、Commonhaus Foundation に Java プロジェクト以外のプロジェクトが新たに加わるかもしれません。さて、貢献したい人たちはどのようにして貢献できるのでしょうか？ Andres Almiray: 私たちが課題管理システム（issue tracker）で行っていることのひとつに、さまざまなラベルを付与することがあります。そこには常に「help-wanted」や「good-first issue」といった小さなラベルが付けられています。これらを確認していただければと思います。おそらく数時間、あるいは数日で取り組めるような内容です。これらの課題は、コードベースの理解を深めたり問題を解決したりする際の入り口として役立ちます。事前に大量の知識を習得する必要はなく、すぐに着手できるものです。もうひとつ、少なくとも私がストリーミングを行っているスイスでは、「HackerGarten」と呼ばれる一連のイベントを推奨しています。これは異なる都市で開催されるもので、オープンソースプロジェクトで楽しく取り組めるものを選び、数時間一緒にハッキングする人々の集まりです。セッションの終了時には、そのプロジェクトへの貢献を提出します。 したがって、初めてのオープンソース貢献を始めたい方にとっては、HackerGarten のようなイベントが理想的です。すでにオープンソースのやり方を知っているが、Journaliser というツールを使っていて始め方がわからないという方には、この特定のイベントが役立つでしょう。なお、HackerGarten のイベントに直接参加できない方のために、スイスとドイツで開催されています。もう一つの選択肢は、常にディスカッションページにご連絡いただくことです。現在は GitHub でホストされており、「この機能はどうでしょうか？」「職場で使っている別のツールがありますが、JReleaser と統合されていません。もしこれができたら素敵ではないですか？」といったご意見があれば、そこで議論を始めることができます。パッチを提供したいか、他の誰かがお手伝いできるか、あるいは他の誰かがパッチを提供できるかなどについて話し合うことができます。 Olimpiu Pop: ここに特別なことは何もありません。貢献を受け入れることは歓迎ですが、まずは新規参加者向けの課題にラベルを付けてください。そうでない場合は議論を開始してください。最終的には人々が貢献する方法を見つけます。 Andres Almiray: 前回行った議論に基づくと、SLSA のサポートを提供する段階まで近づいていると述べたことを思い出します。 Olimpiu Pop: はい。 Andres Almiray: 実はブログ記事は書いていません。正直、あまりいい加減だったのですが、SLSA に対してネイティブビルダーを提供していることを何らかの形で発表する必要がありました。少なくとも SLSA の GIFO 実装についてはそうです。GitHub Public または GitHub Private Enterprise でビルドを実行する際、GitHub の SLSA ジェネレーターを使用できますが、これには GitHub Actions にさらに YAML を追加する必要があります。しかし、JReleaser を使用している場合は、SLSA 用の非常に特定の再利用可能なワークフローと YAML ファイル（あるいは Maven の場合と同じ仕組み）を利用するだけで動作します。つまり、設定すべき項目が減ります。まず証明されるのは、Maven プロジェクトや Gradle プロジェクトでもこれが可能だということで、私たちはクロスプラットフォームコンパイルを提供する言語向けの追加デモも拡張しました。Go、Rust、C++、C、JavaScript、TypeScript です。Deno や Bond を使用するかどうかに関わらず、Ocalm 用のデモもあると思います。 要は、SLSA が必要で関心があるが、どう始めればいいか分からないという場合、このネイティブ SLSA ビルダーをユーザーと共に使用すれば、非常に簡単です。 Olimpiu Pop: 確かにそう聞こえますね。実際には...といった感じでしょう。これらの洞察を共有してくださり、ありがとうございます、Andres。またお時間を割いていただき、ありがとうございました。 Andres Almiray: オリンピウさん、ありがとうございます。オープンソースに興味を持たれた方は、始めるのはとても簡単です。現在取り組んでいるオープンソースプロジェクトでチケットを起票してください。世界中の他のメンバーに、あなたがその課題に取り組んでいることを知らせてください。うまく動作していない部分や予期せぬ問題が見つかるかもしれませんし、機能不足があるかもしれません。とにかくチケットを起票すれば大丈夫です。パッチを送る必要はありませんし、最初からコードやテストケースを送る必要もありません。いきなり何かをするプレッシャーを感じる必要はありません。まずは会話を始めて、その先どうなるか見てみましょう。 Olimpiu Pop: 分かりました。皆さん、ぜひ実行してください。 Andres Almiray: はい。 Mentioned: Commonhaus Foundation JReleaser About the Author アンドレス・アルミライ アンドレスは Java/Groovy の開発者であり、Java チャンピオンです。ソフトウェアの設計と開発において 20 年以上の経験を持ち、Java の黎明期から Web アプリケーションやデスクトップアプリケーションの開発に携わってきました。オープンソースを真に信じており、Groovy、Griffon、DbUnit といった人気プロジェクトへの参加や、自身のプロジェクト立ち上げにも関わっています。Griffon フレームワークおよび Hackergarten コミュニティイベントの創設メンバーです。Twitter では @aalmiray で活動しています。ハッキング（開発）をしていないときは、最愛の妻イクシェルと過ごす時間を大切にしています。 Show moreShow less display:none; Podcast は RSS フィードを通じて最新情報を入手でき、SoundCloud、Apple Podcasts、Spotify、Overcast、YouTube でもご利用いただけます。このページからは録音されたショーノートにもアクセス可能です。これらにはクリック可能なリンクが含まれており、音声の該当部分へ直接移動できます。

ポッドキャスト: Andres AlmirayがJReleaserであらゆるソフトウェアをあらゆるOSにリリースする方法について語る

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト