次週のEclipse Keplerリリースを目前に控えたMike Milinkovich氏が，Eclipseにおけるソーシャルコーディング の今後をテーマとする記事を書いた。その中で氏は，Eclipseプロジェクトのマスタサーバについて，現在の財団独自のものからGitHubに移行する可能性に言及すると同時に，その変更において重要な役目を担うものの筆頭候補として Vert.X の名前を挙げている。
Gitの採用数は，ごくわずかだった数年前からデファクトスタンダードへと飛躍的に増加した。現在ではほとんどのプロジェクトがGitを採用している。その普及に伴ってGitHubやBitbucketなど，他のGitリポジトリのミラーを行うサイトも現れた。すでにGitHubには，Elipcse財団のオフィシャルページのリポジトリが多数ミラーされている。その他，Googleのeclipse.googlesource.comホスティング機構にも，すでにEclipseのデータのコピーが配置されている。
今回の決定を実現するためのキーとなるもうひとつの要素は，CLA(Contributor Licence Agreement)の採用だ。Eclipse CLA ではユーザに対して，Eclipseライセンスの下でのコード公開に電子的手段で合意することを認めていると同時に，以降３年間のコントリビューションについてもカバーする(３年の期間後に再署名することも可能)。もしEclipseのレビューツールとしてGerritを採用しているならば，ライセンスの手続きはさらに簡単になる。Gerritを通じて寄贈された機能コードには，その時点でのCLAを求められるので，コード受け入れの際の障壁を低減することになるからだ。このCLAは Keplerリリース後，自動的に施行される ようになり，発生したバグをありのままの状態で適用するという旧来の要件は置き換わることになる。
過去に何度となく話題に上がっているにも関わらず，現在のGitHubにはCLAを施行する手段が用意されていない。これはつまり，GitHub上の多くのプロジェクトがライセンスや，あるいはEclipseが拠り所とする基本信念である知的財産(IP/Intellectual Property)清廉性を保持していない，ということになる。GitHubコントリビューションをチェックする上で，コミットコードが有効なCLAを所持するユーザのものであることを確認する作業は，既存のプロジェクト所有者に任された形となっている。ただし将来的には，gitフックでコントリビューションを自動的に確認してくれるようになるだろう。結果として，多くのプロジェクトが将来的な関心を表明しているものの， 初期段階からGitHubを使用するのは，ごく少数のデモンストレータによるプロジェクト (Vert.Xのような) に限られている。Stephen O'Grady氏が書いているように，GitHub時代のオープンソース創設者 にとって，ブランドと知的所有権の管理は重要なものなのだ。
Eclipse IDE自体は，先日行われた Eclipse Community Survey の 結果から，Eclipse 4.2の採用が不調であることが見て取れる。これは 初期バージョンのパフォーマンスに関する悪評 に起因するものだ。先日のEclipse 4.2.2でもパフォーマンスは改善されているが，次週リリースされるEclipse 4.3 (Kepler) では，Eclipse 3.7の頃のパフォーマンスを取り戻すように期待されている。Eclipse 4.xシリーズの採用を促進すると思われるもうひとつのポイントが，主要なプラグイン - EGit 3.0など - がすでにEclipse 3.7のサポートを完了していて，今後はEclipse 4.2以降でなければ動作しなくなることだ。これですべてのユーザの懸念を払拭できるかどうかは定かではないが，Eclipse 4.xの主眼点が新機能ではなく，ブラッシュアップにあることは間違いない。