オープンソース コミュニティでリーダーシップを構築する

オープンソース コミュニティに溶け込むには、時間と労力を要し、また、製品開発への新しいアプローチを施行することが必要となります。従来のプロプライエタリ製品の開発は、機密性と管理の階層を必要としますが、オープンソース開発は、オープンであることが必要であり、意見の一致を重要視します。役職や地位ではなく、コードの貢献こそがオープンソース プロジェクト内での影響力と技術的方向性を決定付けるのです。

オープンソース プロジェクトは、独自のルール、慣習、ツール、そしてプロセスを持つ、多様かつ地理的に分散されたコミュニティで開発されます。端的に言うと、各コミュニティには独自の文化がありますし、オープンソースに影響力を発揮するために必要とされる信頼を確立し、協働の仕方を学び、文化を理解するには時間がかかるものです。

本ガイドは、ある組織が関与し、商業的に依存しているオープンソース プロジェクト内で、リーダーシップと影響力を構築するための方法を説明します。本ガイドを通じて、リーダーシップの文化とプロジェクト内での役割、決定がどのように下されるか、組織がリーダーシップを構築できるかを学び、そしてオープンソース コミュニティで良いリーダーになるためのヒントを得てください。

内容

  1. オープンソース プロジェクトでリーダーシップを構築する理由
  2. オープンソースのリーダーシップ文化
  3. リーダーになるには
  4. 結論

ガイド一覧 » GitHub上で貢献する »

このガイドの貢献者

Gil Yehuda Oath (Yahoo + AOL) オープンソース担当 シニア ディレクター

Guy Martin Autodesk Open@ADSK ディレクター

セクション 1

オープンソース プロジェクトでリーダーシップを構築する理由

オープンソース文化は、協働的ではありますが、アップストリームの貢献は、オープンソース プロジェクトを進展させる第一歩に過ぎません。そのプロジェクトが、企業・組織の製品にとって必要不可欠な場合、プロジェクトの方向性を主導し、影響を与える上で積極的な役割を担うことも重要です。

オープンソース プロジェクトが、競合他社も巻き込んだ協働活動による価値の創出を繰り返し生み出していることは、まぎれもない事実であり、多くのオープンソース プロジェクトの成果物がデファクトになっていることで証明されています。このようなプロジェクトにおける方向性に関して発言権がないということが、競争上の優位性を失うことにつながることは明白です。これこそ、オープンソース プロジェクトでのリーダーシップを構築、維持することが、企業の戦略と目標のカギとなる理由です。ただし、この実現は、机をドンと叩いて主張したり、金銭的な影響力を振り回したりすれば成し得るほど簡単なことではありません。

セクション 2

オープンソースのリーダーシップ文化

企業がオープンソース コミュニティにおけるリーダーシップの仕組みについて考える時、会社内のリーダーシップと同じように働くと考えると思いますが、そうではありません。

「企業はしばしば『そうは言っても、私たちは大きな影響力を持つ企業です。強く要望を伝えれば、コミュニティに私たちの希望に添ってもらうことができるのでは？』と考えますが、コミュニティ活動を行っていくと程なく、その戦略が有効でないことに気付きます。リーダーシップを獲得する唯一の方法は、努力してコミュニティ内での役割を得ることであり、それを実現する唯一の方法は、信頼を獲得し、貢献することだと理解し始めます」

Guy Martin — Open@ADSK ディレクター

企業・組織がオープンソースでのリーダーシップ獲得を目指すべき理由
1. 企業・組織の製品がオープンソース ソフトウェアと技術（そして、それを開発するコミュニティ）に依存しているため
2. リーダシップは企業・組織にイノベーションへの近道を示し、付加価値の実現手段に焦点を当てられるようになるため
3. オープンソースがソフトウェアのエコシステムを規定しているため（別の言い方をすると『Open Source is Eating the Software World (ソフトウェアの世界をオープンソースが侵食しているため)』）
4. ソフトウェアこそが新しい差別化要因であり、（ハードウェアと比較して）これからの中心的価値があるところであるため。ソフトウェアはすべての産業を再定義しつつある

企業 VS オープンソース リーダーシップ

オープンソース プロジェクトでリーダーシップを獲得することが、商業世界における企業自身の成功に欠かせないものである中で、全く違った新しいアプローチを製品開発に取り入れることは、しばしば直感に反するものであり、始めは落ち着かないかもしれません。

従来のプロプライエタリな開発は機密性と管理階層を必要とします。これと比較すると、オープンソース開発では、役職や地位は意味を持たず、オープン性とコンセンサスが重要視されます。

コードの貢献こそが、オープンソース プロジェクト内での影響力と技術的方向性を決めるものです。つまり、コードでの貢献は、ごまかしが効きません。コードは、本質的でかつ本当の意味で、プロジェクトを何らかの方法で真に進展させるものでなければなりません。

初めは、アップストリームに貢献し協働することが、自社の資産を持ち出しているように感じられるかもしれません。しかし、その感情は、オープンソースの現実に基づくものというより、一般的な考え方、行動を大きく変化させるときの不安感から来る痛みによるものであり、イノベーションを起こすためには特に必要となるものです。

オープンソース リーダーシップの考え方には、以下の項目に関して考えることが含まれます。

プロプライエタリからオープンソースの考え方・文化への移行を成功させるには、時間と努力、それを実行することのメリットについて定期的に再検討することを必要とします。Samsung Electronics社のR&D担当バイスプレジデント兼オープンソース グループ長であるIbrahim Haddad氏は、この理解を進み易くするため、以下のチャートを作成しました。

共同開発に適応する必要性

文化プロセスツール人事
開発モデル貢献ITインフラチームの形成
コラボレーションガバナンス開発ツール組織的
透明性承認知識の共有雇用習慣
実力主義運用モデルコードの再利用指標
コンプライアンス

協働的なオープンソース開発は、新しいスキルの獲得と自社の持つ既存の文化、プロセス、ツールに融合させることを必要とします。

この取り組みから、どのようなメリットが期待できるでしょうか？

  • グローバルな開発コミュニティと開発コストを共有すること
  • 研究開発のコストを削減すること
  • さらなる差別化に焦点を当てることでイノベーションを促進すること
  • 製品開発を加速すること

ガバナンスの概要

オープンソース コミュニティにおけるガバナンス ガイドラインは、項目が少ないことがほとんどではあるものの、厳格に執行されています。行動規範またはコミュニティ ガイドラインは、そのコミュニティ固有のものですが、一般的に許容でき期待される行動と許容できない行動を取り扱う手順、そしてその他のインシデントの取り扱いについて言及しています。ガバナンス ポリシーは、オープンソース プロジェクトのポリシー、構造とロードマップの管理に関する詳細を規定します。メンテナンス ポリシーは、通常、ソフトウェア更新など、その他のプロジェクトに関する決定について規定します。

しかし、プロジェクトやコミュニティ レベルのガバナンスは、ガバナンス ポリシーや問題の全体を表すものではありません。また、オープンソース ソフトウェアが商業的な利益のため、またはその他の組織により使用する、貢献する、再配布または製造される場合にも、そのようなガバナンスが存在します。つまり、オープンソース ガバナンスは必然的に、より広範なITガバナンスの取り組みの一部であると言えます。

企業は、オープンソースの消費方法にまつわる複数のプロセス、コミュニティにおけるアップストリームの貢献をするための方法に一貫性がないこと、オープンソース プロジェクトが社内で作成される際の違いなど、企業が同じような種々の問題を経験する傾向にあります。上記のような問題に対しては、標準的なガバナンス対策を構築すれば、混乱を和らげることができます。

「私たちはアップストリームの貢献について、単一のプロセスを目指していました。エンジニアの一人として、私はそれを効率化したいと望んでいました。私は5行のバグ修正のための500ページのドキュメントを含む10週間のプロセスを望んでいなかったので、ワークフローを合理化し、技術者が合理的な時間内にそれを達成できるようにしました。そして、社内にあるコードからオープンソース プロジェクトを作成するために同様の取り組みを行いました。」

Guy Martin — Open@ADSK ディレクター

それぞれの企業が、実際の取り組みに最も合うよう、自社のオープンソースに対するガバナンス ポリシーとプロセスの具体的な内容を検討することが最善です。これは、実際にコミュニティ レベルでガバナンスが最も効果的に発揮される方法とよく似ています。ただし、企業・組織内でのすべてのオープンソース活動で、同一のプロセスを繰り返すことができるわけではないことに注意してください。

一貫性のあるガバナンス計画は、オープンソースのライセンスとセキュリティの問題だけでなく、大きなバージョン間の歪曲も防ぎます。「オープンソースの消費についての一貫性のあるガバナンスモデルは、コンプライアンスの保証に役立ち、私たちが何かを出荷する際には、正しいライセンスへのコンプライアンスが実践されていると確信することができます。」

![](https://www.linuxfoundation.jp/wp-content/uploads/2018/12/sixkeyelements.png =350x350)

文化の概要

組織の社内文化をオープンソースの考え方に変えることが急務ですが、それは、社外にあるオープンソース コミュニティを見失うことなく、またそこから切り離さずに達成する必要があります。

「オープンソース プロジェクト上での影響力を得るためには、あなたがよく知らない人、さまざまな企業で働く人、別の目的を持った人々の集団に対して、自分の意見に賛成してもらわなくてはなりません」

Gil Yehuda — Oath社（Yahoo+AOL）オープンソース担当シニア ディレクター

それは、口で言うほど簡単なことではありません。争いや反対がよく発生しますが、それらの解決策として、コミュニティのコンセンサスに依存する多数の選択肢の中から1つを選ぶことが解になります。

Yahuda氏はこう解説しています。 「オープンソース コミュニティには、さまざまな企業に勤める人が集っており、多くの領域では共通の目的や成果を持っていますが、一部の領域では、それぞれの主張や相反する目的を持っているかもしれません」

たとえば、何か作業をするために必要な新しい機能を望む開発者がいますが、安定性を求め新しい機能を望んでいない別のグループもいます。

「新機能が安定性や拡張性を悪化させるかもしれません。それについて紛争が起きるか、少なくとも緊張が生じるでしょう」とYehuda氏は述べています。

1人の人が決断する責任を持っている訳ではないので、プロジェクトがいずれか1つの方向に前進するよう問題を解決することは容易ではないものの、その代わり、コミュニティとして決定することになります。

「コミュニティが、あなたが望ましいと思う解決策に到達する助けになることの1つとして、プロジェクト内でのあなたの影響力を大きくすることがあります。あなたにリーダーシップがあり、コミュニティで信頼を集めるメンバーとしてコミュニティの関心を引き付けることができれば、彼らは短期的には小規模であれ彼らにとってマイナスの影響を及ぼす決定であっても、あなたに賛成してくれるでしょう。」

Gil Yehuda — Oath社（Yahoo+AOL）オープンソース担当シニア ディレクター

そのリーダーシップを構築し維持することは、個別の開発者の目標であると同時に会社のミッションでもあります。

Oathのアプローチは、所属する開発者達が潜在的に争いに発展しそうな状況に直面した場合に、会社の支援を求めるよう指示することでした。

「私達は、相談を活発に行い、状況とそれに対する最善のアプローチについて社内での話し合いを持ち、開発者がお互いにコミュニティでの議論の状況と解決策を共有するようにしています」とYahuda氏は述べています。

また、リーダーシップは、企業ではなく個人に依存するということを理解することが重要です。 よって、個々の開発者が自分の雇用主からの援助と支援を受けているにもかかわらず、雇用主はその開発者が離職を選択した場合、影響力を失うリスクがあるのです。

「企業・組織の製品にとって、とても重要なオープンソース プロジェクトがあり、企業・組織からアップストリームの貢献をしている人物が1人しかいない場合、企業・組織は、単一障害点を抱えていると同じ状況にあります。後継者の育成計画を設定し、常時2人以上の人員を関わらせる必要があります」

Guy Martin — Open@ADSK ディレクター

これは、企業・組織から複数の人員がアップストリームの貢献をしていく、ということを意味します。このようなアイデアに対するよくある反応として、他の企業も恩恵を受けるオープンソース プロジェクトに自社の多くの人的資源が拘束される、というリスクがあります。しかし、それらの人員の時間をうまく調整すれば、そのようなことはありません。

「3～4名の他の開発者とアップストリームへの貢献をするために使われる開発者の負担が共有されているため、1人当たりの時間が減ります。このことは、エンジニアリング管理に取ってより好ましい状態だと言えます」とMartin氏は述べています。

仕事の負荷のバランスを取ることで、主要な役割を担う開発者が退社して会社が影響力を失うリスクも減らすことができます。コミュニティ内でのリーダーシップ構築に積極的に参加しようとする開発者自身にとっても、結果的に自分のキャリアと収益力を高められるため、これは魅力的なプランです。このプランでは、より多くの開発者が先導的な役割を得ます。

さらに、企業はオープンソース文化に移行し、イノベーションと成功の速度を向上させ、オープンソース コミュニティとのつながりをさらに深めてリーダーシップを構築することにより開発者にとっての魅力が増すため、インナーソーシングを通じて、社内でオープンソースの実践と理念を取り入れることができます。

インナーソーシング

インナーソーシングは、オープンソースの共同開発で使用されている理念・実践と同じものを社内の全社横断的プロジェクトで採用することを指す用語です。

推奨される12のベストプラクティス

1. 試験方法を改善、自動化し、開発プロセスのなくてはならない部分とする5. 「早く、何度もリリースする」哲学を取り入れる（より短期間で、頻度の高いリリース）9. 文書化の実践を改善し、品質保証の追加の方策として使用する
2. ピア レビューを実行し、実践を自動化するためのツールを実装する6. コードの再利用ができる、拡張可能でモジュール式のアーキテクチャを構築するために時間と労力を投資する10. プロジェクトに参加していない人々でもコードをコミットできるようにする
3. 組織の全員がソースコードにアクセスできるようにする7. 継続的な統合アプローチを採用する11. 意思決定プロセスの透明性を促進する（信頼を確立する）
4. 協働サポートが組み込まれた開発ツールを採用する8. 流動的でオープンなコミュニケーションを奨励し、実践する12. 貢献度合いにより個人に力を与える（実力主義）

まとめると、リーダーシップを構築・維持する、という目標を掲げている場合、文化はたくさんの意味合いと多くのレベルで必要不可欠なものであり、故に重要プロジェクトではコントロール対策も欠かせません。

すべてにおいて、1%ルールに留意することを忘れないでください。「90%は流れに身を任せ受け身で参加します。これがユーザーコミュニティです。9%は積極的に参加してバグを報告し、公に質問に対して回答します。私達は、この9%の人々を『貢献者』と呼びます。残りの1%は、プロジェクトを指揮またはコントロールする手助けをする人で、『メンテナー』或いは『リーダー』です」とIntel社/YoctoプロジェクトのJeff Osier-Mixon氏は述べています。

それぞれのプロジェクトはユニークなものなので、プロジェクトごとに適応させましょう。

共同プロジェクトにおけるリーダーシップの役割

共同プロジェクトにおけるリーダーシップの役割は、企業での役割や構造に類似しているように見えますが、特定のコミュニティガイドラインとガバナンスポリシーによって、全てのプロジェクトが異なっており、構造化され、管理されています。役割の定義方法やプロジェクトの構造、管理方法については、マニュアルを読んだり、リアルタイムチャット、プライベートチャットのためにIRC(Internet Relay Chat)に参加したり、メーリングリストを購読するなど、してください。どのように役割が定義され、プロジェクトがどのように構造化され、管理されるかについてのガイダンスを提供します。

また、リーダーシップの役割の一般的な種類は、以下のような内容です。

技術的リーダーシップ

ガバナンスでのリーダーシップ

運用上のリーダーシップ

リーダーシップの役割マトリクス

これらの役割は、歴史的な従来型の管理階層と同等の役割と似通ってはいますが、同じではありません。古いクローズド モデルの価値、プロセスと理念を新しいオープンソース モデルに単純に置き換えることはできません。多くの点で、2つのモデルは正反対或いは鏡に映ったイメージであると言えます。いずれにせよ、それらはあらゆる重要な点で異なっています。1つを選択するには、もう一方を拒否することになります。

オープンソースにおけるリーダーは、リラックスして透明性の確保に取り組み、プロジェクトを進める前にコンセンサスを得る必要があります。そのプロセスとリーダーシップのスタイルは、従来のビジネス構造に縋りつきたいと望む人々にとっては、神経を逆なでされるようなものです。

この劇的な文化の変化で、しばしば直面される不満に対して、「多くの企業は、抵抗が最小限になる道を選びます。これは素晴らしいことです。これをベースとして社内に展開していくことで、独自のやり方でやれるようになるだろう」

「問題は、長期的に見ると持続性と拡張性がないということです。なぜなら、コミュニティの他の部分から離れれば離れるほど、コミュニティから取り入れたい次の大きなアップグレードが行われたとき、より大きな困難に見舞われるからです」とMartin氏は述べています。

端的に言うと、オープンソースとはコミュニティによる取り組みであり、そのコミュニティから自分の仕事を引き離す行動は、いずれ企業・組織の不利益につながっていくということです。

セクション 3

リーダーになるには

協働的な環境でリーダーになるためには、相当の対人スキルと、あらゆる仕事を自分の地位に相応しくないと言って断らない意欲が必要です。

「それは、何かを実行しなくてはならないことに気付くことと同じくらい簡単なことです。バグを記録し、質問に答え、展示会でブースに立つことを引き受けるようなことです」

Jeff Osier-Mixon — Intel社 オープンソース コミュニティ マネージャー

そして、もちろん、それはオープンソースにおける重要な技術的スキルと、それらを果敢に使いこなす大胆さを必要としますが、これらについてはあなたがそのコミュニティの状況を詳しく調べ、グループのダイナミクスを理解し、自分自身で割に合わない仕事を請け負ってからの話です。

言い換えると、リーダーになることは、グループの尊敬を勝ち取ることから始まります。あなたは、それを要求することはできません。自ら勝ち取らなくてはなりません。

あなたのスキルを証明し、リーダーシップを勝ち取るためにはどこから参入するべきか

プロジェクトは通常、委員会への参加方法、メンテナーのなり方、およびあらゆるレベルでの参加方法を文書化しています。それらの文書を見て、グループに馴染み始めるべき場所を見つけましょう。どこからでも、好きなところから始められますが、ただ列に割り込むことだけは避けましょう。

「影響力を得るためにできることの1つとして、話を聞き、理解し、飛び込む前に状況を真に把握する努力する、ということがあります。そのような習慣を時間とともに身に付けられれば、人々はあなたの貢献を尊重するようになり、あなたはより大きな影響力を手にする、と私は思います」

Gil Yehuda** — Oath社（Yahoo+AOL）オープンソース担当シニア ディレクター

オープンソース カンファレンスも、コミュニティ内の他の開発者、リーダーシップに出会うすばらしい場を提供します。ネットワーキングだけでなく、そのようなイベントで発表することは、オープンソース コミュニティへのあなたの、そして自社の実績と貢献を共有するための注目すべき方法です。

Yehuda氏は、彼の会社であるOathでは、開発者のプレゼンテーション スキルを磨き、特定のプレゼンテーションを磨いてステージ上で成功するように支援している、と発言しています。練習することで完璧にプレゼンテーションできるようになるので、開発者がより多くのプレゼンテーションを行うほど、その能力が向上します。その結果として、オープンソース コミュニティにおいて、顔や名前、仕事が認識されるようになります。

しかしやはり、アップストリームの貢献が、コミュニティにおいてあなたの信任と評判を確立するのに最も効果を発揮します。自分のプロジェクトだけでなく、他の部分にも関心を持ち、バグを見つけたら修正し、コミュニティ全体の役に立つ貢献をしてください。

プロジェクトに参入する VS プロジェクトを作成する

プロジェクトへの参加は、リーダーシップ ポジションへの遠い道のりのように思えるかもしれません。確かに、時間はかかります。 しかし、これにはメリットもあります。コミュニティが既に行っている作業から恩恵を得ることができますし、自分のプロジェクトを開始する費用もかかりません。 リーダーシップを確立するという目的のために自分のプロジェクトを始めることは、あなたに多くをもたらしません。

Martin氏は次のようにコメントしています。「もし、あなた達が砂場にいる唯一の子供のグループだったら、全員が同じ会社に勤めていたら、本当にあなた達はリーダーであると言えますか？それとも、単にそのプロジェクトで働いている関係者なのですか？」

もし、あなたが新たにプロジェクトを始めるのであれば、リーダーシップを確立するという理由以外の理由で実行しましょう。なぜなら、率直に言って、そのプロジェクトに誰も参加しないということがありえるからです。それは、あなたのプロジェクトが非常にすばらしいものではない、既に確立されたプロジェクトと競合する、などの場合が当てはまります。

「プロジェクトを立ち上げるには、多くの労力が必要となります。あなたのコードが別のプロジェクトに貢献し、コードの貢献に基づいてそのプロジェクトであなたがリーダーになれる可能性があるならば、新しいプロジェクトを立ち上げることはやめておきましょう」

Guy Martin — Open@ADSK ディレクター

新しいオープンソース プロジェクトを立ち上げる前に自問すべき質問集

既存のオープンソース プロジェクトの取り組みに参加することはできますか？オープンソース モデルを使ってそのプロジェクトを立ち上げ、維持することができますか？成功の構成要素は何ですか？どのようになったら成功と言えますか？プロジェクトを経済的に支援できますか？社内に幹部の支持者がいますか？そのプロジェクトは（最初から）他社の参加者を集められますか？開発者のコミュニティを形成し、成長させるに十分な外部からの関心がありますか？

技術的貢献

コードの寄付は、オープンソース コミュニティにとって重大な取り組みです。プロジェクトの構築は、まさに共同課題を掲げるということを意味します。多くの手があれば仕事は軽くなり、多くの貢献があればリスクは減少し、品質が高まります。これらが目標です。

鉄則は、あなたの貢献が自分だけに役立つものでなく、他者にとって有用であることを確認することです。ただし、有用性は大きな進展に限定されるものではありません。小さなバグの修正やその他の微調整も評価されるものです。重要なのは、あなたの貢献をその規模に関わらず、誰にでも役立つものにすることです。

Ibrahim Haddad氏も、貢献者が適切なコーディング スタイルに従い、プロジェクトの提案過程の範囲内で働き、文書と説明を提供し、フィードバックを聞いて、辛抱強く承認を待つよう勧めています。

アップストリーム活動のベストプラクティス

所属組織内部で

  • アップストリーム活動は正しい理由のために決定すること
  • アップストリーム活動を念頭にコードを設計、実装すること
  • 簡単な関与でもよいので、自社の開発者をオープンソース プロジェクトに関与させ続けること

プロジェクトに向けて外部へ

  • 自社の貢献が、他者にとって有用であるようにすること
  • 適切なコーディングのスタイルを踏襲すること
  • プロジェクトの提案過程の範囲内で仕事をすること
  • あなたからの貢献について文書と説明を提供すること
  • フィードバックに耳を傾け、それについて対応すること
  • 辛抱強く、承認を得るまでコードを修正すること

人材の採用

オープンソース開発者が不足していることは、周知の事実です。オープンソース プロジェクトの採用が高まるばかりで、鈍化の兆しが見えないことを考えると、しばらくの間はこの状況が変わらない可能性が高いでしょう。これは、スキルのある開発者を見つけるのが困難であることだけでなく、彼らを引き留めることが難しいことも意味します。

2016年のCloud Foundry Reportにおいて、「米国だけで25万のソフトウェア開発者の就職口があり、技術スキルを必要とする空きポストが50万ある」ことが報告されました。さらにアナリストは、埋められない開発者のポスト数が「次の十年間で100万名分に達する」と予測しています。

オープンソース開発者の需要は、それよりも熾烈なものです。

それでも、オープンソース コミュニティで誰が指導者であり、誰かが定期的に参加しているスキルのある貢献者であるかを把握し、彼らを直接採用することができます。或いは、彼らに一緒に働きたいと思う開発者を推薦してもらうこともできます。

「メンテナー、または強力な貢献者を採用しようと計画しているなら、それらの人々の需要が高いこと、世界で最も仕事に柔軟性を持つ人々である、ということを念頭においてください。それは、彼らが会社を渡り歩いても、同じプロジェクトに取り組むことができることを意味します。何か変わることと言えば、彼らの給料の小切手に署名する会社名だけです」とMartin氏は述べています。

オープンソース開発者の採用活動に関するさらなる助言については、このガイド集の『オープンソース デベロッパーの採用』を参照してください。

人材の育成（最善策）

幸運なことに、オープンソースはとても熱心な需要があるため、開発者達は開発に携わる、またはオープンソースでの才能を洗練させる機会を積極的に探しています。Martin氏は、彼がこれまでにインタビューした開発者は全員、彼自身のオープンソース ブランドを構築する上で、会社がどのような支援をしてくれるか、と聞いてきたと言います。開発者がオープンソース コミュニティでリーダーシップを取るような人材に成長することを支援することは、最も活性化させる方法であり、採用価値のある武器となります。

自社のオープンソース活動の認知度を高めることは、結果的に開発者の採用にも役立ちます。一部の会社では、魅力を高めるためにオープンソースに関するトレーニングを提供していたりします。展示会で会社のオープンソース プロジェクトを発表すること、コミュニティでコードに貢献することは、自社の認知度を高める最善の方法です。自社の開発者に、他の開発者とのネットワークを作らせて、入社の勧誘を依頼することも、うまくいくことが多いようです。

開発者を惹きつけるためのもう1つの重要なアプローチ方法は、実習期間を提案することです。開発者は、自分の評判・評価を築くことができる挑戦機会が多くある重要なプロジェクトに携わることを好みます。実習やメンターシップ プログラムの提供は、入社のきっかけとしての魅力を追加し、既に社内にいる人材も活用できる優れた方策です。

何よりもコミュニティの信頼を得ることで、オープンソース開発者、そして信頼できるオープンソース リーダーで働くことによってキャリアを前進させたい開発者にとって、自社の魅力を高めることができます。

「他の人と同様、商業的なモチベーションを持った開発者は、彼らの貢献の質と量を通して、プロジェクトでの影響力を獲得します」- GitHubのオープンソースガイド "Leadership and Governance" 従業員が貢献を開始したら？ (英文) より

戦略的な貢献

戦略的貢献は、リーダーシップを確立する上で重要です。このような貢献は、エコシステムを横断して共有されている大きな問題に対応する、或いはプロジェクトをコミュニティが設定しているゴールラインを超えて進める重要な進展を提供する傾向があります。 ただし、単にコードをリリースしてそれを放置することはできません。文書の提供、エコシステムの拡張、そのコードまたはツールセットをさらに進展させるためにパートナーシップを組むなど、たくさんの仕事があります。活動を続けること、認知度と信頼性を保つことがカギとなります。

技術以外の貢献と支援

技術的、戦略的、その他の貢献以外にも、コミュニティに貢献、支援して、結果的にリーダーシップ構築を推進する方法があります。

それらには、開発者の教育に貢献、支援することと、メンターシップの提供等が含まれます。技術的要素に支援を提供することは、リーダーシップ確立の成功をもたらすもう1つの方法です。

重要なのは、よく観察してコミュニティが技術的貢献以外に何を必要としているかを見極め、そのうちの一部に貢献するため、さらに力を入れることです。

セクション 4

結論

要約すると、良いリーダーになること、影響力を獲得することには、時間と大きな努力を必要とします。

リーダーになるための具体的な方法には、以下が含まれます。