[personal profile] mjg59
Piston, an Openstack-in-a-box vendor[1] are a sponsor of the Red Hat[2] Summit this year. Last week they briefly ceased to be for no publicly stated reason, although it's been sugggested that this was in response to Piston winning a contract that Red Hat was also bidding on. This situation didn't last for long - Red Hat's CTO tweeted that this was an error and that Red Hat would pay Piston's sponsorship fee for them.

To Red Hat's credit, having the CTO immediately and publicly accept responsibility and offer reparations seems like the best thing they could possibly do in the situation and demonstrates that there are members of senior management who clearly understand the importance of community collaboration to Red Hat's success. But that leaves open the question of how this happened in the first place.

Red Hat is big on collaboration. Workers get copies of the Red Hat Brand Book, an amazingly well-written description of how Red Hat depends on the wider community. New hire induction sessions stress the importance of open source and collaboration. Red Hat staff are at the heart of many vital free software projects. As far as fundamentally Getting It is concerned, Red Hat are a standard to aspire to.

Which is why something like this is somewhat unexpected. Someone in Red Hat made a deliberate choice to exclude Piston from the Summit. If the suggestion that this was because of commercial concerns is true, it's antithetical to the Red Hat Way. Piston are a contributor to upstream Openstack, just as Red Hat are. If Piston can do a better job of selling that code than Red Hat can, the lesson that Red Hat should take away is that they need to do a better job - not punish someone else for doing so.

However, it's not entirely without precedent. The most obvious example is the change to kernel packaging that happened during the RHEL 6 development cycle. Previous releases had included each individual modification that Red Hat made to the kernel as a separate patch. From RHEL 6 onward, all these patches are merged into one giant patch. This was intended to make it harder for vendors like Oracle to compete with RHEL by taking patches from upcoming RHEL point releases, backporting them to older ones and then selling that to Red Hat customers. It obviously also had the effect of hurting other distributions such as Debian who were shipping 2.6.32-based kernels - bugs that were fixed in RHEL had to be separately fixed in Debian, despite Red Hat continuing to benefit from the work Debian put into the stable 2.6.32 point releases.

It's almost three years since that argument erupted, and by and large the community seems to have accepted that the harm Oracle were doing to Red Hat (while giving almost nothing back in return) justified the change. The parallel argument in the Piston case might be that there's no reason for Red Hat to give advertising space to a company that's doing a better job of selling Red Hat's code than Red Hat are. But the two cases aren't really equal - Oracle are a massively larger vendor who take significantly more from the Linux community than they contribute back. Piston aren't.

Which brings us back to how this could have happened in the first place. The Red Hat company culture is supposed to prevent people from thinking that this kind of thing is acceptable, but in this case someone obviously did. Years of Red Hat already having strong standing in a range of open source communities may have engendered some degree of complacency and allowed some within the company to lose track of how important Red Hat's community interactions are in perpetuating that standing. This specific case may have been resolved without any further fallout, but it should really trigger an examination of whether the reality of the company culture still matches the theory. The alternative is that this kind of event becomes the norm rather than the exception, and it takes far less time to lose community goodwill than it takes to build it in the first place.

[1] And, in the spirit of full disclosure, a competitor to my current employer
[2] Furthering the spirit of full disclosure, a former employer

Date: 2014-02-24 09:38 am (UTC)
From: (Anonymous)
This is the kind of thing where you really expect a "Those responsible have been sacked."

Importance of community

Date: 2014-02-24 06:05 pm (UTC)
From: (Anonymous)
"This was intended to make it harder for vendors like Oracle to compete with RHEL by taking patches from upcoming RHEL point releases, backporting them to older ones and then selling that to Red Hat customers."

This is anti-community behavior. As much as I dislike Oracle, making changes to intentionally harm them is definitely not pro-community.

"Someone in Red Hat made a deliberate choice to exclude Piston from the Summit."

I'm sadly not surprised, I've seen this sort of poor behavior from RedHat's sales team first hand. It's just business as usual for them these days.

This falls back to the whole "is Linux about choice" meme, which according to RedHat is false. The only choice in our community these days is RedHat's.

Re: Importance of community

Date: 2014-02-24 06:28 pm (UTC)
From: (Anonymous)
"This is anti-community behavior. As much as I dislike Oracle, making changes to intentionally harm them is definitely not pro-community."

Nobody is arguing that it wasn't. The argument presented in the article is that maybe this anti-community behavior was justifiable in the face of Oracle showing almost no willingness to work with the community. That point is certainly debatable, but I don't know where you see the claim that it wasn't anti-community.

"This falls back to the whole "is Linux about choice" meme, which according to RedHat is false. The only choice in our community these days is RedHat's."

If you're referring to the seminal rant at islinuxaboutchoice.com, then that's a gross misrepresentation of the argument presented. The argument there (which is a personal view of someone that happens to work for Red Hat) is that a Linux distributor (in this case, Fedora) is under absolutely no obligation to provide multiple interchangeable implementations of software that solve the same problem so that the user can choose his or her preferred implementation. In that context, Red Hat may choose to support one particular implementation of a sound server or init system in their product, and that's their prerogative. If you, the user, disagree with the software choices that Red Hat supports, then you can either put in the work to implement your preferred solution, or you can choose to use another distribution that is more aligned with your preferences.

Re: Importance of community

Date: 2014-02-24 07:30 pm (UTC)
From: (Anonymous)
"Nobody is arguing that it wasn't. The argument presented in the article is that maybe this anti-community behavior was justifiable in the face of Oracle showing almost no willingness to work with the community. That point is certainly debatable, but I don't know where you see the claim that it wasn't anti-community."

No anti-community behavior is justifiable for any reason. Just as it has been wrong to judge Ubuntu for their lack of upstream contributions to certain projects.

"The argument there (which is a personal view of someone that happens to work for Red Hat) is that a Linux distributor (in this case, Fedora) is under absolutely no obligation to provide multiple interchangeable implementations of software that solve the same problem so that the user can choose his or her preferred implementation."

It is constantly used against any semblance of choice, I haven't misrepresented it, it has been used by many RedHat employees (and others) to silence critics of any sort.

Re: Importance of community

Date: 2014-02-25 04:58 pm (UTC)
From: (Anonymous)
If you want to make choice happen, do the work. At some levels it is a lot of extra complexity. The site links against the email where it is explained in detail. It is not about silencing, it is about making people understand what they're asking for. I suggest reading the linked email.

Re: Importance of community

Date: 2014-02-26 02:44 pm (UTC)
From: (Anonymous)
I have read the email, my reading the email however doesn't stop other prominent people from misusing that email, and the #linuxbandwagon from parroting that misuse.

Piston contributing?

Date: 2014-02-24 08:17 pm (UTC)
From: (Anonymous)
For icehouse they have contributed to two projects :

http://stackalytics.com/?release=icehouse&metric=commits&project_type=openstack&module=&company=piston%2Bcloud&user_id=

and just trivial non core project contribution stuff....

I agree with your article tho.

Re: Piston contributing?

Date: 2014-02-24 08:19 pm (UTC)
From: (Anonymous)
I mean by two tiny patches only for the full release. So literally mostly nothing. They are trying to pass themselves as OpenSource but they never contribute.

I am not affiliated to any OpenStack companies for what is worth, sorry for the anonymous post.

Date: 2014-02-25 10:58 pm (UTC)
From: (Anonymous)
It says a lot about your integrity that I strongly suspect you'd post this even if you still worked for Red Hat.
From: (Anonymous)
It's not just the kernel development that shows how Red Hat is becoming more "closed" or self-centered, the number of bugzilla entries that are private (closed to the public) is also worrisome.

As an example that I ran into yesterday, the bugfix announcement of Red Hat Satellite yesterday has 7 references to bugzilla entries, and none of them are open to the public. So putting them in the announcement is basically to help Red Hat engineers/consultants but Red Hat customers are left out in the dark.

https://rhn.redhat.com/errata/RHBA-2014-0228.html

So when we found a few regressions in the Satellite product we could not look into the what-and-why's or even engage in any discussion. This makes it impossible to assess the risk of a security/bugfix update.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags