IMHO I think a bug tracker does not require a *new* language or compiler or translator or whatever you damn well want to call it – I mean – it’s a bug tracker for Christ’s sake. Jeez.

Why is such a simple concept as “Customers * Price = Revenue” so difficult for some people to grasp? I don’t know where you work, but at most of the companies where I’ve done consulting which use IIS and ASP/ASP.NET, they most definitely do NOT “almost certainly have PHP installed.” And I can say with a good deal of certainty that most of them would not even try FogBugs if PHP was required to run it (bundled or not) as long as there was another bug tracking solution that did not require PHP. In case you’re still not following, that translates to a whole lot of lost revenue.

It’s almost comical to see people trying to argue against Joel’s decision using stupidly obvious arguments that he certainly already considered. It’s obvious to anyone who thinks about it that any single technology stack you propose as an alternative Joel’s solution absolutely WILL cause you to loose a certain percentage of customers. Technological considerations are completely irrelevant to the discussion. The only question is what that percentage is, and whether those additional sales are enough to pay for the extra development and maintenance time. Joel obviously believes it does, and he’s in a much better position to know than you are. If you actually took a second to do the math, you would see that he probably wouldn’t have to increase sales by much for ASP and PHP support pay off – easily as little as 3-5%, which is next to nothing.

Like I’ve said before (c.f. 19, 23), it is not just installing PHP. That is trivial. It is maintaining PHP, making sure you are up-to-date, have all your security patches, etc etc. that kills you.

I refer you back to my first comment – [19]. What I said then:

“What Joel was asked: “What should I do my _brand new_ development in”

What Joel replied: “Some well established language”

What Joel did himself: Several years ago, took his own advice and used an established, well known and tested language – VBScript.”

What Wasabi appears to be about is leveraging his investment in vbscript as the web programming landscape changed to other languages. That is clearly not the same as starting a brand-new development.

In fact, to make this even more clear, the original question included the line: “The project is starting from scratch and so there is no legacy code involved.”

Had the questioner instead stated “I have 5 years of vbscript code developed that I would like to leverage if possible,” then we Joel’s answer may very well have been different.

Answering two different questions (new development -v- leveraging existing code) in two different ways is not hypocrisy, it is a sensible design decision.

Even if they had to invest the equivalent of six full time months a year into maintenance (which I highly doubt it’s even a fraction of that), it would probably still make financial sense for them. If you take into consideration what FogCreek probably spends on payroll without support for both ASP and PHP, they wouldn’t have had to increase sales by that much to turn a profit on creating and maintaining Wasabi.

But now we’re taking wild guesses at FogCreek’s revenue figures, the percentage of sales that are attributable to having installs for both platforms, and the amount of maintenance they have to put in. So it seems like all this hand waving from a bunch of programmers who probably couldn’t run their own business, let alone know the first thing about Joel’s, is just plain stupidity. Say what you want about Joel, but he knows how to run a business. I’m sure he ran the numbers on building AND maintaining Wasabi to see if it made sense. If it didn’t, you can be pretty sure he would have dropped it like a hot rock.

And how is Wasabi not domain-specific? While they didn’t invent a whole new language syntax from the ground up, it sounds like they extended an existing language to provide both syntax and functionality specifically (and pretty much exclusively) for their problem domain.