I often get the question of why open source code is important, aside from the usual benefits of code review, security auditing, and the general idea that more eyeballs makes for better implementations ?

Well, where it really shines is during support, when you are investigating a bug.

Let's say that you have a bug, and that for once it is not in your code. It seems to come from some library that is used by your software. When this happens, for example when I'm working on an iPhone application, it usually takes a long time to find the method responsible for the bug. If the libraries are closed-source, this time can be made longer simply by the fact that you are not sure what the dependencies between libraries are, and can spent time trying to pin-point the location of the problem. Once you have managed to track it, all you can do is file a bug report to the author, and hope it will be adressed. In this example case of an iPhone application, this might be a long time, if ever it gets fixed (as bugs are proritized by project managers).

In the case of an open source product, such as Jahia, you have the full source code, and you are free to modify it for your own means, or redistribute the modification under the same license. So this means that when tracking down a bug, I can not only more rapidly find the origin of the problem, but I can, if I know how to do it, correct it myself and not have to rely on external resources that may not be available at the time. Also, when debugging, it is really great to be able to trace through the code to understand what is going on. Maybe the bug is in your own code, but actually seeing the source code of the external library made you understand what was wrong in your own code a lot faster. You could ask an external consultant to work on it, and he could do it provided he has a good knowledge of the code, and help you fix the issue faster. Finally you can contribute the fix back to the author of the source code if the issue was found in an external piece of software.

So in the end, bugs get identified and fixed faster, you spend less time with bugs, the customer gets a answer faster, basically everyone wins.

This is for me one of the biggest commercial advantages of open source against closed source, and if it makes the customer happier, it means you will retain him.

I have just heard about the Google Wave discontinuation by the end of the year, and I must say my feelings are mixed. For me, the real reason for it's failure is not user adoption like Google and others seem to put it, but mostly execution.

Google Wave had a lot of technical hurdles, because it was very ambitious. For me the most promising part of the technology was the fact that Google announced they would, at some time, open source the back-end server and let everyone, in their own infrastructure, install Wave servers, much in the same way that people install Mail servers. This is what was really great about Wave, not all the gadgets like real-time typing and correction. Because it meant that this technology would be truly de-centralised, that no one could "own" your information. Actually with the hindsight this was very strange coming from Google, who tries to get as much as people's data as they can in their infrastructure. Maybe this is the real reason they cancelled this project ? :)

Anyway, at Jahia, we initially were very skeptical about the technology, and to be frank, when we got our first accounts we didn't really know what to do with it. We had all kinds of ideas of how to integrate it with Jahia, and we played a lot with wavelets, but apart from the basic fun, we never found good use cases for it. Then suddenly one of our developers really insisted that we use it as a brainstorming tool, and we quickly discovered how great this new tool could be ! This was really the killer application for this type of usage, and despite some hurdles (no notifications at first, and lack of integration with browsers or desktop clients), we started using it regularly and were becoming quite good at it.

So for us we really found a good way to use Google Wave and despite its flaws we were happy with it. And now Google has decided to cancel the project. Fine, we'll go back to our old ways of doing things, maybe having learned a little on how to better collaborate.

I think that Google really has an opportunity now, at least if they are ready to take this chance, to fully open source the technology. Sure there might be some Google specific parts, or maybe even some missing parts, but both the GWT client and server parts could be very interesting to a lot of developers, and some might even be able to use it as a basis for building libraries to implement the Wave protocol. They have already some source code available at the Wave Protocol website and they should just expand on that, make it into something easy to build and test locally, including the GWT client.

I hope this is what they will do, and who knows, maybe this could even save Wave ?

Yesterday I had to find a bug in EHCache in a cluster installation, and wanted to use the EHCache remote debugger, as described here : http://ehcache.org/documentation/remotedebugger.html
 
It turns out the documentation wasn't very clear, and it wasn't less clear was where the package could be found. In fact it can be retrieved here : http://sourceforge.net/projects/ehcache/files/ehcache-debugger/ (note the fact that it seems the name of the debugger is either "remote debugger" or "debugger", but it's the same code base).
 
Now the tricky part was to make it work with Jahia. The way the debugger works is to actually participate in the cluster as an EHCache cluster node. What the documentation doesn't tell you is that in order to participate in the cluster, it will need to be able to deserialize all the objects it receives in the cluster messages, and this is why your application JARs are required. Also, I have tested it with JGroups replication, and it seems to work fine, so it can safely be used in other setupts than the RMI replication.
 
Another problematic part of the documentation is the fact that the example command line mixes the -classpath and -jar command line options, which isn't supported by the JDK 1.5. So the example command line from the documentation will not work. Also, as is the case with Jahia, there might be a lot of application JARs, so it can be quite tedious to list them all. I put a little shell script together, that will automatically create the classpath correctly for a Jahia installation, which I am showing here :
 
debug_ehcache.sh
--------------------------
 
buildClassPath() {
  jar_dir=$1
  if [ $# -ne 1 ]; then
  echo "Jar directory must be specified."
  exit 1
  fi
  class_path=
  c=1
  for i in `ls $jar_dir/*.jar`
  do
  if [ "$c" -eq "1" ]; then
  class_path=${i}
  c=2
  else
  class_path=${class_path}:${i}
  fi
  done
  echo $class_path
  #return $class_path
}
JAHIA_LIBS=/Users/loom/java/deployments/jahia-6-0-hotfix/apache-tomcat-6.0.18/webapps/ROOT/WEB-INF/lib
JAHIA_SHARED_LIBS=/Users/loom/java/deployments/jahia-6-0-hotfix/apache-tomcat-6.0.18/lib
JAHIA_CLASSPATH=`buildClassPath ${JAHIA_LIBS}`
JAHIA_SHARED_CLASSPATH=`buildClassPath ${JAHIA_SHARED_LIBS}`
CLASSPATH=${JAHIA_CLASSPATH}:${JAHIA_SHARED_CLASSPATH}:./backport-util-concurrent-3.1.jar:./commons-logging-1.0.4.jar:./commons-collections-3.2.jar:./jsr107cache-1.0.jar:./ehcache-debugger-1.5.0.jar
export CLASSPATH
java net.sf.ehcache.distribution.RemoteDebugger ehcache-jahia_cluster.xml $1 $2 $3 $4
-------------------
 
Before launching this, make sure you copy your EHCache configuration file from WEB-INF/classes/ehcache-jahia_cluster.xml . Also, as this file uses variables injected from the jahia.properties file, you will have to replace the variables with the real values, as in the example below :
   <cacheManagerPeerProviderFactory

   class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"   properties="connect=TCP_NIO(start_port=7870;bind_addr=127.0.0.1;loopback=true;recv_buf_size=20000000;send_buf_size=640000;discard_incompatible_packets=true;max_bundle_size=64000;max_bundle_timeout=30;use_incoming_packet_handler=true;enable_bundling=true;use_send_queues=false;sock_conn_timeout=300;skip_suspected_members=true;use_concurrent_stack=true):

You can then start using the script to listen to a cache in a Jahia cluster installation. Here is an example command line :
 
./debug_ehcache.sh SkeletonCache
 
The output looks like this :
 
Received removeAll notification.
Cache: SkeletonCache Notifications received: 1 Elements in cache: 0
Cache: SkeletonCache Notifications received: 1 Elements in cache: 0
Cache: SkeletonCache Notifications received: 1 Elements in cache: 0
Received put notification for element [ key = 2-normal-en-administrators|administrators|guest|users-$$$#$#G_ContentPage_2WORKFLOWSTATE-normalLANGUAGECODE-en#$#G_SITE-2#$#G_USERNAME-administrators|administrators|guest|users, value=org.jahia.services.cache.CacheEntry@9d04dc, version=1, hitCount=0, CreationTime = 1252940741198, LastAccessTime = 0 ]
Cache: SkeletonCache Notifications received: 2 Elements in cache: 1
Cache: SkeletonCache Notifications received: 2 Elements in cache: 1
Cache: SkeletonCache Notifications received: 2 Elements in cache: 1
Received put notification for element [ key = 2-normal-en-guest:0-$$$#$#G_ContentPage_2WORKFLOWSTATE-normalLANGUAGECODE-en#$#G_USERNAME-guest:0#$#G_SITE-2, value=org.jahia.services.cache.CacheEntry@8caee7, version=1, hitCount=0, CreationTime = 1252940747195, LastAccessTime = 0 ]
Cache: SkeletonCache Notifications received: 3 Elements in cache: 2
Cache: SkeletonCache Notifications received: 3 Elements in cache: 2
Cache: SkeletonCache Notifications received: 3 Elements in cache: 2
Received put notification for element [ key = 302-normal-en-guest:0-$$$#$#G_USERNAME-guest:0#$#G_SITE-2#$#G_ContentPage_302WORKFLOWSTATE-normalLANGUAGECODE-en, value=org.jahia.services.cache.CacheEntry@535057, version=1, hitCount=0, CreationTime = 1252940754196, LastAccessTime = 0 ]
 
This can really be a neat tool to diagnose or simply get a feel of how Jahia is using EHCache to communicate within a cluster. I hope this little blog entry will help you use this debugger, because despite the tricky setup it is very useful and a neat design.

I was going through some CMS and portal software implementations yesterday, and looked at them from a standards point of view. You might wonder, why are standards important ? Isn't it easier to build something minimal that will do just the job ? Well in terms of software engineering it probably seems to be, but you end up in a very proprietary system, but using standards don't necessarily mean that you will have to build more code.
 
One standard comparison that is often mentioned nowadays is the one between SQL and CMIS. Some call CMIS the "SQL for content", while others (like my good colleague Stéphane) view it more as the SQL for file systems :) But anyway, what do these standards really bring us, except for the hassle of implementing them and even harder testing interoperability ?
 
I think one of the best examples in this area is what has happened in the browser world. They would have never existed if it wasn't for standards. When Mozilla was started, there wasn't really a standard for HTML, it was written based on the implementation, but that's ok. When Mozilla became Netscape, it added a lot of extensions to HTML, like layers, that weren't part of the standard, and when Internet Explorer came to the market, it had a different implementation of layers. So basically for a while, people building web sites either had to do two versions of their websites, or just refrain from using layers until they were standardized.
 
So what did people gain from the standards ? Well on the end users part : choice. On the web developers side : less work. On the browser's side : a very good API to implement and especially to test against ! The last point is very important, it is one of the reasons that Java became such a success. The API was clearly a "standard", established through the Java Community Process process, to make sure that various implementations would comply to the same API. Sure there were some glitches here and there, but globally it was quite a success.
 
Giving customers choice is not necessarily something they will immediately understand, but it is good for them. When Internet Explorer became the dominant browser, the best way to attack it was through its less than compliant implementation of CSS. Suddenly web developers starting complaining about high development costs, were developing better looking layouts on other browsers, and Firefox became a very strong competitor.
 
In the CMS market, this need for standardization is still in the process of happening, but nonetheless important. Customers must understand that the investment they are doing into their content management system must imply the possibility to import and export the content easily, and especially interoperate between various content system. This is especially true when you go into the semantic web, where content systems will need to create semantic links across vendors, and that is still a bit of a pipe dream at this moment.
 
Some standards are de-facto standards. When these de-facto standards are actually owned and controlled by a single company, this is more of a problem. Look for example at Microsoft's Internet Explorer or the iPhone's AppStore. Both these de-facto standards are really creating frustration on both the user and developer's sides. In the iPhone's AppStore for example, the end-user cannot use applications that run in the background or fully interact with the phone, the applications only run on the iPhone or iPod Touch, and any complaints are completely ignored by the company because it cannot handle the sheer volume of customer requests. On the developer's side, the closed platform means that you can spend 6 months developing an application that will never be accepted. Again the fact that a standard is de-facto doesn't guarantee it's success.
 
But when the de-facto standard is established by an open-source foundation such as the Apache Foundation, things can be very different. Even in the case of SpringSource, fathers of the excellent Spring Framework, the de-facto standard can become a real strong force. So the combination of de-facto and open source is a really powerful one, especially if the implementation has a large public. But what is even better is a real standard and open-source implementations, like the Apache Jackrabbit or Apache Chemistry projects. Even if the project might still run out of steam one day, the standards on which they are based will still be there, and the legacy can be guaranteed to be understood and the interface still present to allow future developers to be able to interact with the systems.
 
In the aviation industry, they do the exact opposite to what most of the software industry does, they only use "old" bricks, that they know have been proven to work, and adhere very strictly to standards and specifications. This allows constructors to protect human lives from harm. This has an incidence on cost of course, but because they are doing this mostly within a single company and also because of the materials and manpower needed. But there is software running in airplanes and space shuttles, so the importance of standards and high reliability doesn't need to be incompatible with the business of building software.
 
The real hard part is building software quickly and reliably, without incurring too many costs, and this is where the open source community comes into play. Some projects in the Apache Foundation have been incredible in that regard. The Apache Jackrabbit project is such an example, the Spring Framework is another, and there are many such stories of high quality software, adhering to standards, that have been developed much quicker than ever before. But they wouldn't be interesting if they didn't adhere to a standard, be it de-facto (because of community size and open-source) or "real".
 
Jahia was born out of a proprietary content management system, and is moving all of it's sub-systems to be built on on top of both the "real" and de-facto standards. It builds value on top of bricks that have been proven to be reliable, modern and standard such as the JCR, the Portlet API 2.0, WebDAV, GWT, the Spring Framework, Log4J, and many more. We are working on integrating CMIS and possibly other new standards (such as the work being started in the IKS project). Of course the real value to the customer is not in the bricks, but in the building you have constructed using the bricks.

After the successful launch of Jahia 6, I'd like to take some time to give you a different perspective on what this version means to us. Basically, Jahia 6 was the beginning of a very interesting trend going on here : building on the experience and re-writing some of the older codebase.
 
Jahia, the company, is now a little over 7 years old, and it has grown during all these years without having any external investors. So it has not always been easy, but the people that we have here are really amazing, and it is a real testament to all that we have achieved so much. You might not have heard much about us so far because we haven't been communicating much, but we intend to correct that now :)
 
Coming back to the codebase, you can accumulate a lot of code over 7 years, especially since the project started even before the company, and was bought-in when we started the business. I participated to the original codebase, and it is quite amazing to see how it has grown. Over the years, little by little, we have improved the software, adding features and making it faster. We have constantly worked to make it as easy to use as possible, and that is always a great challenge. This challenge is made even harder by all the browser incompatibilities. When Jahia was first written it had support for Netscape 4.7 and Internet Explorer 4 ! We basically had *very* different HTML for the two browsers then :)
 
Jahia 6 was a great project, because we decided to take huge leaps instead of smaller steps this time. Despite this, we didn't compromise on quality nor performance and constantly had the aim that this version should be one of the best ever, and of course you be the judge but I think we did quite well. Jahia 6 introduces major platform changes : new content definitions based on the standard JSR-170 CND format, completely new file repository based on JSR-170, connectors to all kinds of repositories, complete rewrite of the AJAX framework using GWT, lots of improvements on our templating in order to make it easy for integrators to work fast, using re-usable blocks.
 
The new version expands on one of Jahia's biggest strengths, the tight integration of CMS and portal features. In Jahia 5, you could easily include content objects and portlets on the same page, and in Jahia 6 you can not only continue to do this, but also use mashups (think of "Javascript portlets") interchangeably with JSR-168 portlets. Actually we went further than that and directly included support for the brand new portlet API 2.0 standard , which adds support for inter-portlet event communication and other niceties. We support both mashups and portlets because we moved the portlet instance data into the content repository, and so we can easily reference both front-end code (HTML + Javascript) or a reference to a portlet deployed in Jahia. Upon page rendering, Jahia simply resolves the content to be displayed, either extracting the mashup from the repository, or dispatching to the portlet to get it's view. This is of course completely transparent to the end user, who can then simply re-use block elements inside a page, should they be portlets or mashups. We have also added the possibility to deploy portlets inside the same context as Jahia, making it possible to access all of Jahia's API from within a portlet. We have used this feature ourselves to build our RSS portlet, that comes packaged with Jahia 6.
 
On the front-end side, I think that a lot of users will enjoy a new feature we call "inline editing". It allows you to simply click on the text you want to modify, and directly modify it right on the page. This makes it so intuitive you'd like everything to work that way :) This new feature requires users to use Safari 3, Firefox 3 or Internet Explorer 6+, since it uses a feature originally introduced by Microsoft and then included by others.
 
I sincerely hope you will enjoy Jahia 6 as much as we enjoyed working on it. Don't hesitate to download it, or test it on our online demo. Please don't hesitate to let us know what you think about it, either by commenting on this blog or through our public forums.

At Jahia, we constantly run into the problem of IE 6 support, which (unfortunately) is still a requirement for us. But I couldn't suppress a huge smile when the following excerpt from this page : 
SharePoint Server 2010 won’t support Internet Explorer 6<. From the SharePoint Team blog: SharePoint 2010 will be “targeting standards based browsers (XHTML 1.0 compliant) including Internet Explorer 7, Internet Explorer 8 and Firefox 3.x. running on Windows Operating Systems. In addition we’re planning on an increased level of compatibility with Firefox 3.x and Safari 3.x on non-Windows Operating Systems,” according to the SharePoint Team Blog."
So basically even Microsoft is not phasing out IE 6 support and improving compatibility with Safari ! I love the "targeting standards based browsers", clearly implying that IE 6 is far from it, which I think nobody in their right mind will contest.
The real problem is that according to a Forrester Research report, IE 6 still has a 60% market share in the enterprise. I believe that the only real way that we can get this situation to change is for companies to introduce a browser policy, and to possibly use Firefox as the "new browser", and whatever version of IE is required for "legacy applications". But the reality is that IE 6 must die, and if the newer versions of IE are not interesting enough, then users should switch to other implementations, like Firefox, Safari or Chrome.
Another interesting point, although less surprising, is that CMIS is confirmed for the next version of SharePoint.

During the CMIS PlugFest, an idea that was mentioned by a few participants consisted of using JSON as a transport mechanism for CMIS repository operations. The idea was to be able to easily develop thin clients such as Javascript or PHP clients, and avoiding the pains of generating or parsing XML data.
I think this might potentially be the "revolutionary" binding in the specification, that really has the potential to surpass all the others over time. Sure it is absolutely great (and at the same time a double-edge sword since it means more work for implementors) that CMIS has all these bindings for a first version, but I think that we will eventually see a natural selection where only the easiest to integrate with all technologies will survive.
It takes one line of PHP (5.2) to serialize/deserialize JSON data (json_encode), and there are high quality libraries available for all the modern languages out there. Personally I've implemented JSON for an iPhone application in Objective C and it proved to be the most efficient way of transferring UTF-8 data over the wire.
The hard part of course is that JSON does not specify structure, only serialization format, and therefore it would be very important that the CMIS specification strongly describe the structure of the JSON payloads that are going back and forth between the client and the server.
JSON handles complex serialization a lot more elegantly than SOAP web services, and is simple enough for anyone to understand in a matter of minutes. Wouldn't that be a great basis for the content management interoperability standard ?
I know that a few people involved in the CMIS specification are already hard at work on proposing JSON as a binding for the 1.0 specification. This will be tricky since the deadline for the approval of the specification cannot change, so it means that all this must happen without slowing down the rest of the work. This will be a challenge, but I'm really interested in helping out, so please let me know how :)
I dream of a world where I can directly interface a lightweight Javascript CMIS client with any CMIS compliant server. My mind is racing with the possibilities...