If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

AdamW, thanks for your response. However, I had made some corrections to clarify what I meant, although it looks like your response would have been the same either way.

1. My point is that there is no distinction between the two.

And my point is I'm not sure that's a terribly smart policy, as along with Linus' tendency to explode at the slightest provocation, it leads to gigantic messes like this. Gentoo's image has been rather badly damaged among vaguely clued-up developers by the perception that it has made a fairly ad hoc and ill thought through decision to start using an immature udev fork. Even though that's not exactly what's actually happened, a policy where any sandbox project started on Gentoo resources by any Gentoo developer with no oversight is an 'official Gentoo project' is clearly likely to contribute to confusion here.

Originally Posted by ryao

2. Our QA rules are not yet in full effect. I would appreciate it if you would review our work after our first few tags and then let us know what you think of our commits.

I sympathize with you there, but welcome to the world of high-profile F/OSS development. Did you consider that perhaps Kay's response to Linus' hair-trigger flame was precisely the same as your response to my post? If you're planning on strapping in for the long haul, expect more of the same.

Originally Posted by ryao

3. That does not change the fact that you are openly criticizing our work at a point in time that RedHat's own things would have been developed behind closed doors. It does not seem fair.

That is an assumption you're making that I don't think is based in reality. Many Red Hat developers work on all sorts of projects that are developed in the open all the time. The only example you have cited to the contrary is a project which was not a Red Hat project at the time in the first place. Can you cite a single company with a better track record of public open source development than Red Hat?

Originally Posted by ryao

4. People resell Gentoo under different names and we are okay with that. We do not change how we do things because of them.

None of those people, to my knowledge, is a major international enterprise software distributor with whom you are in direct competition. RH is a for-profit publicly traded company; whether you like that or not, it's a fact. It's also a rather successful for-profit publicly traded company, whose success allows it to pay the salary of rather a lot of F/OSS developers. Arguably, without RH backing, the entire F/OSS ecosystem would be appreciably damaged. RH builds on the work of lots of other people, and in return, contributes an awful lot of work back to the wider community. Oracle is pleased to try and build on the work of lots of other people, including all of RH's work, and contribute absolutely nothing back to the community. Surely you can see why RH may have a motive to try and discourage Oracle's approach. It's worth noting that none of the non-commercial RHEL clones have expressed any displeasure with RHEL's kernel release policies. It's also worth noting that Fedora's kernel is not released in the same way. It's *further* worth noting that all of the work of Red Hat's kernel engineers is contributed, promptly, to the upstream kernel. In practice, the RHEL kernel release policy negatively affects exactly one specific type of actor: the type of actor which wishes to take the RHEL kernel, modify it slightly, and sell support for it. It does not negatively affect any actor which simply wishes to release the RHEL kernel as is; they can do so easily. It does not negatively affect other actors who are participating properly and productively in the F/OSS ecosystem - like Gentoo - as they do not simply attempt to copy RHEL's kernel with slight modifications, they work from the collaborative upstream kernel base.

And my point is I'm not sure that's a terribly smart policy, as along with Linus' tendency to explode at the slightest provocation, it leads to gigantic messes like this. Gentoo's image has been rather badly damaged among vaguely clued-up developers by the perception that it has made a fairly ad hoc and ill thought through decision to start using an immature udev fork. Even though that's not exactly what's actually happened, a policy where any sandbox project started on Gentoo resources by any Gentoo developer with no oversight is an 'official Gentoo project' is clearly likely to contribute to confusion here.

Feel free to email feedback on that policy to gentoo-project AT lists DOT gentoo DOT org.

Originally Posted by AdamW

Did you consider that perhaps Kay's response to Linus' hair-trigger flame was precisely the same as your response to my post?

I corrected my comments after I asked someone that I know for feedback on how well I expressed my thoughts. I consider the the two versions to be logically equivalent for the most part, but others seem to disagree. I apologize for my inability to distinguish between the two. It is by no means intentional.

With that said, Kay has been given multiple opportunities to clarify what he meant and he has refused to take them. That differs sharply from my own response.

Originally Posted by AdamW

That is an assumption you're making that I don't think is based in reality. Many Red Hat developers work on all sorts of projects that are developed in the open all the time. The only example you have cited to the contrary is a project which was not a Red Hat project at the time in the first place. Can you cite a single company with a better track record of public open source development than Red Hat?

None of those people, to my knowledge, is a major international enterprise software distributor with whom you are in direct competition. RH is a for-profit publicly traded company; whether you like that or not, it's a fact. It's also a rather successful for-profit publicly traded company, whose success allows it to pay the salary of rather a lot of F/OSS developers. Arguably, without RH backing, the entire F/OSS ecosystem would be appreciably damaged. RH builds on the work of lots of other people, and in return, contributes an awful lot of work back to the wider community. Oracle is pleased to try and build on the work of lots of other people, including all of RH's work, and contribute absolutely nothing back to the community. Surely you can see why RH may have a motive to try and discourage Oracle's approach. It's worth noting that none of the non-commercial RHEL clones have expressed any displeasure with RHEL's kernel release policies. It's also worth noting that Fedora's kernel is not released in the same way. It's *further* worth noting that all of the work of Red Hat's kernel engineers is contributed, promptly, to the upstream kernel. In practice, the RHEL kernel release policy negatively affects exactly one specific type of actor: the type of actor which wishes to take the RHEL kernel and modify it slightly for commercial purposes. It does not negatively affect any actor which simply wishes to release the RHEL kernel as is; they can do so easily. It does not negatively affect other actors who are participating properly and productively in the F/OSS ecosystem - like Gentoo - as they do not simply attempt to copy RHEL's kernel with slight modifications, they work from the collaborative upstream kernel base.

They are non-profit organizations and we are in direct competition with them. Their existence threatens our marketshare, but we do not try to undermine their efforts.

Yes, well, Mark claims lots of things. Ask yourself this: would the future maintenance prospects of the code shipped by Gentoo be affected more by Red Hat going bankrupt tomorrow, or by Canonical going bankrupt tomorrow?

Originally Posted by ryao

They are non-profit organizations and we are in direct competition with them. With that said, I am a strong believer in permitting others to undercut OSS products. I openly encourage people to undercut us.

'Undercut' has a specific financial meaning. Gentoo does not appear to sell support contracts (or, really, anything else), nor do any Gentoo-derivative distributions, so far as I can tell. Gentoo is supported by volunteer work and donations, which is admirable.

A large chunk of RH's support comes from commercial support contracts. As RH believes in contributing to the F/OSS ecosystem, our overheads include all the money spent on this development. The Oracle UL business model is to take RHEL, repackage it under a different name, and sell support for it - without any of the overheads of contributing to upstream development. This is not a problem Gentoo has, as it does not engage in this kind of activity at all. RH is at a theoretical disadvantage in attempting to compete against Oracle to sell support for the same codebase while we are also paying for the development of a lot of that code, but Oracle isn't. Fortunately, RH's customers appear to understand that RH is in a better position to support the same code since we employ a lot of the people who write it, but still, surely you see the problem. Again, as long as no-one else in the F/OSS community really wants to just take the RHEL kernel - which is really just an old stable kernel with specific upstream backports in any case - and use it as the basis for independent development, which they don't, there really isn't a _problem_. There'd be a problem if RH was putting stuff in the RHEL kernel that it didn't contribute to the upstream kernel, but we don't do that.

Anyway, look, we're getting way off into the weeds here. I don't want to be mean or condescending and I'm sorry if I have, I just really am not sure if you're entirely aware of how big a hunk you're biting off here or how much of a (however transient) shitstorm you may (however inadvertently) have triggered. If I'm wrong and your fork turns out to be a raging success, great. That's how F/OSS works, and heaven knows I've been wrong enough times before. I guess I'm just saying, one, Linus likes to yell at people and you can't take his declarations that people are not fit to clean sewers entirely seriously, and two, when the guy who wrote the thing you're trying to fork says, hey, maybe you're not doing it right, it's probably a good idea to listen. I guess we'll see how things turn out.

Yes, well, Mark claims lots of things. Ask yourself this: would the future maintenance prospects of the code shipped by Gentoo be affected more by Red Hat going bankrupt tomorrow, or by Canonical going bankrupt tomorrow?

Canonical has done wonders for Linux marketshare and our community grows in size as Ubuntu users have jumped ship. On the other hand, RedHat's actions have been fairly problematic. RedHat developers do not care about regressions that their patches cause in software that we distribute, which causes plenty of headaches for us. RedHat is also actively trying to chase other contributors to OSS projects away, such as Oracle and RisingTide Systems.

Which company do you think that we would prefer to go bankrupt tomorrow?

Originally Posted by AdamW

'Undercut' has a specific financial meaning. Gentoo does not appear to sell support contracts (or, really, anything else), nor do any Gentoo-derivative distributions, so far as I can tell. Gentoo is supported by volunteer work and donations, which is admirable.

A large chunk of RH's support comes from commercial support contracts. As RH believes in contributing to the F/OSS ecosystem, our overheads include all the money spent on this development. The Oracle UL business model is to take RHEL, repackage it under a different name, and sell support for it - without any of the overheads of contributing to upstream development. This is not a problem Gentoo has, as it does not engage in this kind of activity at all. RH is at a theoretical disadvantage in attempting to compete against Oracle to sell support for the same codebase while we are also paying for the development of a lot of that code, but Oracle isn't. Fortunately, RH's customers appear to understand that RH is in a better position to support the same code since we employ a lot of the people who write it, but still, surely you see the problem. Again, as long as no-one else in the F/OSS community really wants to just take the RHEL kernel - which is really just an old stable kernel with specific upstream backports in any case - and use it as the basis for independent development, which they don't, there really isn't a _problem_. There'd be a problem if RH was putting stuff in the RHEL kernel that it didn't contribute to the upstream kernel, but we don't do that.

Lets say that I put some software on the Apple App Store and I charge $0. Hypothetically speaking, someone else could undercut me by listing a fork of my software on the Apple App Store for $-0.01. I would clearly benefit from such behavior and I encourage it.

With that said, Gentoo does benefit from marketshare. A bigger community means that it is easier to recruit additional developers, we have more bug reports and the foundation receives additional donations that could be used to purchase better infrastructure that could be used to do more comprehensive QA testing on our tree. Please do not confuse our lack of pricing for a lack of competition. We are in heavy competition with other distributions.

Originally Posted by AdamW

A large chunk of RH's support comes from commercial support contracts. As RH believes in contributing to the F/OSS ecosystem, our overheads include all the money spent on this development. The Oracle UL business model is to take RHEL, repackage it under a different name, and sell support for it - without any of the overheads of contributing to upstream development. This is not a problem Gentoo has, as it does not engage in this kind of activity at all.

We do engage in such activity. Until recently, all of our projects have been lower profile than RedHat's projects. eudev is the first of our projects to receive widespread attention. It is also the first to be slashdotted before the official announcement.

If you look in various upstream commit logs, you will find plenty of @gentoo.org email addresses in commits. We do contribute to upstream development. We just do not believe in actively trying to obtain revenue from our contributions.

Arguably, without RH backing, the entire F/OSS ecosystem would be appreciably damaged. RH builds on the work of lots of other people, and in return, contributes an awful lot of work back to the wider community. Oracle is pleased to try and build on the work of lots of other people, including all of RH's work, and contribute absolutely nothing back to the community. Surely you can see why RH may have a motive to try and discourage Oracle's approach.

Last I checked, Oracle still employed people working on X, btrfs, and gcc. Has this changed?

Arguably, without RH backing, the entire F/OSS ecosystem would be appreciably damaged. RH builds on the work of lots of other people, and in return, contributes an awful lot of work back to the wider community.

I am tired and I appear to have missed this comment. I must thank curaga for highlighting it.

I think that there is an argument to be made the RedHat's involvement in the community causes damage. RedHat has no qualms about sending poorly tested patches upstream and letting the community fix the problems that they cause. I am told by developers on our virtualization team that this is exactly what RedHat has been doing with QEMU and that upstream QEMU was removed from our tree because of it. The increasing dependence of GNOME on systemd is another instance of damage that RedHat's influence has had. It has forced Gentoo, FreeBSD and numerous others to try to fix the damage. I started the eudev project because I noticed changes that RedHat employees have made to udev are harming our tree. There are likely other examples, but three should be sufficient.

The community would be better off if RedHat only contributed production ready changes. That would dramatically reduce the number of commits that Redhat employees make to various projects. However, many of us feel that RedHat is wasting our time on experimental patches and we would appreciate it if Redhat would stop doing things that make us feel that way. Forks such as eudev are what happen when Redhat's QA standards for upstream contributions annoy enough people.

I am tired and I appear to have missed this comment. I must thank curaga for highlighting it.

I think that there is an argument to be made the RedHat's involvement in the community causes damage. RedHat has no qualms about sending poorly tested patches upstream and letting the community fix the problems that they cause. I am told by developers on our virtualization team that this is exactly what RedHat has been doing with QEMU and that upstream QEMU was removed from our tree because of it. The increasing dependence of GNOME on systemd is another instance of damage that RedHat's influence has had. It has forced Gentoo, FreeBSD and numerous others to try to fix the damage. I started the eudev project because I noticed changes that RedHat employees have made to udev are harming our tree. There are likely other examples, but three should be sufficient.

The community would be better off if RedHat only contributed production ready changes. That would dramatically reduce the number of commits that Redhat employees make to various projects. However, many of us feel that RedHat is wasting our time on experimental patches and we would appreciate it if Redhat would stop doing things that make us feel that way. Forks such as eudev are what happen when Redhat's QA standards for upstream contributions annoy enough people.

I have to say that's the first I've heard of any such concerns with qemu. Have these been documented on the appropriate lists? Use of systemd by GNOME has nothing much to do with 'Red Hat influence' and everything to do with the fact that systemd provides capabilities of which GNOME wishes to make use. The whole point of systemd is to provide capabilities that sysv does not provide, after all. If it didn't, there'd be no point to its existence.

Last I checked, Oracle still employed people working on X, btrfs, and gcc. Has this changed?

Okay, I should qualify that somewhat. Oracle's contributions are significantly smaller than RH's - or, indeed, for instance, SUSE's, or many other projects, even non-commercial ones. And Oracle contributes nothing significant to the development of the precise codebase they ship, i.e. RHEL.

I have to say that's the first I've heard of any such concerns with qemu. Have these been documented on the appropriate lists? Use of systemd by GNOME has nothing much to do with 'Red Hat influence' and everything to do with the fact that systemd provides capabilities of which GNOME wishes to make use. The whole point of systemd is to provide capabilities that sysv does not provide, after all. If it didn't, there'd be no point to its existence.

I am not involved with QEMU maintenance. I suggest that you contact Doug Goldstein for details.

As for systemd, why is it that the GNOME project feels that mandatory dependence on such features is necessary when the KDE project does not? The KDE project seems to have no trouble writing cross platform compatible code. The only instance in which KDE fails to be cross platform involves Network Manager, which is Linux specific. As far as I know, Network Manager is developed primarily by RedHat employees. They seem to only care about Linux (and quite possibly, only RedHat's version of it). This causes headaches for us because Gentoo encompasses more than just Linux. Unfortunately, our teams dedicated to non-Linux things lack the man power necessary to address that issue.

With that said, Gentoo has its own cross platform solution called OpenRC that runs on top of sysvinit. I do not think that we would be having this conversation had OpenRC been incorporated into Fedora instead of Upstart.