Re: companies contributing to X
Eirik Byrkjeflot Anonsen wrote: 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. Yet the three companies that own over 90% of the graphics market are the vendors with the best record and continued participation in contributing to X.Org - clearly it hasn't hurt Intel, AMD or Nvidia. All of them contribute to the shared software stack, and Intel AMD contribute heavily to the open source drivers for their chipsets as well. 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. Or worse - other companies, which is why even very pro-open-source, pro-X.Org companies like Intel Sun end up with drivers they can't really contribute. 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. Unlike FSF, we allow companies to retain their copyrights, so that doesn't seem to be a problem (we don't even have an option to allow copyright assignment to the foundation, but we probably should - that would mostly be for individuals though, since it's harder to track down people years later or find their heirs, than it is to traipse through corporate acquisition histories). -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Documentation conversion status [was: Re: companies contributing to X]
Thanks a lot for this update and the work in general. I know it was very difficult for me to get involved, and even now I'm only comfortable in a few corners of X11. In addition to making it easier for new contributors, this work will make it easier for existing contributors to expand their influence or better integrate newer technologies. We may actually get around to supporting COMPOSITE and EXA in XQuartz ;) Thanks, Jeremy On Nov 27, 2010, at 15:24, Matt Dew wrote: As many of you know, with some guidance from Alan, Gaetan and I have been quietly slugging through converting the in-tree documentation to docbook/xml. With the goal of having attractive, usable documentation that's easy to edit and generate html,pdf,ps and text, with an emphasis on consistency across it all. I can speak just to the conversion: There are roughly 2200 pages of documentation in the tree, written in 5 different formats (SGML, troff, Framemaker, tek, asciidoc) by multiple people across multiple years. This means the conversion must be done in a couple steps. One of the purposes of the first step is just to get an idea of what has been done so that we can get a list of xml tags used in all the docs. We can then pair down this list to remove redundant tags. From this smaller list, we'll generate an example document from which we can apply tags across all the documents consistently. The xorg.css and Xorg_profile-mode.xsl stylesheets use those xml tags to control presentation. One thing that some have noticed. The documentation that has been converted is ugly. It has the content but lacks the formatting. That is step 2. Normal spiel: Having consistent documentation that's easy to edit and generate will make it easier to create new and update existing documentation as well as help new people find information. I'm happy to report that this initial conversion is almost done. 2000 pages have been converted, with another 200 to go. Step 2 will begin soon. Happy Thanksgiving, Matt ___ xorg-de...@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X
Matt Dew m...@osource.org writes: On Thu, Nov 25, 2010 at 5:36 AM, Eirik Byrkjeflot Anonsen ei...@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 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Documentation conversion status [was: Re: companies contributing to X]
As many of you know, with some guidance from Alan, Gaetan and I have been quietly slugging through converting the in-tree documentation to docbook/xml. With the goal of having attractive, usable documentation that's easy to edit and generate html,pdf,ps and text, with an emphasis on consistency across it all. I can speak just to the conversion: There are roughly 2200 pages of documentation in the tree, written in 5 different formats (SGML, troff, Framemaker, tek, asciidoc) by multiple people across multiple years. This means the conversion must be done in a couple steps. One of the purposes of the first step is just to get an idea of what has been done so that we can get a list of xml tags used in all the docs. We can then pair down this list to remove redundant tags. From this smaller list, we'll generate an example document from which we can apply tags across all the documents consistently. The xorg.css and Xorg_profile-mode.xsl stylesheets use those xml tags to control presentation. One thing that some have noticed. The documentation that has been converted is ugly. It has the content but lacks the formatting. That is step 2. Normal spiel: Having consistent documentation that's easy to edit and generate will make it easier to create new and update existing documentation as well as help new people find information. I'm happy to report that this initial conversion is almost done. 2000 pages have been converted, with another 200 to go. Step 2 will begin soon. Happy Thanksgiving, Matt ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X
On Thu, Nov 25, 2010 at 5:36 AM, Eirik Byrkjeflot Anonsen ei...@opera.com wrote: Luc Verhaegen l...@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 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
Matthew Garrett wrote: The lack of documentation for various aspects of the server doesn't help either. I found X development far more intimidating than getting involved in the kernel. That is something we know we've been lacking for a long time, and have been working to correct. So far most of the efforts have been around getting the docs to a place where people can edit them and then have the toolchain around to see the html/pdf/etc. output. (Matt Gaetan have made amazing progress here over the last year after years of the rest of us talking about it, though most of that is around client library protocol level documentation, since that's where the bulk of our existing documentation is, and not so much server/driver side.) For Xorg 1.9, I got the server internals docs in-tree and building with the standardish xmlto tools - now comes the hard part of getting them up-to-date again and having useful contents. The X.Org Board has recently approved Bart's proposal to set aside a few days before the 2011 X Developer Conference for a book sprint to produce documentation for developers and hopefully we'll be able to build upon the existing docs, Matt's Summer of Code KMS docs, and Stephane's draft driver writing guide to actually have some good docs for people. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
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 think X faces the problem that our approach to code quality is pretty similar to the kernel, but the number of skilled coders with domain experience is much smaller. There's a pretty strong cultural mismatch between our willingness to accept patches and people's willingness to submit them. Vendors are willing to argue that their component suppliers have in-kernel drivers, but X.org's modular development model makes it far easier for those suppliers to argue that an out of tree X driver is equivalent to something that's maintained within X.org. The unsurprising outcome is that drivers in X.org only tend to be regularly updated if they have someone who can work with the X.org community. If they don't, it's far easier to keep the code in their own tree. Working out ways to improve this situation would seem worthwhile, but simply being more enthusiastic about accepting contributions doesn't seem like a great plan (compare the code quality of nouveau, intel and radeon to that of some of the out of tree drivers, for instance) -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
but simply being more enthusiastic about accepting contributions doesn't seem like a great plan (compare the code quality of nouveau, intel and radeon to that of some of the out of tree drivers, for instance) I think that is a little naïve. There is a difference between vendors attempting to use Xorg as a dump and run for crap code, and being a bit more relaxed about obscure drivers that are otherwise unmaintained. The latter makes a good ground for people to learn the craft, as indeed can staring at some of the finest vendor Vogon poetry and turning it into something resembling C to help get it upstream. X is a bit odd in other ways - it's history has been rather closed at times which hasn't helped as it means there isn't a long standing large developer base. It consists (for much of the relevant stuff) of a very small number of very large and very complex drivers for insanely complex bits of hardware. That doesn't have the same scaling for newbies the kernel does where there are hundreds of random USB widgets you never knew you needed that make good starting points. Maintaining the old Voodoo2 driver was a bit like minor kernel hacking. I can't even imagine how KeithP fits everything he needs to know for the intel drivers into his head. Alan ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
On Thu, Nov 25, 2010 at 09:23:38PM +, Alan Cox wrote: but simply being more enthusiastic about accepting contributions doesn't seem like a great plan (compare the code quality of nouveau, intel and radeon to that of some of the out of tree drivers, for instance) I think that is a little naïve. There is a difference between vendors attempting to use Xorg as a dump and run for crap code, and being a bit more relaxed about obscure drivers that are otherwise unmaintained. I don't entirely agree. If people provide code review and the vendor maintainer's attitude is approximately We're only willing to work with you if you accept our approach, I don't think that benefits us. It can be an opportunity for learning - I'm just not sure that it has been in the real world, so far. X is a bit odd in other ways - it's history has been rather closed at times which hasn't helped as it means there isn't a long standing large developer base. That's certainly true. The small number of developers has been a longstanding issue, and the fact that companies can't really just pick up an existing developer makes all of this much harder. It consists (for much of the relevant stuff) of a very small number of very large and very complex drivers for insanely complex bits of hardware. That doesn't have the same scaling for newbies the kernel does where there are hundreds of random USB widgets you never knew you needed that make good starting points. Maintaining the old Voodoo2 driver was a bit like minor kernel hacking. I can't even imagine how KeithP fits everything he needs to know for the intel drivers into his head. The lack of documentation for various aspects of the server doesn't help either. I found X development far more intimidating than getting involved in the kernel. -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
But you also might want to consider that i was at a hardware vendor two weeks ago, and i had to listen to their main engineer calling contributing directly to X a waste of time, and that they rather fix the versions their customers ship, and hand the patches to their customers directly, never bothering to submit to X directly. They rather implement stuff, hand it to their customers, as 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. Despite all my personal feelings about free software and the likes, I had absolutely nothing to counter, anything i could even try to throw up against that would either be completely irrelevant and meek, or a lie. 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 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: companies contributing to X [was: Re: Respository vandalism by r...@...fd.o]
Matt, I think what you are asking is: is the Microsoft FUD working? The answer is: yes. Should we roll over and play dead? No, not me. Freedom, as in free range, Pat --- On Wed, Nov 24, 2010 at 3:56 PM, Matt Dew m...@osource.org 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? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
