days
1
8
hours
1
0
minutes
3
7
seconds
4
6
search
Challenges and misconceptions, and why they exist

Open Source: The not-so-secret to success

Milen Dyankov
open source

© Shutterstock / Photo Art Lucas

Open source is a great tool for developers, but it doesn’t solve all problems. In this article, Milen Dyankov discusses the lessons he has learned as a long time user and advocate of open source software, and the value of nurturing relationships.

Open source software is very attractive because you can see what you’re getting yourself into and take an active role making suggestions or committing code to help it achieve the desired result. Like any enterprise developer, I want to know if it will solve the problem I am facing – I am not here to evangelize for open source but to explore some of the common challenges and misconceptions, and why they exist.

Commercial open source vs. free open source

The commercial open source business model is a tough thing to get right. Yet, there are many, many examples of fantastic companies out there today that I am content are getting it right. The challenge is that the supporting company is usually the driving force behind the software development, and – not to put too fine a point on it – pay their developers. That business needs to be sustainable for the project to become a sustainable codebase upon which to develop enterprise applications.

There’s a sliding scale where companies can get it wrong, and it relates to how they sit in both the enterprise commercial market and the community. Those companies that get it right understand how the community gets involved in their project and support that in their culture and activities.

As enterprise developers, we need to understand that open source is not about companies giving everything for free – open source means people can download the code and inspect it, perhaps make suggestions or fixes and try things out.

Having a product offered as both commercial and free open source software (FOSS) is a double-edged sword. Hopefully, we all understand the benefits so let me focus on the other edge.

In his great book “Thinking, Fast and Slow”, Daniel Kahneman introduces the WYSIATI (What You See Is All There Is) concept. When you experiment with FOSS project, the intersection of what you need and what you’ve been given is your WYSIATI!

Liferay Portal [1], for example, has won many CMS awards thanks, in part, to the fact that over 10,000 projects were using the CMS functionality of our free Community Edition (CE) software to manage their sites. As a company, Liferay is very happy to see people making use of its software, particularly worthy causes such as nonprofit organizations. The flip side is, such awards emphasize a particular feature and shadow others. For example, you may never realize that Liferay Portal could be your choice of modular, scalable, highly extensible software platform with multiple-device clients, just because other people’s WYSIATI will make you think it’s only a web CMS!

Another situation where this comes into play is when you’re evaluating if a given product can solve a particular problem. You look for something that can help. You will download the candidates and have a poke around. In general, you’re going to look at these factors:

  • To what extent does it solve the problem?
  • Can I afford it?
  • How long will it take to have the final solution?
  • What support can I get if something goes wrong?

If you download a free open source product and it does what you need, you might investigate the commercial offering to see if you can get the support and features for future needs. But if you download the software and you find there’s something you really need that’s missing, there’s a good chance you won’t go looking for a salesperson just to find out if the commercial version has it. Why? Because you’ll have to explain your needs to someone outside your comfort zone, then understand the conditions and restrictions that apply and then add some more ‘if’ statements in your reasoning process. That is not a fun thing to do, especially if you have alternatives in the bucket!

That is why making a FOSS offering a very limited version of the commercial one is almost always a bad idea. It takes time and effort to set apart fundamental functionalities from those that only have value to the enterprise customers.

To give you an example, in my opinion, one of the biggest blunders Liferay has made was to release the latest version (7.0) of Liferay Portal CE without support for clustering. Clustering is only available in Liferay DXP. I understand why that decision was made and the business had every right, but it was an important feature for anyone evaluating Liferay and for those people in the community that were not in a position to engage on a commercial basis. As it turns out, Liferay listened and I’m delighted our CEO Bryan Cheung announced the reintroduction of Liferay Portal CE support [2].

What makes a community?

That is a question which, as obvious as it may seem, is not easy to answer: Should it be people that contribute? Anyone who uses the software? When you’re a big enterprise project, you can start to think that the community represents the clients. That’s not the case though — they are paying customers who have signed a contract that explicitly defines what rights and obligations both sides have. This is how you guarantee they’ll receive the quality and service an enterprise application requires.

They do, however, also benefit (even though not directly) from a support network beyond their commercial subscription that includes many different people including early adopters, contributors, independent consultants, etc. That’s your community! A group of people who have something in common — your great product(s). The common interest of any software community is to make the product(s) better for the community. They provide feedback, report issues, commit improvements, document functionalities … and, in return, they get better software for their project.

But that also works in the other direction. Your community members would be pleased to know that, should they shift to needing to run a business critical situation, they have the option of enterprise support. All this is very important to build a successful OSS company brand.

Branding

Another important learning for me was branding. Liferay was the name of a software product long before it became the name of the company behind it. Up until today, both shared the same name. After all, the company was created to support the software in major enterprise deployments.

Last year, Liferay Inc. launched its commercial product with the name Liferay DXP, which recognizes the re-architecting of the monolithic java portal to a modern microservices platform to address the changing needs of its customers. This created some confusion in the community because for continuity’s sake, the Community Edition is still called Liferay Portal (version 7). Had there been a fork? Was DXP an end to open source? Of course not – that would go against the core values of the company.

So today, when you hear someone saying “Liferay”, you usually need a wider context to be able to tell if they refer to the company, the FOSS Liferay Portal CE, the Liferay DXP or any other of the many products Liferay Inc. has introduced over the last 10 years. We are working hard to find the best way to make things less confusing for all.

What’s in a name?

You are probably well aware of this famous saying: “There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.” As it turns out, in software, we love buzzwords and trends. And even worse, we love to name things after them. If something like Liferay Portal was to be first released today, it would likely contain “microservices platform” in its name. And developer tools similar to those Liferay offers would most likely proudly use DevOps in more than one place.

The important lesson here is that trends and buzzwords change, the name stays! In fact, Liferay also fell into that trap by using the word “Portal” in the name. In the early days of Liferay, portals were as much of a buzzword as microservices are today. Liferay was the most feature-rich open source solution in that space competing with commercial, closed source offerings from biggest software giants. So why not call it a portal? Fast forward several years, portals are far from being cutting edge technology. The product itself has followed the trend and evolved into multi-purpose, multi-device, highly modular platform for independently deployable services. Its name however still pays the tribute to those heroes of the early days.

Liferay

I’m lucky to be part of an organization that is fundamentally committed to open source development – from the opportunity for its developers to become better coders to the obligation to give back. While not everything at Liferay is OSS, every product or service we release is somehow related to open source. And I’m particularly happy when we can make other open source developers happy or simply make their lives easier!

For example, Liferay’s WeDeploy project is not open source [3] but is addressing the community’s desire to utilize cloud platforms. We could have chosen a platform, for example, AWS and optimized Liferay Portal / DXP deployment and operation processes for that, but that way we would be ignoring Liferay’s community members’ preferences in favor of our own.

It is important that anyone can run Liferay Portal / DXP on a cloud server (IaaS), and that means it has to be ready for virtually anything that you might call cloud. That is already the case, even though we are still working hard to make it even more “cloud native”. However, we also wanted to make it so easy that you really can get up and running in few minutes.

With WeDeploy, we aim to provide a solution for the need for developers to be productive while working with what they know best. Therefore it’s more than a hosting — it provides really valuable services such as data service, login service, and email service — right up to enterprise deployments! It even knows how to host and serve applications written in multiple programming languages. It is advancing very quickly and it’s all free for now! And yes, you (we) can deploy WordPress. :)

Do you need a developer relations team?

I have noticed a general shift in how software companies engage with the developer community. The transition goes from “listened to learn” to “listen in order to respond” and I’m afraid we all follow this trend to some extent.

At Liferay, we used to have a Community Manager. (James, if you are reading this, I want you to know you have done a great job! We really miss you!) The problem with that title is that it suggests the community can be managed. Many seem to believe this is the case, but my experience shows it’s rather the community that “manages” you.

This is why we decided to go for a developer relations team and instead of trying to manage people, try to develop real relationships, as the name suggests. Many companies have such teams consisting of evangelists. In our team, we have developer advocates. I know some people believe those mean the same thing but there is a huge difference.

  • An evangelist is there to tell you how great something is and why you should be using it.
  • An advocate is here to listen to what the community needs, think about it and propose a solution or advocate this internally within the company.

It means our goal is to find out if there’s a mismatch between the company’s and community’s perception. If so, we try to understand the problem and take actions to make sure both sides have the same positive view of the matter.

Another subtlety is that we show people how to solve a particular business problem using Liferay technologies — not simply the technologies as such. Sharing experience and building trust are more important than pushing the product, whether we are talking about building software using Liferay or how we build Liferay itself.

Liferay Portal is an unusually free and open source proposition because it is the sort of robust and scalable platform normally associated with a large price tag. It’s used by complex organizations such as the UN or Société Générale to deliver content and applications with granular role-based permissions, and it has a comprehensive feature set out of the box complemented by open interfaces that make it very flexible for integration with APIs and web services.

Liferay DXP enters the emerging Digital Experience Platforms market with a heritage of powering great intranets and partner portals. Its internal architecture is highly modular providing platform of robust microservices (CMS, user management or document management) that you can deploy as needed. You can both deploy it alongside your multi-language microservices or deploy your Java microservices to it, to quickly build and manage resource-efficient applications.

References

[1] Liferay

[2] Bryan Cheung blog

[3] WeDeploy

 

Open Source

To read more about open source, download the latest issue of JAX Magazine:

All eyes on Open Source

Open source skills are a boost for career prospects — if you don’t believe it, it’s time to bring out the big guns.

We invited the Eclipse Foundation, The Apache Software Foundation, Cloud Foundry, Red Hat, Hyperledger and more to show you why open source is important. You’ll surely learn a lot from their experiences!

But don’t take my word for it! Open the magazine and allow their passion to “infect” you.

Author

Milen Dyankov

Milen Dyankov is passionate about designing and building software, and today that mostly means helping others design and build good software. He is a Developer Advocate at Liferay.


Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of