companies contributing to X

[Eirik Byrkjeflot Anonsen]

Matt Dew <matt at osource.org> writes:

> On Thu, Nov 25, 2010 at 5:36 AM, Eirik Byrkjeflot Anonsen
> <eirik at opera.com> wrote:
[...]
>> 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?

Not competitors to X.Org, but competitors to their company.  If they
improve X.Org, they also improve the software stack of their
competitors.  Also, if they have a good market share, a common software
stack (like X.Org) makes it easier for their customers to switch to one
of their competitors, as there is a large layer of compatibility in
place.


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

I figure this is pretty typical for a lot of closed code.  It is hard to
justify putting in the effort to bring code from "shippable" to
"maintainable" when there are so many other important bugs to fix and
features to implement.  (I'm sure this applies to open code too, by the
way.  But I think some of the social mechanisms surrounding open code is
less conducive to this kind of thinking.)

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

There is the option of attitude adjustment through propaganda.  There
are benefits to getting your code into X.Org, most importantly a lower
maintenance burden.  Also, as long as X.Org maintainers must accept code
before it enters the X.Org codebase, this also somewhat doubles as a
free code review.  (Not everybody likes code reviews, but it usually
makes the code better...)

And even if the code isn't accepted, it could be the push that makes
X.Org developers implement the feature themselves.  There's nothing like
demonstrating a (partial) solution to a problem to get other people to
put some work into that same problem :)

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


I see I forgot one other issue: The IP rights management maze of the
company needs to be successfully traversed before any contributions can
be made.  This can be a huge issue, as it involves getting the company
to make a legally binding commitment.

Apart from making sure the X.Org licenses are generally palatable, I'm
not sure what else can be done about this.  FSF has some boilerplate
legalese that many companies feel reasonably comfortable about signing.
Something like that could be an idea.  Then again, FSF requires a real
signature for transfer of ownership of code before accepting
contributions, which does make the problem more pressing.

eirik