Good vs. Great Redux: Communication
It turns out Hacker News thought my Good vs. Great article was decent enough to hit the front page, which is awesome. The message, however, may have been lost behind the GitHub/Tender Support discussions.
If I Feel Appreciated, I'm Coming Back
This applies to open-source projects just like it does to SaaS startups: if I feel like my voice is being heard, I'm going to care a lot more about your product/project than I would otherwise.
GitHub took care of me. I had a real issue with their service (which I'm not even paying for yet), and I got a response in what, for me, was record time. That builds goodwill. Their issue tracking system – Tender Support – is really good, but that isn't the point. It's the people monitoring the account that communicate with you that makes the process good.
If You Don't Care, Why Should I?
Conversely, almost everyone that's worked with open-source has had the awesome experience of filing a bug, then waiting, then waiting some more, then having it closed as WONTFIX with no reason or something.
It's certainly a project's prerogative to assign resources as they see fit, but that doesn't foster a feeling of "Oh boy they really care!" that a more proactive solution does. Even if the issue was inconsequential in the long run, ignoring it doesn't give that person any incentive to come back and continue QAing your project for free.
Startups, Listen Up
If you're running a software startup, this is Big. Customers – especially the non-technical variety – will fall in love with you if you buck the software world trend and actually respond to their issues.
At the absolute least publish a support email address that filters right into your bug tracker. Customer's issues should be given the tip-toppest priority until a developer has politely responded and classified it otherwise – this priority should be communicated to the customer.
On the other end, go all out and publish a support phone number. Think you don't have the resources for a full support department? The Company gives our customers emergency 1-800 numbers – we have one for each major project or client. There's maybe fifteen of us on a good day. Support calls ring to one dedicated employee first, then ring a handful of other employees/owners at the same time. No 1,500-person call-center, just a few guys that want to let people know we're listening.
Both of these methods involve actual people responding to issues. As hackers, we can fall into the trap of thinking the Support issue is solved by a Bugzilla instance, but that only maybe works for OSS projects. If you're taking someone's money for your service, make them feel like their issues are your issues.