37Signals "just says no" to feature request: "please fix that security flaw"

Unfortunately, the result is customers that can't think for themselves. Anyone with a brain uses someone else's services.

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. http://basecamphq.com/survey

http://www.matasano.com/log/mtso/ethics/

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?

http://forum.37signals.com/basecamp/forums/5/topics/3155

Suppose we're both basecamp users. It may be possible for me to steal your session by giving you a link to a shared calendar or something with malicious javascript. Or I can steal the login cookie of one of the admins by luring them to my website with a support request.

I don't think permitting XSS is a good idea in a shared environment.

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.

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.

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.