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 dev.liferay.com, 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.

Questions

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, Salesforce.com, Endeca). With Liferay 7, it's even easier thanks to modularity and OSGi. For databases, check out https://issues.liferay.com/browse/LPS-61156 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 https://issues.liferay.com/browse/LPS-61123). 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).