Much time and energy has been devoted to analysis of TCO on open source
vs. proprietary systems. I have, for a long time, been overly
optimistic about open source in general. I can attribute this to a very
conservative exploration of open source packages, usually limited to
widely used applications with deeply committed and knowledgeable
communities, such as those that support Apache, BIND DNS, Postfix and
Courier-IMAP on the server side and Mozilla’s Firefox and Thunderbird
applications on the client side.
Recently, however, I have been working with projects that have exposed
me to projects with lesser depth and attention to usability acrossed
many environments. Trying to use the projects together in such a way
that they weren’t necessarily designed to work, but claim to be
compatible, has proven to be more of a task than the websites of each
project let on, do to the complexity and maturity of these projects.
For example, I have been investigating the realm of Java based portal
software as of late. What with the promises of
wikipedia!”JSR-168″{JSR-168} technology combined with an enterprise
level programming language in Java and all of it’s extensions, I was
hoping to develop a nice platform in which to architect a functional
intranet site, but to extend our legacy and seperated systems into the
portal and create a functional and easy to use customer extranet site
as well. What I have actually experienced, so far, is far from the
rosey scenario I originally naively imagined.
I went about things in what seemed to be a logical plan and did a quick
Google search on open source Java wikipedia:”portals”{portal} and found
a few that seemed to be highly regarded:
#1. Jetspeed-2 – Jetspeed-1
was also regarded well, but doesn’t have the JSR-168 capabilities, and
I had already reviewed it quite a few years ago.
#2. Exo Portal

#3. Liferay Portal
Note: JBoss seemed to be good as well, but infant in it’s release. It
also didn’t seem to have much history yet, and even though I like
technology, I wasn’t ready to be a bleeding edge adopter yet.
Before I begin with my experience, please note that I will be
spending more time on all of these platforms to achieve some sort of
satisfaction in my quest for a good portal.
I started with Jetspeed-2. I downloaded the prebuilt package and got it
running in a Tomcat web container after trying and failing to get it to
compile from source. I believe I could have gotten it to compile from
source eventually, but I was not in the mood to commit that much time
to the project just to get a decent example up and running so I could
do a good test trial. Regardless, I found the interface confusing at
first, with not many portlets included, so I continued on my way
recognizing that if I came back to Jetspeed as my choice, I would have
to write a few basic portlets as well as my customized ones.
I then moved onto Exo’s Portal. I can’t remember what the exact problem
was now, but I was just not able to get it to run the way I wanted it
to. It may have been my desire to run my Wildfire
wikipedia!”Jabber”{Jabber} instant messaging server. Regardless, I was
unable to get any of their versions to adequetly run to my
satisfaction.
Finally, I downloaded and tried to run the Liferay Portal. I was unable
to get it working in my version of JBoss or Tomcat, so I finally
resorted to downloading the bundled portal+JBoss suite (preconfigured).
When I did install it, I was unimpressed with the layout and with what
the general consensus around the project said it would do. I’m sure it
was there, I just did not have time to go looking much deeper than I
got to.
Now, on all of these, I didn’t have a good server with more than 512MB
of memory in it to spare, so I kept running out of memory in each of
the circumstances, which is something that concerned me as I was the
only user even configured to login. The sites also seemed quite slow,
though I admit that I hadn’t given them much of a chance to cache the
compiled JSP pages and servlets, that was almost expected with how
often I was restarting the web containers.
Note: Now, I’m going to go onto my general gripe about open source
architectures.
Maybe it’s just me trying to do things that don’t quite match the way
the developers environments were setup, but if a project says it’s
compatible with a certain environment, at very least it should have
basic instructions as to how to set it up, and they instructions should
be kept up to date. Well, the instructions are less important if it
just works, but instructions are what is generally lacking in most
software development projects. And, without structured support
scenarios as you generally find in proprietary projects, accurate
documentation becomes a significantly more important factor in the
success in any open source project.
Now, most people knowledgeable in the open source space realize that
the TCO (or Total Cost of Ownership) of any given project is affected
by the general level of knowledge required by system administrators. It
is, therefore, appropriate to assume that since the general population
of open source projects require a higher level of expertise to install
and maintain, the post-acquisition phase TCO of open source projects is
generally a little bit more expensive. However, this is generally
offset by the low entry cost to these projects and the ability to get
“more bang for your buck” by having access to the source code and being
able to alter the code and contribute those alterations back to the
community.