Liferay Portal 7 CE - App Server, Database & Clustering Support

Today I’d like to let you know that Liferay Portal 7 Community does not have "out of the box" support for clustering, non-open source app servers (Oracle WebLogic, IBM WebSphere), and non-open source databases (Oracle Database, Microsoft SQL Server, IBM DB2, Sybase DB). Support for these non-open source systems will be found in Liferay's current and future commercial releases, which are available by Subscription, or you can develop your own OSGi module independently to support these features.

It’s a huge decision and we think it may raise concerns from some community members, so we want to be upfront and explain our thinking. Why are we doing this?

With this decision, we hope to maximize the success people have with Liferay in production.

Here’s an outline of a common situation that leads to a bad Liferay experience for companies:

  • A systems integrator (SI) hired by a company to build a solution makes a proposal that includes Liferay CE. The SI provides an all-inclusive service including new development, configuration and customization of Liferay, deployment, and support of the solution.

  • The solution proposed is built on Liferay CE, but the SI makes no mention of Liferay or our subscription offering. This prevents the company from knowing they can have a formal relationship with Liferay as the software vendor.

  • The SI sometimes does many things that lead to a poor experience, including:

    • re-implement features from scratch because they haven’t invested enough time into deeply understanding what’s available out of the box with Liferay. This makes their customers (who aren’t familiar with Liferay) pay the SI more than they need to for the solution. It also means those custom features may not work as well with the rest of the Liferay platform.

    • charge their customers for one-off support and maintenance of the project. SIs don’t have the same scale of customers that Liferay does, they don’t have as many fixes, and the support costs they charge their customer aren’t shared across multiple installations. So those companies pay more for less coverage of defects and improvements.

    • implement Liferay with non-standard practices or customize the code in non-standard ways, leading to unstable projects and a poor experience. This also makes it difficult or impossible to use standard apps from the Marketplace and to upgrade.

The net effect is that many companies have a bad experience with Liferay, and this hurts the Liferay eco-system: our community, partners, and our company. These companies usually don’t know that having a Liferay subscription is an option; they don’t know that the SIs aren’t following best practices; and they don’t know about all the standard features they’re missing out on. We think companies should have the chance to consider a relationship with the Liferay eco-system and make an informed decision whether they will use our community or commercial offerings. So by removing the compatibility and features that are essential for business-critical deployments, we are (in a brute force sort of way) making companies aware that a better option (for most) is available.

Now, when discussing this decision internally, some of us at Liferay rightly raised that this might be an annoyance to the community who now have to go build their own modules, and that SIs will just build their own connectors anyway to the goal wouldn’t be achieved. Meanwhile, we may lose potential community members, for example non-profit organizations that received Oracle licenses for free but want to use Liferay open source. Companies who would have tried Liferay Community on their proprietary infrastructure for a POC and then contacted sales later, now may never do so.

Those supporting the change said there isn’t enough incentive for these SIs to become contributing community members. Taking out commercial infrastructure and clustering support is one step in encouraging the SIs learn how to develop Liferay modules. They also feel that companies who can afford integrator services and proprietary infrastructure should pay for Liferay. Not doing more to monetize these companies is a disservice to the hard work of our community.

While we can’t know with certainty whether the net effect will be negative or positive, we’d like to go forward with the change and bring about a conversation. We want to understand who uses Liferay Portal Community on proprietary infrastructure without taking the Subscription. As they share their stories, we’ll better understand their needs and evolve our mix of free and commercial technologies and services to better meet the needs of all our users.

Of course we also want to see whether this decision does indeed help more companies to know our Enterprise subscription exists and to take an informed decision on engaging with Liferay.

I’m sure some of you will disagree with this change, whether for idealistic (FOSS) or pragmatic reasons (I can’t afford a Subscription). I know this isn’t the ideal solution for the problem. And you may feel that Liferay is unjustly burdening the community with our business issues.

So we want to do as much as we can to limit the effects of this change only to those who aren’t giving back. If you’ve been an active member of our community, or you really have a constrained budget but need to use Liferay with proprietary software, or you’re an existing customer putting together a POC for your upgrade, we can make exceptions and provide connectors privately.

One of my team members, who is very passionate about Liferay and about the community, voiced his disagreement, saying, “we (Liferay) are increasing our sales. I mean, I could understand these decisions if Liferay is going down.”

And it’s true that Liferay is profitable and increasing our sales, but to me it’s also a matter of principle. I want Liferay (the community and company) to decide how to distribute value from what we’ve built, not a random third party. Sure, it’s great that some companies are getting good open source software, and that SIs are getting a lot of value out of our software, but we should have some influence on the allocation of that value.

I also want to invest more back into Liferay. In 2010, we were very worried about how changing the license from MIT to LGPL would impact the community. That decision had its share of dissenters and supporters, both among our employees and in the community once it was announced. But what we heard more than anything else was that people wanted Liferay to invest more in our community. Pay attention to our contributions. Moderate our forums. Give us a way to vote on features.

We’ve responded to those requests, and there’s more we want to do. Our Community Manager Emeritus James Falkner launched programs like the BugSquad, Liferay Ideas, Community Expedition, Top Contributors, Community Pulse Awards, Official User Groups, and Community Verifiers.

We also launched our Marketplace, which now has over 512 Apps, 1,500 Registered Developers, 482,896 Downloads, and has allowed community members to sell their Apps and get recognition for their work.

From DevCon and Symposiums around the world, to our documentation team and, to more open source projects like AlloyEditor and Metal.js, we are taking seriously our commitment to invest our success back in our community, and excited to do much more. Unlike other open source companies, we have zero outside investors to answer to, so we can invest in our community on our own terms.

What’s next?

Like I said, we want this to be a conversation. So if you’ll trust us with this decision, we’ll continue to do our best to understand your needs, see how the market responds, and make adjustments as necessary.

Meanwhile, we have a lot of ideas in the works for the Liferay community. We are already looking for a new Community Manager to replace James Falkner (feel free to apply—job posting here), and we’re establishing a new Community Action Team to provide additional support to the Community Manager. We’d like to establish a formal onboarding process to help new community members get up to speed quickly. And we’ve been working with Bitergia to understand where our community needs more attention.

With Liferay Portal 7 Community now available, I hope you will see that your investment and dedication to Liferay is worthwhile. I look forward to hearing your thoughts.



If it's pluggable, can I plug in my own implementation in CE?

Yes! Indeed, it is possible to provide "DIY" support for clustering and your commercial infrastructure (or any other database/app server/clustering technology). People have been doing this for years for other systems (think Siebel,, Endeca). With Liferay 7, it's even easier thanks to modularity and OSGi. For databases, check out which extracts FOSS support into modules, and implement your own in this pattern. For app servers, check out the DeploymentExtension class, and implement your own subclass for your chosen app server.


Tell me more about clustering?

Although it is technically possible to cluster previous versions of Liferay CE (like 6.2), it has always suffered from scalability problems because its cache replication technique is not tuned at all, and it is up to you to tune it (and support it) for CE. So it wasn't that useful out of the box, and most people that used it were doing so through an enterprise subscription anyway (which included plugins to enhance clustering and support for configuration of a cluster). Clustering has been modularized and abstracted in 7, and now the "out of the box" distribution includes a boilerplate implementation module provided (via If you need scalable, highly available Liferay because you are supporting thousands or hundreds of thousands of users, and your business or state depends on it, you will need to implement this (along with the other clustering configuration that you've always needed to do for your database, app server, load balancer, document store, etc).

I think this is a good thing. We've worked with customers in the past that do not wish to pay for Liferay EE. So they go for Liferay CE (because it's free) and ask us to make some customizations. And then the first bugs appear. Most of them are already issued in Liferay's own JIRA, but we have to fix them anyway because there is no official support. After a while, the customer notices all those shiny new functionalities in the next version, so they ask us to upgrade to the latest version. More problems, still no support.

Bottom line is, the customer pays us for problems in the Liferay platform and they're stuck in a solution that turns into an unmaintainable mess that cannot be migrated any more. So it doesn't take long for the customer to abandon Liferay and look for the next best thing. And from there on, they're associating Liferay with a buggy product.

I just hope this decision will finally make Liferay CE a no-go for actual companies that want to build a proper solution on top of Liferay. I, for one, won't cry if those companies consider another product rather than going for an EE subscription. Even if it means we're making less money.
I am fine with this strategy. If you can afford Websphere it seems reasonable that you consider Liferay EE. As a large customer building business critical applications it never occurred to us consider CE in spite of our love and use of open source frequently in our IT architecture (we replaced WAS with Tomcat). From a practical standpoint we felt the portal piece of the infrastructure just had to be supported.
If a they can pay for Oracle/Microsoft/IBM products, they also can (should) pay for Support (Subscription).
Non-commercial communities need clusterring ! (especially if they have already built their tools on top of liferay portal).
Hi Bryan,

It looks like the primary concern is the reputation that is at stake. The step that you have taken may partially solve that problem.

You need partners and systems integrators that are rated based on a combination of revenue and best customer service/implementation. The awards are great but still it is a tough vetting process for a lot of customers to find the right partner.

As you may know, a successful project implementation requires various components and what do you trying to do may be the first step towards it.

All the best!
I think Liferay will be hurt, the company will be hurt. You know the Community is the foundation of Liferay.
It's going to hurt just for a short while. Peter actually explained it very well and although I'm one of those concerned with the fact that I cannot immediately move to Version 7 because I've built everything on Liferay 6 with MSSQL support, I did plan in the future to move to EE to get support and stable version of Liferay. Open source is free, sure but in the long run it does come at a quite pricey solution when you really think about it. From what I know they are still supporting the major and most popular Open Source database which can easily be converted to MSSQL or Oracle after the move to EE, this means the community can keep on supporting and contributing to Liferay the very same way they did before. Furthermore, have you tried to get support for Microsoft SharePoint? If you pay the support they offer, I can tell you that it will not even be close to what Liferay can offer in term of support and I know this for a fact I worked for Microsoft in the support team for Business Applications and left because I felt I was being useless to customers -not because I don't know what I'm doing, I'm a Microsoft Expert and yet I choose Liferay. I could do lots with SharePoint but that would also means lots of work and time that can be spent more intelligibly.
It makes economic sense for LR to remove "out of the box" support for non-open source app servers (Oracle WebLogic, IBM WebSphere), and non-open source databases (Oracle Database, Microsoft SQL Server, IBM DB2, Sybase Demoticon. However, I think that "out of the box" support for clustering should NOT have been removed from the CE. This will render CE practically production useless for any meaningful low budget deployment with open source databases like MariaDB and Postgres as well as app servers like tomcat and jboss. This will likely hurt the widespread adoption of Liferay as a certain class of SI will likely drop Liferay and go for other frameworks (including non-java like odoo). This move will make Liferay less attractive for low budget organizations which are potential sources of future commercial subscriptions. I strongly suggest that a reasonable "out-of-the-box" clustering support be maintained in the CE.
On the contrary, the "low budget organizations" would likely never step up to EE and would not be "potential sources of future commercial subscriptions".

As Bryan points out, there's now a path to EE through contributions, so the "low budget organizations" would only need to contribute something back to the platform.

So they're not being totally shut out from getting onboard the Liferay train...
Hi Pius, can you tell us more about yourself? What geography are you in? What's your role? Do you work for an integrator? What kinds of solutions do you consider Liferay for? What are your thoughts on the value of the Enterprise Subscription?
I am presently working in price sensitive markets in Africa but with growth potential
Thanks for the info, Pius. I think if you reach out to Job Ndagi Goshi in our Morocco office he could get a deeper sense for the market dynamics you see on the ground and we can figure out better offerings that are appropriate for Africa. What do you think?
I'll reach out to him as suggested.
Meanwhile, an important point to keep in mind is the fact that some Solutions Providers/Systems Integrators like myself prefer to work with the same version that will be deployed for clients. As far as I know, there is no developer friendly license for Liferay EE hence the resort to Liferay CE. As I always test my solutions in a clustered environment, removing that feature from CE practically renders it useless for production, out-of-the-box. A way out in my opinion is that Liferay introduces Liferay EE Developer License, distinct from Enterprise License. In this way, Liferay will likely not scare away third party Solutions Providers/Systems Integrators.
Pius, there's the EE Trial, which is in effect a developer license. You can always use that—or is there something about it that doesn't meet your needs?
EE Trial license is for 30 days. Third party developers should not be subjected to such limits. Their clients will eventually pay for their respective licenses.
Hi Pius,

If your customer has an active subscription, then their third-party contractors are entitled to use developer licenses on their behalf. Hope this clarifies things.
Hi Pius, what's the scenario for when a project is business-critical enough that you need clustering (to avoid downtime) but not business-critical to be worth getting support for? That's the reasoning we came up with for tying clustering to the Subscription—if it's important enough to have failover, it should be supported.
you completely ingnored non-profit organizations and social activities. so it is absolutely necessary to include clustering in CE.
yes business is important but there are others that already implemented liferay for non-business activities.
Hi N H,

I understand. If you reach out to us, we can learn more about your NPO, and either offer you a module for clustering or possibly even help you with a Subscription that is more affordable.
Hi Bryan and thanks for your kind attention.
I'm working for a NPO, developing a collaboration and publishing system using Liferay 6.2. It is used internally (no public web site).
As we are using DDL extensively, I contribute in liferay by extnding and bug fixing this module. (There are items in the liferay issue system)
I really do not like to make a personal request. But by cutting clusterig from CE version, you will definitly lose communities that use liferay in real scenarios. It seems liferay already has enough benefits from community and know it becomes MORE CLOSE step by step. Thanks
Hi NH, I understand your concern. Our goal definitely isn't to become closed. We absolutely appreciate your contributions to the community. Is your user name the same in our JIRA system? Can you tell us more about the NPO you are supporting? Does it have a website?
HI Bryan
My username in jira is nadih nadi H.
You might see : LPS-45354, LPS-50113
And a few helps in searching within DDL and velocity templates.
It is now about 2 years that I work to build a rich collaboration system, using new Liferay (SPA, and OSGI are two main features that makes liferay 7 much more interesting). I'm designing a "RAD toolset" for collaboration systems for teams that use liferay for internal use cases (no public web site, but very dynamic needs.). A uniform system for any community method : ISDN, SMS, EMail, Internal Messages, ALerts, ...
It was liferay 4.0 when I built my first web app! It's nice and powerfull. Please do not drop features that force communities like us to immigrate to a new platform.
Hi Nadih, I can see the two issues you contributed to our issues list. Thank you for that, it's definitely helpful.

I wonder, if you could provide any more information about the non-profit you're working with? What kind of work do they do? Is there a website (even if it's not on Liferay)? The RAD toolset sounds very interesting—can you provide screenshots or a video?
Pius, as Bryan said, I would be happy to chat with you to think through your thoughts on how to better serve in Africa.
Hi to all.
I was upset, so I engaged a bit and put the support for Oracle DB. The next challenge is the Cluster.
Few days ago I published the project to add support to Oracle DB in Liferay 7 CE GA1. You can read the details of this article Liferay 7 CE: How to add support for Oracle DB (

I hope you find it useful.
Hi Antonio, that's great! I am totally excited to see that you were able to solve this problem easily.

Did the new modular architecture make it easier than usual to create?

In any case, I can see you're friends with guys like Luca Borghesio and Denis Signoretto, who we are very close to, so I imagine you're helping build the Liferay community in Italy. Please continue to contribute a lot!
As one of those systems integrators deploying Liferay portals sometimes, I've always recommended buying the enterprise edition ever since it existed. Several years of difficult upgrades with one customer who uses oracle and predates Liferay ee still hasn't convinced them to do it though. This should make them buy something, but knowing the customer it might be SharePoint. It doesn't matter much to me what customers choose after I make my recommendations, but I'll be glad not to have to support Liferay CE in the future.
Hi SB, what market do you work in and how big is your typical customer?

It's not a good thing that you feel that Liferay CE is hard to support. We do expect it to be functional and provide value in smaller deployments.
We have been a partner of Liferay for almost 4 years now and been working with the technology for close to 9 years. Here is our take on this

1. It is a welcome and a natural step. Some of the points made by Bryan are actually coming out of experience of failed implementations of Liferay. Most of the leads we get are with some kind of crisis with CE implementations gone horribly wrong and the previous SI has either stopped supporting or tacitly communicated they are not able to (off course dividing blame on open source and Liferay confusingly )

2. It's also important that large customers interested in open source do not look at it with just a free alternative but a quality alternative to proprietary software. This automatically means that the value to be paid for the software is a question that needs their attention more than ever now.

3. I have seen hardly any CE customer switch to a paid version easily. Most of the time the question is posed in the backdrop of a suspended and gone wrong CE implementation and most business stakeholders then do not understand why they should continue further.

4. Most damage towards a production grade CE implementation is done by IT managers who know they can go few easy steps ahead with CE and almost train their business decision makers not to move to EE. Most of them rarely contribute to the ecosystem. Even within the SI space this practice is rampant where partial responsibility to run a production grade implementation is taken and then abandoned mid way when the solution is successful and complex at the same time.

5. Clustering and other features should be left untouched in CE though as making it not look like a production system may make it difficult for The ecosystem to attract right and paying customers.

The challenge will emerge after this step. Liferay ecosystem will need a good vetting of partners with closer understanding of how open source. In countries such as India it is still very misunderstood. The branding and marketing messages around this move have to spread out down the line with crisp clear arguments.

Ultimately if Liferay improves as software in quality and features and at the same time does not take too hard a stand firewalling EE from CE my view is this will click.

Shubham Nagar
InfoAxon Technologies
Hi Shubham,

Thanks for sharing your thoughts. Regarding clustering in CE, I asked the question to Pius as well, but what's the scenario for a customer using CE with clustering. If it's more for a proof of concept, could they use the EE Trial? What we find is that if the project is started on CE, it's very difficult to migrate to the Subscription—and it sounds like you agree (point 3 above).
I've been working with liferay for years, i think the main problem is related to Clustering. The thing is, every production environment from the smallest to the greatest needs at least a cluster of 2 instances. This means that little companies,who doesn't have budget to buy a license for EE,and wants to use liferay as intranet or cms cannot configure its production environment because the liferay 7 version does not support it.
I agree to migrate some jdbc drivers to the EE because if you have budget to buy Oracle license you must have budget to buy liferay license. I do not agree for clustering because this situation will lead developers create their own clustering osgi modules. So the community probably will continue to use CE with "custom" modules for clustering. I think this is the scenario Bryan wants to avoid, but this decision is pointing directly to that direction. The hard part of success is to stay as you was at the beginning. Liferay WAS designed for NO PROFIT companies, now is BUSINESS. So Bryan please, be honest with the community that has supported liferay for many years. If liferay reached this success is thank to the orignal approach.

Stay as you were.

I totally agree with those who are saying that this is not the best way.

Stay as you were

Francesco, Aristide, I don't know if we've ever met at the Italy Symposiums. If not, please introduce yourselves to me next time. Do you have photos you can upload to your profiles? It'd be nice to see the faces behind the comments here on this thread—it helps to remind us that we are talking person to person.

If you haven't ever attended our Symposiums, let me know. I'd be happy to give you a discount to our next event.

Do you use Liferay for non-profit organizations? If so, please do tell us more about them.

If you use Liferay commercially, I understand you might be in a tough situation. One group we considered when we took this decision was actually integrators that work in countries like Italy, where project budgets might be a little tighter. Maybe you used to use Basic or Limited and now that's not an option. Or maybe you've always used Liferay CE and are doing projects for customers with really low rates for man days. I totally understand that you're an audience that's under-served by this decision. So in order to serve you better, we really need to understand your situation better. Why are your clients not able to afford an Enterprise Subscription? What would be their alternatives if not Liferay CE with clustering? What price would they be willing to pay? How do they currently get maintenance and support, and how much do they pay for that?

It's hard for us to make an offering for a customer we don't understand, so please help us get to know your situation better.
Hi Bryan, i've been attending liferay symposium for years (4) and i'll be doing it in the next years.
I'm even trying to contribute on market place with IoT and Big Data free plugin.
Personally i didn't contribute on bugs but i've introduced liferay to a lot of people and companies that still use it.
It's clear that your point of view it's on economic side, but my point is different, i think it doesn't matter if the customer is big or small or how man days or money it can spend.
The main problem for me it's related only to clustering not other functionalities.
Basicly you are saying that if i have i little or big customer for who CE functionalities may fit good, but i want to install a cluster,may be not just for users problems, but for avoiding a single point of failure, i can't do that.
For my point of view (technical), in this way CE can be used only for development purpose, not in production because it doesn't meet the basic requirements for a production environment. You could add on market place a clustering plugin for CE and set a price for it, it would be ok. I think that with this approach you are missing all customer whose needs fit the CE functionalities, but for production environments they need for clustering .
Personally i don't want a customer pays EE just because it's a huge company , if i can deliver the 100% of its requirements with CE i will do it,i must do it ,for professional ethic. Hope it's clear.
We cannot use EE where CE fits good, and we cannot use EE just for clustering.

If you want to know more about which kind of customers i'm referring to, i would be very glad to talk to you:

I am trying to follow the logic here....Your SI's are the problem but in spite of that your sales of EE is increasing. So the "solution" is to remove a needed feature from the Community Edition to force more people to go to EE. Sounds more like greed than need in my humble opinion.
You can solve your SI issue through sharing more information not only about who CE users should gravitate to, but also sharing more information about fixes and correct implementation. We are currently planning on moving to 7.0 and having given some thought to signing up for EE and paying (way too much IMHO) for that privilege. But I am going to rethink that and recommend to my manager that perhaps we shouldn't get in bed with a company that removes options under the guise of solving an SI problem. Maybe we sign up for EE and then the LR team decides that other components, which might have been part of EE are now "additional features".
This move says way more about LR as a company than it does about technology. I am worried about what will be the next "fee based 'extra'" even if we go to EE.
We are on 6.0.6 CE with about 200,000 users in the database and about a half a million potential users worldwide. We are a non-profit and 6.0.6 has worked quite well for us. But this whole thing now has me concerned about real focus of LR as a company. Are you interested in OSS and the community, or just the money?
Hi Pete, yes, you're right, the main problem we're trying to solve is SIs who use Liferay Community for commercial / enterprise projects. I wouldn't say we're forcing people to go to EE, but to get people to choose the offering that's fit for their purpose: community for community projects and enterprise for enterprise.

It's always a risk to invest time and energy into a relationship with a technology (and the vendor or community behind it), so I understand your trepidation after this decision, but if you've been in relationship with Liferay for a while, I think you'll see that we carefully consider our decisions and try do what's right by the company, customers, and community.

Whether we are being greedy... you could look at our books and see how Liferay operates and you might still think we're greedy, or you might change your mind. We certainly don't want to be greedy. If we really wanted to maximize personal financial gain, we could have taken outside investment years ago and made many more profit-focused decisions, but that's not the company we want to be. We're in this for the benefit of multiple parties, and free users of our software are included in that.

As for your concern about Liferay's focus as a company, I don't think it's binary. We're interested in all of it: building a great community, and making great open source software available to people, but also building a successful company, and using that success to provide jobs all over the world and to serve non-profits as well both financially and through service. I personally believe more companies should use their for-profit position and success to make a positive impact in the world, and to do that you have to have a certain measure of financial means.

Finally, I mentioned before that we are happy to make special cases for worthwhile non-profit organizations. And if you're an outstanding contributing community member that merits special treatment as well. Have you made contributions or bug reports to our project? If so, let me know your ID on JIRA or Git / SVN and we'd be happy to talk to you more.
Thanks. So, it isn't in my profile but "reactive" is my middle name. I might have been a bit strident. But here is another example of the immpact of *removing* features for non-technical reasons: Lets say that FreeMarker, or Apache, or Oracle, or any of the other organizations that LifeRay currently integrates into the solution or the IDE decides to make a feature fee-based, for whatever reason. Would the LR folks almost immediately look for an open and free alternative? That is the position you are putting a CE user into. Let's hope that your partners in the OSS world don't adopt your approach! IOW. I appreciate your careful review of the possible outcomes but put the shoe on the other foot as an OSS consumer: If other organizations follow the pattern, what would that do to the OSS movement?
As for only rewarding those who have enough skill to contribute, that again doesn't serve the broader community. I have posted to forums and I do promote LR as an OSS platform but I am not a competent enough Java programmer to fix bugs or contribute plugins, yet.
I am thankful for what Antonio Musarra has done with his SPI solution and for sharing it. I wish I had his skill set because I would contribute here more. Thanks Antonio!
Hi Pete,

You bring up good points and I will start by saying that we do see the virtue long-term of adding more value to our subscription rather than necessarily removing things from our open source edition. Philosophically I'm in line with what you're saying even if our decision in this specific instance wasn't.

In some cases, we do negotiate commercial agreements with commercial open source vendors to give customers the option of having a commercially supported set of products. For example, we have an agreement with ElasticSearch and we've had maintenance and support options for Tomcat from various providers. You're right that it might put us in a spot if an open source library's features were suddenly made fee-based, and we might migrate to something else or we might negotiate an agreement with the vendor. As a fellow open source vendor, I might not like the outcome but I *think* I'd try at least to empathize with a company going through the trial and error process of sorting out the right balance of business model and community.

You're right that the OSS movement would suffer from *too much* of the sort of thing that we've done, but OSS also benefits from the fact that vendors like us are able to stay commercially viable. Big contributors to open source—IBM, Red Hat, Google, Facebook—can contribute because they sell proprietary software, or ads, or our personal data. emoticon Liferay happens to have a commercial open source model, so we have fewer levers to pull to strike the right balance that does the maximum of good across all our audiences. We might not have it perfect at the moment, but we'll do our best to get there. And meanwhile we're able to produce other interesting OSS, like,,, in addition to all the core Liferay stuff.

Regarding contributions, yes, we realize that 90% of community members won't be able to contribute, especially code. But you can also answer questions, provide translations, report bugs, host user groups, or even just write a great case study and tell the world about Liferay.

Finally—I realize this doesn't change the open source philosophical aspects of the conversation, but—I don't know if you were part of those discussions, but my understanding was that our sales team was to offer complimentary EE access for your non-profit organization when you reached out to us a few years ago. I'm not sure if that went through, and you still opted for CE, or perhaps there was a communication breakdown and the offer wasn't made?
Today, I wanted to give Liferay 7 CE a try and installed it on a new hardware and prepared to upgrade my existing 6.2 Database. I received the error message "java.lang.IllegalArgumentException: Unsupported database type sqlserver". I tried to use different drivers and configs but then I figured out, it is because you removed the support for the SQL Server, forcing everybody who wants to use it to buy the EE License.

Unfortunately we are a small government department using Liferay just for internal purposes, as an intranet, but our business relies on it, because we got used to it during the last past years. The Enterprise License, including the goverment discount, is 19.000 EUR per year which is more expensive than any other software we are using, including the SQL Server license, which btw. we are using for many other softwares that need to store data. Unfortunately there is no other licening model than the 20K/Year one and this is for companies like us WAY to expensive.

Now you are dropping us out, with reasons like low quality we would get from SIs and high prices we had to pay for the SIs, but the fact is: I was the SI. There was no reason for my company to use the EE version for 20K. We could manage everything on our own, the quality was good and the price was cheap, because I get paid anyway.
Now you started to remove necessary features from the CE version, so nobody can use this product any more without buying your EE license and this just sucks so much! You should have offered some "real" value to the EE version insted of cutting it from the CE one.
I expect more complains like this to emerge. LR should have gone the way of SaaS as a paid alternative to both their EE and CE versions instead of depleting CE. I think that there is something to learn from the likes of
Hi Martin, I totally understand your point and we will try to do more in the future to add to EE and not take from CE.

Help me understand a few things:

1) Which geography are you in?
2) What do you get from paying for SQL Server vs. using MySQL or MariaDB (either open source or commercial)?
3) Did Microsoft give you promotional pricing since you're a government body or are you talking about their retail price? Or was SQL Server perhaps priced as part of an overall stack of Microsoft technologies?

Meanwhile have you checked out Antonio's SQL server compatibility module?
Hi Bryan,
thank you for your reply.

My company is located in Germany. We have SQL Servers because we need them for some software that cannot run on MYSQL or other database servers. Mainly specialised software developed with .NET. My company highly depends on a Microsoft infrastructure. Therefore we have administrators who know how to configure and backup SQL Databases and everything else about M$ networks. We need Liferay to run on the SQL Server because we already have the knowledge and the infrastructure. The licences for the SQL Server we got together with many other Microsoft products and they were cheap, because Microsoft supports small businesses and also governments and connected departments like us. I think you cannot assume that everybody who is running a sql server has enough money (or is willing) to buy a Liferay EE licence.

For my company this is mainly a question about the money. We are willing to pay for Enterprise features like clustering, quickly available security patches and bug fixes for a reasonable price.
Because right now, 6.2, the CE version is already almost impossible to use in productive environments. You do not need to take more functionality from it to make it even worse. The release cycle is too long and upcoming problems are only fixed for the newest versions, so software developers like me have to fix these bugs themselfs, merging code from your trunk to their "own" stable releases and this is one cause for the mess that happens to these CE production systems.

I think these problems could be avoided if you offered a more dynamic licening model, like user based, or features based or what so ever, so everybody could decide for what he wants to pay the money for.
- Someone does not need a 24/7 SLA with remote support, but he would like to get frequent security updates.
- Someone else might want to buy the clustering feature
- Someone might want his bug reports being addressed properly, which btw. is a joke like it is handled right now, in CE. When you open a bug report for 6.2 CE and nobody is looking at it for 6 month and then you receive an email, telling you your bug for 6.2 has been closed, it is obsolete because they are planning to do everything better in 7.x, but there is not even an offical release date for it. These are things that make CE a mess.

And not only bug reports. Also fixes from the community. Look at this:
I fixed the bug and published the solution for 6.2.0-GA1 on your jira. Enterprise customers got a fix only 2 month later, but everybody else, including myself, had to wait until 7.0 M3. This was the work from the community. I found it and I fixed it. Why does the rest of the community does not get access to my fix?

So, Bryan, I hope you see, the way it works right now, CE and EE, the community model, the licening model, the space in between. I think there is much to improve..

Preventing non-paying customers from getting fixes quickly and reliably is the main reason making their systems a mess and in the end they will blame your product.
But this is neither the customers fault nor the developers. This is your model of how thing should work.
Right now this model is black and white and has a little bit, just enough, of grey in between, but once you start tighten it up you will remove this little grey part. But I think it should rather be as wide as possbile. Get everybody in the boat first with a well maintained community product running stable all the time and offer some additional enterprise features or services for already satisfied customers instead of forcing them to pay money by making their versions more and more unstable.

Just my 5 cents

Hi Martin,

Sorry for the long delay in replying and thanks for investing in this conversation.

I think basically you're the kind of person and organization that gets shut out by this new model, and I'm sorry that we don't yet have a better offering that fits your situation. What I mean is, our decision around clustering is really to address the specific issue of larger companies whose SIs are mis-directing them to use CE with their support instead of ours. Removing clustering is one lever we have to bring them to the negotiating table. But groups like yours, who aren't in that "enterprise" market segment, are caught in the "cross-fire."

As you pointed out, ideally there would be a commercial offering that fits your budget that offers our updates and fixes but doesn't necessarily have 24/7 support. (Though even that situation can lead to a poor end-customer experience depending on the skill of the in-house Liferay developers). We wanted to go down that path with Liferay Connected Services (LCS). We assumed that a lot of CE users would use it to install security updates and other patches without requiring support. But the uptake of that offering wasn't very high on the community side (see my recent blog post). So we're going back to the drawing board to try to devise that more affordable offering. If you'd like to give your input on what that would look like (both in terms of pricing and what's offered) feel free to email me privately.

The other option would be that you'd use CE and be able to fully support the solution yourself (including issue resolution and patching / fixing bugs), but you're also currently hindered in that because the process for reviewing and incorporating contributions into CE is bureaucratic at best / broken at worst. I mentioned in my latest blog post that we are soon going to announce changes to community management, and some of that will seek to address the contribution process. That's what I can give you for now, and I only hope you can stay part of the conversation so we can better meet your needs.

I don't know if you have a specific timeline for wanting to upgrade to Liferay Portal 7 Community, or if there are specific features of 7 you want to take advantage of. Understanding that could also help us.