はじめに
つい最近まで、ソフトウェア開発環境では、オープン ソースとプロプライエタリの 2 つのまったく異なるモデルが提供されていました。 オープンソース ソフトウェアは、そのトレードマークであるオープン性の恩恵を受けています。誰でもコントリビューションを提供することができ、多くの人がそうしています。 一方、プロプライエタリ ソフトウェアは、その知的財産 (IP) のプライバシーを尊重するクローズド システムによってアクセスが制限されています。
あなたは、自社のプロプライエタリ ソフトウェアに大きな投資を行っている企業のリーダーであるとします。 テクノロジ企業である必要はありません。あらゆる業種や規模の企業が、業界における競争力を高めるために、独自のソフトウェアやその他の IP を構築し、メンテナンスを行っています。 とはいうものの、あなたは、オープンソースで使われるパターン (ソース コードの可視性、プロジェクトのバグの認識、機能要求の透明性など) を高く評価しています。 また、外部のコントリビューションの統合を簡略化する pull request モデルも気に入っています。 あなたはこれらのベネフィットを自身の開発チームにもたらしたいと考えていますが、会社の重要なソフトウェアのソースをオープンにしたくはありません。 必要なのは、両方のアプローチの利点を提供するハイブリッドです。 あなたに必要なのは InnerSource です。
このモジュールでは、効果的な検出可能性、ガイダンス、メンテナンスを通じて、GitHub で成功した InnerSource プログラムを管理する方法について学習します。
学習の目的
このモジュールでは、次の方法を学習します。
- ユーザーと組織が所有するプロジェクトを比較する。
- 必要な GitHub 組織の数に関する推奨を作成する。
- 検出可能なリポジトリを作成する。
- 堅牢なリポジトリ Readme を作成する。
- issue と pull request のテンプレートを使用する。
- リポジトリに透過性を組み込む。
- 組織内の InnerSource の成功を測定する。
- InnerSource ツールキットを配布する。
前提条件
- GitHub アカウント。
- GitHub でファイル内を移動したり編集したりできること。
- pull request に関する知識。
このモジュールを開始する前に、「GitHub の概要」を完了することをお勧めします。