Wrong paradigm [LWN.net]

Wrong paradigm

Posted Dec 9, 2004 10:28 UTC (Thu) by zooko (subscriber, #2589) [Link]

> 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.

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,
FreddyH

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.
....
Company A adds ... feature X back to the public Linux. B will eventually pick up on it ... but A has had advance notice of and experience with the feature, and is months ahead of B in making use of it....

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,
Wol

Wrong paradigm

Posted Dec 20, 2004 8:24 UTC (Mon) by craigmcc (guest, #26784) [Link]

>> ..and have no assurance that needed features and capabilities
>> will be built into Linux.

> "Oh, dear me, we're so helpless. We want these features and
> capabilities and we're totally at the mercy of the kernel
> development team to put them in there. We couldn't possibly
> code them ourselves or hire someone to do it."

> Sounds like some people still don't understand how to work
> with free software...

Alas, this attitude is exactly why FOSS is not being accepted at the rate it really should be. In order to gain mass popularity, Linux software developers need to understand that:

* There are people in the world who are not
technically capable of "code them ourselves" --
in the case of the Linux kernel, I'd certainly
classify myself in that camp, although I am more
than middlin' capable at software development
within my domain of expertise.

* There are people in the world who are not
willing to "hire someone to do it" and then
have to figure out how to (a) hire such people
(or acquire an appropriate contractor), (b) figure
out how much to pay them, (c) understand how to
manage them.

The reality of the world is that many people are more interested in the results of the software development process than in the process itself. Microsoft (and many other commercial software companies) understand these principles -- that's why you can actually make money at software. But it comes down to goals.

If the attitude proposed by this response continues to be the standard attitude of FOSS developers, then we'd better assume that our potential market share is limited to the number of users both capable and willing to either do it yourself, or hire it done. On the other hand, if we truly want to offer a compelling alternative, we need to (gasp!) listen to the needs of our (potential) users, and meet them on their turf, instead of ours.

The real world doesn't care about whether they "know how to work with open source software." The real world only care about solving their problems. Are we willing to help, or are we going to continue to sneer at them?

NOTE - either answer to this question is perfectly legitimate -- just don't be surprised when the consequences of these two choices are different.

Craig McClanahan