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.
Subscribe to:
Post Comments (Atom)
7 comments:
I can understand the point about corporate portlets not making into the public area. I think what would sell portals more is more customization portlets for the Portal server. I am currently trying to get LDAP/Active Directory up and running and am having a bear of a time. A great portlet would allow me to test an ldap connect. View users and the groups. A option to map fields. Another great one would be a Database setup wizard. There are soo many different options to configure to get JBP tied into our Corporate Network. The learning curve is just very high. Basic install works great. Once up and running the Admin login should have customization portlets to further configure JBP. Looks like Liferay is heading in this direction with there latest release.
I think you are fooling yourself if you thing that a portlet can do the job of setting up your infrastructure for you. Instead, a good understanding of the infrastructure would more likely be necessary. The portlet would have too many restrictions compare to what can be done.
Sorry for the "sales pitch" but, really, we can help you integrate to *your* environment though support with human beings behind, something a set of portlets will never be able to do.
Integrating LDAP/AD has been successfully done by many users and customers so far, if you didn't succeed following the current documentation, it might be because your environment is somehow different, something a set of portlets wouldn't help.
Sure we couldn't certainly do some configuration on first install through a web interface, that's actually a good idea, but it wouldn't solve the difficult issues, the ones you might have troubles with and then have a low-value. I'd rather spend time on providing a good API to adapt to any environment. Hope you understand my point.
There is certainly room for improvement as far as visual configuration tools for Portal go... and we're certainly committed to improving Portal's usability. However, like Thomas said, it's a matter of priority. We tend to focus on the back end first because we think it's more important to get it right first. This leads to a lag between Portal's capabilities and what can actually be configured in the user interface. I'd like to point out, though, that if something is important to you and you would like to see it implemented, you can always file a feature request for it in JIRA: http://jira.jboss.com/jira/browse/JBPORTAL
That said, this is quite beside the point of the blog entry: while these portlets, if they were to be developed would certainly be open-source, they wouldn't be very useful outside of administrating JBoss Portal, thus wouldn't be a good example. I could see how a generic LDAP interaction portlet would be helpful though. The question, then, is, again, what do we have to gain from developing such a portlet (which certainly wouldn't be trivial)?
While a large set of configurable, generic portlets would be nice, I'd prefer that JBoss concentrate on a portlet development tool. Something like a cross between the mashup tools that are being offered in the industry (e.g. Yahoo Pipes, Kapow, etc.) and the RAD tools for portlet creation (e.g. Vignette Builder, IBM/Bowstreet). Having a way for users to create workable, custom portlets without having to open an IDE would be huge...
Care to elaborate, Scott?
I think more corporations need to provide standards-based portlets for integration of their applications. For instance, why wouldn't IBM release Lotus Notes portlets? For free? I can't use them unless I have Notes, which I don't have unless I already purchased it. The only viable solution is a 3rd-Party vendor, why not have solutions from the source? Especially when you're competing in the portal space yourself.
We need more (and better) portlet integration solutions from the major players.
This would indeed be ideal. However, the same tension between development cost vs. added revenue is very much an issue for vendors who don't compete in the portal space. As for those who do, well, not providing their portlets for free is a way to add value to their portal offering (especially if the portlets happen to use proprietary APIs) so they don't have much incentive to do so. :(
Post a Comment