companies contributing to X

[Eirik Byrkjeflot Anonsen]

Luc Verhaegen <libv at skynet.be> 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