About a year back, when Apache Rave was announced, I had mentioned in my blog that It will be a while before Rave reaches a stage where customers can actually benefit from it. Now Rave has graduated to become an Apache top-level project. That itself is an achievement and congratulations are in order to the team supporting Rave. But is Rave anywhere closer to realizing its promise, and is it good enough today for you to consider it seriously for your Portal?
Rave's wants to be a "web and social mashup engine," to integrate many of Apache's existing projects such as OpenSocial, Shindig, and Wookie.
What does that mean?
Traditional Portal technology -- while mature and battle-tested -- is getting long in the tooth, and as a result has become comparatively complex as well as "heavyweight." Emerging alternatives to portal tools use more agile and lightweight components such as Gadgets to aggregate and present information. Gadgets go by many names, such as Widgets and even Biscuits, but they are fundamentally client-side applications as opposed to server-side portlets. We explore Gadgets and Portlets in this Advisory Briefing and this one.
As with everything else in our space, there have been many attempts to build a framework or specifications around Gadgets. Some of these include iWidget specification by IBM, W3C's Widgets, Google's OpenSocial, et. al. As a result, there are many (overlapping) projects that provide something for you to be able to build a Gadget-based, Portal-like application. However, none of these projects were comprehensive or provided a tool that you could install and build a complete Portal without struggling with basics.
Now after one year of its announcement, Rave has indeed managed to bring some of these projects together. So you can now install it, create your pages, have some security, drop the gadgets you need, and create a basic structure for a Portal-like application. There's also an admin interface where you can create users, configure gadgets (both OpenSocial as well as W3C), and perform other basic configuration tasks required of a Portal.
So in that sense, Rave has certainly made considerable progress.
However, if you want to consider it as a credible alternative to formal Portal tools, you should remember a few things. Rave still does not have a V1 out yet (its still 0.9). And while this version does integrate several projects, there's not much new in terms of additional features. A Portal building tool without some capabilities to handle personalization, collaboration, or content is not particularly useful. Sure, you can use OpenSocial gadgets to integrate some social features, but that's not really same as building a collaboration-based Intranet Portal.
So I think considerable progress still needs to be made for Rave to be a serious contender for building Portal applications. To be fair, the community has plans to build extend some functionality -- for example, next in line is content integration (HT @arjecahn) -- but all that still lives in the realm of developer mailing lists, and there's no published roadmap.
But the good thing is that the Portal Marketplace is still very much alive. I am all for standards, and Rave is going in the right direction. I hope though that the progress accelerates and it gets support from the many vendors who have thusfar declined to sign on.