There are quite a few fundamental differences between XOOPS and Mambo (I don't know Xaraya well enough to comment). Far too many differences to list out here, each with their positives and negatives. It really comes down to what your needs are.

As for themes, if you are looking for free themes than yes, they are all variations of the same monster. That's not to say you can't do more though yourself, or hire someone to.

A few of my sites for instance are not similar (I think) to others.

http://www.gaining-mass.com
http://www.mmaglobal.com
http://www.fantasyasylum.com

these are a few that "break" the mold a bit, although they are all still "magazine" style layouts.

I think you guys may be missing the point behind a dual license, you would have the CHOICE of downloading a GPL version or if you choose to use it in some type of a business offering (packed with your branding) then you could buy a commercial license allowing you to do so. I imagine, at least from my point of view, you would do the same with a module. DL the GPL version if you just want it for your site, buy a commercial license if you want to sell a bundled version to a client as your own.

This allows BOTH a GPL and commercial approach to the software. The code isn't closed per say, it is just a different license giving you the rights to use it in ways the GPL doesn't.

So XOOPS really wouldn't change at all, it would simply add the ability for the system to be used in a commercial offering (Hosting companies, design companies etc could all resell modified versions with support to their clients under their own brand).

Does this make sense?

On a side note, something needs to be done about the timeout times for login. Trying to do a long post like above, if you don't save it locally you lose it all since you get logged out during the creation. When you try to post you get "You do not have permission to post here" and get sent to the homepage, very frustrating if you don't already know this happens and lose 20 mins of typing. :)

Hmmm, no idea how I missed the progression of this thread, considering I started it :)

In quick response to my comment about an application framework, if you think of modules as little applications (which they are) using the XOOPS "frame work" to accomplish certain aspects (Auth, DB access, Presentation handling) then I think you can see why I call it such. Yes I suppose it could be called a library, but a library is nothing without the applications that use it, XOOPS on the other hand can be used without any modules (I don't count the system module as it's part of the core).

<begin rant>
Comments on the system design:

Almost all "CMS" (really portal scripts) in the Opensource community right now "attempt" to follow the MVC (Model, View Controller) pattern in some way or another. XOOPS is loosely based on the Page Controller using a Template View to handle the View portion, Mambo is a Front Page Controller and while it also implements a Template View it does so much differently than Xoops. It uses PHP and not a template engine like Smarty. This to me makes perfect sense, since PHP is in fact a template engine or at least it was back in the early days of C. Just as PHP developed into its own full scripting language, so too is Smarty but the one crucial difference is Smarty needs PHP to interpret it. So we have Smarty->php->C, which is an unnecessary layer of processing. Is it really easier to learn Smarty than to learn basic PHP??? For a good read concerning templates, read thishttp://www.massassi.com/php/articles/template_engines/old/ . Now I'm off topic, let me get back on track.

In order for XOOPS to be a contender in the CMS realm, as Herko mentioned, it needs to completely separate the three layers (or 4 really if you consider the page controller). Right now there is far too much presentation logic contained in the Page Controllers of modules and other pages. The page controller should simply be the facilitator of input data from the user, relaying that to the Model layer (Business/application logic) and telling the View layer(presentation logic) that something has changed in the Model layer and it needs to update (i.e. refresh the screen with new data from the model). The model should not be concerned with the data it's receiving, nor the data it delivers, it should only be aware of itself, and in the case of web apps, the data access layer (which is part of the model, but in N-Tier systems considered a separate layer).

Once this is achieved, multiple View layers can be developed(XML output, RSS, HTML, XHTML, Print, PDF, etc etc) and multiple Data Source Layers (DB, XML, SOAP, Flat File) without any problems at all.

Moving back to the CMS functionality; as has already been mentioned, one of the most crucial points of a Content Management System (funny how the words really do explain it all) is, well, managing the content. This not only includes the ability to add and update, but also the ability to manage the flow of which the content is produced, and by whom. While Groups are a step in the right direction, these are still geared towards a portal system managing web surfers, not workflow.

While I could list a million "features" to add to make XOOPS that little bit closer to a CMS, I find myself now asking, "Are we asking too much"? Is trying to combine Portal functionality and classic CMS functionality simply creating a beast that's only half assed at both? Are we trying to be too many things for too many people?

For me, the answer is yes! And for that reason, I've decided to pursue other avenues to fill my need for Content Management, and continue to use XOOPS for Portal site (Something it's VERY good at, the best IMO).
</end rant>

Try to remember that having the right to sell a module doesn't mean you have to, should or even could sell it. For the most part, and no offense to the developers, 90% of the modules would never make any money, people wouldn't pay for them. So the developer can either release it for free or keep it to himself. He will most likely not get anyone to pay for it, IMO.

What it WOULD encourage is for people to step up the quality of their modules so they might have a chance of making money, thus improving the quality of business level modules available for Xoops. Atleast this is my view on it.

Quote:

You sound just like me :)

Quote:
I'm right downtown, about 2 blocks from the Eaton Center. :)


Quote:

Yeah, I think so too. However, the core developers of X3, if indeed it was a complete rewrite, could go this route I suppose. Although I'm sure this would open a whole other can of worms

Quote:

Ture, there's a quote I'd love to reference but I can't for the life of me find it, basically it was along the lines that relying on selling services for a product (support, installation etc) to support developent of the product wasn't a very viable business module and many companies using this module fail. Note that I mean businesses, not an individual like myself selling these services, since I am only supporting myself.


I defineitely think there's an advantage to a company releasing code to the public, but also having means to pay a small core group to develop the product on a dialy basis, Redhat and MySQL are great examples.

Xoops has reached a point that it is, or almost is, a viable product for corporations and possibly even developers looking to sell a modified verson to clients (not just the service). So this is an interesting debate and I definitely find myself slowly in need of something along the commercial license lines.

Getting back to the dual license stuff, I found some more info and answers.

Here's a little FAQ I pulled from open office.org with regards to subitted code and how it "could" work with dual licensing.
Quote:

I haven't read all of this yet (large white paper on dual licensing) but it looks promising.
http://opensource.mit.edu/papers/valimaki.pdf

Quote:

It is my understanding that the copyright holder (Xoops.org) withholds the right to release XOOPS under other licenses. I could be wrong though.

This leads me to another question, would a dual licensing model (like MySQL, MAMBO or EZPublish) be another option? Essentially there would be two licenses available for Xoops, the free GPL license, or a commercial license giving the right to rebrand and sell versions of XOOPS and develop modules under a commercial license. The only thing I'm not sure of is if a module is developed under the commercial license, can it be used under the GPL version without taking on the GPL license itself? I've tried searching the web for an answer but haven't found anything yet to that exact question.

Could you restrict module use to only commercial versions? Thereby allowing people to develop modules for either the GPL version (open) or the commercial version (closed)?

Another question is how improvements submitted work. If an improvement is made to the GPL version, can it be included into the commercial version or does the improvement need to take on the GPL license??? Not really sure how mambo and eZpublish work this since I'd assume their software is essentially commercial and then grants a GPL cversion afterwords, since you couldn't do it the other way around... could you?

Gah, I've been reading licensing sites for hours now and I'm more confused then when I started. lol

I definitely think a dual license could be a possible solution that satisfies both sides, the GPL for free use, and the commercial for those wishing to do more with Xoops. The only thing I'm not sure of is how this would work with XOOPS since Xoops.org isn't really a company, while the site owns the copyright, no one person owns the site, or do they? Would Kazu?


References and discussions of interest:

Here's a great write from Mike Olsen at Sleepycat (Berkeley DB), a company currently using the dual license. Has some great reasons why a corporation would not use an Opensource product, but would if it were duel licensed.
http://www.linuxworld.com/story/33893_p.htm

FAQ on MySQL's Dual License
http://www.mysql.com/company/legal/licensing/faq.html

Interesting discussion concerning eZpublishings dual license
http://ez.no/community/forum/general/license_issues/re_gnu_gpl_license_finally_answers

Duel licensing as a marketing approach
http://management.itmanagersjournal.com/management/04/06/24/2057239.shtml

Don't get me wrong, I don't have a problem with pay for products. What I do have a problem with is the weesly tactics they used. Put out a free product, claim it will always be free, wait till thousands of people are using it each with thousands of users in their DB and then turn around and say, " well now that we know it would be a huge pain for you to switch products, guess what, we are going to charge you". Knowing full well they've got atleast half their users by the balls and they're gonna have to pay because they simply can't migrate their large user DB to another system. That's slimy if you ask me.

This is why a company should never own an opensource product. Samething happened with Redhat linux, and I'll almost gaurantee Mambo will do the same since it's owned by a company who already sells a version of it. They wait till their "opensourced" project has reached a point that it's now a viable product agianst other pay-for CMS systems and shutdown the opensource code for further releases.

I believe Koundashi from bbpixel is switching gears and concentrating on phpBB now, which is still a good forum and may be worth looking at for you.

I know the feeling, I also use IPB on my site and I'mextremely upset that they made the move to pay for software :(