Liferay Development Model vs Closed Source Development Model
Liferay uses an open source development model. Open source refers to software for which the source code is available freely over the internet from the original developers of the software (Niu, 2016). Android operating system is one of the most popular example of open source software. On the other hand, closed and commercial software is usually closely protected by the company that developed the software, using proprietary license agreements. For example, Microsoft windows is a closed source software protected by a license of Microsoft. Other users cannot use the source code of the software and develop variations of Windows (Niu, 2016).
Closed Source Model
In a typical closed source development model, software companies introduce the software in the market and then release the software upgrade periodically. For example, Windows comes up with new versions of its Windows software periodically (Niu, 2016). In a closed development process, a company owning the software develops a newer version of the software using its own developers. Development, testing and quality checks are done internally before the software is rolled out to the final users. In some cases, companies release alpha and beta versions of the software to collect feedback from the users. Once the alpha and beta versions of the software are released, the company collects feedback from the market regarding bugs and problems and the internal development team based on the feedback fixes those bugs and releases upgraded versions. The whole development process is controlled and operated from within the software company that developed the software. Because of greater control, release times and bug fixes are often quick.
Open Source Model
On the other hand, open source software such as Liferay uses more democratic and collaborative development approach. First, Liferay gets feedback from its sales team about the upgrade requirements. Based on the feedback, Liferay Architects and developers decide the change requirements based on the market feedback, customer feedback and employee feedback. Once changes are implemented in the software code and interface, it is sent to key customers and partners, a strong community of users and intermediaries developed by Liferay over the years for feedback before releasing it in the market for all. At this stage, the chief software architect also reviews the code and functionalities. Once the software/upgrade is publicly available, Liferay collects feedback from the whole community. In fact, it also releases the code to the outside community so that others can develop their own variation of the software and release it. Once the software is out, Liferay gets informal and formal feedback from many sources. It then prioritizes the feedback and prepares a roadmap for new releases. Liferay is a more collaborative process and often may take more time to categorize, prioritize and develop newer versions, but on the positive side, it receives valuable input and thoughts that help the software become more robust and customer relevant.
Liferay’s Platform Strategy
Liferay Core
Liferay has a platform independent strategy. As the installation of the software is housed in the Java Virtual Machine layer, Liferay is operating system independent. Therefore, almost any application server using any OS that supports Java is able to run an active installation of Liferay. Liferay developed a software that is modular in nature. It wants to build an easily expandable software. The core of the Liferay software was Liferay Core. Liferay Core houses the administrative tools and supports different development tools. As Liferay is an open source software, the development tools and the Liferay core are available to everyone. Anyone can create a customized version of Liferay software by changing the codes at the Liferay Core and sell that as a proprietary software.
Administrative kernel and Plugins
Administrative kernel sits on the top of Liferay Core layer. This layer defines the framework for supporting different applications and enterprise modules. For example, the standard version of Liferay supports all the common enterprise software plugins such as Google Apps, OpenOffice, SAP, Oracle and Salesforce.com. However, one problem with Liferay being open source is that developers and companies that are changing the code at Liferay Core level can create a fragmented administrative kernel unable to support the different plugins if proper care and testing are not done during the development process. As Liferay software is totally open source software, the company has no control over those independent individuals or companies that are using the modified version of the Liferay software. However, to reduce such issues, Liferay provides a Plug-in Standard Development Kit (SDK). This tool structurally supports compatible plugins and at the same time, it removes dependence on specific development technologies for creating plugins. The SDK is so well-structured that it virtually can connect to any new enterprise plugins without the need to touch the core. This helps in keeping a stable Liferay Core architecture. New plugins are generally tested and added to the upcoming versions of the software upgrade. Independent developers can also market their plugins in the plugin marketplace separately. These plugins can be installed and used with the Liferay Core as and when needed.
Liferay’s MIT Licensing Strategy and Other options
There are several different types of licensing strategy used by companies for the development and release of their software. The most common and successful technique is the proprietary licensed and close source development technique. Most of the successful software such as Oracle ERP, Salesforce and Microsoft Windows are protected by patents and licensing. However, with increasing competition, closed-source software faced quicker turnaround and increasing cost of development (Bashir, 2014).
General Public Licensing
Liferay used an open source approach for software distribution and development. Anyone could download and use the community version of the software as long as they wanted. For using enterprise plugins and advanced functionalities, customers were required to get into purchase agreement. The most common form of open-source licensing was General Public Licensing (GPL). If a software was released under GPL licensing, then no user could change the software code and license and sell the customized version of the GPL software (Atal and Kameshwari, 2015). GPL licensing made sure that all upgrades, versions and customizations were released under GPL only and remained open source throughout its lifetime. An Apache license is a good example of GPL. Although GPL is called open source licensing, it is actually restrictive for modification and customizations. Permissive class of open source licenses allowed the open source software to be used or patented by anyone. These licenses allowed the developers and creators of derived work to apply for their own licenses and did not compel them to retain the original license. Mozilla public license, Berkley Software Development and Massachusetts Institute of Technology (MIT) license were examples of permissive class of open-source license (Atal and Kameshwari, 2015).
MIT Licensing of Liferay
Liferay was released under the MIT permissive open-source license. Therefore. developers and creators were allowed to modify and release other licenses. Even anyone was allowed to modify and create their own proprietary licensed version of Liferay. Liferay, under MIT licensing, allowed anyone to obtain a copy of the software and any associated software code files for free of cost. Under MIT licensing, Liferay was allowed to be used without restriction on the right to use, modify, copy, publish, distribute, sell copies, sublicense and copy the software. The only restriction was that the publishers needed to include the copyright notice while using any copy of the software. Under MIT license, the company was not liable under any warranty clause. The open source copyright holders of Liferay were also not liable for any damage or claim. MIT Licensing technique reduced the overall development cost for Liferay by reducing the overall cost of ownership of the software. As described above, clients were allowed to download and use the community version of the software without any restriction and any trial period. This method also helped the clients reduce the overall software acquisition cost as clients were able to use the software first and then decide later.
Options Available to Bryan Cheung
As discussed above, apart from the MIT licensing option used by Liferay, there were primarily two options available to Bryan Cheung, the owner of Liferay Company. The future options for Cheung were to make the software a GPL. Under GPL, the software would still be an open source software and the codes and development packs will still be available to the developers but under GPL, all suggested changes and upgrades would be done through the GPL license. Cheung and his team of architects and developers will be more accountable for regular software upgrades and bug fixes than they are now. Another option is to make the software open source. This will make the software license restrictive, but Liferay will be able to get more revenue by selling licenses. However, Liferay will be responsible for getting feedback, developing and fixing codes for newer versions and also for warranty claims by the customers in case of any problem arising from the software malfunction.
Liferay Licensing: Factors to Consider
Liferay’s current strategy for MIT licensing was to work well for the company. In the last ten years, through the use of this licensing strategy, the company was able to closely interact with the market, developers and customers who not only provided feedback on all the aspects of the software as all parts of the software were openly available but also helped developers develop new codes to make the software more functional and robust. Therefore, it seems that MIT licensing strategy for Liferay worked well in the past and there is no reason to believe that it will fail in the future. However, one of the problems with Liferay’s MIT licensing strategy was its unrestrictive nature. Many companies started licensing and offering modified versions of Liferay. There were many versions of Liferay in the market sold under different names. Additionally, some of the companies were unable to develop a good code and often distributed a fragmented code that supported only a few plugins. This has the potential to negatively portray the image of Liferay in the coming days.
Another factor was Liferay’s lack of control over the codes. Anyone was allowed to touch any part of the software. Developers were not the only ones allowed to customize plugins using SDK, rather anyone could change the Liferay Core as and when they wanted. Finally, it was also difficult for Liferay to manage the suggestions. As it was a permissive-open source license, a huge number of suggestions were provided to Liferay. The problem for architects and developers was to prioritize them before each upgrade.
As discussed previously that Liferay could have gone for more restrictive GPL licensing. Under GPL licensing, all code upgrades had to be published under the GPL licensing. This meant Liferay’s increased control over the product and the code changes. There is no chance that others will develop and distribute a fragmented code under the GPL licensing without Liferay knowing and approving it. However, this would introduce additional responsibility for Liferay. They would require more architects and developers to make all the changes as market will be more inclined to provide suggestions. Additionally, even with greater control, other companies will be able to share revenue with Liferay and Liferay will not get the whole chunk of the revenue.
Liferay has the option of patenting its Liferay product and make it a closed source software. This means that all the responsibilities for development, changes, bug fixes and upgrades will be on the shoulders of the company software architects and developers as the code will not be available to the outside community. The upgrades need to be done based on customer feedback on a regular and frequent interval. This approach requires superior and disciplined team of architect and developers. The benefit in this approach is that Liferay will be able to get all the revenue alone by selling the software as others will not be allowed to sell the software under a close licensing.
Recommendation
Looking at all the options, it is advised that Liferay should continue to use its MIT licensing path mainly because it is a proven process for Liferay that has benefitted the software. However, to ensure that all the versions of the software are robust, it can introduce a framework of guidance at Liferay Core level and plugin levels for all the developers to follow.
Works Cited
Atal, Vidya, and Kameshwari Shankar. "Developers’ Incentives And Open-Source Software Licensing: GPL Vs BSD". The B.E. Journal of Economic Analysis & Policy 15.3 (2015): n. pag. Web. 10th February 2016 < http://dx.doi.org/10.1515/bejeap-2014-0007>
Niu, Shuai. "The Optimal Licensing Policy". The Manchester School 82.2 (2013): 202-217. Web. 10th February 2016 <http://dx.doi.org/10.1111/manc.12007>
Bashir, Rabia. "Anti-Patterns In Open Source Software Development". International Journal of Computer Applications 44.3 (2012): 23-30. Web. 10th February 2016 <http://dx.doi.org/10.5120/6244-8197>
Liferay. About Us. Web. 10th February 2016 < https://www.liferay.com/about-us>
