companies contributing to X

[Matt Dew]

On Thu, Nov 25, 2010 at 5:36 AM, Eirik Byrkjeflot Anonsen
<eirik at opera.com> wrote:
> 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 took it as sarcasm but regardless, the question is honest and valid.

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

Who are the competitors?  Besides Xi graphics,  do you include FB or
wayland here?

>
> - 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.
>
This one I can definitely believe. :)


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

This one seems most likely.

If it's the in-house developer(s) who isn't all that interested in
giving back and won't go out of his/her way at all, then there's
nothing we can do and I don't want to spend effort here.

If it's an in-house developer(s), who would be willing to try to work
with Xorg devs to get it in tree, then this is the case I'm interested
in.  Can we make it easier for him/her without killing ourselves?

Matt