-just my 2 cents
But, we also get thousands of requests a year so we can't do everything everyone wants. Many of these requests conflict with one another, and many of them just aren't a good fit for our products (adding Gantt charts to Basecamp, for example). The good ones, however, often make it into the products eventually. Sometimes exactly as requested, sometimes in a different form, but customer requests are almost always the seeds of improvement.
It is our job to be editors and museum curators. We have to decide what makes it and what doesn't for the benefit of the overall product and the overall customer base. No combination of yes or no is going to satisfy everyone, so we have to work on behalf of the majority.
Every company with millions of users has to say no more than they say yes, we're just honest and up front about it about it. We don't want to set false expectations or promise things we won't be able to deliver.
While this policy may rub some people the wrong way, we think it's the right policy. And seeing that 94%+ of our customers would recommend Basecamp to a friend or colleague, I think we're on the right track.
Perhaps the 94% are not tech savvy enough to identify these problems?
Incidentally, I've read that specific example of adding Gantt charts to Basecamp before:
Unfortunately, the result is customers that can't think for themselves. Anyone with a brain uses someone else's services.
In this case, 37Signals has already been notified. They've been told about other flaws on public forums and not fixed them. What would we be accomplishing?
This strategy works better. Several thousand people have already read Dave's article. We don't have to worry at all about the "wrong people" getting details and messing with other users. This seems like a win-win.
The bug is probably something really trivial that affects a small portion of users in an insignificant way. The secrecy about specifics on the author's part seems to be just to spare him embarrassment at this point.
I'm not sure Dave's too worried about what YC board people think about him, but if that makes you feel better, you can go ahead and keep thinking that.
Here's what I want to accomplish by posting this story on YC (and not Reddit, or anywhere else):
The 37Signals attitude towards feature requests is refreshing and powerful. But if you apply it mindlessly, like they themselves did in this case, you can cause problems for yourself. Not every request is really optional. Maybe this one was --- I'm on the fence leaning towards "they should probably fix this soon" --- but others truly won't be, because they will reveal customer information, lose data, or crash the system.
I think there's a lesson in here somewhere. Maybe it'll just have to wait for an actual incident at 37Signals.
I don't think permitting XSS is a good idea in a shared environment.
1) Pick a company that has been the source of recent controversy.
2) Find a silly security flaw in one of their products that you can make sound serious with a bit of sensationalism. This should be easy to do, because most web apps have a few silly security holes.
3) Inform the company, and when they inevitably assign the silly flaw a low priority, write an inflammatory blog post and submit it to major news aggregators (e.g. news.yc)
Did you read the post? We reported this over a year ago. We notified them repeatedly. We withheld the name of the vendor for over a year as a courtesy. They started with a "soft no", and, when Dave checked in a few months later, they simply ignored our email.
Also: 37Signals has nothing to do with the recent Ruby "controversy" (where by controversy, you mean "someone found security vulnerabilities in it, and some blogger freaked out about it"). 37Signals doesn't produce Ruby; an Open Source team does.
The issue here is that one of 37Signals signature philosophies is "just say no" and be true to your own vision of your product when users request things you don't want to do. Fine. But there's a slippery slope to that logic, and you need to be careful not to fall down it. Some requests that you don't want to do, especially when they come from paying customers, can't be blown off.
I think users deserve more respect even if they're incompetent out of their fields of competence.
That's the real disconnect here. It isn't that responding to secuity vulnerabilities needs a unique process, it's that the author considers this issue significant and 37Signals does not.
[Edit] On second thought, this is a dumb thing to say, and I retract it. I have no idea if anyone's seen it, which is itself a problem. If I was going to assign a cause to this, it's that the cost of fixing this particular bug may exceed the perceived risk of the vulnerability.