The importance of standards
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.
