Matt Dew <[email protected]> writes: > On Thu, Nov 25, 2010 at 5:36 AM, Eirik Byrkjeflot Anonsen > <[email protected]> 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 _______________________________________________ [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]
