It's always the throwaway comment that gets me into trouble - in this case something I said last week about commecial code development strategies:
If you don't think about it much you might think doing the Wintel product first makes business sense, but it doesn't. The right order for almost any code product these days is to do the generic version first, compile and test that under an open source environment like Linux, and then spin-off custom variations for specific markets like Vista or MacOS X.The rule in logic, science, and commercial code development is to always reason from the general to the specific - in the commercial IT development case from a code base that compiles on almost anything, to [optimized] variants that compile for specific target environments like XP/2003, OpenBSD, or Solaris.
The contrary side of this is simple. As quite a few people pointed out, Windows has a dominant market share, for many applications UI considerations dominate design issues, and so developing first on Windows makes sense.
The pro side is less obvious: the basic arguments are that developing a generic Unix version with custom configurations for each OS you want to target reduces long term development costs, improves testing, and ensures your ability to adapt the product, and the company, to downstream market change.
This assumes, of course, that your product is of sufficient scale and generality - if you're developing a fat client extension for IE8, adding a screen to an SQL Server application developed for dot.net, or doing custom development within whatever architecture your employer uses, there really aren't any development environment choices to make.
The options we're considering: develop for and on Windows first while intending to evaluate adding other run-time environments later, versus developing a generic version on Unix first and then compiling optimized variations for specific markets, only arise for larger projects aimed at more general commercial or open source release.
To take an extreme case, imagine yourself about to set up a new company to develop, support, and license software based on some insanely great business idea of your own. Suppose further that your target market is really businesses ranging in size from a few hundred employees to the lower ranks of the Fortune 5000, and that you expect to blow through a few million prepping for your first licensing deal. Now which choice looks right?
The answer has relatively little to do with how you develop software and a lot more to do with the way your customers make decisions about software. The more expensive and the more revolutionary your product is, the higher the organizational level at which the decision to license it will be made - and, the longer term and more risk focused the view of the ultimate decision maker should be.
Sell a Windows security product and the decision will be made for hundreds of thousands of people by a junior buyer at Dell or HP evaluating your $9.00 price against the profit potential in name brand recognition and a $9.99 price tag. Sell complete ERP/SCM "solutions", and each decision will be weighed by client committees loaded with some fairly senior people - and then face final scrutiny at the CEO/CFO and even Board levels.
In the former case Windows only development makes sense - in the latter, developing on Solaris for release on Windows, Linux, and MacOS doesn't affect your ability to pass the nayweighers at the lower levels of the evaluation process, but adds valuable positives at the final committee and top executive meetings.
The reason for that is simple: the guys at the bottom want to know how it will affect their jobs tomorrow, the guys at the top want to know what risks a "Yes" decision exposes the business to over ten or more years.
Most of the guys at the bottom care that you support Windows servers and Windows clients - but they neither know nor care what DTrace is and you'd be insane to mention it to them. Look at your product development process from the perspective of a customer executive evaluating risks five years out, however, and your split development process starts to answer a lot of questions in ways the Windows first people can't.
For example:
Nothing. We develop on Solaris and keep our Microsoft configurations as current as they'll let us - so if they replace something critical like SQL-Server or the win32 API, we'll just replace a few libs and be right there with you.
Not going to happen - but in the worst case scenario our source code for the Solaris/Linux version is unencumbered and we'll give you a contractual commitment to open source it if our finances fall below bank limits. That wouldn't be good news for anybody, but it wouldn't leave you with no options but a forced migration either.
It might, you know about straws and the camel's back right? but we use the hardware we need - nothing more. Internally we use a tool called DTrace, to tell us where we bog down so we can fix it. We can't use that on the Windows side - if Microsoft makes you buy more horses to churn their stuff there's nothing we can do about it - but from our side nothing gets past performance review - and when those guys find problems we've got the tools to fix those problems.
No. You can use almost anything you want on desktops or in the server room without affecting our software much - that's because we do our work internally on Unix and then compile for whatever the customer has. We're selling your guys our Windows product because that's what you've got - if you want to switch everything to Linux tomorrow, nothing about our software will stand in your way. Hell, if you want an iPhone client we can probably do that - not free though.
You get the picture: doing the generalized version first and spitting out targetted versions reduces long term risks for both you and your customer - and so leads to easier sales for bigger packages.
That's the obvious bottom line on this discussion, but there's something else too - a kind of horrible afterthought: a lot of big customers still demand source escrow agreements as part of strategic software licensing contracts, and because just about 100% of those agreements violate licenses those companies have signed with their suppliers, your freedom from that concern can be a powerful weapon taking your competition out of the sandbox.