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:
- How does this company make money?
- 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.
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 withheld 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.
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.
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.
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.