IceFaces Ace Forks PrimeFaces for jQuery Support, PrimeFaces not Happy
There has been a recent stir in the JSF community regarding PrimeFaces and IceFaces. The PrimeFaces projects is claiming IceSoft copied PrimeFaces code "LINE BY LINE" for its new IceFaces Ace components.
Note that PrimeFaces uses an Apache license. The Apache license is very liberal and business friendly. Commercial and open source companies have forked Apache projects. One could say whole companies and industries have been built with Apache forked projects.
InfoQ caught up with Çağatay Çivici, PrimeFaces lead and well known JSF expert, to get his opinions on this conflict. Also for fairness we caught up with Brian McKinney, President of IceSoft who is quoted later. But first, we interviewed Çağatay Çivici.
InfoQ Why do you think they copied PrimeFaces?
I really don't know the actual reason, IceFaces is a competitor of PrimeFaces so IceFaces 3 has been expected to be an alternative solution to JSF ecosystem. Instead of providing an alternative they have decided to copy another library.
PrimeFaces is currently the most popular UI library for JSF and a popular RIA framework in general for Java EE. So the library they have chosen to copy is PrimeFaces. They claim that they have improved the code of PrimeFaces, we've checked out what has been improved but just seen the same lines as posted on our blog.
They have based their copy on PrimeFaces 2, I don't think anyone needs IceFaces to improve code of PrimeFaces, we the PrimeFaces Team has done it for the past year and it is called PrimeFaces 3. Currently we are wondering if they will sync our current development changes with their code or not.
InfoQ From your blog post and twitter feed, it seems like you feel IceFaces is struggling and losing mindhare. What was wrong with IceFaces? Why are they struggling and losing mindshare?
The popularity of IceFaces is fading drastically and they can't seem to catch up with the development pace of PrimeFaces. IceFaces 2 that supports JSF 2.0 was roughly released one year after we released PrimeFaces 2 that supports JSF 2.
Popularity of IceFaces is so important for a company like IceSoft because they sell commercial support, trainings and consulting in addition to other commercial services. In order to catch up and increase their popularity.
They've made a wrong decision and copied PrimeFaces code. I'm sure there won't be many users of IceFaces 3, their reputation has already been damaged, there are even some icefaces jokes out there. For example, Spring Roo only supports PrimeFaces for JSF scaffolding, people say IceFaces is also supported now. Why would anyone use an old copy (of PrimeFaces 2) if the greater original (PrimeFaces 3) is available as well.
I've used IceFaces for 3 months in a project I've joined in a late stage when I was working as a freelancer in 2008, this was couple of months before we created PrimeFaces for Prime Teknoloji. IceFaces is generally known as slow, sluggish and not usable which I experienced during that 3 months period. For example they use AJAX too much even for every user click. I'm not the only one who thinks this way.-- Çağatay Çivici
InfoQ How does PrimeFaces compare to other RIA providers? Why is PrimeFaces doing so well against RichFaces and IceFaces?
There is a recent InfoQ article on PrimeFaces 3 that has an analysis on this as well.
We are a consulting firm that make use of JSF and Java EE for consulting, trainings and software development. We had some serious troubles with other JSF libraries in the past and decided to create a lightweight and easy to use library in 2009, now known as PrimeFaces.
The prime difference is; PrimeFaces is created by application developers not software vendor developers. We can see the cases from an application developer's point of view. We use PrimeFaces in production every day for our clients, fix bugs before they are released to community and improve the usability continuously.
In addition, PrimeFaces is not sponsored by a big vendor as in the case with RedHat-Jboss RichFaces, so we believe in the fact that we must be the best and work much more than our competitors not to feel this handicap and we are succeeding so far. PrimeFaces Core team consists of the founders of Prime Teknoloji so working on PrimeFaces is not our daytime pay job, we work on it through days, nights and weekends without seeing it as an overtime work. We just enjoy working on it.
We are like a sports player who has to stay in the gym after the training is completed and continue working motivated by passion to be the better than others.--Çağatay Çivici
InfoQ Any complaints on how IceSoft has handled this issue?
First, IceSoft has been deleting our posts and posts of our users from their forum, we believe in free speech! So hopefully they will no longer do that. After getting a lot of criticism from community, IceFaces has updated the (IceFaces Ace product page) to add reference to PrimeFaces.
In addition to this list, although not stated there are more components based on jQuery/PrimeFaces such as slider and dateTimeEntry. The conclusion we reach is that IceFaces is powered by it's competitor, PrimeFaces. We would have liked this more if they have linked to PrimeFaces by doing a compile/runtime dependency to do this instead of copying the code and renaming the packages.
IceSoft has approached to us last year with an (monetary) offer ... to sponsor the project however in return they have asked for commit access and more which was unacceptable for us.
... PrimeFaces is licensed under Apache license which permits other libraries to copy, paste and redistribute. Our point is not legal at all, we just want to spread the word that a competitor of PrimeFaces has copied our code and is trying to sell commercial services like enterprise support, consulting and trainings. Although it is legally ok, a competitor should not just do something like this just because the code is open source and the license permits, instead IceSoft should have come up with their own alternative solution. That would be much better for JSF and Java EE in general. Please see the case from this point of view is not legal.
In general, we see this whole thing as good news for PrimeFaces. It states that PrimeFaces is the best library for JSF. "Imitation is the sincerest form of flattery."--Çağatay Çivici
In the interests of fariness, InfoQ caught up with Brian McKinney, President and CEO of ICEsoft Technologies, he sent us this statement:
ICEsoft sees no reason to re-invent the wheel if there is no new innovation to be gained from it. In the case of the PrimeFaces open source library, we saw no material innovation to be gained by redeveloping JSF wrappers for the jQuery library. Rather we sought to leverage an available open source solution so that we could apply our resources to innovating elsewhere, such as in the delivery of data table feature enhancements or in the availability of our latest open source project, ICEmobile. Innovation of this sort would not have been available to the open source community had we not been able to leverage the contribution of open source projects such as JQuery, YUI, and Primefaces -- Brian McKinney
InfoQ spoke to Brian at length about this issue.
Brian stated that ICEsoft identified PrimeFaces as a project that was really well done and utilized jQuery effectively. His customers were asking for JQuery support. Rather than reinvent the wheel, they decided to use PrimeFaces, which is sort of the whole point of Open Source and Apache license. They wanted to make changes to the PrimeFaces code base to support other browsers like older version of IE that their customers need, and support for WebSphere Portal as well as fit nicer with their framework and code generation.
They could not come to an arrangement with PrimeFaces project to get commit rights, and rather then reinventing the wheel, they forked PrimeFaces. He feels the value they add to his customers is the certification that they do with all of the browsers, service they provide and additional features.
He went on to say IceSoft provides support and services around the framework; therefore, the ability to commit changes and patches (feature requests and bug fixes) is a requirement for providing good support and service.
To get the full reasoning on why IceSoft did the fork, please see their FAQ on this subject.
Brian further stated that the primary value-add they delivered with ICEfaces ACE was the integration with the ICEfaces framework and the addition of new features (described in the FAQ). The changes needed to make the legacy browser work was also important.
Using PrimeFaces to facilitate jQuery access allowed them to focus on the delivery of other open source contributions such as ICEmobile and the latest data table features instead of wasting time reinventing the wheel according to Brian.
After reading what Çağatay Çivici wrote, Brian McKinney asked to include the following.
In constructing the ACE library for ICEfaces 3, we sourced components from the best open source solutions we could find. We integrated popular components from jQuery, YUI and PrimeFaces and brought them together within the ICEfaces application framework along with our own Advanced Component Environment (ACE). Along the way, we improved upon the components by adding major new features, fixing bugs and getting them to operate seamlessly together across a wide range of middleware and browsers. Finally we constructed a comprehensive QA process around them so that users could rely on them for quality and consistency of performance. The net result is a product that exceeds the sum of its parts. Users can now have access to high-quality, industry-leading library that can interoperate with one the industries most popular application frameworks. And in the best tradition of open source, it was all re-released back to the community under the Apache 2 license so that others can benefit and carry the work forward.
Questions have been asked as to why we forked the PrimeFaces components. The answer is that our community had expressed interest in accessing jQuery functionality within the ICEfaces framework. Primefaces has done a good job wrapping jQuery and YUI components so that they could run in JSF 2 and ICEsoft sees no reason to re-invent the wheel. In the case of the PrimeFaces open source library we saw no advantage to the community by having our developers redevelop wrappers for the jQuery library. Rather we sought to leverage an open source model and free up resources so they could deliver additional value and innovation to the community.
In the course of our integration of various PrimeFaces, jQuery and YUI components we made over two hundred code improvements to resolve bugs or provide enhancements to the components. The data table in particular saw extensive code and feature enhancements, and it is now one of the richest and most comprehensive components in the industry.
One hundred percent of the components we integrated were modified and two-thirds of the PrimeFaces components were the beneficiary of extensive feature enhancements and bug fixes required for them to work in a consistent fashion across the wide range of browsers, application engines and portal containers that ICEfaces supports. Claims that 90% of the ACE library was copied line by line from the PrimeFaces library or that no value was added are as ludicrous as they are laughable.
ICEsoft has a very long and rich history of innovation, with a number of patents and patent applications ranging from DOM-based rendering to Ajax Push. Whether its our patents, data table enhancements, bug fixes for IE 7 compatible components or our most recent open source project, ICEmobile, innovation is what made us an industry leader and its what keeps us there. By leveraging open source models where appropriate we can and will continue to innovate to benefit of the community. --Brian McKinney
One Last Question to ICEFaces
Re: One Last Question to ICEFaces
jQuery is just assumed.... I would imagine
It would likely be much less of an assumption that a JSF component lib is a fork of another JSF component lib. This is not to say that fork is wrong or what any one did is wrong just that one might assume a JSF component lib uses jQuery but you would never just assume a popular JSF component lib is a fork of another JSF component lib.