I guess I am late to the party, and noone told me to dress formally, so ... let me just say for the start that I think, like tromey does, that it's awesome news.
Whatever People Say I Am, That's What I'm Not / Angst in Javaland
There is a huge amount of angst in some areas of Java user and developer base about free software, and free software VMs forking, breaking, smashing Java to pieces literally. Or it's RubyOnRails, or .NET, or whatever the fear of the year is. That's rather irrational, but that's how fears work. So I'm interested to see if the feedback Sun receives will be couloured in the terms of the struggle of good vs. evil, as an inversion of sides in the struggle Simon describes as a blatantly false metaphor for what's actually an ongoing process.
Meanwhile, going with the "healing" theme, that Simon set, I've contributed my first ever patch to the Sun JDK yesterday. I managed to pull that feat off without looking at Sun's non-free code, by fixing the BSD-licensed Java2D demo to build on top of Kaffe, through refactoring it to use standard image io interfaces, instead of VM-specific extensions. There is a nice little thread on JavaLobby, of all places, starting with Sun's Dmitri Trembovetski's curiosity about our Java2D implementation, our own David Gilbert pointed out that the Java2D demo in Sun's distribution won't compile on a free runtime due to the lack of those VM-specific classes, I stepped in with a patch and a bug report in Sun's implementation, and Dmitri confirmed that the imageio bug I stumbled upon was fixed in Sun's Mustang builds. So now I've got a fix for the JDK waiting for review on Sun's bug parade, and if the stars align right, it may even go in.
I would not have gone through the effort to improve the Java2D demo and contribute my fix back to Sun if it wasn't free software.I would have investigated the bug I observed (Duke's nose was the wrong colour in the flipped image) had Sun's class library been free software, but without being able to use the fixed code in Kaffe due to its non-free, GPL-incompatible license, I had no particular interest in doing that.
Perhaps Vampires Is a Bit Strong But... / Licensing
There is a simple lesson about licensing in all that: chosing a software license that allows people to reuse a work motivates them to contribute, while chosing one that prohibits them from using a work keeps them away.
In that respect, JRL, SCSL, etc. worked great for keeping all those dozens of GNU Classpath developers away from Sun's JDK sources for almost 10 years, and dozens of developers working on other projects. That's quite unfortunate.
Apache Harmony offers another demonstration why the simple lesson above is so important. Back when we started the project, we thought we'd be able to find an easy way to make the source code contributed to Apache Harmony reusable between all the different free and non-free VMs, by using a GPL-compatible and Apache-compatible license for the contributions, and reproducing the success of GNU Classpath's innovative approach to permeable development in a larger setting.
Trying to get Apache to be flexible on the licensing turned out to be a complete desaster, due to the way the Apache Foundation works, so we ended up having to pick between being able to have GPLd VMs using a mostly complete class library, or having to prohibit GPLd VMs and use an infant class library under a GPL-incompatible license. The binary choice, encouraged by an odd "Apache License or bust" attitude on the Apache Harmony mailing list, led to a lot of potential contributors packing and giving Harmony up. Fortunately, Geir rescued Harmony by sucessfully soliciting contributions from Intel and IBM, and now it's a very lively project in incubation. It's mildly amusing to think that we'd be finished with open source Java already, if it wasn't for this fraction of efforts.
It'd be great if Sun could avoid the mistakes we made. One thing is to avoid adding yet another license to the mix: Use the GPL+linking exception, or a dual license with GPL+linking exceprion and ASL. Please don't add a third GPL or ASL incompatible license to the mix that makes sharing between those projects harder than necessary, as then their developers will have no incentive to help you, and we'll end up with three different competing efforts. Yikes.
There is a giant window of opportunity right there for Sun to come riding in on a white horse and be the missing link between the various free Java communities, starting from the leading position, and ensuring compatibility by encouraging everyone to work together with them on a liberally licensed code base. It'll be interesting if Sun sees and captures it. One can hope.
As an additional note on licensing, it may make sense to consider what communities they want to engage with their source code releases, and license accordingly. Javac offers an interesting intersection point between Eclipse and Sun, for example.
When The Sun Goes Down / Governance
I've posted before on JCP's problems, with a bunch of constructive suggestions how to fix them. I'm a deliberate outsider to the JCP since it forces NDAs on participants per default, and offers little real value to members as most communication takes place behind closed doors anyway, and each JSR is a small, walled off garden. That's at least what the people inside that process are saying.
Since I am familar with other standardisation bodies like ISO's C and C++ WGs, and the work being done in various places at the W3C, I've got a rather high level of expectations from standardisation groups, and I hope the JCP will move towards an improved, more transparent, quality and developer-oriented approach in the future.
As far as governance of Sun's project goes, tromey said all that needs saying. If in doubt, ask the NetBeans, Opensolaris, GlassFish and OpenOffice.org teams and compare the results.
Red Light Indicates Doors Are Secured / Compatibility
What tromey said, basically. We need an open source TCK. The distributions trying to figure out if they are in compliance with the DLJ need an open source TCK. The people fixing Sun's opened up code next year will need an open source TCK.
This is so basic, that I am afraid I'm telling Sun the obvious when I say: open up the test suite. But who knows, maybe there are still some folks left under some rock who think the open source Java developer community doesn't care about compatibility, or something equally weird. People get the strangest ideas when they don't communicate, and naturally, the amount of communication between Sun's gated community, and us outside has been limited. So I hope to see some movement on that, and the things David Herron talks about are quite encouraging.
The View from the Afternoon / Branding
That's a non-issue for me, as Kaffe has never been Java(TM)-branded. Whatever works best for those needing the brand, works for me, as long as it doesn't impact the actual source code license in odd ways.
For example, most distributions rebuild their software from scratch, to avoid all sorts of problems. A branding requirement that insists on a single pristine binary that must not be touched will not work for them. That's one of the issues that made me think that pursuit of certification under current TCK rules is something for people with very specific needs only: no distribution would package a random binary off the web, so noone would distribute a certified Kaffe or Harmony build, when they can rebuild it from scratch and optimise it for their distribution. They'd build their own, uncertified packages, so the certification would be pointless for the majority of multiplicators, under current rules.
That would obviously change if the TCK was open source, and could be run as part of the build process. Then a simple peek at the build logs would be sufficient to judge the quality and compatibility of the package.
Still Take You Home / Operation Issues
Well, a few of these things are rather simple: as my little contribution above shows, there should be a way for people to contribute to the opened up portions of the source code, without having to accept the non-free JRL/SCSL licenses. I chose Sun's bug parade, as that was the only way to do it, but as a source code contribution system, the bug parade is lacking in very useful features, like a simple text attachment feature. I'm not sure if the servlet didn't munge up my patch submission, but without a BugID, I can't verify it. The official review time for a bug parade submission is three weeks, I believe, so in the worst case, I'd have to wait up to three weeks to see if my patch arrived in a good state. Yikes.
Who the Fuck Are Arctic Monkeys / Closing Thoughts
The Arctic Monkeys have their own Wikipedia page that tells it all. I've used song titles from one of their albums as headers, as I am currently listening to their live shows, and like it for the time being.
The Arctic Monkeys are a nice little band, if you are into the sort of music. But they are also a massive hype phenomenon, selling out concerts in minutes, which leads to very high expectations. In Sun's case, the expectations are huge, and diverse. I hope they figure out how to meet them and all this feedback ends up being useful and used.