これらのステップを参考に、初めてのプロジェクトや次のプロジェクトに向けて、しっかりとした土台を築いてください。
、分散型モデルと開発されたソフトウェアのコミュニティへの貢献を通じて、コミュニティと業界の問題をオープンに解決する、繁栄と利益をもたらすエコシステムです。
このエコシステムが爆発的に拡大するにつれ、多くの開発者が新しいオープンソースプロジェクトに参加し、構築したいと考えています。問題は、どのようにしてこれを成功させることができるかということです。
この記事では、オープンソースプロジェクトのライフサイクルと構造を明らかにします。オープンソースプロジェクトの内部構造の概要を説明し、私の個人的な経験に基づいて、成功し持続可能なプロジェクトを構築する方法を紹介します。
オープンソースの概要
の正式で詳細な定義は、ウィキペディアに要約があります：
オープンソースソフトウェアとは、著作権者が、ソフトウェアとそのソースコードを、誰でも、どのような目的でも、使用、研究、変更、配布する権利をユーザーに許諾するライセンスに基づいてリリースされるコンピュータソフトウェアのことです。
オープンソースソフトウェアは通常、ウェブ上でコードが公開されており、複数の人が共同で、あるいは一人で開発します。そのため、異なる地域、文化、技術的背景を持つ人々と、しばしば遠隔地で共同作業を行うことになります。
オープンソースプロジェクトの構成
人間の身体と同じように、オープンソースプロジェクトは、システム全体を構成する複数の構造から成っています。私は、それらを「人」と「文書」という2つの枝と考えています。
ブランチ 1: 人
通常、オープンソース・プロジェクトには以下のような人々が含まれます：
- 作成者：プロジェクトを作成した人
- メンテナー：プロジェクト全体を積極的に管理する人たち
- 貢献者：プロジェクトに貢献する人々
- ユーザー：開発者や技術者以外の顧客を含む、プロジェクトを利用する人々
- ワーキンググループ：特定のトピック分野を中心としたコレクションに焦点を当てた、ドメイン別のグループへの貢献者のグループ。
- スポンサー：プロジェクトに財政的支援を提供する人
新しいプロジェクトを立ち上げる準備として、上記のリストにある各グループについて検討する必要があります。それぞれのグループに対してどのような計画を立てていますか？
- 擁護者については、擁護者を任命する基準を明らかにしてください。通常、積極的な貢献者が最も適切な管理者です。
- ユーザーや貢献者に対しては、信頼できる文書、ガイド付きのプロセス、プロジェクトを成功させるために必要なものすべてを準備する必要があります。
- ワークグループについては、必要かどうかを判断し、将来的にプロジェクトをどのように論理的に分割するかを決めます。
- 最後に、スポンサーにとって、あなたのプロジェクトに関する十分なデータと情報を提供しなければなりません。
プロジェクトの開始時に、上記の質問すべてに対応する必要はありません。しかし、将来の拡張プロジェクトが確実に定着し、成功するための正しい土台を築くことができるよう、早い段階で考えておくことが賢明です。
ブランチ II: ドキュメンテーション
オープンソースプロジェクトには、通常、プレーンテキストまたはマークダウン形式で、以下のドキュメントが含まれています：
- ライセンス: この法的文書は、プロジェクトがどのように、どの程度まで自由に利用、修正、共有できるかを説明します。OSIが承認したライセンスのリストはOSIのウェブサイトで入手できます。明確なライセンスがなければ、プロジェクトは法的にオープンソースではありません！
- 行動規範: この文書は、何らかの形でプロジェクトに参加することを決定した人の ルール、規範、許容される慣行、責任を概説したものです。オープンソース オープンソースである文書の良い例です。
- Readme: 新しいユーザーにプロジェクトを紹介するファイルです。GitLabやGitHub、Codebergなど多くのGitホスティングサイトでは、リポジトリの初期ファイルリストの下にReadmeファイルが表示されます。通常、このファイルにはドキュメントや必要なドキュメントへのリンクが書かれています。
- 貢献ガイド
Contributing): インストール手順や設定など、プロジェクトへの貢献方法を説明する文書が含まれています。 - セキュリティ
Security): 脆弱性レポートやセキュリティ問題の提出方法を説明した文書が含まれています。
さらに、プロジェクトには通常、問題、サポート、コラボレーションのためのウェブページがあります。
大まかにはこんな感じ：
- バグ報告: ユーザがバグを報告する場所です。このページはまた、開発者が一つまたは複数のバグを修正するタスクを割り当てられる場所でもあります。
- プルリクエストやマージリクエスト: 機能拡張やバグ解決のための提案を提供する場所です。これらのパッチは誰でも作成でき、メンテナによってレビューされた後、プロジェクトのコードにマージされます。
- ディスカッション: メンテナ、貢献者、ユーザーがオープンソースプロジェクトについて議論する場所です。専用のサイトであったり、共同コーディングサイト内のフォーラムであったりします。
また、ほとんどのプロジェクトでは、オンライン・チャットを通じて、コミュニティ・メンバー間の対話と交流のためのコミュニケーション・チャンネルを提供しています。
ライセンス
コントリビューター規約 、オープンソースプロジェクトを作成する前に考慮すべき、おそらく最も単純でありながら最も重要な基準です。ライセンスは、プロジェクトのソースコードやその他のコンポーネントの使用、変更、共有を許可する条件を定義します。
ライセンスには多くの法律用語が含まれており、多くの人は完全に理解しているわけではありません。わたしは choosealicense.comを使っています。これは、あなたがターゲットとするコミュニティや、そのコードを使う人たちからパッチをもらいたいという願望、あるいは他の人たちがそのコードに加えた改良を共有することなくそのコードを使うことを許可しているという事実に基づいてライセンスを選ぶ手助けをしてくれます。
これは、いつMITライセンスやGNU GPLv3ライセンスを使うべきかの指針を提供します。また、コミュニティに貢献する人々は、そのコミュニティが好むライセンスを使うよう提案しています。この表は、利用可能なライセンスがもっとあることにも注意しています。ウェブサイト choosealicense.com 、より詳細な情報にリンクしたテキストベースのバージョンがあります。
オープンソース・プロジェクトの13の段階
オープンソースソフトウェアプロジェクトをどのように始めるか？
私が考えるオープンソースプロジェクトの段階は以下の通りです。
- ブレインストーミングでアイデアを出し、アウトラインを書き、適切に記録します。
- アイデアに基づいて開発を開始します。これは通常、使用する適切なツールや技術スタックを特定し、コードを書き、バージョンを管理し、デバッグし、コーヒーを飲み、StackOverflowをぶらぶらし、他のオープンソースプロジェクトを利用し、眠り、特定された問題を解決するために何かを構築することを含みます！
- プロジェクトをローカルでテストし、必要に応じてユニットテストや統合テストを書き、必要に応じて choosealicense.comセットアップし、ステージングブランチを作成し、プロジェクトをデプロイするために必要なその他の作業を行います。
- 良質で効果的な文書を書きましょう。これには、プロジェクトが何をするのか、なぜ有用なのか、どのように使い始めるのか、どこでサポートを受けられるのか、などが含まれるべきです。
- 使いたいコード規約をすべて文書化しておきましょう。コード整形ツール、Gitフック、コマンドラインツールなどのツールを使って、これらの規約を強制しましょう。
- 適切なライセンスを選択し、Readmeファイルを作成します。
- インターネット上でのプロジェクトの公開
- 更新ログを公開し、記録するプロセスを確立します。
- プロジェクトを世界中に宣伝しましょう！ソーシャルメディアへの投稿、ニュースレターの開始、友人との個人的な共有、製品発表会、ライブストリーミング、その他あなたが知っている伝統的なマーケティング戦略でもかまいません。
- プロジェクトの周りにコミュニティを構築します。
- 必要に応じて、ワーキンググループを導入し、プロジェクト管理を論理的なセグメントに分割することを検討します。
- 新しいアイデアの継続的な実施と、プロジェクトを支えるリソースと人材の維持。
プロジェクトが進むにつれて、プロジェクトのさまざまな部分を評価することが重要になります。そうすることで、評価や将来の開発戦略に利用できるデータを得ることができます。
さあ、プロジェクトを始めましょう！
この記事が、あなたが検討しているプロジェクトを前進させる一助となれば幸いです。
一流のオープンソースソフトウェアプロジェクトを構築する際に、私が見逃したギャップを埋めるためのガイドとしてお使いください。
