What might differentiate a JA-SIG portlet collection from one packaged with another portal product? Well, for starters, a higher education orientation would be an obvious distinction. I can think of a few useful functions that would no doubt provide value to campuses—simple things like Classified Ads, Ride Board, etc.—and have more relevance than the Cartoon of the Day.
Another characteristic—“openness”—could also distinguish JA-SIG portlets from the rest of the crowd. While openness is not synonymous with open source, it is certainly an important value and design goal for us in the interests of portability and interoperability. The unfortunate reality is that, despite the almost universal adoption of the JSR-168 portlet standard, one portal’s portlets actually have a slim chance of running in another guy’s portal. One reason is the inherent limitations of the portlet spec itself. This has spurred portal vendors to cook in extensions to proprietary services, rendering their portlets pretty much bound to their specific implementation.
The case could be made that these hooks are necessary to provide real utility. Even so, there are probably more responsible ways to architect these extensions than we’re currently seeing—pluggable interfaces, transparency, and good documentation exposing the problem areas, among others. It would be nice to say that the uPortal portlet bundle is the collection that will run best in other people’s portals, some necessary tweaking notwithstanding.
A portlet “style guide” for uPortal—and I hope to see one someday—would encourage best practices and civic-minded behavior so that we could brag about having not just the most useful content for higher education but the most “portable portlets” as well.
