The JCM7 was an awesome meeting. Lots of great ideas shared by the best and brightest people I've ever met. If any group were to ever get together to make something happen, this group would be it. On the other hand, I'm stricken by the fact that only a very few in the Community make an effort to actively participate. Why so many "lurkers"? Sun Marketing has done a great job with the limited resources they've been given and I believe the Community is a largely untapped resource that can supplement Sun's efforts.
Jennifer Kotzen and Jim Hurley are doing a fantastic job - just imagine what could happen when we do it all together!
Due to the distributed nature of Jini, the SCSL has some pesky side-effects that prevent using Jini from any product that is not also SCSL licensed. The Community has made it clear that the SCSL is not developer-friendly. Yet, Sun continues to drop back to the position that it is protecting it's intellectual property. Why is Sun so scared of opening up the license? JXTA is open source!
Sun needs to lose the unfounded paranoia that IBM or Microsoft will steal Jini and provide a more reasonable, developer-friendly license.
Work to eliminate the misperception that Jini supercedes (or is superceded by) technology X:
Web Services
JXTA, Grid
J2EE: JNDI, JMS, JTS, JMX, JCA
Apple Rendezvous
Bluetooth, RFID
In fact, the truth is closer to thinking about them as complementary technologies. The Judy Project is a Web Services bridge, the Athena Framework is a distributed datasource transaction bridge, Danial Jiang and Mike Warres recently gave excellent presentations on how to customize JERI RMI semantics to other technologies (I'm thinking JXTA, Rendezvous), Danial Fuchs added the JMX Remote API to the list of Jini standards, Java.net's Editor-in-Chief Daniel Steinberg gave a presentation on ideas for integrating Rendezvous and Jini, and the list goes on.
By encouraging the building of bridges to/from other technology stacks, the Community can focus on how Jini transforms impossible problems into solvable solutions.
Again, JXTA is completely open source, so why not Jini? The Jini team's stance on this aggravates me nearly as much as the SCSL. Early in Jini's development, it was wise to hold the reins tightly since few people understood the technology and it's principles. It was also wise to protect the technology from being stolen or subverted by an anti-capitalist. Fortunately, these problems are less significant than just getting people to use Jini. Gregg Wonderly, Dan Creswell, Calum Shaw-McKay, Mark Brouwer, the commercial licensees and others are really on top of the technology. Having a closed development process prevents the Community from contributing.
Sun's protective hand-holding limits creative inputs and lengthens the time between releases.
If you are a member of the Jini Community, exercise your right to vote in the General House Jini TOC Election. To see the entire voting page, please log-in with your Jini.org username and password.
My take on the SCSL is fairly simplistic yet practical. In order to build my code, you need to download Jini - thus you need to sign the SCSL. In order to run my binaries, you need to download Jini - thus you need to sign the SCSL. Therefore, IMO, it should not matter, what license I release my code under, because until the end-user signs the SCSL and downloads Jini, my code will not work and is effectively 'crippled-ware'.
I believe there is some case from Sun regarding the release and availability of source code via CVS - people can extrapolate key interface signatures from your source code. But given that the mailing list is open and searchable, for many interfaces the signatures can be found with a bit of research. I do understand Sun's position on this, but they're in a Catch22 - if they open up the license it could go either way; the WS-Discovery guys, or similar begin to strip it down ( I think this is unlikely, as the Jini stack is pretty mature) or developer adoption begins to thrive. I think it is a gamble that could pay off for Sun
Previous Topic
