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.