Thread: Future Qt scenarios...
View Single Post
wmarone is offline wmarone
2011-02-14 , 21:47
Posts: 1,746 | Thanked: 2,100 times | Joined on Sep 2009
#20
Originally Posted by rm42 View Post
While I do agree that having a single common trunk is the best option, I'm not sure I agree that spawning several slightly incompatible QT-derived tool kits would be good for MS. We are talking about developer tools, each with a different name/trademark, not OSs.
Apparently I didn't make myself clear. Microsoft would -love- it if Qt wholly fractured as such. The chance for compatibility goes out the door and suddenly it's too much of a pain to work with "JoeBob's Custom Framework (based on Qt!)" You'd have naming conflicts all over the place, version conflicts, etc.

Fortunately, even BSD I doubt it'd fracture. Hell, that'd make the licensing question even easier for proprietary users.

I doubt this too, frankly. But, it is possible. I just don't think that the benefit they would get from it could compensate for the level of threat of having a viable, top notch, cross-platform, tool kit in the market.
The threat's been there for years, and it's used by many vendors deliberately to avoid platform lock-in and increase cross-platform availability (Xilinx, for instance, uses Qt for their tools.) If it wasn't a threat before it won't be a threat going forward.

The worst thing for who? For MS? I don't think this is their worst case scenario.
No, for people who use Qt. There is no real worst case scenario for Microsoft, since at least on WP7 they bar all non .NET/CLR code (including "managed c++").

I could live with this scenario, but I am not sure it is the best that can be had.
Well, the only thing you lose is the ability to take it proprietary. The desire to do that requires that people who submit code assign copyright, which was a large part of why OpenOffice.org rarely ever got the community involved in fixes. Once you can't take it closed, there's no reason to refuse outside help.