BT

Oracle to Close Java.net and Kenai.com Forges

| by Abraham Marín Pérez Follow 9 Followers on May 11, 2016. Estimated reading time: 3 minutes |

Oracle has announced that the Kenai.com and Java.net forges will be taken down for good in approximately one year; project administrators have been advised to request all their project data, including code, bug tracking information, email history, wiki pages and fora content, so they can continue to operate elsewhere. The move seems to be aligned to other similar decisions in the market, after sites like Codehaus and Google Code also announced previous closures.

The closure of Kenai shouldn't come as a surprise on itself, for it was already announced in September 2015. However, the announcement at the time indicated that projects would be migrated to the Java.net forge, effectively simply merging both platforms. This means that recent decision has further reaching consequences, for a number of projects may become unavailable if project administrators don't act on time.

The fact that this isn't an isolated case begs the question of why GitHub is so popular compared to the offers. Both Project Kenai and GitHub started operations in 2008 and, although GitHub started a few months earlier, that difference is not enough to justify first mover's advantage. On the other hand, the breadth of functionalities offered by Kenai is larger than that of any other platform's, which means that there must be other factors into play.

The most obvious difference between GitHub and other platforms like Project Kenai or Java.net is the main drive behind them: while the latter are projects to support the open source community, the former is a fully set out commercial initiative. Since its inception, GitHub has raised $350 million to support their growth ($100 million from Andreessen Horowitz and $250 million through Sequoia Capital); Project Kenai, in contrast, is still labelled as Beta eight years after it was launched.

The most important differentiating factor, however, might be a subtler one. Being developed by Sun and tightly integrated with NetBeans, Project Kenai was a platform mostly aimed at Java developers; on the other hand, GitHub, developed in Ruby and Erlang, initially appealed mostly at Ruby developers. The author of this article could not obtain any official data regarding the use of languages across time for projects hosted in Kenai.com, although it is to be expected that the most popular language was Java. In contrast, Ruby was the most popular language in GitHub for its first five years of operation. The technical differences between Java and Ruby may have played part in the difference of popularity.

For every open source project, there are two types of users: those who want to read it or modify it, and therefore require access to the source code, and those who simply want to consume it, and therefore require access to a distributable form. In Java, the standard way to consume libraries is through package managers like Maven or Gradle, which will download pre-compiled jar files from an artefact repository like Maven Central. This means that having access to the source code is not enough to easily consume an open source project written in Java, which further implies that Kenai.com on itself is not enough to make open source projects fully available to the public.

Ruby, on the other hand, has in Bundler its de facto standard package manager. Although it can be compiled to a number of target architectures, including the JVM, Ruby is mostly used as an interpreted language, which means there is no need to consume pre-compiled objects. This allows Bundler to consume Ruby projects directly from the repository where the source code is stored, which means that GitHub can act as both a source code repository and a distribution mechanism for consumption for the Ruby projects there hosted.

Not needing a second system for consuming open source projects written in Ruby means that these projects can be used much more easily, which may have encouraged more people to share their Ruby projects. This combined effect is likely to be largely responsible for the initial growth in popularity in Ruby; since Ruby was the most popular language in GitHub during the first five years, the popularity of the language probably contributed to the popularity of the platform. This would imply that, for public repositories to succeed as a platform, one needs to look at the whole lifecycle of the code being shared.

Given the availability of alternatives, the closure of the Kenai.com and Java.net forges is not necessarily bad news for the Java community. New projects like Junit 5 are successfully being shared in GitHub, and conversations have started to consider a migration of all existing JSR content to other platforms like GitHub or Bitbucket.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Use of GitHub to consume Ruby code by Kevin Rood

Thank you for your article. Following are some points of clarification on the relationship between Ruby, Bundler and publishing code on GitHub.

It is not typical to add Ruby code to an application directly from GitHub. For many years, even before GitHub was popular, Ruby developers used a standard Ruby library management system called RubyGems to manage dependencies (rubygems.org/pages/about and en.wikipedia.org/wiki/RubyGems). Ruby source code is typically packed into a "gem" and published to RubyGems. Ruby developers then consume gems directly from RubyGems.

Bundler has made using RubyGems easier, and it also makes it easier to add a gem to an application directly from GitHub, but again, this is atypical of how Bundler is generally used.

Re: Use of GitHub to consume Ruby code by Abraham Marin-Perez

Hi Kevin,

Many thanks for your contribution. It is true that consuming Ruby code directly from GitHub is not the main use of Bundler, apologies if I made it sound like that. In this article I decided to focus on this particular capability because of its effect to projects shared through public repositories.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss
BT