My votes:
-1 Billing system
This has nothing to do with server administration. We should concentrate in one thing and do it well instead of trying to cover everything. It would be much better to provide the required hooks so that external billing systems (WHCMS and the like) can be used with i-mscp.
+1 Cron system
So long as it is administrator-supervised as Kika proposed.
-1 User-editable php configuration
First of all, notice that right now the user can modify its php.ini settings by modifying the php5 starter script and telling it to load the php.ini from another place. Therefore, my point is not about security reasons (you have to slightly trust your users, with the proper monitors in place to detect abuses).
However, allowing users to easily modify the php.ini trhough the GUI is calling for troubles. Max upload limit reached? Hell, change it to 2Gb so that we never find this again... and the server is suddenly vulnerable to easy Denials of Service. To summarize, I think that php.ini settings are in the server admin's domain, not in the user preferences domain. If they need something changed, try to make them ask the admin or they will break stuff without no one noticing.
-1 Advanced backup system
I'm against this because I think that there's no backup solution that fits all the potential i-mscp users.
First of all, the gzip/bzip backups that we do right now are extremely bad because they impose a huge load to the server, possibly killing it (by io/memory starving) in the process. Thus, I would remove these periodic backups altogether.
As I see it, there are two kinds of backups:
1. User backups: these are backups of websites with their databases. The users themselves should be the ones responsible of performing this type of backups (using ftp and mysql/pma), not the server.
2. Server backups: including websites/dbs/mails/configs. The best way to backup the whole set of resources stored in the server is extremely dependent on the specific deployment. I use a centralized backup server that makes periodic copies of all my servers using rsnapshot. Other people might prefer rdiff-backup, bacula, or any of the other myriad of solutions out there. Furthermore, my backup shedule doesn't need to match anyone elses, and having plain FS vs LVM2 vs BTRFS significantly changes how backups should be done.
Therefore, I think that each admin should chose and implement the best solution for himself.
+100 API Support
Yes, I think that having an (as complete as possible) API is not just a nice feature, but the feature. Aside from billing and order systems, an api would allow for many other things. For instance:
- Webmail plugin that allows users to change their pass and set their vacation message. Since it would be using the api, the plugin would *not* have to be updated for each new panel version.
- Custom panel that allows an admin to see/control some things on many servers at once. For instance, just having a unified list with all my clients' domains, and that redirected me to the corresponding panel on click would be a great time-saver for me.
+1 Full DNS magamement
This is a much needed thing. Allow admins/resellers to define the "templates" (to be stored in the db, in the form of records that use placeholders), and then allow users to modify both the zone's properties and all the records.
+1 Different webmails as plugins
Define a plugin interface to allow the admin to install different webmail packages. Something similar to the "software installer" but specifically for webmail packages, that end up well integrated in the GUI. This would have two advantages:
1. No need to fight over which should be the default webmail package (don't include any webmail package in the installation, and let the admin install the one(s) that he wants when configuring the panel).
2. Webmail packages can be updated without requiring new panel versions. This is extremely important because as of now we are forced to release a whole new version of the panel whenever a security issue appears in the included webmail!
-1 Support for DSPAM
DSPAM does not look very well maintained nor developed. It was totally inactive for a long while, and despite they are supposedly working on it again, I have not seen any great progress. Additionally, there are no debian/ubuntu packages for it, so it will be a PITA to properly maintain it within i-mscp.
IMHO, if we have to integrate any antispam software, the best option would be amavisd-new+spamassassin, which also does a pretty good job and is much better maintained.
-1 Support for PureFTPd
Don't get me wrong. I have nothing against PureFTPd, but why would it be better to use it? I simply think that it would be better to focus the development efforts on the other features discussed in this thread.
Edit:
+1 "Debug mode" switch for the websites
I think it would be great to give users the option to switch their website to a "Debug mode". This is, when debug mode is activated, php is setup so that it produces verbose error logs (in the phptmp folder), apc is disabled for the domain, mod_rewrite logs are generated, etc. (I know I thought of other settings, but my mind is failing me right now hehe). This would be a great help when trying to see why a website is failing. Obvisusly, debug mode should somehow deactive itself after some time (1h?) to prevent users leaving it always on and degrading the server's performance unnecessarily.
