Thursday, November 22, 2007

Will Apache Harmony succeed?

There was a survey [1] two and half years ago when Apache Harmony was started, to get people's comments on Apache Harmony's fate. Reading through it, I felt more pessimistic or negative opinions than optimistic or positive ones. Many people believed Harmony was either useless or going to fail, although they had different reasons.

About nine months ago, an article "How To Tell The Open-Source Winners From The Losers" [2] tried to summarize why an open source project could fail. Those are nine points to check:

  1. A thriving community: A handful of lead developers, a large body of contributors, and a substantial--or at least motivated--user group offering ideas.
  2. Disruptive goals: Does something notably better than commercial code. Free isn't enough.
  3. A benevolent dictator: Leader who can inspire and guide developers, asking the right questions and letting only the right code in.
  4. Transparency: Decisions are made openly, with threads of discussion, active mailing list, and negative and positive comments aired.
  5. Civility: Strong forums police against personal attacks or niggling issues, focus on big goals.
  6. Documentation: What good's a project that can't be implemented by those outside its development?
  7. Employed developers: The key developers need to work on it full time.
  8. A clear license: Some are very business friendly, others clear as mud.
  9. Commercial support: Companies need more than e-mail support from volunteers. Is there a solid company employing people you can call?

Using this checklist to measure Harmony, though Harmony has good scores for most of the points, Charles doubted "what passionate user community will form around Harmony when open Java is available on the Net?"

I have to say Charles has made very valid points largely for open source projects, but I can't agree that Harmony is losing developers due to OpenJDK. I won't elaborate my arguments, just one point here: Harmony is not necessarily existing only as an alternative Java implementation. So Harmony is not necessarily losing its developers, because they are not just looking for an alternative Java implementation. For this specific point, I have a couple of examples:

  • Google Android uses Apache Harmony for its class libraries;
  • People are porting Harmony GC(s) to other runtime systems;
  • Some Java applications do not care if Harmony is Java certified, using Harmony as default runtime environment.

Let's see how Apache Harmony is going to evolve. It's still too young (less than three years old). Stay tuned.


Monday, November 19, 2007

Google Android, Apache Harmony and Java Packaging

Last week Google released SDK for Android, an open and free mobile platform to write most of the code in Java. However, you do not call it Java, which makes you free from licensing. Stefano Mazzocchi shows how this move by Google is really elegant. He uncovers tricky details about likely strategies of both companies. Stefano's thoughts are really impressing and made me shout "Aha! Now I see who is who!".

Same time, folks working on the Apache Harmony are really impressed to see what is behind the release. Especially we are glad to meet Android as a big "customer" that uses a significant part of the Apache Harmony class library (detected by Geir Magnusson, the original chair of the project). Still, I believe, there were people who used Harmony class library for their proprietary app development based on JavaME. But this time I can joyfully jump and tell all friends "Apache Harmony is considered not pointless, wow, wow!".

Now Google is going to give away it's largest Open Source piece of code. The important question is here to raise: how Google and other companies in the Open Handset Alliance are going to develop the platform? Will they throw new code "over the wall" or are they going to grow a community that works based on collaborative development?

As a Google employee I cannot describe what the Open Source strategy of the company is. The strategy is obviously just too tricky to describe on one page and not specified in details for projects of that scale. The thing of special hardness is to predict how other companies in the Alliance are going to cooperate here. I hope, by signing a non-fragmentation agreement they mean it, but it is completely not clear how seriously they consider it.

As of special note. Apache Harmony, as a project, has always been welcome for companies to combine their efforts on development of class libraries, VMs and other Java components. We believe that the best strategy for everyone would be the open development of platforms for innovation. At least, this is the easiest way to maintain all components in compatible state.

As for me, there is another really interesting implication behind the announce: Google thus showed everybody that it no more considers Java certification important on mobile phones. Hey, what can JavaME conformance give you except stripped functionality and extra cost for so called Sun's certification? It appears that Java itself does not have a nature of open source software stack yet. Jilles van Gurp, a member of research staff at the Nokia Research Center (Helsinki) advocates compatibility and is disappointed about reinvention of many wheels. Yes, people have been taught by Sun for 10+ years that Sun's certification is important. And many among Java people really care about Java compatibility. But does this certification guarantee you no bugs of some fair level of performance? Obviously, it does not.

Why this does not happen for Linux people? When I run my favorite Linux distribution I do not care about full-featured, certified Linux with all certified libraries. I just get some open source software, and when I need some more, I apt-get install them into my system. With broadband Internet it is very convenient.

But Java is not like that. It is huge, all ways certified. It takes a while to download once you accidentally decide to get a Java plugin in your browser. What happens when I want to start developing something? I download the same chunk with extra bits called JDK. Do I need all that stuff twice? In Linux you would just install a package with headers and one with a compiler, right? So, Java is still lacking bazaar, a naturally open source way of living.

JPackage project addresses this for some extent, but it limits itself to provide extra packages and leave the core Java where it is. Even Sun knows that Java must be leaner, but their solution of on-the-fly downloading all necessary packages appears to be just another brick in the cathedral's wall.

Hey, I want to play my favorite pacman game on my phone, why do I need this completeness and certification of Java? Leave that story for enterprise! How about Java packaging and binary distributions? I know, I know, it is out of the Harmony's scope now, but given that no open letter to Sun can make our implementation the official Java SE, maybe we should go the Google way?

A small disclaimer: This is my personal opinion. The views expressed in this article are mine alone and not those of my employer.