It is very often the case that portal users wonder where all the free / open-source JSR 168 portlets are. After all, there is an abundance of
portlets for other non-JSR 168 portals (NetVibes and Google come to mind). So, what is different in the world of JSR 168 compliant portals?
First, let's look at portlets bundled with the different JSR 168 portals. After all, the number of bundled portlets is (quite astonishingly to me) often used as a selling point for portals. This makes some sense: you want your users to hit the ground running and deploy a portal that does
interesting stuff out of the box. The
interesting part of it is central to the issue though. Interesting means different things to different users and that's where things start to get complicated...
For portals such as NetVibes, Google or Yahoo (which was the first historically), which I call aggregation-oriented portals, developing useful portlets is not usually a challenge in the sense that users of these portals are not interested in integrating complex services but rather in aggregating information that's usually available as web pages/services. A bit of HTML, some javascript, a well-crafted API and you're on your way. JSR 168 compliant portals, on the other hand, usually target business users that have to deal with integration of disparate web applications to provide a unified interface to their users, who, in all likelihood, will depend on these services to do their job. Now, this is not to say that JSR 168 portals cannot or shouldn't be used as aggregation-oriented portals but the fact is that the user community for such use of JSR 168 portals is quite small compared to business deployments.
Interesting, in this enterprise context, means something quite an order (if not more) of magnitude more complex than aggregating content which won't be missed much if not available... And, to me, that's the biggest reason why we don't see a more striving marketplace for JSR 168 portlets. The ones that are developed are never seen because they don't make any sense outside of the context for which they were developed as they are so tightly bound to the enterprise services they interact with. Sure, for some of these portlets, some effort could be spent on writing them in a more generic way so that they can be reused by other people, but how often do developers have the latitude/time to spend on extra-curriculum activities as these while working on mission-critical projects?
The argument could also be made that
portal developers should spend the time to work on these business-level, reusable
portlets. From
my portal developer perspective, portal development and portlet development are two different separate activities, with different lifecycles and constraints. There is definitely a market for JSR 168 portlets. However, the return on investment on open-source portlets that would be bundled with JBoss Portal is very low. First, it's not clear what portlets the community wants/needs. Second, a significant amount of time would have to be spent developing them to make them both useful and reusable (though, obviously, this depends on the portlet). The more generic, the more time we would need to spend on them, also running the risk of making them more complex. Now, what do we have to gain from doing this? Increased visibility in the community and market share, which are both good things. But how much of this would translate to paying customers? Would it be enough to justify the time we spent on these portlets as opposed to working on the core product? Hard questions to answer... The only way I see this making sense from a business perspective would be to span a complete separate group that would only deal with portlet development and associate support, just like any other products. Is it something that JBoss want to get into? I don't know and it's not for me to decide anyway. :)
Another point is how bundled (and more generally open source) portlets are desirable as startup projects for further developments. Once again, it makes a lot of sense. How is it, though, that rarely are these portlets contributed back to the community? Hint: useful, reusable portlets take time and attention to develop. Most people write custom solutions and don't bother/care about making it reusable. A community doesn't build itself. It's a two way street... JBoss Portal provides an
open repository for portlets... It is not as great as it could be, and we are aware of that, but like most things, this takes time and, from my personal point of view, with seemingly low interest from the community, I'd currently rather spend that time on improving Portal itself.
More interesting, to my mind, to remedy to the perceived dearth of portlets, is easy integration of popular user-oriented, non JSR-168 portlets within a JSR 168 portal. Starting with JBoss Portal 2.6, it is now very easy to use Google widgets within a Portal page. Support for other (NetVibes comes to mind) is coming up...
In conclusion, when looking at a portal, should you be looking at the set of bundled portlets? Sure. Should it be a deciding factor? Maybe, if you only want to deploy a simple, aggregation-oriented portal. However, if you are on the market for an enterprise-class portal, you should probably be looking at the portal's compliance with standards, capabilities, scalability, how well it integrates with enterprise services,
how well tested it is, etc.
