Luc Verhaegen <[email protected]> writes: > On Wed, Nov 24, 2010 at 02:56:32PM -0700, Matt Dew wrote: >> This I'm curious about. Are there more companies that feel it's >> too-hard/not-worth-while for companies to contribute stuff to Xorg? >> I know the linux kernel has this issue, but is X's contribution >> difficulty larger? >> >> I ask out of complete curiosity, not trying to stir any pot. >> Matt > > Yes, a mail like this will get them all to come clean and tell you, > publically, that they do not want to contribute back, and then list > all the reasons why. > > That sounds like a good thing for a commercial company to do.
Meta-grammatically that seems like sarcasm to me. But if commercial companies are blocked from doing what they want to do by some organizational issues with X.Org, I would think it would be in their interest to clarify those issues so they could potentially be improved upon. I can see some reasons why companies would not want to contribute and also not want to say why: - They wish X.Org would just go away, because then they think they'll have less competition. - They believe they gain a competitive advantage by keeping their clever code to themselves. - Their code is so shitty that they don't want anyone else to see it. Admittedly, I believe there is some truth in all three of those reasons, but I would hope that most companies would recognize that those are generally not good reasons. You suggested one possible reason yourself: >> > ... they know that their >> > code will not be accepted, and that it will be reinvented a few weeks or >> > months later. Then they go and use the reimplementation afterwards, and >> > save a lot of manpower and frustration in the process. I'm a little confused by this. It sounds like 1. They implement something useful. 2. They send the patch to X.Org. 3. X.Org does not accept the patch as is. 4. X.Org implements an alternative patch. 5. The company gets an X.Org with the fix they wanted. It sounds to me like this is a win for the company. If they hadn't shipped the patch, the feature would (probably) not have been implemented. By shipping the patch, they get X.Org to implement and maintain the feature they wanted. I'm probably misunderstanding your description. I would assume that the main stumbling block to contributing to X.Org is quite simply that it takes time and effort to get X.Org to accept a patch. And since the company has already shipped it, they don't see the immediate benefit of spending this effort. I would think this is a serious issue, but I don't think there is any way to eliminate it. I expect it is usually true that some time and effort is needed to bring a patch from "it works, ship it" to something the X.Org developers should be happy about maintaining. eirik _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
