GitLab for Open Source プログラム
GitLab のオープンソースプログラムは、Developer Relations チームの一部です。このプログラムは次の要素で構成されています:
- GitLab for Open Source プログラム: 適格なオープンソースプロジェクトが、GitLab Ultimate の機能と 50,000 コンピュート分を無償で利用できる特典を受けられます。
- コンソーシアムメンバーシップ: 主要なオープンソースイニシアチブにおける GitLab のリーダーシップを拡張し、GitLab のブランドを強化し、エンジニアリング上の整合性を改善します
お問い合わせ方法
- DRI: @ihuerga
- Slack チャンネル:
#developer-relations-programs - Email:
[email protected]
取り組み中の業務
私たちは プログラムサポートリクエスト を、専用の内部プロジェクトと、それぞれの Issue キュー および 追跡ボード で管理しています。
私たちは プログラムの編集業務 を、オープンソースパートナー編集キュー で管理しています。 これらの業務は Developer Relations のチームロードマップの一部としてトラッキングしています。 詳細は Developer Relations Programs オペレーショナルガイドライン を参照してください。
GitLab for Open Source プログラム
オープンソースプロジェクトに当社の最先端の機能を提供することで、GitLab for Open Source プログラムは、誰もが貢献できる世界を作るという GitLab のミッションを支えます。 私たちは GitLab を、オープンソースプロジェクトが成長し繁栄するのに最適な場所にすべく支援します。
GitLab for Open Source プログラムについての質問は [email protected] にお送りください。
FAQ
GitLab for Open Source プログラムの特典は何ですか?
GitLab for Open Source プログラムのメンバーは、GitLab Ultimate サブスクリプション(self-managed または SaaS)を無料で受け取ります。これには プログラム固有のコストファクター で計算された 50,000 コンピュート分が含まれます。 このサブスクリプションには製品サポートは含まれません。
GitLab for Open Source プログラムの対象は誰ですか?
GitLab for Open Source プログラムに採択されるためには、申請者は次の条件を満たす必要があります:
- プロジェクトに OSI 承認済みライセンスを使用していること: 申請するネームスペース内のすべてのプロジェクトが、OSI 承認済みオープンソースライセンスで公開されている必要があります。
- 利益を追求していないこと: 組織は活動を維持するために寄付を受け取ることはできますが、サービスの販売、機能拡張やアドオンの有料化、その他の手段で利益を追求することはできません。
- 公開されていること: 申請者の GitLab.com グループまたは self-managed インスタンスとソースコードの両方が公開されており、一般公開されている必要があります。
注意: GitLab for Open Source プログラムの特典は、ネームスペース単位で適用されます。 プログラムの対象となるためには、申請者のネームスペース内のすべてのプロジェクトに OSI 承認済みオープンソースライセンスが付与されている必要があります。
私たちは適格性基準について次の例外を設けています:
連邦例外ポリシー 残念ながら、米国連邦政府に関連するすべてのオープンソースプロジェクトを受け入れることはできません。 関連するプロジェクトは、Sales 担当者と協力して対象となるかを確認する必要があります。
プライベートプロジェクトの例外
場合によっては、プログラムメンバーが機密データを含むプロジェクトを少数のプライベートプロジェクトとしてホストすることを許可しています。
メンバーは、この例外について議論するために [email protected] にメールを送信してください。
プログラムメンバーは、プログラム要件以外でライセンスを使用するためには GitLab Open Source プログラムチームから書面による許可を得る必要があります。
セキュリティニーズのため、デフォルトでは公開プロジェクト以外に 1 つのプライベートプロジェクトをネームスペースに保持することを許可しています。
戦略的適格性の例外
私たちはプログラム要件に対して戦略的な例外を設ける場合があります。
GitLab Sales チームメンバーがオープンソースプロジェクトに代わってこのリクエストを行う必要があります。
例外をリクエストするには、迂回したい要件と理由を詳述したメールを [email protected] に送信してください。
GitLab for Open Source プログラムの規約は何ですか?
GitLab for Open Source プログラムへの採択時に、すべてのプログラムメンバーは GitLab for Open Source プログラム規約 の対象となります。
GitLab for Open Source プログラムへの申請方法は?
申請者は GitLab Customers Portal のフォームから申請する必要があります。 このページはサインインしているユーザーのみがアクセスできます。各顧客は既存の GitLab アカウントから Customers Portal で自由にサインイン(またはサインアップ)できます。 オープンソースプロジェクトのホスト先(GitLab.com または Self-managed インスタンス)に応じて、フォームは申請者から異なる情報を要求します。 送信およびチェックの通過後、申請者は次のステップに関する手順を含むメールを受け取ります。
GitLab for Open Source プログラムの申請はどう処理されますか?
GitLab for Open Source チームは、Developer Relations Programs 申請ワークフロー に従って申請を処理します。 プログラム固有のワークフローについての詳細は、Open Source プログラムワークフロー ページを参照してください。
GitLab for Open Source プログラムのメンバーはメンバーシップを更新する必要がありますか?
はい。 プログラムメンバーは年に 1 回メンバーシップを更新する必要があります。 更新しない場合、アカウントはダウングレードされます。
GitLab for Open Source プログラムで付与されたサブスクリプションは 自動更新されません。
申請者は、十分な処理時間を確保するため、更新日の少なくとも 1 か月前に更新プロセスを開始することをおすすめします。
GitLab for Open Source プログラムのメンバーシップを更新するには?
GitLab for Open Source プログラムで付与されたサブスクリプションは自動更新されません。 更新をリクエストするには、プログラムメンバーは プログラム申請 を完了する必要があります。 チームはこのフォームを使用して、更新申請を行うエンティティがプログラムの適格性基準を引き続き満たしているかどうかを判断します。 プログラムへの初回申請でも既存メンバーシップの更新でも、申請者は同じフォームを記入します。
サブスクリプションの更新を主張する人は、GitLab Customer Portal でこのオープンソースプロジェクトまたは組織のサブスクリプションを作成した人と同じである必要があります。 別の人が更新を開始したい場合は、既存のオーナーが Customers Portal アカウントのオーナーシップを移譲 する必要があります。 既存のオーナーがオーナーシップを移譲したり更新したりできない場合、プロジェクトは更新を開始する前にサブスクリプションのオーナーを変更するために サポートチケットを開く 必要があります。
申請フォームを記入後、検証された申請者はサブスクリプションのアクティベーション手順を含む検証メールを受け取ります。
GitLab for Open Source プログラムのメンバーはどこでサポートを受けられますか?
GitLab for Open Source プログラムの特典には製品サポートは含まれませんが、プログラムメンバーはさまざまな方法で GitLab のヘルプを受けることができます。一般的に、次のことをおすすめします:
- 即時の対応や機密情報を必要とする質問や問題は、GitLab for Open Source プログラムチーム宛
[email protected]に送信してください。 - 一般的な製品関連の質問への回答は、GitLab Docs を確認してください。
- GitLab フォーラムの GitLab for Open Source カテゴリに質問を投稿するか、コミュニティメンバーや GitLab チームメンバーがレビュー・議論できる Discord で質問してください。
- バグレポートや破壊的な動作は、製品チームがレビューして対応するために Issue として ファイルしてください。
プログラム管理リソース
プログラム申請ページの更新
GitLab for Open Source 申請ページを編集する際は、適切なファイルを data/solution_children/join.yml で見つけてください。
プログラムサポートキューの管理
Developer Relations Programs チーム のメンバーは、GitLab Service Desk を使用してプログラムメンバーのサポートリクエストを管理しています。 これらのリクエストには機密データや個人を識別する情報が含まれることが多いため、プライベートプロジェクト に Issue として記録します。
- 新しいリクエストが届くと、Service Desk は Issue に
OS Program Support::Intakeラベルを付けます。 - 自動の最初の返信が送信され、進め方の手順と一般的なシナリオのセルフサービスリソースが含まれます。
- チケットがチームメンバーによってアクティブにレビューされ修正されているとき、そのチームメンバーは自分自身に割り当て、
OS Program Support::Openラベルを追加する必要があります。 - サポート Issue がプログラムメンバーのレビューおよび/または追加の詳細を待っている場合は、
OS Program Supprt::Pendingラベルを付ける必要があります。 - サポート Issue が解決された場合は、
OS Program Support::Closedラベルを付ける必要があります。
すべてのオープンなプログラムサポート Issue の現在のステータスは プライベートプロジェクトボード で確認できます。
コンソーシアムメンバーシップとスポンサーシップ
GitLab のオープンソースプログラムチームは、選定された業界コンソーシアムにおける GitLab の代表と参加、および選定されたオープンソースコミュニティイベントへの GitLab のスポンサーシップも監督しています。
FAQ
コンソーシアムとは?
「コンソーシアム」とは、何らかの技術的目的を進めるために作られたグループと定義します。 オープンソースソフトウェアの文脈では、典型的なコンソーシアムは Linux Foundation (LF) です。これは Open Source Development Labs と Free Standards Group の合併として 2000 年に設立された非営利組織であり、オープンソースソフトウェアプロジェクトの共同開発を ホストおよび推進 しています。
コンソーシアムマーケティングはなぜ重要ですか?
コンソーシアムは、それぞれのエコシステムにおいて影響力のあるリーダーであり、特定の技術開発に関する世界的な対話に影響を与えるカンファレンスを開催したり、プログラムを支援することがよくあります。 コンソーシアムへの参加は GitLab のブランドを強化し、世界的な取り組みやトレンドに GitLab のエンジニアリング活動を整合させるのに役立ちます。
GitLab はどのようにコンソーシアム活動に参加していますか?
選定されたコンソーシアムメンバーシップは GitLab のオープンソースプログラムの管轄(と予算)の範囲内ですが、Developer Advocacy チーム はコンソーシアムマーケティングに焦点を当て、GitLab の全体的なコミュニティメッセージと技術的視点を最も適切で効果的な業界対話に統合する活動を行っています。
GitLab がコンソーシアムに関与することをおすすめするには?
コンソーシアムメンバーシッププロジェクト で Issue を開くことができます。Issue を開く際は、membership-evaluation テンプレートを使って構造化してください。
オープンソースプログラムチームのメンバーが、次の基準で申請を評価します。
申請をレビューする際、これらの観点を念頭に評価します:
- 認知の機会
- コラボレーションの容易さ
- コントリビューションと採用プール
| 観点 | 私たちが関心を持つこと | 私たちが問う質問 |
|---|---|---|
| 認知の機会 | 組織の規模 マーケティング機会の頻度とインパクト | 組織のウェブサイトを月間で何人の認証済みおよび未認証ユーザーが訪れていますか? 組織のコミュニティに何人が参加していますか? 組織はどのようなマーケティングおよびコミュニケーションチャネル(ソーシャルメディア、ニュースレター、ブログ、イベント)を使用していますか? GitLab はそれらの公式チャネルに登場しますか?私たちの掲載はどれほど目立ちますか? |
| コラボレーションの容易さ | 専任のマーケティングリソース/担当者へのアクセス 標準的なコミュニケーションタイプの実行までの時間 | 組織にマーケティング能力はありますか? 組織のブランドとマーケティング部分はどれくらい成熟していますか? この組織はどれくらい早くリソース(例: 事例研究)を生成できますか? 1 週間? 1 か月? 1 四半期? 関係を担当する人はどれだけ反応的ですか? マーケティングはボランティアによって行われていますか、それとも有給の従業員によって行われていますか? |
| コントリビューションと採用プール | コントリビューター/メンバーベースの規模 全体的なコミュニティ/メンバーの活動 コミュニティコントリビューションの頻度 採用率 | 組織が育もうとしているコミュニティはどれくらい活発ですか? 組織は自分のコミュニティの健全性を把握していますか? コミュニティのタレントプールから採用の機会はありそうですか? コミュニティや財団自体の成長はどの程度ですか? そのソフトウェアエコシステム内に求人機会はありますか(このコミュニティから一般的にコントリビューターを採用している企業はありますか)? 私たちの興味と整合する形で GitLab はどのように貢献できますか? 相互の価値を生み出す形で、GitLab はプロジェクトのロードマップに参加できますか? |
GitLab はどのコンソーシアムに関わっていますか?
私たちは現在、次のコンソーシアムのメンバーです:
- Cloud Native Computing Foundation
- Fintech Open Source Foundation
- InnerSource Commons
- Linux Foundation
- Open Source Security Foundation
- TODO Group
これらのグループでの GitLab の活動の完全な詳細 は、Consortium Memberships プロジェクトで利用できます。
このプロジェクトには機密データや個人を識別する情報が含まれているため、GitLab チームメンバーのみがアクセスできる ことに注意してください。
プログラム管理リソース
取締役会への立候補機会のための選挙
私たちが参加しているコンソーシアムの一部は、メンバーがそれぞれの取締役会に立候補することを許可しています。
GitLab がサポートしているコンソーシアムにより深く関わりたい人は、Consortium Memberships プロジェクト を訪れて Issue を開いてください。
コンソーシアムのポジションへの推薦(または選挙)を求めることを考えている場合は、以下の情報を確認してください。
内部推薦
Developer Relations チームはコンソーシアムの取締役会選挙を綿密に追跡しています。
選挙の機会が生じた場合、チームはそれについて議論するために Consortium Memberships プロジェクト で confidential issue を作成します。
チームは、選出されたポジションで効果的に務められそうな GitLab チームメンバーを決定します。
彼らの考慮事項は、次の基準を優先します:
- 組織の取締役会の一員として影響を与えたいテクノロジーに関する専門知識と経験
- 当選可能性を高めるであろう、現職の取締役会メンバーやメンバー組織との既存の関係
- GitLab での在籍期間と GitLab での役割における年功
チームは、上記の要件を考慮して役割に最適と感じるトップ候補と個別に連絡を取り、その個人に意欲と空き状況を尋ねます。 候補者は、必要な時間投資と、取締役会への出席およびコンソーシアムイベントでの GitLab の代表能力を考慮する必要があります。 候補者が務めることを希望する場合、チームはマーケティング組織のリーダーシップに選定を確認した後、推薦書類の準備と推薦声明の作成を候補者と進めます。 チームは、このプロセスでの参考と支援のために 立候補声明 のリストを管理しています。 候補者が時間やその他の制約のために辞退する場合、チームは上記の基準で優先順位リストの次の人物と連絡を取ります。
キャンペーン
GitLab の候補者が推薦されると、Developer Relations チームはポジションのためのキャンペーンを支援できます。
他の GitLab チームメンバーに選挙を知らせ、キャンペーンを支援するための準備を整えます(例: #whats-happening-at-gitlab Slack チャンネルでキャンペーンを発表する)。
プロモーション ソーシャルメディアチームは選挙通知ニュースをプロモーションすることができます。 彼らに必要なのは、人々を案内する場所だけです。望ましいのは、取締役会を一覧表示する更新されたウェブページか、選挙結果に言及する組織からのソーシャルメディア投稿です。
イベントスポンサーシップ
GitLab の Developer Relations チームは、GitLab がオープンソースコミュニティと関わることができるイベントのスポンサーシップのために、小さな予算を維持しています。 通常、この予算は、GitLab のコーポレートイベントおよびフィールドマーケティングチームがすでにスポンサーやスタッフ提供に同意していない、ローカルおよび地域コミュニティ主導のイベントに割り当てます。 複数のオープンソースプロジェクトおよびコミュニティが参加するイベントのスポンサーを優先します。
オープンソースプログラムチームは、GitLab 上の Developer Relations Programs プロジェクト でイベント参加を追跡しています。
オープンソースイベントのスポンサーシップを提案するには、このプロジェクトで Issue を開き、event Issue テンプレートを使用してリクエストを提出してください。
GitLab と協力するイベント主催者やコンソーシアムリードは、GitLab のプレスキット で GitLab のブランド関連アセット(ロゴファイル、プレスリリースのボイラープレート、商標情報など)を見つけることができます。
成功の測定
私たちのチームは、次の方法で業務の成功を測定しています。
プログラムへの登録
GitLab for Open Source プログラムチームは、全体的なプログラムメンバーシップとメンバーの年次更新率を追跡することで、プログラムの健全性と活力を監視しています。これは次の Tableau ダッシュボードで行います:
ダッシュボードでは、プログラムが現在管理している Number of Licenses、プログラムに関連する Enrolled Institutions の数、Number of Seats を報告しています。
Tableau への SAFE アクセス権を持つ GitLab チームメンバーは、追加の詳細をこれらのレポートで確認できます。
プログラムメンバーの GitLab 利用状況
GitLab for Open Source プログラムは、オープンソースプロジェクトやコミュニティが GitLab のさまざまな機能や機能をどのように使用しているかについての洞察を提供します。 そのため、可能な限りメンバーの全体的な GitLab 利用状況を追跡しています。 これは Salesforce で次のレポートに従って行います:
Salesforce および Gainsight へのアクセス権を持つ GitLab チームメンバーは、追加の詳細をこれらのレポートで確認できます。
サポートチケットの量と対応
GitLab for Open Source プログラムチームは、対応する Service Desk を持つ 専用のプライベート GitLab プロジェクト でプログラムサポートチケットを管理しています。チームはプログラムメンバーに迅速で役立つサービスを提供することに専念しているため、四半期ごとに受信するチケットの量と、それらのチケットへの平均応答時間を測定します。これは次の Tableau ダッシュボードで行います:
Tableau へのアクセス権を持つ GitLab チームメンバーは、追加の詳細をこのレポートで確認できます。
Hacker News へのインパクト
私たちはまた、オープンソースプログラムとパートナーの両方に関連する Hacker News のディスカッションを追跡し(必要に応じて参加)しています。 例:
- 2023-12-08: Arch Linux bugtracker migration to GitLab completed
- 2022-06-14: GitLab Now the Main Development Platform for Wine
- 2020-10-28: Wikimedia is moving to GitLab
- 2020-06-29: The KDE community is moving to GitLab
- 2018-05-31: Gnome has moved to GitLab
- 2019-09-30: KDE is adopting GitLab
- 2017-11-15: Debian and GNOME announce plans to migrate communities to GitLab
- 2017-05-16: A proposal to move Gnome to GitLab
