Open Source Business: Liferay

Today I wish to introduce a new blog category to share stories about how companies backing open source projects make business. To inaugurate the new Open Source Business category I spoke with Bryan Cheung, Liferay’s cofounder and actual CEO, one of the founders serving with the company since its inception in 2004. Here’s our conversation.

Bryan, can you tell us more about how you develop your project into a successful product?

There are two parts to this answer: the first is about Liferay the software, and the second is about what we sell—our subscription.

For Liferay the software, we evolved from a very agile approach to one where we can balance agility with long-term stability.

In the early days, Brian Chan was the main developer of the project and he decided what got built. Back then (early 2000s) knowing what to build was easier because there was a standard for portlet containers (JSR-168), so Brian just made sure Liferay fulfilled that. In the coming years, certain architectures became convention (Hibernate – Struts – EJB, later replaced by Spring) and Liferay adopted those as well.

As the community grew, so did the number of people who had an opinion on how the product should evolve. As early as 2002, people wanted to supplement Liferay’s portal core with web content management and collaboration capabilities. Forum software packages like Ultimate Bulletin Board were very popular back then, but most were written in PHP, so Liferay added message boards and became a good Java alternative. We also saw a shift from the manual HTML-coding of the early web to WCM systems that allowed non-developers to author content separately from its layout and display. In fact, many of our WCM requirements were driven by Jorge Ferrer, an early community member (and now our VP of Global Engineering), who was using Liferay to build a learning management system for the City of Madrid School System (after a failed attempt to do it with a well-known proprietary portal product which I won’t name).

In those years the common thread was that it was mostly developers, working on projects for their organizations, who defined requirements and worked with Brian to build them. But over time, we had customers lend their voices to the mix as well, which took the product in new directions because their requirements reflected deeper business needs or the specific demands of enterprise IT. For example, Goodwill Industries, a major non-profit organization in the US with nearly $3 billion in assets under their management, had specialized requirements around how to represent their organizational hierarchy and generate sites for the groups in it. This is how Liferay’s Organizations and Communities were born. Another major customer wanted a better interface for managing multiple portal sites running in production, which led to the development of our Control Panel.

In the early days, one of the great advantages of working with Liferay was that Brian Chan knew the code inside and out (and still does), which meant he could re-factor the whole codebase over a weekend. So if the portal needed to support a new feature required by a user, it would be a very quick change to make. Over time, however, this became untenable because customers needed to rely on architectural stability to make upgrades easier and ensure customizations were compatible with future versions.

So we developed a plug-in architecture that separates add-on functionality from the core platform. It’s even designed to accommodate customizations of the core platform, which means you get a high level of flexibility with minimal risk to upgradeability and maintainability. It gives you the open-slate possibilities we love about open source, without leading you down a path of no return in terms of your codebase customizations.

So where are we today? With the richness of the Liferay platform as it stands in 2012, we realized the need for a formal Product Management group to gather up all the great ideas we get from community members, customers, and our internal staff, think through them and organize them into a cohesive whole. They’ll also be looking for new ways to extend Liferay in ways people might not naturally consider, things that they see out in the market or discover through R&D. We are still staying agile—so much so, in fact, that our VP of Product Management, who is from Los Angeles, is moving to Madrid to sit directly with our VP of Engineering, so they can rapidly cycle through feature iterations—but with formal product management we see the greater possibility now of really digging deep into the possibilities Liferay has to offer.

Perhaps most important is the mandate I gave to our team: we must create features that solve problems so deeply felt by our users that they make a deep emotional connection to our product. Liferay has been successful at creating a platform for building many different solutions, which developers then use to build solutions for people. But in this situation, the users don’t see Liferay; they see the partner or the IT team that built the solution as the ones who have made their lives better. We want to get closer to the problems our end users face, the ones that cause them real frustration during their work day, and get users to say, I love what Liferay does for me.

How did you offering change over time, and what did you learn during the process?

Now, that was just the first part of the answer! Regarding our second product, which is the Liferay Enterprise Subscription, this was an interesting road as well. We started out simply providing support for Liferay, which was almost like selling insurance. We had two offerings. One was a developer support option, which was priced ridiculously cheap at something like $16,000 for six months for unlimited questions—80% of which ended up not even being about Liferay but rather about CSS or ESBs or some other ancillary technology. That was very popular.

The other was Production Support, which allowed customers to call or email us if they ran into issues running Liferay in production. Now there were two problems with that offering. The first was that people figured they would just purchase Support when they needed it—when a problem came up. Understandable, but didn’t make a good business model for us. The second—and this was more important, because it meant we weren’t providing the right value to the customer—was that our support offering didn’t meet enterprise needs. Here’s what I mean.

Back then there was always one continuously evolving branch of Liferay, and new features, bug fixes, performance updates all got mixed up in the same branch. So when people had bugs or issues, the answer was always the same—upgrade to the latest version. If you were on 3.6.1 and experienced a problem with single-sign on, and Liferay had fixed it in 4.0, you had to switch to 4.0. Our support folks would tell you that, and they might even point you to the JIRA ticket that mentioned it and show you how to build a patch, but the recommended path was to upgrade.

Being a small, nimble organization, we didn’t realize at first that that wouldn’t sit well with enterprise customers. Over time, the light bulb went off and we introduced the Enterprise Edition of Liferay, which basically provided what we never had before: long-term maintenance updates of Liferay that would not add new features (and therefore instability)—only bug fixes, performance enhancements, and security fixes. Not only that, we would pro-actively create new Service Packs for our customers, and we would have a library of Fix Packs for known isolated issues that customers could apply to production instances of Liferay. This was a much more enterprise-friendly approach to software and the results have been phenomenal for us.

When I look back, I think the things that drove our success were 1) some level of foolishness—we all lacked enterprise software industry experience, which made us hungry to keep trying new things, make mistakes (and some lucky right decisions), and consistently improve over time—and 2) listening to our users (which relates to #1 because, in the absence of wisdom we found it easier to listen to the recommendations from the community). People these days are very much into the model of product management called Customer Development (formalized by Steve Blank) and driving toward Product-Market Fit. By making frequent releases and evolving toward our users’ needs, I think that’s what we did, even though we didn’t know that’s what we were doing.

Plug-in creators seem first class citizen in your community, how do you help them?

Having grown up in the US we all grew up with the mythos of opportunity and entrepreneurship that you could say are the core identity of American culture. We’ve experienced that for ourselves in starting and building Liferay as a company, but what really kind of made our jaws drop was when we saw what Apple was able to achieve with the iOS platform. To me, this is Apple’s greatest achievement—more so than the stunning design pieces they sell as computers. They made it possible for anyone with a laptop, 99 bucks (for the Apple SDK) and a PDF reader to become a millionaire selling iPhone apps. I remember thinking as a kid, “There are 270 million people in America. If I could get just one penny from each person, I would be a 2.7 millionaire. If I could get a dollar, boy I’d be rich.” Well, that’s more or less what Apple has made possible—for all of us.

Of course, we believe open source is its own reward and that community participation is about maximizing what we at Liferay call “Return on Giving”—when we give away our software for free, that gift returns back to us in the form of improvements, bug fixes and everything else our community gives in return. Likewise for our customers: when they sponsor a feature to be developed and release the IP back to Liferay, they will get much more on top of that once the community takes that feature and runs with it. It will end up being more rich and robust than if they had kept it behind their corporate firewall.

Well, that’s all fine and good, but at the end of the day, free software doesn’t feed your family. So we wanted to give our community members an opportunity to monetize their investment in the Liferay platform. At first, back around 2005, we simply created a plug-in repository for people to contribute their stuff. But we got more ambitious after seeing what Apple managed to do. So we decided to release the Liferay Marketplace, which allows our community to upload everything from simple themes and plug-ins to full-blown enterprise apps (BPM portals, learning management systems, ERPs), under the open source or proprietary license of their choice and either as free or for purchase. I believe it’s the only one of its kind in the enterprise software industry, that handles transactions between members internationally (there are a lot of US domestic marketplaces already out there and thriving of course). It’s still in progress, but we’re hoping it will really change the way people think about how enterprise software should be charged for and purchased.

How do you resist the temptation to not ‘cannibalize’ your own community by hiring all the top talents?

I can’t say whether we have successfully resisted the temptation—like I mentioned, our VP of Engineering was from the community, as have been other key hires—but we have had a guiding principle, which is never to poach a community member currently working at a company, which may often be a customer or a partner. So the folks we’ve hired from the community were generally on their way out of a position, and most of the time approached us about the possibility of working at Liferay. So that’s definitely helped temper any hiring spree on our community.

The other aspect is I think Liferay is more targeted toward enterprise customers, which means many of our community members are using Liferay in their professional work as systems integrators or as in-house IT for a large company. Working for an SI or a big corporation is quite different from working at Liferay, and I think someone has to really want to be in a product company with a fast-paced environment like ours to make that jump.

 Thank you Bryan for all the insights, hope your experience will be inspirational for others.