Fragmentation can be a powerful tool when you're a large player in a market. Consider the "embrace and extend" strategy.

Very true. However, network effects at the scale of an individual decision are weak. If I am considering taking some package proprietary, adding a feature, and selling the modified package, I am faced with the decision of whether or not to give myself a strong, if temporary competitive advantage. Sure, the original package may catch up with me, but if I play my cards right I'll be playing Scrooge McDuck in my basement vault by that time. Further, the catch-up date can be delayed if I hire as many smart people from the package as possible to work on my fork.

Or, it may never catch up, if fragmentation (or any other effect) destroys the market for the product in the mean time. I've wondered if that had any role in the rise and fall of Lisp machines; I'm a little too young to have direct experience there.

In practice, however, what typically happens here is that you have your killer feature you want to sell, but will find other things you want to fix. You don't want to maintain all of your fixes yourself, so you try to modularize your enhancement off, and contribute everything else back.

Failure to do this means you end up with high maintenance costs if you want to pull in enhancements from future versions. So the fragmentation tendency is only partial. You have to either fully go your own way (usually suicide) or you have to give almost everything back (which opens up the possibility of competing with the community).

Sure people may choose unwisely. They will suffer the consequences and maybe learn lessons the hard way. ;-)