Once customers are paying you for a product, it is no longer enough to respond with "we'll see what we can do", "if you really need it", etc. as is custom on open-source projects. In open-source, nobody has any right to ask you to meet any expections. But, in a commercial context, customers need a clear, definitive explanation of what they are buying so that they can judge for themselves what is and is not valuable.
Ilija Studen:A new release that includes fixes to known bugs is nearly finished
rqsweat:Ilija Studen:A new release that includes fixes to known bugs is nearly finished
Ilija, any idea when this update will be available? I'd like to wait until it comes out before my company purchases.
There are a number of issues that I would measure, as a commercial software developer and business owner, to be severe problems:
I. THE "LAUNCH"
The most glaring issue I believe you guys need to resolve is this business of taking peoples money but also saying the launch has not officially happened. You can say it is not official until you are blue in the face. But, the moment you start taking payments, you are entering an obligation to customers. Whatever information those customers have at the time of purchase is what you are obligated to live up to. Otherwise, what you are really saying is:
"We will take your money. But, we warned you not to give it to us yet."
I believe that you should immediately take accountability for the product you are already getting paid for and post whatever "official" announcement you can with a frank explanation of what existing customers and new ones can expect. You should also offer the option for anyone who bought the product before the "official" announcement to recieve a refund if they later learn that the product doesn't contain the features they expected. Even if the announcement doesn't contain everything you wanted it to, it would be far better to have something there than to let this situation linger any longer. It gives the feeling that those who bought early are suckers who are paying to be beta testers and don't really know what they actually purchased. Maybe that's what they really are (me included). But, do you really want to let them be that as their service provider?
II. COMMERCIAL != OPEN-SOURCE
Various questions, requests, etc. have been raised in these forums about features that have been discussed in the past. I believe that you guys need to take note of the significant differences between communication with a commercial company and an open-source project team. Once customers are paying you for a product, it is no longer enough to respond with "we'll see what we can do", "if you really need it", etc. as is custom on open-source projects. In open-source, nobody has any right to ask you to meet any expections. But, in a commercial context, customers need a clear, definitive explanation of what they are buying so that they can judge for themselves what is and is not valuable.
You should post, as soon as possible, a more detailed description of all features. This description should be able to be cross-checked against and clarify any past understandings of what would be in the product being sold. If nothing else, you should post a disclaimer of some kind that clarifies that no implications made in the forums are gauranteed to be in the current product.
As it is, features like time-tracking are something short of the way that they were left described in the forums. You shouldn't start taking payments for that impression unless you have clarified what IS in the product. "We'll think about adding it if you ask us a lot" is not an appropriate commercial response, imo.
III. SELLING ONLY WHAT YOU CAN DELIVER
I had a support problem that took longer than expected to resolve. I have tried to be patient in consideration of this being a newly launched product. However, I realized too that this really is about managing expectations. It only took longer than I expected because the license agreement including a "year free support" built that expectation.
I know that you see support as a way to maintain continued revenue for your work. But, maybe you aren't really equipped to deliver that part of the deal at this time and should focus on product development for now. Instead of offering support for the first year free, why not just leave support out of the sale entirely. You could still offer support in the meantime. It would just then be on your own, realistic terms. Then people won't be in a position to feel let down if things don't happen as fast as they expect. Instead of dedicating a bunch of time to constant support you feel contractually obligated to meet, you could look at building support FAQ's and other troubleshooting guides that would minimize that work load until you are in a position to offer 24 hour, dedicated support and charge for it.
Really, I don't think I am alone in my preference that you have everyone on the team focused 99% on bug fixes and upgrades rather than trying to individually troubleshoot the same server problems that 20 different people have.
IV. CONCLUSION
Again, thank you for the great product. It is inevitable that a transition like this is going to require some steering and adjustments as you work things out. I understand that. I hope that my impressions, as a customer rather than some open-source commentor, will hold some weight and be helpful.
At the end of the day, I think that all of my concerns are resolved by more clear communication. Your level of communication has actually been very diligent in responding to all posts, questions, etc. I just believe that the product related matters need to become more focused and concise now that expectations are tied to dollars.
Thank you for bearing my 10 or 15 cents. :)