Current Poll Rankings

Hi Danny,

Yes, billing has been a clear leader in all of our conversations with folks using Virtualmin. And we already have something up our sleeve on this front (Ok, it's up someone elses sleeve, but it integrates with Virtualmin Professional using the new API, and we've been working with them for a couple of months to make it all spin nicely). We'll be co-announcing the product integration with the other company next Tuesday. How's that for responsive? ;-)

We won't be locking anyone into any specific set of products, but this soon-to-be named product will be the Golden Path to a Billing+Virtualmin setup. It is a pretty popular and well-established host billing system with a responsive developer backing it, so I think it will satisfy a lot of folks requirements without having to do any custom development to make it all work.

Also, the completion of the APIs (remote and shell) allows folks to integrate with <i>any</i> other accounting or billing product as long as that product can be convinced to perform a few actions on the Virtualmin server to query it for domain accounts, possibly create new accounts, etc. One could use it in reverse as well, and have Virtualmin call out to the billing server on domain creation and modification, and use the Custom Fields feature to identify your customer to Virtualmin (so that your commands to your billing system could include a customer ID). At least, I'm pretty sure that would work--and if it doesn't we'd consider it a bug. This would take some coding, but not a huge amount--a good perler could do it in a few days.

We're all about flexibility.

Hey Vernon,

Yes, an integrated support ticket system would be very useful, though I'm not sure how we want to go about it. Writing one from scratch is foolish, as it is a very big set of problems mostly orthogonal to our core goals. It would be nice if there were a simple, but good, ticket tracker that we could integrate (possibly even matching up the theme and running it under the Webmin server...so maybe something in Perl). Most of the existing ones have pretty big dependencies and complex configuration. We'd want one that uses an embedded database, like SQLite or BDB, rather than PostgreSQL or MySQL, because database administration probably should not be imposed on anyone just to have an issue tracker.

This might be an area where third party plugin modules can play a role--maybe we can convince one or more of the existing ticket tracker vendors or Open Source projects to hook their product into Virtualmin. We'll have to see what folks want us to spend our development time on, and whether any existing product can fit the bill in some way.

I've been thinking on it all day (I started this post this morning, and it's 10PM now as I'm finishing it up...I got distracted by FreeBSD installer work), and something is bubbling to the top which might be a useful solution to the problem--without requiring a lot of work--that would integrate very well with Virtualmin. Virtualmin has something called Custom Fields, a per-domain storage mechanism, and an &quot;Email Server Owner&quot; function. Given a small modification to each of these, plus a catch-all email alias, one could construct a reasonable ticket system with minimal functionality but perfect integration and very good ease of use (very limited functionality is almost guaranteed to be easy to use--the Mac is a perfect example of this...if you strip things down to the minimum necessary and do them right, it's often just the right thing for the majority of users, though some power users might miss the flexibility of a more complex implementation). There are several products that I've looked at (both Open Source and proprietary) that have ticket systems like I've just described, very limited but well-integrated with the whole system. I don't know anyone using them heavily to know if they work well for their purpose, however.

Hmmm...Well, just some brainstorming.

Does anyone have any opinion on whether a very simple ticket system like that with the ability to provide tiers of tickets based on whether the logged in user is a domain owner, a reseller, or an administrator, would be more valuable than a full-featured ticket system that doesn't know automatically about those tiers?

There's no way we're going to re-implement something like Bugzilla within Virtualmin, but the more I think about it, the more I think Bugzilla is way too big for this. It took me half an hour to figure out how to file an issue the first time I used bugzilla (five or six years ago, and its gotten easier since then, but it's still way too big for normal users). Maybe we just need simple communication system for discussing issues with the interested parties automatically notified of changes in state and new notes, and with the ability to mark a &quot;ticket&quot; closed.

Anyway, it's not on the plate for next week (stabilization and new OS versions get that honor), but it's definitely something worth thinking about.

OTRS is probably a very good product...but I have a few concerns about it. It is quite complex in its usage, dependencies, installation, and maintenance. It relies on a half-dozen Perl modules, and a MySQL database, among other things.

It might be easier to deal with than I recall, but I have tried to install and use it in the distant past with disappointing results. I ended up dropping it in favor of Roundup (which is not strictly a ticket tracker, but it worked for my needs at the time). I'm sure others know more than I. Perhaps someone with better experience with it will tackle the job of writing a plugin module for it. If the task is going to be big (as I suspect OTRS will be), it might be best taken on as a third party plugin, much like the billing application integration we're announcing Tuesday.

But, maybe we'll find that customers consider this a core feature that we really ought to be focused on until we've got it. (I doubt this will be the case, as cPanel doesn't offer a ticket tracker, and Plesk only has it as an optional purchase which I've found no one talking about online...seems like many hosts like to choose their own rather than have one selected for them by their virtual host administration tool vendor.)

I certainly wouldn't argue with you writing up a minimal proof of concept plugin (or even a full-featured integration with user awareness and other good stuff), Vernon, if you think this is a good direction. You've certainly got more plugin writing experience than anyone other than Jamie. Might be a good challenge. ;-)

Speaking of third party modules, we need to plan on having a contest every year or so to reward the best third party plugins, application integrations via the API, and themes, with fabulous prizes (well, an iPod or something) and heaping praise. I'll have to stew on that a bit and plan to budget for it for a few months from now when folks have had a chance to get a feel for the full API.