2021 年にオープンソース戦略を改善するための 5 つのステップ

[[385201]]

あなたの組織におけるオープンソースに関する取り組みは、個人またはチームの成果につながっていますか?そうでない場合は、オープンソース戦略の改善を検討してください。

現在、オープンソースに対する組織や個人の間での熱意は非常に高まっています。 GitHubは2020年のOctoverse State Reportで、2020年のオープンソースプロジェクトへの個人開発者の貢献率が2019年と比較して25％増加したと指摘しました。組織の観点から見ると、Red Hatが発表した2020年のEnterprise Open Source State Reportでは、ITリーダーの95％がオープンソースは戦略的に重要であると述べ、75％の組織が企業におけるオープンソースが今後も成長すると予想しています。

これは良いことのように思えますが、オープンソースに関する全体的な取り組みが個人または組織の取り組みの結果につながらなかったらどうなるでしょうか?オープンソース戦略を見直し、改善の機会を探す時期が来ているのかもしれません。

オープンソース戦略を改善する 5 つの方法

クリエイター、プロジェクト コミュニティ、そしてオープンソース テクノロジーを使用し、貢献する組織の増加の観点から、数名のオープンソース エキスパートが 2021 年以降のオープンソース戦略の改善に関するアドバイスを提供します。

（１）目標を設定し、再設定する

他の長期計画と同様に、オープンソース プロジェクトを実装する場合も戦略的な計画が必要です。組織は適切な頻度で毎年これを再調整する必要もあります。これは、持続可能なプロジェクト自体にとってだけでなく、オープンソース技術を使用または貢献する企業にとっても重要です。

「毎年初めに個人や企業の目標を設定するのと同じように、オープンソース コミュニティと組織との関わりの目標を設定することが重要です」と、Red Hat の北米担当チーフ アーキテクト兼ストラテジストである E.G. Nadhan 氏は述べています。 「組織の技術革新チームの延長となることができ、またそうなるべきです。」

Nadhan 氏は、組織がオープンソース戦略を再考するための枠組みとして役立ついくつかの質問を提示しました。

•組織は現在どのようなオープンソース プロジェクトに取り組んでいますか?

•2021 年に取り組むべきプロジェクトは何ですか?

2021 年の関連プロジェクトはどこにありますか? 2年後、彼らはどこにいるでしょうか？

•目標を達成するために何をする必要がありますか?

•組織の成長と導入を推進し、維持するために、組織は誰と提携すべきでしょうか?

（２）変化を無視しない

「積極的な計画の欠如は、オープンソース プロジェクトが直面する最大の潜在的な問題の 1 つにつながります」と、Crunchy Data のプラットフォーム エンジニアリング担当副社長であり、PostgreSQL グローバル開発チームの中核メンバーである Jonathan Katz 氏は述べています。 「組織のオープンソース プロジェクトが苦戦する理由は数多くありますが、主な理由は変化を無視していることです。」

これは時代が変わり、テクノロジーも変化しているからです。たとえば、クラウド コンピューティングとクラウド ネイティブの広範な影響と、それらとオープン ソースとの広範な関係について考えてみましょう。 Red Hat の 2020 年エンタープライズ オープンソース レポートの調査対象となった IT リーダーのうち、83% が、組織でオープンソース プロジェクトを採用することで、最新のクラウド コンピューティング アーキテクチャをより有効に活用できるようになると回答しました。

業界における大きな変化を無視したり、ツールとそのコミュニティを放置したりすると、その価値は失われる可能性があります。

「組織にとって、オープンソース プロジェクトを継続的に維持し、対象とするエコシステムにおける最新のソフトウェア トレンドを把握しておくことが重要です」と Katz 氏は述べています。 「オープンソース プロジェクトが機能的に完全であると考えられていたとしても、テクノロジーの進化に伴い、バグ修正やインターフェースのアップグレードが必要になります。オープンソース プロジェクトを開発しない場合でも、維持し続けるための計画を立てることは、プロジェクトの継続的な発展に役立ちます。」

オープンソース技術を採用する組織も同様の警戒を払う必要があると、レッドハットのチーフアーキテクト、エミリー・ブランド氏は述べた。

「組織は、活発な開発を確実に行うために、使用しているオープンソース コミュニティ (自己サポート型かベンダー サポート型かに関係なく) を定期的に確認する必要があります」と Brand 氏は述べています。 「参加が減少している場合は、コミュニティにエネルギーを注入するか、代替技術と近代化予算を事前に検討し始めてください。」

（３）Readmeファイルの内容を理解する

開発努力やコミュニティ全体の関与が低下していることに気付いた場合は、README を開いて、不明瞭な言葉遣い、古い情報、プロジェクトが全体的に失敗しているという印象など、問題がないか確認してください。ツール自体と同様に、README は一度だけ書くべきではありません。

「第一印象は重要です。そのため、プロジェクトの GitHub リポジトリの README ファイルを確認してください」と、Aqua Security のオープンソース エンジニアリング担当副社長 Liz Rice 氏は述べています。 「これは潜在的なユーザーが最初に目にする文書であることが多いため、プロジェクトの内容と問題解決方法を明確に記載する必要があります。また、ツールのインストール方法と実行方法についても明確な指示を与える必要があります。」

「自分のプロジェクトや知識ベースについて何も知らない人の立場に立って考えてみましょう」と彼はアドバイスします。 「Readme と取扱説明書から基本を理解できますか? 他の人にもっと簡単に説明できますか? そうでない場合は、再起動する時期です。」

（4）フィードバックの募集

エンジニアリングにシームレスに翻訳できる提案はたくさんあるので、フィードバックを得る必要があります。これは、テクノロジーや創造的なアイデアと、そのアイデアの実行の間にギャップが生じることが多いためです。

ライス氏は、これはツール自体だけでなく、組織の Readme ファイルにも当てはまると述べた。組織がプロジェクトまたはその全体的なオープンソース戦略に問題があると感じた場合は、率直な意見を共有してくれる人々からのフィードバックを求める必要があります。

「オープンソース プロジェクトを試用し、フィードバックを得るには、組織外の人材が必要です」とライス氏は語った。 「たとえ 1 人か 2 人からのフィードバックであっても、オープンソース プロジェクトを改善する方法について多くの知識が得られます。」

（５）心理的安全性の文化を確立する

オープンソースは、クラウド コンピューティング、DevOps、その他の現代 IT の柱と多くの共通点を持っています。これは、オープンソースの成功は、特に人材と文化の観点から、同様の基盤に依存しており、開発者はそれらの貢献に対する反応を懸念しているからです。

「高業績チームは、心理的に安全な環境で作業してアイデアや学びを共有する必要があるが、嘲笑や恥ずかしさを恐れずにソースコードを組織全体に公開するなど、実用的な観点からも安全である必要がある」と、レッドハットのカナダ担当チーフテクノロジーストラテジスト兼ソリューションアーキテクチャディレクターのマイケル・カーディ氏は述べた。

この安全文化とそれが育む協力は、育まれなければなりません。プロジェクトまたは組織の文化が否定的であったり、明らかに有害であったりする場合、これはオープンソースの原則と矛盾することになります。

「報酬、インセンティブ、ビジョンを通じて安全な環境を作り出すのは組織のリーダーの責任です」とカーディ氏は指摘した。 「文化は失敗を学習の機会と見なす必要があります。失敗は、教訓が学ばれず、組織の他のメンバーと共有されない場合にのみ悪いものになります。」