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

Zope

[Ashish Kulkarni]

try Zope ... it's open source, and very well-known, too.

Re:Zope

[Etyenne]

I had to work with Zope recently and had been quite underwhelmed :

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

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

3. Authentication scheme : I tried to coax Zope into authenticating to a MySQL database. Two package seems to be doing what I wanted. One was full of bug, the other would have required that I port it from PostgreSQL to MySQL.

Quality of module vary greatly. Some are good, but a lot are outdated or broken.

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

Documentation is uneven. It's better than none at all, however.

Error messages are useless. Although it might be nice to know the function call stack, I would have prefered something more informative than "KeyError" for error message. And have a look at the data that made Zope choke, too.

I suppose it's a matter of taste. For the Python freak it might be ok. I personnally dislike it with passion.

Re:Zope

[scheme]

3. Authentication scheme : I tried to coax Zope into authenticating to a MySQL database. Two package seems to be doing what I wanted. One was full of bug, the other would have required that I port it from PostgreSQL to MySQL. Quality of module vary greatly. Some are good, but a lot are outdated or broken.

I don't see how third party packages and modules are the fault of the zope software. Zope doesn't magically update modules to fix bugs and use the latest methods.

Error messages are useless. Although it might be nice to know the function call stack, I would have prefered something more informative than "KeyError" for error message. And have a look at the data that made Zope choke, too.

Why don't you can the error message then? The stack trace is because an uncaught exception is thrown. If you don't like the stack trace, then catch the exception and have the code output the error message that you want it to show. Incidentally, the stack track and exception type identifies the error pretty explicitly. Just based on your description, I'm fairly sure that the error was due to the code trying to look up something that wasn't present in a dictionary.

I suppose it's a matter of taste. For the Python freak it might be ok. I personnally dislike it with passion.

Well that's your problem. You don't like python so you are bitching about the fact that Zope uses python and a lot of Zope modules use python also. You do know that Zope modules can be written in perl as well right?

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.

Re:Zope

[babbage]

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

DTML is but one of several template schemes Zope offers. The technology is evolving fast, and even recent books are a little out of date on this one, but if DTML doesn't meet your needs then check some of the other alternatives. In particular, Zope Page Templates, with their HTML attribute based markup, are a very interesting approach that has the nice side effect of keeping everything within perfectly well formed HTML -- thus keeping the web monkeys with their whizz bang frontdreamy editors happy.

3. Authentication scheme

Again, you have a wide variety of options here -- basically anything you want, anything you could do in pure Apache, etc. A quick search for authentication & authorization on Zope.org turned up this nice paper on the component architecture of the security system.

In general most of your points deserve these kind of pat responses. It seems to me that the Zope system *is* very good, but the software itself is evolving much faster than the documentation is managing to keep up. That's not to say that the documentation doesn't exist -- it does, and help is out there if you want it -- but once the software hits a certain stable plateau a revamping of the documentation would be very welcome. Zope is an excellent system though. What finally won me over was to see a presentation on it at a Boston Perl Mongers meeting and having everyone watch in awe at the things this Python software could do so easily, with responses to the effect of "mod_perl is nice and all, but why haven't we come up with something high level like this?" Good question...

Re:Zope

[Etyenne]

3. Authentication scheme : I tried to coax Zope into authenticating to a MySQL database. Two package seems to be doing what I wanted. One was full of bug, the other would have required that I port it from PostgreSQL to MySQL. Quality of module vary greatly. Some are good, but a lot are outdated or broken.

I don't see how third party packages and modules are the fault of the zope software. Zope doesn't magically update modules to fix bugs and use the latest methods.

Authenticating to a RDBMS is not built-in (more precisely, it was'nt in the version I used) so you need to use a third-party module. If the module for the functionnality you need is buggy/inexistant, it impact the usuability of the whole package.

Error messages are useless. Although it might be nice to know the function call stack, I would have prefered something more informative than "KeyError" for error message. And have a look at the data that made Zope choke, too.

Why don't you can the error message then? The stack trace is because an uncaught exception is thrown. If you don't like the stack trace, then catch the exception and have the code output the error message that you want it to show. Incidentally, the stack track and exception type identifies the error pretty explicitly. Just based on your description, I'm fairly sure that the error was due to the code trying to look up something that wasn't present in a dictionary.

Excuse my ignorance, but I did not understand a thing about what you said. Why can't Zope output standard error messages, like "Can't locate object method "do_something" via package Neat::Gizmo" or "compilation error: syntax error at line 123" ? Also, not "canning" (whatever that mean) error message seem to be the default because I can't recall seeing a helpful error message in the two month I had been battling with Zope.

I suppose it's a matter of taste. For the Python freak it might be ok. I personnally dislike it with passion.

Well that's your problem. You don't like python so you are bitching about the fact that Zope uses python and a lot of Zope modules use python also. You do know that Zope modules can be written in perl as well right?

No, I am bitching because it did'nt fit my needs (no SSL, only Basic Auth in the default install ... I know you can use Apache's mod_proxy but come on!). As for fitting a square peg in a round hole, why not use a square hole in the first place (use a Perl-based portal toolkit if Perl is what you know) ?

What I really don't like about Zope is advocate claiming support for X and Y and, when you are down implementing it, you realise the module had not been maintained in two year and break with 2.5.x.

Overall, Zope leaved me an unfinished, unpolished and akward feel.

Re:Zope

[GeorgeH]

Can you suggest something better? This is not a troll, I may be spending
a good chunk of time learning Zope and if I can find something open source
and better than their CMF I would
love to hear about it.

Re:Zope

[Etyenne]

It really depend on your particuliar situation and what you try to build. Which language do you know ? Which feature do you need ? The only real advice I can give you is to try a little a pilot and make sure all the features you need WORK and are well supported. Ie if you need LDAP support for your portal, don't trust the fact that John Doe said on a weblog that Zope support LDAP; go out and find out if the LDAP module work with current Zope version, if developpemet is still active, etc.

As for recommending another solution, I put a lot of hope in the Horde framework (www.horde.org). Written in PHP, clean OO, easily extensible, featureful, etc. However, the content management feature is in early developement so not really useable yet, and documentation is basically inexistant.

Beside that, I am sorry I have not had the chance to work with any other solution.

Re:Zope

[Etyenne]

Just curious : what make filesystems independance such a deisrable feature for Web portal ? And what are "TTW capabilities" ?

Zope

[Scaba]

Zope may be what you are looking for. It's hard to beat for ease of use, maintenance, separation of code from content, etc. Zope is scalable, can also do enterprise-like stuff, connect to RDBMS and all, use any number of authentication schemes other than its own built-in scheme (LDAP, *nix passwd files, NT domains, databases). I believe you can also run Zope behind Apache w/SSL, which should take care of your security needs. Give it a try, anyway.

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.

Re:Meh.

[greenhide]

My definition of portal is a lot broader than yours, I guess.

I feel that the format of a portal, be it reverse chronological (thus emulating a weblog), or more "frontpage" style, is really secondary to its purpose and use.

My definition of a portal really is an interactive, frequently updated destination point for gathered information, and in this sense Slashdot really excels.

Re:Meh.

[gallen1234]

It seems to me that Slashdot fits your criteria. Above the fold you have the latest headlines, a little advertising and links to other sections. Below the fold you have search functionality, a relevant quotation and links to past stories and other sites of potential interest.

The only point of difference is that Slashdot has the added criteria that all items have a technology slant but even within this restriction there's still the variety you described. Instead of sports, weather and entertainment we have Security, Anime and "Your Rights Online".

Portal Software? What's That?

[photon317]

I would use vi, perl and postgresql, but that's just me :)

Re:Portal Software? What's That?

[greenhide]

"Great. We want it done by next Monday."

Maybe you really could set up the whole works by Monday, but sometimes it's better to take somebody else's wheel, clumsy at may be, rather than crafting it yourself.

On the other hand, if you have plenty of time to develop it, that's great. Coding it yourself gives you the best form of control, but often making these products do everything that is required of them takes much longer than expected, especially since there will often be a lot of back-and-forth exchanges with the client about features that they want.

Re:Portal Software? What's That?

[photon317]

Deadlines are the death of all good software. If the business guys need it done faster than it can be done right, that's their problem, not mine. Plan ahead :)

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.

Document Management

[dimer0]

Document Management? .. Plumtree has this, Jetspeed doesn't. I see this as being a pretty large effort to get this built in. Sure, I can arrange gadgets all over the place, but managing the content on these pages is another huge task I don't believe Jetspeed addresses.

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.

The word "Portal" is too generic...

[PinglePongle]

Different people mean different things when they use the word "Portal", or "Content Management System".
I have worked with one of the market leaders - Vignette - and their product is largely "framework" - you get very little out of the box, and have to do a lot of work to get something running that matches your particular requirements. Even though they sell themselves as a Content Management System, they don't support revisioning of documents.
On the other hand, products like Zope or PHP-Nuke - which also fall under the broad category - are far more like "web-site in a box" applications for content-driven, community-based websites.
On the whole, the big-ticket commercial systems tend to address a bunch of narrow concerns (e.g. documentum is very good at document management, Interwoven is very good at web-based workflow-driven content management), but often are weak in other areas (Vignette (certainly in the pre-version 6 days) is very poor at dynamic functionality so forums etc. are difficult to implement. I would suggest that you make sure any evaluation adequately addresses all the features you require, and ask for reference sites. We didn't and got burnt very badly as a result.

As far as open software goes, I like Cocoon. It requires you to do a lot of work, but should be very easy to work with once you've got it up and running. On the other hand, if you don't want to spend your life working on the portal, get Zope or PHP-Nuke, install it and walk away. They'll prob. do 90% of what you want, and are pretty easy to support.