Larry Meadors said:
First priority: Get it out the door, and make sure it is easy to build so everyone who want to tweak it can.
You do realise that there are conflicting priorities here? Get it right and do it now?
Matthew, after all these years of open source I can tell you one thing: there is no such thing as 'doing it right'.
The 'release early and often' concept has one incredibly big advantage that is often overlooked: it makes the ecosystem selective, in a darwinian sense. Try/fail cycles should be small, evolution incremental and reversible, so that, as thermodynamics explains, the entropy of the system doesn't increase.
This is modern software engineering and aligns very well with the extreme programming methodology, which has been shown to be more effective than traditional software engineering practices even in closed environments.
I used to be a hard core 'design then code' dude. Some of the people here know very well how painful that can be, especially when you reach disagreement and architectures *do* look objective but at the end, they are not, they are just an expression of personal opinions on a very abstract level.... and disagreement becomes a religious battle.
As I have already stated, my priority would be to get it right. If you want a free Java right now, there are plenty of excellent candidates out there already.
This seems to imply that what the others did is "wrong", or suboptimal. I think this would be a mistake. In many ways, social and technological.
Harmony is not about reinventing the wheel just because there is a clean slate. It's about enlarging that software ecosystem around existing "free and open" java solutions, hopefully building better bridges between the two licensing worlds as well (for sure, we already have better social ones!)
I would like to see the process being similar to a multi-threaded application: do a certain amount of up front work, setting out the boundaries and requirements. We then fire it out to the open source community at large and allow many, many different teams to work on unrelated small areas.
Sound chaotic? Maybe. But so long as the boundaries are clear enough, I don't see much duplication of effort.
Here I agree. But instead of 'doing it right', I would say "draw the minimal possible architecture so that most can play", which is a community-engineering version of "do the simplest thing that can possibly work".
Second priority: Work with the community to make it faster and more stable than anything anyone has ever seen.
I see a fundamental problem with this. I have not been on this list long, but already I can see there are many conflicting interests. Faster!!! Cross platform!!! Secure!!! Reliable!!! Free!!! Complete!!!
You may get it fast enough and stable enough for 75% of users, but I would be willing to bet that many users of an open Java would have less mainstream uses for it, and would want the ability to tweak, customise, or maybe even gut and replace large portions of the code base.
Hehe, it is amazing what a well behaving organic development ecosystem does to software. It beats, hands down, any corporate and top-bottom driven development. Not because volunteers are smarter (that's completely unrelated) but because they scratch their itches. Read: lazyness is a local minimization of energy.
The benefit of that is the opposite: what does *NOT* itch doesn't get scratched. Resulting in optimal use of ecosystem resources (aka 'cut the crap and get the job done').
Collective lazyness is a less local minimizer: good architectures are those that allow even more lazyness and less energy spent to maintain/modify the software system.
In that regard, what the "free java" ecosystem has created is truly a magnificent achievement: overall, even if a lot of energy was spent in it, compared to the millions of dollars and men/years that commercial companies poured into a JVM, it's already very efficient.
Apache shows very well what a healthy and collaborative community can do to software development.
Harmony just wants to continue that tradition and help in enlarging that ecosystem, friendly and for mutual benefit, hoping to capture all those people/interests that, for good or bad reasons, the "free software" side was not able to capture.
-- Stefano.
