Hi,
I basicly agree with Maltes views, and thanks for the "translation".
Even though: I think that our categories are better... :)
Just a joke. Forget it. Talking seriously: There are some duplicated models between OpenACS and P/O. However, I've carefully studied the OpenACS stuff before branching off, so there were some very good reasons why I choose to invest so much effort in "simply duplicating functionality". These differences mainly are related to runtime-extensibility and a higher usability (newby-proofness).
Runtime Extensibility:
This is a simple issues with big consequences. For example, it means that you can't update a standard OpenACS system via "CVS update" or "APM upgrade". OpenACS would loose most of its customizations. In contrast, P/O stores (most of) these customizations in the DB, effectively preserving them between updates. This is essential if you want to sell (not only in monetary terms) a "product"/"solution" instead of a "toolbox". Is this better or worse? Depends. Our model is more complex. But Malte is right, it's just a different way. However, we won't be able to revert to the Portlet model for these reasons.
GUI, Integration and User Friendlyness
Malte says:
Offices / Customers. This can be represented [...]
Completely correct. Toolbox against solution. OpenACS follows the toolbox approach, which is perfectly aligned with the way of how most people in the community use OpenACS (how they earn money with it). However, you should not expect that anybody outside the community is going to use the combination of project-manager plus contacts. Or mix in some stuff from e-Commerce? These options are not usable out-of-the-box and they are not integrated. I don't say that there are _no_ links between the modules. But there are many processes that are not integrated. And that is a very, very tough barrier for everybody outside the OpenACS community.
Anyway, I really like how we come down in this discussion to the differences between OpenACS and P/O. This is why I feel that we are not really violating "the spirit" of the GPL. We have discarded and redesigned a considerable part of the OpenACS kernel in order to provide users with a "solution". This "solution" focus is something that is not valuated very much in this community (I believe in open-source communities in general).
Btw., I think that there is actually a vey similar conflict going on right now between the OpenACS community and (some users of) dotLrn, if I'm allowed to comment on this as an outsider 😊
Bests,
Frank
