Enterprise vs. Open Source Portals?

lowvato asks: "I have recently been tasked with building two enterprise level portals. One is already in the making using Apache Jetspeed and the other is in the planning stage. I have been impressed with Jetspeed and its progress and versatility as a portal environment. One portal needs a very high level of security and interaction with disperate web services while the other is more of a community building service with CMS, forums, and so forth. Upon a limited review of the commercial portal solutions, I have found it hard to determine what they offer over open source solutions (especially since a few are based on products like Jetspeed or UPortal). I would like to hear what others have found using commercial and open source portal products."

Comments

Meh.

[Twirlip of the Mists]

I thought portals went out with stock options, VRML, and "push."

Re:Meh.

[greenhide]

That only really applies to portals that tried to make money through banner ads, particularly portals that were too generalized or didn't have a specific audience or target ("Our target is Gen-Xers" is a good example of a target that was not specific enough).

On the other hand, industry specific portals are hugely successful. You're looking at one right now, but examples exist in many industries.

The point is that many of these portals now make money by:

1. promoting certain companies outright, not through banner ads but with articles, detailed press releases, and product showcasing
2. online catalogs, which sell items of great interest (not bumper stickers or t-shirts) to the customer
3. actually charging the user for access

Also, if you look at portals that are still in existance, most of them rely heavily on volunteer-provided content. About.com is a good example. It's still going fairly strong, mostly because its costs aren't that huge (sure, they have to cover hosting costs, but in the long run, providing their own content would have been much, much costlier). Notice also that they employ two of the other "success techniques" -- they promote other companies (using sponsored links -- studies have proven that people have developed banner ad "blind spots", but they still pay attention to links, sponsored or not) and have links to purchase products.

Re:Meh.

[Twirlip of the Mists]

On the other hand, industry specific portals are hugely successful. You're looking at one right now...

At this point, the definition of "portal" becomes blurry. I would consider Slashdot to be more like a weblog than a portal; Slashdot is, ultimately, a collection of links (a la Metafilter or Memepool) smooshed up against a pretty nice posting board system. I wouldn't consider that to be a portal, by any useful definition.

I would put netscape.com down as the canonical example of a portal. Just typing "netscape.com" into my browser shows me these things: "Eminem's a Movie Star!"; "Workplace Weasels Beware: Dilbert's Back"; "DJ30 8418.95 -118.18"; "Deal of the Day: Big Stereo Sound at Half the Price!"; "Weather (Enter ZIP:)"; and "When will the tech sector rebound? [Vote]". In other words, Netscape's site tries to look like the front page of a newspaper, with a couple of articles above the fold, the weather forecast in the corner, stock market statistics in the other corner, some ads, and a bunch of smaller articles and ads below the fold. It does this by scraping web sites or web services, assembling the content according to a template and/or some user preferences, adding a dash of advertising, and stirring until blended. This basic pattern is true of general portal sites, like my.yahoo.com and netscape.com and others; industry-specific portal sites; and corporate portal sites. The only difference is the sources from which the content is collected and how it's presented.

I don't think Slashdot (or K5, or MacSlash, or Metafilter, or any similar site) qualifies as a portal, in the traditional sense. Of course, if the definition of "portal" has changed over the past few years without my noticing-- before this morning, I hadn't been to netscape.com since about 1997, and that was to download Netscape Navigator 3 for IRIX-- then pretty much everything I've said here is outdated and irrelevant.

But I suppose, if I'm anywhere close to being right about this, that a discussion of what, exactly, constitutes a "portal" in the context of this Ask Slashdot is in order. Then again, I don't really care, so WTF.

Also

[greenhide]

I completely forgot to mention the number one consumer of portals these days:

Individual companies.

Portals are an excellent "intranet" tool, offering company news and documents to their employees. They're often a better and cheaper alternative to investing in one of the Intranet-ware applications that are provided by M$ and others or trying to develop them in-house, since generally most of what an intranet needs to do is share documents, which can be done easily and well through a portal.

Additional questions

[greenpooh]

Do you have to choose the same solution for both portals?
Do both portals need to consume the same set of services?
Do these services already exist?
Are portlet standards an issue (sun vs. oasis)?
Do the portlets need to provide the security or be compatible with an existing security framework?
Do you have time to market considerations?
Platform considerations?
What's the usage going to be like?

Although portals attempt to do it all, there is no portal solution that resolves all issues. If there is limited functionality and you have time to market issues, jetspeed is a favorable choice. Webapp installation and deployment is probably the easiest of the bunch.

If you have only a community requirement, consider slashcode or phpnuke. These are probably the industry's best and free is a good price. However, these are primarily community portals, additional functionality is limited.

Plumtree excels at community + a little more. There seems to be scalability issues, and it does not provide a true highly available solution.

BEA does not have the same community support, but excels at it's integration with other features (J2EE, BPM, personalization).

These are all customizable, but the more you customize, the more difficult it is to upgrade. BEA seems to be the most customizable, but requires the most time to bring a portal up to production.

Re:Zope

[Scaba]

1. Easy management : yes and no. It's full of "objects", "class", "methods", etc. I can understand that; my client cannot.

Java, Pascal, C++, Python, Perl, etc. are all also full of objects, classes and methods. The programmer's job is to hide these things from the client behind a friendly interface.

2. Separation of code from content : if you don't count DTML as "code", that may be true.

Somewhat true, for DTML. However, Page Templates were recently introduced and they (mostly) separate code and presentation quite nicely.

The zope.org site suck big time. The search engine lack option and return too many hit without any regard to revelance.

Well, most search engines suck; that's why I use Google with the "site:" constraint.