How jLibrary innovates

As you probably already know, jLibrary was nominated to the JAX Innovation Awards. Finally, the project got a place between 6th and 10th, but I don't know really the number :-)

I must recognize that I was very surprised for being on the 10 nominees, so the result wasn't a disappointment for me. It was a big prize being there.

Some weeks before knowing that I was nominated I told some people that I really didn't think about having a 0.00001% to win. Why? Because I don't think that jLibrary innovates on the sense that people likes innovations. Innovation projects are typical related to universities, research institutes, healthcare foundations, etc. In fact, I think that some of the work we do on my job at the hospital could easily have been nominated with good winning possibilities (for example some internal telemedicine projects).

jLibrary is more pragmatic because is a final end user tool, and so tries to give the user a different kind of innovations. So, I really think that jLibrary innovates but not on a "winning-contests-innovation" sense. So, which have been on my oppinion the innovations behind jLibrary?

• Bring content management to the desktop: Traditionally content management has been an area very centric to web applications. Probably we could say that the content management systems are web based on a range that could go from 90% to 99%. Probably, the percentage could go from the 98% to 99% if we only take in count Open Source products. So I think that this is the main innovation, to give the user the opportunity to copy, paste, drag and drop things from the operating system, edit their documents with their tools (OO, Word, ...). In summary, give the user the opportunity of really doing pragmatic content management.
  


• Provide a bridge between Eclipse RCP and JSR-170: Yes. jLibrary is the first application that has merged the Eclipse RCP and the JSR-170 worlds, being able to communicate from an Eclipse based client architecture to a JSR-170 server repository based on Jackrabbit. jLibrary is not as ambitious as the current Apogee proposal, but this shouldn't hide that jLibrary has been the first tool able to do this. Also note this jLibrary architecture has been already used since the 2005. (As a side note, I don't want to confuse anyone with this point. The point is a reality, but the idea behind jLibrary is to remain as pragmatic and simple as it's today and not to compete with anyone. So I hope to don't receive more comments as "hey how do you compare to Alfresco or Nuxeo". We are different tools with different objectives and scopes, and even more, probably jLibrary could easily leverage those both great projects.)
  


• Bringing pragmatism to the content management: As some of our users said on the forums, you can start to work with jLibrary with 0-5 minutes training because it is insultingly easy to use and deploy. And so it appears like a good tool for people, team, enterprises, that don't want headaches to store their documents.
  

BTW, probably this would be my last but one spam post about jLibrary on a very large time. The last would be the 1.0 final announcement. It will be very soon ;)