Nabble has a small team. We want to have a great product with cool features, so we have been working hard recently on development. While this is good for the product, we have less time for free support. So we plan to start a paid support forum soon and the price will be around $100/year.
We will be very responsive to messages posted in the paid support forum. We will pay special attention to feature requests and ideas provided by our users. The free support forum will continue to exist, mainly because we want people to post bugs and other problems for us to look into. The difference is that it will have less priority for us.
Please let us know what you think about this idea.
Official Nabble Administrator - we never ask for passwords.
SteveM, the main purpose of charging for support is to cut down on the amount of free support that we (mostly Hugo) do so we have more time development. We don't expect to make much money from support and we don't think we could make much money from ads either. We need to make Nabble into such a great product that many more people will want to use us, and this takes development time. If you want to take the job of providing free support in exchange for getting all ad and opt-out revenue, that would fine with me.
It was my sense that pending upgrades (templates?!) have been a priority and that has affected Hugo's availability. I want to do whatever I can to help Nabble survive and thrive.
Hugo seems to be saying that the fee is not about revenue really, but more about reducing demand for support. I have actually paid for support over the last few weeks on issues that were critical, so effectively I have paid and reduced demand on the support team.
$100 feels a little steep to me. But I would pay it. I think $20 or $40 might cut down on demand considerably and still achieve the objective. I also think that IMPROVEMENT requests (how do I do this?) should be in a different category than MISSION CRITICAL (my forum is not working).
Nabble has been so generous that "customers" have very high expectations - some unrealistic IMO. You may need to move incrementally toward a normal business model.
ONE more thing: There should be more resource threads. It's not really your job to teach us CSS, but many of us don't know it. If you did a thread for specific recurring topics, it might save you some time.
The biggest problem with turning off the "free embeddable forum" link on your forum is that it is yet another small feature for us to implement. Everyone has their own pet concerns, which is the whole point of having paid support. If you ask for this in paid support, then we would figure out a solution for you, either paid or free.
I find it a little hard to understand how $100 per year can be considered steep. But we will certainly consider hardship cases. If you are willing to do something for Nabble like help with free support, then we could give you free "premium" support. So in SteveM's case, I think it would make sense to give this to him for free in return for his help in the free support forum, and then he can ask for removing that link, and then we will do something about it. But I will check with Hugo on all this.
It's just Hugo and I working on Nabble development, so we don't have much time for documentation right now. But even more important is that we are very busy changing Nabble from what it is today into a completely flexible CMS system. This means any documentation would quickly become obsolete. So I think we are better off giving high quality support to paying customers to help them take advantage of this transition. We can work on documentation when things stabilize.
I don't really want to do case work right now because I want 90% of our development to be to make Nabble more generally useful. But I recognize that support generally sucks, not just for software, but for almost everything these days. By offering paid support, we can deliver high quality support to a limited number of users and make sure that we are developing what users actually want. If these users ask for features, we will give them a straight answer. If it isn't to much trouble, we will do it. Otherwise, we will try to give an intelligent estimate of when we will have the features in place to make the feature possible.
As an old-time marketing man, I don't think that charging $100 pa just for fast support would be attractive. After someone's played about with Nabble for a while (and been discharged from the rest home ) they don't need much support - except when their site goes pear-shaped. That's likely to be a Nabble bug, not a user error, so Nabble shouldn't charge to fix it.
So I wouldn't pay for support itself.
Instead, how about charging on a sliding scale for forum traffic? A Nabble customer who gets only 100 views a day might pay a token $1 per month. Someone who's getting 1000 hits per day could pay $5 pm. And so on. (Let's not do it on the volumes of posts/replies. Some 90% of forum visitors never post, I find. And not all forums want posts.)
That's how Wufoo and FormAssembly do it. Wufoo charges a flat annual fee, on a sliding scale based on volume, with upgrade options as volume increases. FormAssembly charges as you go, and starts low, an option more acceptable for newbies.
For example, I have ten Nabble forums on two commercial sites. A volume customer? No. I haven't really promoted my sites yet, so the forums get little traffic (and they make darned little profit). I'd happily pay $1-$3 pm, just now. If and when I get 1000 hits per day, I'll cough up $100 pa with a happy smile
No , just no
IF this goes paid support, i will change all my forums to PHPBB/myBB
its far more advanced, free,Open Source and allows more customization.
And 'Free' Support Forums.
If you guys want to make money,then use google ad sense and all these other ways,
PAID Support?? Who the hell is going to buy that??
They might aswell get Vbulletin and get free installation and free support!!
Kills the whole point of nabble in the first place.
This is so ridiculous.
I dont get why you dont hire staff, or moderators who are willing to help for free in the site etc.