随着 Eclipse Kepler 的发布近在眼前，Mike Milinkovich 撰写了一篇博客文章，来探寻关于社交编码在Eclipse 中的前景。在该文中，他谈论了Eclipse 项目部署在GitHub 而不是基金会自己的服务器上的可能性，并将 Vert.X 称为引领这一变革的先行者。
在过去几年里，采用 Git 已经从小众行为上升成事实上的标准，现在大部分项目都在使用 Git——这让镜像到其他 Git 托管仓库成为可能，例如镜像到 GitHub 或 Bitbucket。 GitHub 上的 Eclipse 基金会官方页面中已经搭建了许多仓库，而其他 Git 仓库——例如 Google 的 eclipse.googlesource.com——其托管机制已经承载了 Eclipse 数据的副本。
另一个支持这一决定的关键因素在于贡献者许可协议（Contributors License Agreement，CLA）的采用。在Kepler 发布后将强制采用 CLAs 并取代旧的约束条件，从而使 Bug 出现后能够就地指派。
过去 GitHub 曾数次提及强制推行 CLAs 的打算，但目前仍未落实此事。这意味着 GitHub 上的大量项目不具备许可或知识产权清洁度——而这是 Eclipse 的一条关键原则。对 GitHub 上的贡献来说，未来 Git 的钩子（hook）将自动校验贡献，而当前还需要现有项目所有者们检查用户提交的贡献是否具有有效的 CLA。因此，尽管许多项目已经表达了潜在的兴趣，但初期只有少数样板项目（例如 Vert.X）使用 GitHub。Stephen O’Grady 写道，对于“后GitHub”世界中的开源基金会来说，品牌和知识产权的管理是件重要的事情。
至于Eclipse IDE 本身，最近 Eclipse 社区调查的结果显示：受早期性能缺陷的影响，Eclipse 4.2 的用户接受度有所下降。不过，最新的Eclipse 4.2.2 版本中已经改善了性能，而即将发布的Eclipse 4.3（Kepler）将会带来与Eclipse 3.7 Stream 相当的性能。另一个或许有利于Eclipse 4.x 系列用户接受度的因素，是一些关键插件——例如EGit 3.0——已经放弃了Eclipse 3.7，它们将仅支持Eclipse 4.2 或更高版本。这是否解答了每个人关心的问题还有待观察，但Eclipse 4.x 的焦点已经聚焦在“抛光”而不是新特性上。
查看英文原文： Eclipse goes to GitHub
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论