I hate to be the bearer of stop energy, but I really can't see anything useful coming out of this project in the short, medium, or even the long-term.
Exhibit A, from the Harmony FAQ:
10) Do you have any code to start?
No, we don't. We didn't want to "bless" any given implementation that might be donated (if such a thing could happen) but would rather let the community decide how it will create and develop the platform.
I've written this rant before, twice, but I'll say again that this is the worst possible way to start. I would almost go as far as saying that starting an open source project with no code and a committee trying to decide what to do next spells inevitable doom.
The best way to start an open source project is with code. Working code. Hack away at home on weekends, maybe get a couple of friends to help you out, and don't go public until you have something to show people that does something interesting, and that other people can use to build more interesting stuff on top of. You need this for a bunch of different reasons: it establishes the original contributor's bona fides in the open-source meritocracy, it shortcuts all sorts of damaging debates about coding styles and architecture that can stop a project before it starts, and so on.
Most importantly, though: working code attracts people who want to code. Design documents attract people who want to talk about coding. I've seen what happens on projects that start with no code and a commitment to produce a design. Some of the procession of UML diagrams were really well put together, but that's about the extent of it.
Even looking at the initial Harmony proposal document: with twelve names on the list of people volunteering to assist with design and architecture, only nine of them have also volunteered to contribute code. And the fact that these nine felt they needed an incubator, a formal structure and an official public announcement before they started hacking together doesn't bode well.
Exhibit B is the state of the art in existing open-source Java implementations, which is cheerfully dismal. All the existing projects are very worthy, have had a lot of hard work go into them, and are only useful as curiosities, research projects, or something to package with a Linux distribution that will cause all sorts of conflicts when you install a real JDK.
The problem is that with the gratis availability of a fully-featured, mature and advanced Java VM from Sun, there are really only two reasons to write a Free replacement:
- An ideological objection to non-Free software
- So Linux distributions can package a JDK
Most developers are pragmatists. Give us the choice between hacking on something new and interesting, and slaving away over a lot of compatibility edge-cases to reproduce something that is already freely (gratis) available, just so Linux geeks don't have to download the JDK from Sun like the rest of us, and... you get the idea. Unless one of the few remaining cashed-up Linux distributors (are there any?) decide to invest some serious developer time to bringing Free Java to the masses, most hackers are going to see it as a dead-end.
Maybe Harmony will prove me wrong. All I'm saying is the odds are stacked pretty heavily against it, and maybe we should have waited until there was something to show before trumpeting the project across the blogosphere.