James Duncan Davidson stated the money question for java.net.

Part of the answer will be in what Sun's reaction to this community is. And part of it will be found in the people who show up to build that community. So then that leads to another question: Why should you participate?

Here's his answer:

For myself the answer is: I'm participating on the blogging side of things because I want Java to become more open. When I worked at Sun I fought many battles for that to happen. Some succeeded. Some didn't. But even though I'm no longer inside of Sun (two years of freedom this month!), I still want Java to succeed. And for that to happen, it has to become more open.

I don't have an answer right now. I agree with James that Java needs to be more open. Unfortunately, I think that Sun (the corporation) is the biggest obstacle to that right now. java.net is probably going to attract attention. And as we've all heard umpteen times by now, people's attention is finite. java.net has just made life harder for a whole bunch of people outside Sun who have been working hard to make Java succeed. Is the way to help the broader community to drain away energy from communities that are already working and re-channel it into building a new community, one whose heart we don't know yet? I don't know.

Randy Heffner from Forrester has an opinion piece on CNet regarding the JCP and JSR-215, which would help to make the JCP process more transparent. After he finishes his explanation of how the new JSR can help strategic technical planning, he writes.

Still, in competing with the Microsoft platform, Java's biggest disadvantage is not having a unified and efficient way to bring the diverse set of Java community plans, ideas and goals together into a coherent plan that explains the necessity of and relationships between the many different JSRs.

A bit later he writes:

It would be a fatal weakness if, as Java vendors compete for market share both among themselves and against Microsoft, the need for innovation combined with the slowness of the standards process and the lack of a coherent direction resulted in a preponderance of proprietary features over standard features in Java implementations.

After all of that, he doesn't actually talk about the role of a chief architect. He hints at it in his first quote, where he talks about a coherent plan of relationships among the various JSR's. But there's another aspect of an architect's role that he is overlooking. Frequently the architect is the one who says no to the raft of interested parties trying to get stuff into a project. The reason that Java is suffering from a huge number of poorly related JSR's, is that all the vendors are trying to get an edge on each other by slipping their product into the JCP as the basis for a JSR. IBM and Oracle did it this week with an XQuery API -- how can we have an API for something that itself hasn't been standardized? If Java needs an architect, it needs one who will say no.

There's one other point that Heffner misses. The point of avoiding proprietary API's is to avoid lock-in. You don't want to be locked in because you're at someone else's mercy. There is another way to control your own destiny. Community developed open implementations.

If Java gets into the all together, highly integrated platform game, then it is playing the same game as Microsoft, but with a deck that's stacked badly against it. Java technology and the CLR are both technologies that allow more modular development than previous technologies. There are three models you can compare and three dimensions to compare them.

The three models are:

• Java-JCP - the existing Sun big-bang JCP, J2SE, J2EE
• Java-Open Source - Java + open source extensions
• CLR-MS - the centrally planned Microsoft .NET

You could even add a fourth model, CLR-Open Source, that would be represented by Mono, but that's for another post, perhaps.

The three dimensions are, What is the process for platform evolution, how often does the platform evolve, what is the reputation of the platform vendor in the developer and customer communities?

For Java-JCP, the process is the JCP, how often is roughly 18 months to 2 years, and the reputation is Sun's reputation, and to a lesser extent, that of IBM, BEA, and whoever else you'd like to lump in there.

For Java-Open Source, the process is developers scratching an itch, how often is as often as possible, and the reputation is the varied reputation of different parts of the open source community

For CLR-MS, the process is MS .NET engineering, how often is roughly 18 months to 2 years, and the repuation is Microsoft's reputation

The big difference between Java-JCP and CLR-MS is JCP vs MS .NET engineering. I'd like to have something much more nimble.

Simon and William Grosso are going back and forth about the "skill level" of Java programmers.

Simon expanded on his view in a very reasonable manner.

My personal view is that the way to expand the developer community is not to 'drop the threshold' but rather to expand the range of languages that target the Java platform. That's why the discussion in this morning's keynote concerning the embrace of programming languages like PHP and Jython (Sean will be pleased!) is so important. PHP and Jython programming isn't dumbed-down - it's just the use of the tools that are fit for the job, and embracing a wider range of tools simply expands the scope rather than lowers the bar.

The only problem with this expansion is that now you've taken out a piece of the equation, which is the language. One of the supposed benefits of Java is that there is only one language that you need to know. Of course you can run any language that you like on the JVM, but Sun hasn't really been promoting that. If they do, then the story starts to sound a lot like the .NET CLR story...

The best quote in the exchange was this one from William:

A friend of mine recently started including "Lisp is the red pill" in his e-mail signature. I think I know what he means, now.

Miguel has announced that Ximian and Sourcegear are working together to bring up Vault on top of Mono. This will give Sourcegear a way to run Vault clients on non-Windows systems. Ximian is doing a bunch of work to bring Mono's web services functionality up to snuff, as well as doing a bunch of work to make Mono more stable and reliable.

This is an interesting development because it involves a commercial software company taking an interest and investing some money in Mono. It's also interesting because it increases the amount of the .NET framework that Mono implements. I wonder when we'll start hearing rumors of legal action against Mono.