オープンソース・プロジェクトのホスティングとソーシャル・ネットワークを融合する

GitHub や BitBucket などのサイトの世界を理解する

ソーシャル・ネットワークの革命的な影響はソフトウェア開発の世界にも及んでいます。インターネットを介してプロジェクトの共同作業を行うためのサービスが数多く生まれており、オープンソース・ソフトウェアの世界では特にそれが顕著です。分散バージョン管理、日常的なフォーク処理、プル・リクエストといった概念によって、グループ開発の基本プロセスがいくつかの点で変わりつつあります。ソフトウェアの共同作業に最もよく使用されるソーシャル・ネットワークの 1 つは、「ソーシャル・コーディング」を掲げる GitHub です。この記事では GitHub を例に、開発のためのソーシャル・ネットワークについて説明しますが、ここで紹介する原則は BitBucket のような他のサイトにも、さらには皆さんの組織内部のシステムにも応用することができます。

Uche Ogbuji, Partner, Zepheira, LLC

Photo of Uche OgbujiUche Ogbuji は Zephira のパートナーであり、高度な Web カタログやその他のリッチなコンテキスト・データベースの作成を監督しています。彼は長年、XML、セマンティック Web や Web サービス、Akara などのオープンソース・プロジェクトといった高度な Web 技術を初期段階から扱ってきました (Akara は Web データ・アプリケーションのためのオープンソース・プラットフォームです)。彼はナイジェリア生まれのコンピューター・エンジニア兼ライターであり、米国コロラド州ボルダー近郊に住み、そこで働いています。彼についての詳細は彼のブログ、Copia をご覧ください。



2012年 6月 07日

概要

ソフトウェア開発者は最も早くからソーシャル・ネットワークを採用してきました。そのため、開発者、特にオープンソース開発者の間の共同作業という特殊な世界に対応するために、さまざまなネットワークが生まれていることは驚くには当たりません。オープンソースの世界には長年にわたり、さまざまなプロジェクトによく使用されてきたホスティング・サービスがあり、その中で最も有名なものは SourceForge です。長い間、これらのホスティング・サービスは主に「Web 1.0」の原則の上に構築されていました。この原則が少し古くなる一方、他の面で非常に多くの発展があり、Web 上で人々がやり取りする方法に革命が起きました。

ほとんどの場合、オープンソース・プロジェクトのサイトの中心には集中化されたソース・コード管理システム (Source Code Management system: SCM) があり、SCM には CVS (Concurrent Versions System) や、最近では Subversion などがあります。それと同時に、分散 (または非集中) バージョン (またはリビジョン) 管理システム (Distributed Version Control System: DVCS) と呼ばれる新しい種類の SCM が登場してきました。DVCS の中核概念は、集中型の正規ソース・ツリーを持つ代わりに複数の作業コピーで構成されるシステムを持つ、ということです。これはつまり、たとえ開発者同士が折に触れてやり取りするのみであっても、複数の開発者が 1 つのプロジェクトで共同作業を行えるということです。

分散された作業コピーの間でやり取りする、という方式はソーシャル・ネットワークの参加者の間でのやり取りと少し似ています。そのため、DVCS の概念をベースに、コード共有モデルに従い、ソーシャル機能を備えたプロジェクト・ホスティング・サイトが自然に成長してきています。現在最もよく使用される DVCS は Mercurial、Git、Bazaar であり、これらはどれも、それぞれに密接に関連する有名なサービス (それぞれ、BitBucket、GitHub、Launchpad) を持っています 。

この記事では、ソーシャル・ネットワーキング機能と DVCS をベースにしたプロジェクト・ホスティング・サイトについて、GitHub に焦点を当てて説明します。読者の皆さんは、ある程度バージョン管理システムを理解している必要がありますが、必ずしも DVCS を理解している必要はありません。

DVCS を利用した共同作業の基本

共同作業に DVCS を使用する場合、最初のユーザー (ここでは Alice と呼ぶことにします) がコード・リポジトリーを作成し、そのリポジトリーを、例えば最初は同僚の Bob と共有します。Alice は彼女のリポジトリーを同じマシン上で他の人達と共有することも、ストレージ・ディスクを渡して共有することも、ネットワークを介して共有することもできます。Bob はそのリポジトリーに対応する DVCS プログラムを使用して Alice のリポジトリーを複製します。すると、Bob は Alice のコードをベースとする彼自身のリポジトリーを持つことになります。Bob のリポジトリーの内容は、最初は Alice のリポジトリーと同じですが、彼のリポジトリーには独自の ID とライフサイクルがあります。これが DVCS のリポジトリーと集中型のリポジトリーの間の主な違いです。

リポジトリーを複製すると、新しいリポジトリーの ID やライフサイクルは別になるため、実質的にプロジェクトをフォークすることになります。かつては、ソフトウェア・プロジェクトをフォークすることを否定的に捉える傾向がありました。その一因は、フォークの有名な例が、プロジェクトにおける共同作業のソーシャル面での破綻と関係していたからです。長い歴史があって崇拝されているテキスト・エディターであり、プログラマーにとってのユーティリティー・システムでもある Emacs の分裂がその一例です。XEmacs プロジェクトは、それまで Emacs の開発者であった人達が不満を抱いて離脱し、新たに開始したプロジェクトです。DVCS はフォークに付随するソーシャル面を取り払い、フォークを共同作業プロセスの一部を成す汎用プロセスにしています。確かに、Bob と Alice の意見が合わなくなり、それぞれ別々の方法でプロジェクトを進めることにした場合には、ある時点でフォークしてプロジェクトを進める可能性があります。一方で Bob と Alice は共同作業における当然のプロセスとしてフォークを使用する可能性もあります。

変更を通知する

例えば、Bob と Alice はそれぞれが所有するリポジトリーを別々に更新したいと思うかもしれません。Bob はユーザー・インターフェースに取り組み、Alice はプログラムのコア・ロジックに取り組む、といった具合です。ある時点で、彼らは互いの成果物を持ち寄って統合したいと思うかもしれません。彼らはそれぞれのリポジトリーの中に別々のチェンジセットを累積しているはずです。チェンジセットは、ある時点で DVCS を通じて発行された commit コマンドによって登録されたファイル群に対する更新の集合です。

集中型バージョン管理システムの場合、チェンジセットはメイン・リポジトリーに対してコミットされるものであり、インクリメンタルなリビジョン番号で識別されます。最初のコミットは Bob によって行われ、リビジョン番号は 1.1 が付けられ、2 番目のコミットは 1.2 が付けられ・・・のようになります。これは DVCS の場合には意味を成しません。DVCS には中央のリポジトリーがなく、変更の順序をグローバルに管理する手段もないからです。そこで各チェンジセットには、リビジョン番号に代わり、複数のリポジトリーにわたって一意であるように設計されたハッシュが指定されます。図 1 を見てください。この図は、最初に複製が行われた後、Bob と Alice の間で別々にチェンジセットが進行する様子を示しています。星の記号は Bob のリポジトリーと Alice のリポジトリーが同じ状態にある時点 (Bob が Alice のコードを最初にコピーした時点) を示しています。

図 1. DVCS のリポジトリー間での最初のやり取り
この図は DVCS のリポジトリー間での最初のやり取りを示しています

Bob と Alice が互いの作業を統合しようとする場合、彼らはチェンジセットを交換し、彼らの思うとおりに成果物を統合した新しいリポジトリーが実現するまで、すべての競合を解決していきます。このプロセスを開始するためには、Bob が Alice のリポジトリーから変更を「プル」するか、あるいは Alice が Bob のリポジトリーから変更をプルします。この場合、プルの方向は重要ではなく、どちらの方向になるかは純粋に彼らの共同作業の状況によります。Bob と Alice との間のプルの方向が時々、場合によっては気まぐれで逆になることさえあり得ます。

マージのメカニズム

Bob が Alice からプルする場合、DVCS は Alice の各チェンジセットを Bob のローカル・バージョンに順次適用します。あるチェンジセットによって競合が発生することもあり得ます。例えば Bob と Alice がファイルのどこかにある同じ行を偶然に変更した場合、あるいは Alice が彼女のリポジトリーから削除したファイルを Bob が更新したような場合です。競合が発生した場合、DVCS ソフトウェアが自動的にマージの方法を判断できる場合もあれば、マージの結果が適切になるように Bob が調整する必要があるかもしれません。

いったん Bob が Alice からチェンジセットをプルすると、Bob はマージ結果を Alice にプッシュすることができます。DVCS は最後のマージ・ポイントからの Bob のチェンジセットを処理し、これらのチェンジセットに Alice のチェンジセットが含まれており、既に Bob のリポジトリーに適用されていることを認識します。ここでは一意のハッシュが重要であり、ハッシュによってチェンジセットを識別します。Bob から Alice へのマージ結果のプッシュが完了すると、Alice のリポジトリーと Bob のリポジトリーの内容は同じになります。このプル、マージ、プッシュのプロセスを示したものが図 2 です。これらのプロセスによって Bob と Alice の間の共有状態が新しくなることに注意してください。

図 2. DVCS のリポジトリー間でのチェンジセットのマージ
この図は DVCS でのリポジトリー間でのチェンジセットのマージの様子を示しています

このプロセスには多くのバリエーションや微妙な違いがあり、それらの一部は特定の DVCS の実装に固有のものですが、ここでは DVCS を新たに使用する人達が遭遇する最も一般的な問題の 1 つを簡単に取り上げることにします。

例えば上記のプロセスで、Bob が自分のリポジトリーを Alice のリポジトリーにプッシュする前に、彼女の変更をプルするのを忘れたとします。この場合、Bob のリポジトリーは Alice のリポジトリーと最後にマージしたポイントから別のブランチになっているということを、DVCS ソフトウェアは認識します。DVCS の中心原則の 1 つは、チェンジセットはリポジトリーのなかで、ある既知の状態のポイント (コモン・ペアレントと呼ばれます) に対してのみ適用されるということです。Bob のチェンジセットは、Bob が最初に Alice のリポジトリーから複製した時点のコモン・ペアレントに対して存在しているため、DVCS は実質的にそのコモン・ペアレントの状態に戻って、それらのチェンジセットを適用することになるはずです。これにより、コモン・ペアレント以降に変更された Alice のチェンジセットは別のブランチに配置されることになりますが、それは Bob や Alice が望んでいることではありません。通常このような場合、DVCS はプッシュ操作によって「マルチプル・ヘッド」が作成されることに関する警告を発します。Bob はプッシュを破棄した後、Alice からプルすることで Alice のチェンジセットを Bob が所有しているブランチ上でマージすることができます。このプルの結果、コモン・ペアレントからの Bob のチェンジセットと Alice のチェンジセットの両方を含む 1 つのブランチになります。この状態であれば、Bob は「マルチプル・ヘッド」の問題なしで Alice にプッシュすることができます。


DVCS の基本操作のソーシャル面での意味合い

DVCS によるプロセスは非常に柔軟ですが、プロジェクトでは基本的な使い方をベースに、広範な使い方をするワークフローを作成する必要があります。これはさまざまな役割を持った、ますます多くの人々がさまざまなレベルの操作を行う場合はなおさらです。一般的に DVCS では、最初に認識されるリポジトリーは 1 つであるため、いくらか従来の集中リポジトリーと似て見えますが、それは偶然そう見えるにすぎません。フォークは非常に容易で日常的に行われるため、そのプロジェクトに関心を持つ人々の間に多数のリポジトリーが常に分散して存在します。プロジェクトに参加している人達は、規則に従うことによってカオス状態に陥るのを防いでいます。特にオープンソース・プロジェクトの場合には、誰もがメインのリポジトリーを複製 (つまりメインのリポジトリーからプル) することができるため、カオス状態に陥るのを防ぐ必要があります。プロジェクトのリーダーはメインのリポジトリーを特定し、信頼できる共同作業者に対し、変更をプッシュする許可を与えます。

プル・リクエスト

健全なオープンソース・プロジェクトにおいて、すべてのコントリビューターを共同作業者として信頼できるとは限りません。従来のプロジェクト・ホスティング・サイトでは、ほとんどの場合、問題を追跡する人と協調してパッチを追跡する人がいました。誰もがプロジェクトにパッチを提出することができ、提出されたパッチは追跡される一方、中心となる開発者がそのパッチを検証し、場合によってはパッチを提出した人とやり取りして変更を行います。最終的に、そのパッチはプロジェクトのメインのリポジトリーに適用されます。

DVCS の性質から、またチェンジセットが注意深く管理されることから、そうしたプロセスを少し改善できる可能性があります。特に、パッチを提出する従来のシステムでは、そのパッチの元となった変更の詳細な履歴は失われてしまいがちでした。DVCS の場合には、コントリビューターはメインのリポジトリーからプルし、自分の作業リポジトリーで変更を行い、通常どおりコミットし、作成されたチェンジセットを提出してレビューや議論の対象にすることができます。このプロセスはプル・リクエストと呼ばれるようになりました。コントリビューターは実質的に、自分が提案する変更を含む作業リポジトリーをプルするように中心的な開発者に要求します。コントリビューターは変更を改善するための議論を行った後、それらのチェンジセットをメインのリポジトリーにプッシュします。

GitHub などのシステムでのプル・リクエスト機能 (「参考文献」を参照) は、プル・リクエストを開始するためのリポジトリーの指定、提案された変更についての議論、その結果としてのチェンジセットのターゲット・リポジトリーへの適用、というワークフローに対する便利なインターフェースを提供します。

フォロワーと人気

何らかのシステムによって人々が他の人々をフォローすることができ、その結果として人気コンテストを行えるようになっていないと、ソーシャル・ネットワークは完全ではありません。主な DVCS サイトも例外ではありません。皆さんが誰かのプロジェクトに関心を持ち、そのプロジェクト、またはそのプロジェクトの開発者をフォローすることに決めると、その開発者にその事実が通知され、その開発者は皆さんをフォロー返しするかどうかを選択することができます。用語にはバリエーションがあるかもしれません。例えば GitHub では「フォロー」は人に関して使用する言葉であり、プロジェクトに関しては「ウォッチ」を使用しますが、考え方は Twitter や Facebook と同じであり、ソーシャル・ダイナミクスも似ています。例えば、ある開発者の影響力やプロジェクトの健全さをフォロワーの数などから判断することができ、それがソーシャル・ダイナミクスにおいて、DVCS に影響を及ぼす可能性のある役割を担うことができます (さまざまなブランチ間の争いが激しいフォークの中で、どのブランチが「勝つ」かなど)。


まとめ

オープンソース・ソフトウェアは成長を重ね、世界で使われている技術のなかで非常に大きな部分を占めるようになっています。このように成長したのは、すべて大変な作業の賜物ですが、オープンソース・ソフトウェアが持つ魅力や、オープンソース・ソフトウェアが支持されたこともこの成長に寄与しています。

オープンソースに関する共同作業のプロセスを具現化しようとするソーシャル・ネットワークでは、「コードがすべてであり、他はすべて二次的なものである」と言えればよいのですが、悲しいことにソーシャル・ネットワークからソーシャル面をなくすことはできません。ソーシャル・ネットワークに対する関心から GitHub などのサイトに関わる場合、それがユーザーとしての関与なのか、プロジェクトへのコントリビューターとしての関与なのか、あるいは自分が所有するプロジェクトのリーダーとしての関与なのかによらず、そのサイトの基礎にあるさまざまな用途のワークフローを理解することが重要です。しかし同時に、データの交換に付随するソーシャル面での意味合いについても理解することが重要です。

ソーシャル・ネットワーキングには、常識的な助言が当てはまります。つまり面と向かってコミュニケーションする場合と同じようにコミュニケーションを行い、図太い神経を持つことで非生産的な個人間の衝突を受け流し、そして何よりも、フォロワーや、さらにはコントリビューターも引きつけるような最高のコードを作成することです。GitHub などのサイトは、大規模なプロジェクトで本格的に共同作業を行う前に、ゆっくりとしたペースで始められるようになっています。この記事が新世代のプロジェクト・ホスティング・サイトを理解する上で役立つものになることを祈ります。

参考文献

学ぶために

製品や技術を入手するために

  • GitHub はプロジェクトをホストするためのサイトとしてよく使われており、コード・リポジトリーは Git DVCS を使用して管理されています。
  • BitBucket はプロジェクトをホストするためのサイトであり、Mercurial DVCS と密接に関連していますが、Git もサポートしています。
  • IBM ソフトウェアの試用版にアクセスし (ダウンロードまたは DVD で入手することができます)、特に開発者のために用意されたソフトウェアを利用して皆さんの次のオープンソース開発プロジェクトを革新してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source
ArticleID=819328
ArticleTitle=オープンソース・プロジェクトのホスティングとソーシャル・ネットワークを融合する
publish-date=06072012