Archive for the ‘daisy’ Category

Daisy 2.2 released. Kauri keeping Outerthought busy

Tuesday, March 25th, 2008

Outerthought recently announced version 2.2 of their Daisy CMS platform. One of the biggest improvements has been in the area of localization. Daisy, with its “variants” model, has always been strong in managing multiple language renditions of a content asset. With 2.2, Daisy has improved the way different translations of a document are kept in sync. For example, if your native language is English, you may create many incremental English versions of an asset and translate the major versions into the secondary languages. Daisy 2.2 allows you to map different versions of language variants and shows you when the mapped versions are not in sync. For a better, more thorough explanation, see Bruno Dumon’s blog post on translation management.

I think that the Daisy 2.2 release has been ready to go for a while but the team has been working on a new web application framework called Kauri. I know what you are thinking: just what the world needs, another web application development framework. Take comfort in knowing that they are not trying to re-invent everything. They are re-using what they like but have decided to build their own runtime and their own template language. The runtime is based on a “Restlet” (as opposed to servlet) architecture and seems pretty interesting. While servlet based frameworks may be considered to heavy weight for REST style architectures, I think departing from a well known standard (like the Servlet standard) should not be taken lightly. Noelios, the company behind Restlets, is intending to take their Restlet API 2.0 through the Java Community Process this year (see blog post).

The creation of a new templating language makes me a little uncomfortable. While there is really no good standard other than JSP JSTL (not really a templating language in itself) and XSLT (too hard for most to learn), creating a new templating language (or any new language) is the developer equivalent of jumping the shark – an over the top attempt to break out of the status quo.

No templating language is perfect but there is value in working in an imperfect language that you know or that your IDE knows. Most templating languages go through a natural lifecycle where they start out architecturally pure but limiting (and often a little slow and buggy too), then they achieve stability, then they start to get ruined by the desire add programming capabilities that spoils the separation between layout and business logic. I would love to see a better standard in this area that will help slow the decay of a good templating language and bring some commonality between content management systems.

I will try not to pass judgement on the Kauri template language before I see it and I would love to see something that would make me want to teach it to a creative developer. I guess you could say that I have a healthy skepticism.

Daisy 2.1 Release is Official

Tuesday, September 4th, 2007

Outerthought just announced the official release of Daisy CMS: version 2.1. For those who are not familiar with Daisy, it is a fairly simple, easy to use Java based WCM platform. The front end is styled after a wiki although it supports more comprehensive WCM functionality such as structured content types, decent access control, and workflow. The repository is de-coupled and is accessible through a ReST style interface so the more ambitious or Cocoon-phobic (the user interface is written in Cocoon that has a steep learning curve) can write their own management interface and front end.

Daisy is primarily used for basic informational sites, intranets, and knowledge bases. Some companies use it to create documentation because of its XML oriented architecture, its book publishing features, and also its powerful versioning and localization functionality. Thanks to a partnership with the Belgian systems integrator Schaubroeck, Daisy is widely used for local and regional Belgian government sites. Daisy development is managed by Belgian systems integrator and software developer Outerthought which also sells support packages on the platform.

This new release is supposed to be easier to configure and manage (thanks to a new Spring based runtime container) and includes a very cool visual version diff’ing tool. Unfortunately Daisy is still missing user input validation out of the box. You can only set whether a field is required and the size of the input box.

If you have been looking for a basic, mature Java WCM and have been turned off by the complexity (in terms of user interface, architecture, and social dynamics of the community) of Apache Lenya, you should give Daisy a look.

Commercial Open Source

Sunday, January 28th, 2007

There are a number of companies making money “selling” open source software. These products can be very attractive to buyers who are considering using open source but do not want to give up commercial software accountability. When evaluating commercial open source options, in addition to understanding how these applications may satisfy your requirements, you should ask two additional questions:

  1. How does this company make money?
  2. Will you be charged fairly for your intended use of the software?

The first question, is very important. You don’t want to partner with a company that does not have a sound business model. Distributing software under an open source license is a practical and powerful business strategy that dramatically reduces the cost of sales and marketing. However, even with low expenses, a healthy bottom line depends on a reliable revenue stream. If the vendor goes out of business, you will lose all the benefits of going with commercial open source. You want to contribute to the health of the vendor, but you don’t want to pay beyond the value you enjoy. You also want flexibility if you do not experience the value that you have been promised.

To help answer these questions, I thought it would be useful to explain the different business models that commercial open source vendors practice. To do this, I will break them down to groups with examples. These categories are not exclusive. You will see that some companies practice hybrids.

  1. Tiered Versions. Many commercial open source vendors distribute a trimmed down “Community Version” of their software under a restrictive open source license such as the GPL, and then sell a more full featured “Enterprise Version.” Usually the features that are considered necessary for enterprise deployments (such as LDAP integration, clustering, etc.) are witheld from the community version. The enterprise version may be presented as a bundle of commercially licensed “plugins” that work on top of the community foundation or it might be a totally different code base. The enterprise version will usually be sold with a maintenance package which provides commercial style support for an annual subscription fee. The community edition may or not be supportable. SugarCRM, Jahia, Magnolia, and Zimbra fall into this category. Jahia is interesting because a customer can earn credit toward licensing fees of the enterprise version by underwriting the development of a feature that is on the product roadmap.
  2. Badgeware. A corollary to the “Tiered Version” model is to distribute a single, open source licensed code base but require non-paying users to display a “powered by” logo on the application. For WCM software, this includes all the externally facing pages of your website. There is a debate whether software distributed under these restrictions qualifies as open source. The badge requirement may be tolerable for some informal uses such as intranets or a non-profit that looks at their software vendor as a contributing sponsor. Alfresco and Jahia have these restrictions on the free versions of their software.
  3. Dual License. While often confused with the “Tiered Version” model, a Dual License is where the exact same software is distributed under a commercial and open source license. Which license you need depends on how you intend to use the software. The open source version of the license is usually the GPL or a similar license that would prevent the user from selling a derived work or bundling it with a commercial application. If you are just using the software to run your business, you can usually go with the open source version. If you are using it in the creation of a proprietary [updated based on Sandro's comment] product, you need the commercially licensed version. This is how eZ publish is distributed.
  4. Support. Probably all commercial open source companies rely on support and/or maintenance revenues. However, some companies make it difficult not to purchase support. One model is to distribute a “Community Version” that, while functionally equal to the “Enterprise Version,” is “unsupported.” This may mean that it has not been as fully tested as the packaged versions that are distributed to paying customers. It may also mean that if you ask for help, you need to migrate to the enterprise bundle before someone will even respond. Companies that have these kind of policies require their customers to decide whether they ever will need support before downloading the software. They generally have the attitude that if you use the software for production purposes, you should be paying. Alfresco operates in this way. Other companies are more liberal and allow you buy your support package the first time you need it. This is how eZ publish works. There are also companies that run community based projects and sell support packages. Examples include Alkacon software (the company behind OpenCMS), Outerthought (the company behind Daisy). In general, if the software is very widely used, a vendor can afford to be more flexible about support. If there are millions of downloads, they only need a small percentage of users to actually buy a support package. That is why MySQL is so successful. I don’t know if a CMS application could achieve the user base to make those multiples work but there are a number of companies that are trying to find out.

All of these business models try to do one thing: create value for customers and make them pay proportionately. This is not a bad thing. It is what businesses do. Some companies consider the value as the software itself and the users are obligated to pay to use it. Other vendors feel like the value is in the service (support and maintenance). Like all partnerships, your relationship with your software vendor will be better if you understand each others’ needs and perspectives and work together under terms that are mutually beneficial. The relationship will likely fail if either side tries to take advantage of the other by trying to get services for free or locking the customer into unreasonable terms. This does not mean that using commercial open source software for free is immoral. The software vendor also needs to think of getting value from its non-paying user base. But that was a topic for another post.