> can anyone tell me coherently why Joel didn't push for a rewrite when he received the requirement to support Unix servers?
I probably can: "How much money are we really going to make from Unix servers?"
He almost certainly had people complaining about lack of Unix support. But the question was: "If we expend all this energy supporting Unix, will they pay us enough for it to be worthwhile?"
I suspect that the answer was: "Not really, but we can't bid on enterprise without that support"
So, they had to keep a single, unified codebase to keep the cost to support Unix down while only adding some controlled cost support increase to Windows.
The thing is, for real "enterprise" customers who wanted unix you would just bundle Chilisoft ASP into the quote. They would also probably want to use Oracle for the RDBMS which would dwarf the cost of Chillisoft.
But you still have to do the development and debugging.
I've used lots of closed-source "substitute, but just as good for porting" packages over the years. They NEVER work--sure they get the easy 70%, but they all miss the 30% of edge cases that code somehow always manages to trigger. I am not interested in debugging your porting library so you can make more money, thanks--especially if it is likely to piss off a customer. I will control my customer experience as that is my money.
The only exception to this is if you release your code open-source. Then I might adopt it since I can fix a showstopping bug myself if I need to for a customer.
Here's my litmus test if your closed-source package on Unix might be acceptable: Do you support FreeBSD? My team is smart enough to abstract code in such a way that it can run on Linux/FreeBSD/Solaris without killing ourselves. If your team can't do that, it's just going to get in our way.
Hm, your tone is a bit puzzling. Chilisoft ASP was mentioned in the original article as a "Boom. Done." solution. By all accounts I've seen, it was a complete implementation of ASP. ASP was tiny. There were six objects: Request, Response, Server, Application, Session, and Error. Not a lot of room for undetected edge cases, and if there are, likely not harder to work around than the ones in your own porting library.
Anyway the point is, if you are selling to "enterprise" especially at that time, open-source is a scary, uncertain proposition. Enterprise buyers want vendors with phone numbers and help desks and support agreements and maintenance plans. Your sales guy just says, "Sure, unix, fine, no problem" and bundles Chilisoft into the quote.
Ayup. "Boom. Done." It just exploded, and your company is now done.
There is no such thing as "Boom. Done." when I have to answer the call when it goes "Boom." Enterprise customers won't allow me to say "Call Chilisoft"--they will yell at ME to fix things. If I can't fix it, I lose the customer.
If it was so easy and small, why doesn't there seem to be an open source version of it? If it was so easy and small, why did Chilisoft sell for almost $100 million?
Open-source wasn't scary at all to enterprise vendors as they didn't even know it was there if the software used a BSD-like license. Only the GPL causes enterprise legal panic like syphilis in a whorehouse.
I probably can: "How much money are we really going to make from Unix servers?"
He almost certainly had people complaining about lack of Unix support. But the question was: "If we expend all this energy supporting Unix, will they pay us enough for it to be worthwhile?"
I suspect that the answer was: "Not really, but we can't bid on enterprise without that support"
So, they had to keep a single, unified codebase to keep the cost to support Unix down while only adding some controlled cost support increase to Windows.