Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Oracle to Close and Forges

Oracle to Close and Forges

This item in japanese

Oracle has announced that the and 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 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 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, 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 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 and 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