Sales arguments for Jetspeed 2

[Thor Hovden <th...@hdlab.net>]

I am considering using Portal technology next year. As a portal newbie, I
have understood that portlets are easy to develop (subclassing Portlet
class and implement 3-4 methods) because of the framework provided by the
portlet standard / JSR-168. Putting portlets onto a Portal should follow
JSR-168 and should not be too complex.

If this means two JSR-168 conformant Portals could be easy exchanged, then
I am interested in knowing the sales points of choosing Jetspeed 2.

What are the main reasons why I should choose Jetspeed 2 over another
Portal solution, say, Liferay (which I recently found out is a JSR-168
conformant open source portal as well) ?

I am already aware of the argument that it is a Apache project, and thus
of potential high quality. If this is the only argument, what constitutes
this quality?

Thanks,
Thor Hovden


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

Re: Sales arguments for Jetspeed 2

[Raphaël Luta <ra...@apache.org>]

[I have redirected this question to jetspeed-user since it's not
  related to the development of jetspeed by itself]

Thor Hovden wrote:

 > I am considering using Portal technology next year. As a portal newbie, I
 > have understood that portlets are easy to develop (subclassing Portlet
 > class and implement 3-4 methods) because of the framework provided by the
 > portlet standard / JSR-168. Putting portlets onto a Portal should follow
 > JSR-168 and should not be too complex.
 >

Just to start the discussion, JSR-168 is all good and nice but don't
expect to implement any major undertaking without either depending on
some portal specific features or (re)developping your own glue time
and time again. As an example, look the inter portlet communication
features of the spec to see what I mean or try to figure out how to
allow a portlet alter the keywords associated to the portal page
where it's displayed...

 > If this means two JSR-168 conformant Portals could be easy exchanged, 
then
 > I am interested in knowing the sales points of choosing Jetspeed 2.
 >
 > What are the main reasons why I should choose Jetspeed 2 over another
 > Portal solution, say, Liferay (which I recently found out is a JSR-168
 > conformant open source portal as well) ?
 >
 > I am already aware of the argument that it is a Apache project, and thus
 > of potential high quality. If this is the only argument, what constitutes
 > this quality?
 >

<disclaimer>
I don't know very well Liferay or Exo which are the 2 main other 
Java-based OSS Portal so I'll let them explain their own features
</disclaimer>

I think it's possible to answer in two parts: Jetspeed is an Apache
product and as such you get 2 sets of benefits, one mostly technical
specific to Jetspeed itself and the other mostly non-technical related
to the ASF structure and way of working.

Jetspeed specific:
- Jetspeed 2 is built from the ground up around JSR-168 using a very
   flexible component based architecture. This creates a huge delay in
   having a product ready but should guarantee a smooth evolution of
   the engine in the next few years.
- One of our developper is part of the JSR-168 Expert Group (David
   Taylor) and thus we have some opportunity to participate in the
   evolution of the specs.
- We have a host of features either already available or in development
   (flexible and user customizable page model, pluggable security
    modules, etc...) and a CMS module soon to be integrated (JCMS).
- A host of features than others will be better positioned to
   explain than myself... ;)

Apache specific:
- Meritocratic community of peers: if you're willing to collaborate
   with others and work to high quality standard, it's easy to get a
   committership on a project and thus help integrate the features you
   need and participate in Jetspeed evolution.
- No controlling company: one of the great concerns of the ASF is to
   ensure that project communities are balanced and not completely
   controlled by a single commercial entity. This is sometimes an
   hindrance when consensus is hard to reach but a great guaranty
   for our users that the project will survive the loss of one
   core developper (Jetspeed project founder, Kevin Burton, dropped
   four years ago). This is a critical difference with Liferay and
   Exo which are both directly tied to a supporting company.
- Strong oversight: the ASF has some specific policies that need to
   be implemented by all its projects and are enforced by the project
   PMCs (Project Management Committee). These policies especially deal
   with licensing, IP protection, etc... and aim to minimize the legal
   risks for all the participants (developpers, users, etc...).

In general, the ASF structure tries to make sure you can *trust* this
project and community to survive the test of time (Jetspeed is nearly
five years old) and we (the Jetspeed developers) will be very happy to
let you actively participate in the development.

If you need some specific features developped, you'll also find a lot
of service companies with some knowledge of Jetspeed to help you (as
well as quite a few committers who can do customer-specific
customizations).

-- 
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org