| |||||||||||||
Wrong paradigmWrong paradigmPosted Dec 9, 2004 10:28 UTC (Thu) by zooko (subscriber, #2589)In reply to: Wrong paradigm by freddyh Parent article: The Linux roadmap
> True, however they fail to see that if their competitor uses it, they can use their competitor's stuff as well...
This is not true. If two competitors are both using some free software, and one contributes an improvement or fix then the other benefits. The first gains nothing from their competitor -- they are only helping their competitor at their own expense.
(Log in to post comments)
Wrong paradigm Posted Dec 9, 2004 11:19 UTC (Thu) by freddyh (subscriber, #21133) [Link] On the other hand: the competitor has probably fixed or changed some stuff as well. Or you could learn from how they put their system together. I don't agree that the first does not gain anything from helping his competitor.
Yours,
Wrong paradigm Posted Dec 9, 2004 11:40 UTC (Thu) by zooko (subscriber, #2589) [Link] I agree that the first company may benefit from the second company somehow. However, that benefit is not a consequence of the first company contributing to the open source software. The first company would have gotten that benefit just as well while withholding their contribution.
Wrong paradigm Posted Dec 9, 2004 12:24 UTC (Thu) by nedrichards (guest, #23295) [Link] But they'd have also gained a substaintial and ongoing cost of maintaining an out oif tree patch. This is generally unacceptable, especially for companies where software development isn't a core competancy. Much better to let others do the maintenance of your needed feature for you.
Wrong paradigm Posted Dec 9, 2004 16:29 UTC (Thu) by AJWM (guest, #15888) [Link] The first gains nothing from their competitor (emphasis added)True enough, but consider the real situation. Both company A and company B could use some feature X in Linux that is not presently there. They have several options: 1) Moan about it and wait until, eventually, some independent kernel developer creates feature X (although it's more likely to be X', not exactly X). Until this happens, both A and B are deprived of the feature. After, they both have access to the feature. 2) Company A (or B, or both) can add their own implementation of X for internal use only, and never release the source back to the community. This has its own set of problems I won't bother going into, most of you are aware of them. 3) Company A adds (or pays someone to add) feature X back to the public Linux. B will eventually pick up on it and use it, but A has had advance notice of and experience with the feature, and is months ahead of B in making use of it and gaining benefit from it. Neither does A face the ongoing support issues mentioned in (2) above. True, A is then "helping their competitor at their own expense", but they are not "only helping their competitor" (emphasis added), they are also helping themselves, and moreso than they're helping their competitor. The exact tradeoffs will depend on the nature of the companies, their markets, and the particular feature X. But to characterize some company contributing improvements to Linux as "only helping their competitor" is not correct.
Expanded focus Posted Dec 9, 2004 18:10 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link] Nobody's competing on kernel content (other than coders and teams trying to improve on things :-). Not even Mandrakesoft, Red Hat, SuSE, .... Those organizations are competing on packaging, support, community buy-in(?), whatnot. Both company A and company B could use some feature X in Linux that is not presently there.In the world of my first sentence, AJWM's analysis is even stronger. Company A has no direct use for feature X, rather, X strengthens their own (yes, possibly proprietary) offering. So B must pick up not only on X, but also whatever A has that amplifies X's usefulness to them. At that point, the situation is exactly as suggested in the parent post, but still better for A.
Expanded focus Posted Dec 23, 2004 8:46 UTC (Thu) by Wol (guest, #4433) [Link] Plus the fact that B probably actually wants X''. So in order for B really to benefit from A's work, B now needs to maintain an "out of tree patch".
Then add in A's kudos from doing work - if A now says "we need Y as well", independent developers are more likely to jump in and help.
So A has acquired a head start, code optimised specifically for *their* needs, and karma to help with future modifications. B is left trailing behind...
Cheers,
|
|||||||||||||