The community is out there and we want Caudium to be a community product. With Roxen® there has always been a conflict between commercial and community interests. Despite minor improvements in that area, the Roxen development has never been as open as many of us would like it to be.
Our plans are to make it better by, for instance, using SourceForge and all that entails - public bug tracking system, task management (so you can see what is being worked on and what is planned), public CVS and more.
We are also making it easier, and more desirable, for the third party developers to include their modules in the core distribution. This includes named CVS access and also offering these people web space and emails at caudium.org. Of course, we will also welcome developers and other people that want to help in other ways.

We want to make a faster and more stable server than Roxen 1.3. Caudium (and Roxen 1.3) is already better than Roxen 2.x in both artificial tests and real world situations.
We also work on scalability which means both the ability to handle many virtual servers and being able to handle high load. Roxen 1.3 is already pretty good at this but there's always room for improvement.

The main problem with Roxen 2.x is that the server is not fully, or even closely, compatible with Roxen 1.3. This, by itself, has caused a bigger rift in the Roxen community than Caudium will. One of our goals is maintaining the Roxen 1.3 compatibility (especially in the RXML context), but we might also try to work on the 2.x compatibility in the future. It is, however, not a major goal at this time.

Roxen (as any software) has always had bugs but there are bugs in 1.3 (and even 2.x) that have been there forever. It is not a rare occasion that patches are made by frustrated users only to be ignored by the Roxen developers. We will try to fix known bugs, like the issue with reloading in MSIE, and welcome other bug reports and patches.

The subject pretty much says it all. Roxen has traditionally been suffering from the "not-invented-here" syndrome. We believe that supporting open standards and de-facto standards is very important for a larger success. Also if there is already code to do something, it's not always a bad idea to use it.

Documentation has always been something which Roxen had lacked. This is especially true when it comes to extending Roxen (programmer's manual) and use of RXML (tutorials etc). It has always been a traditional open source dilemma - people want to program, not to document. It's hard, but we plan to change this. The current development tree contains provisions for including inline documentation of the Caudium APIs.

Caudium is constantly being improved. New features are added very often - either written from scratch and specifically for Caudium or ported from Roxen.

First of all, make sure the server itself is secure. It probably is, but a basic security audit wouldn't hurt. We should take care to look at at the file permission issues. Builtin group-based auth and multiple userdbs per server is another idea.

We also want to standardize names of attributes of different tags. This had been done in Roxen 2.x. We should try to use the same names as Roxen 2.x but should of course also maintain as much compatibility as possible.

The config interface in 1.3 doesn't scale (memory wise) for large ISPs. Another problem is that the code is rather ugly and hard to maintain.

Eventually we should make a RXML2 compliant RXML parser. We plan to do this by making a third "main" parser that use the same tags and syntax form Roxen 2. This will allow Roxen 2 users to use their pages on Caudium without modifications.

Some part of Roxen 2 Module API looks great. Maybe we can consider to make a compat support for Roxen 2 modules?