Oracle将关闭Java.net和Kenai.com社区

Oracle 宣布在大约一年后关闭 Kenai.com 和 Java.net 社区；他们已经建议项目管理员索取项目数据，包括代码、Bug 跟踪信息、邮件历史、维基页面和论坛内容，以便能够继续在其他地方运作项目。这一举措同市场上的其他类似决定一致，如像 Codehaus 和 Google Code 这样的网站之前就已经宣布关闭。

关闭 Kenai 本身并不让人意外，因为2015 年 9 月 Oracle 就已经宣布。只是那份公告指出，项目将会迁移到 Java.net 社区，实际上只是两个平台的合并。这就是说，最近的决定有严重的后果，如果项目管理员没有及时采取措施，那么许多项目可能会消失。

事实上，不单是这个案例会让人产生疑问，为什么与其他类似社区相比 GitHub 如此受欢迎。Kenai 和 GitHub 项目都是在 2008 年开始运作，虽然 GitHub 早几个月，但那种差别不足以解释先动优势。另一方面，Kenai 提供的功能比其他任何平台提供的功能都广泛，这就是说，肯定有其他因素起了作用。

GitHub 和其他平台（如 Kenai 或 Java.net 项目）最显著的不同是他们背后的主要推动力：后者是为开源社区提供支持的项目，而前者是一个全面的商业计划。自创立以来，GitHub 已经募集了 3.5 亿美元来支持他们的发展（1 亿美元来自 Andreessen Horowitz，2. 5 亿美元来自红杉资本）；相比之下，Kenai 项目在启动 8 年之后仍然处于 Beta 状态。

不过，最重要的区别可能是一个更不明显的因素。Kenai 项目由 Sun 开发，与 NetBeans 紧密集成，主要是一个面向 Java 开发人员的平台；另一方面，GitHub 使用 Ruby 和 Erlang 开发，起初主要是吸引了 Ruby 开发人员。对于托管在 Kenai.com 上的项目，本文作者没有找到任何有关语言使用情况随时间变化的官方数据，不过，Java 是最流行的语言也在意料之中。相比之下，在 GitHub 前 5 年的时间里，Ruby 是最流行的语言。Java 和 Ruby 在技术上的差别可能在流行度差异上发挥了一部分作用。

对于每个开源项目，用户都有两种类型：希望读取或修改它的用户，他们需要访问源代码；只希望使用它的用户，他们需要访问一个可分发的形式。在 Java 中，使用库的标准方式是通过像 Maven 或 Gradle 这样的包管理器，它会从类似 Maven Central 这样的工件库中下载预先编译好的 Jar 文件。就是说，访问源代码不足以让开发人员可以轻松地使用一个用 Java 编写的开源项目，即 Kenai.com 本身无法完全提供一个可供公众使用的开源项目。

另一方面，Ruby 将 Bundler 作为事实上的标准包管理器。虽然可以被编译为多种目标体系结构，包括 JVM，但 Ruby 主要是作为一种解释型语言使用，就是说，不需要使用预先编译好的对象。这让 Bundler 可以直接从存储源代码的库中使用 Ruby 项目，就是说，GitHub 既可以作为源代码库，也可以作为一种分发机制，供开发人员使用托管在那里的 Ruby 项目。

使用 Ruby 编写的开源项目，不需要第二个系统，就是说，这些项目的使用要容易许多，这可能会鼓励更多的人分享他们的 Ruby 项目。这种综合效应可能在很大程度上促成了 Ruby 最初的流行；由于 Ruby 是 GitHub 前 5 年里最流行的语言，所以语言的流行或许也促成了平台的流行。这意味着，作为一个平台，公共版本库要取得成功，就要着眼于其中分享的代码的整个生命周期。

即使还有其他方案，关闭 Kenai.com 和 Java.net 社区对于 Java 社区而言未必是个坏消息。像 Junit 5这样的新项目已经成功在 GitHub 上分享，有关将当前所有的 JSR 内容迁移到其他平台（如 GitHub 或 Bitbucket）的讨论也已经开始。