Hacker News Reader

Comment by notatoad | Hacker News Reader

>they are effectively gaining control of the Linux userland.

but they aren't gaining control by some dastardly power grab, they're gaining control because they're the only ones actually putting in the work. They're simply doing what they think is best for their product, while at the same time contributing their work back to the open source world. That is good, that's how it's supposed to work.

The only reason they're gaining control is becuase the rest of the linux userbase has decided that although they might complain about Red Hat's work on hacker news and deride it as "not good", it's actually good enough that nobody wants to use any alternative projects to the ones red hat works on.

View on HN

> The only reason they're gaining control is becuase the rest of the linux userbase has decided that although they might complain about Red Hat's work on hacker news and deride it as "not good", it's actually good enough that nobody wants to use any alternative projects to the ones red hat works on.

The decisions they're making are what prevents others from doing that. When they make a bad choice you would be willing to write code to correct, you can no longer just replace that one component with one that works better, because everything is tightly coupled without clean interfaces between them.

Then since no one else can justify spending the resources to replace the entire Linux userland in order to correct that one problem, the problem remains, and they accumulate. And still no one else can do anything about it unless they have the resources to replace far more than the individual problematic component(s).

> Then since no one else can justify spending the resources to replace the entire Linux userland

Well that's just it, though. Red Hat is spending the resources to maintain and build much of the Linux userland. And they are no longer willing to do so in a way that helps support the userlands for the BSDs or the buffet mentality of building the Linux userland. If people don't want to use the Red Hat userland, then they _need_ to be willing to support a whole Linux userland that resembles what they want. Fighting a set of small individual battles just keeps losing.

So far, nobody seems to have gotten traction on this, I think partly because most of the opponents are only unified in their disagreement with what Red Hat is doing and partly because I think the opponents don't have the resources Red Hat has.

Meanwhile, 20 years ago on Slashdot...

"Well that's just it, though, Microsoft is spending the resources to maintain and build the underlying standards of the PC ecosystem. And they are no longer willing to do so in a way that helps support Linux, the BSDs, or the bazaar mentality of open source. If people don't want to use Windows, then they _need_ to support an entire computing platform that resembles what they want."

It seems to me that that is true, that it happened, and that it saw greatly varying levels of success for different use cases.

>Red Hat

is not the owner of Wayland, of the repositories, of the protocols, and is not the biggest contributor base

Given that the blog post in question quotes from "On the Road to Fedora Workstation 31," I think Red Hat's adoption of Wayland is germane here.

It is run by an ex redhat employee though, it seems to be a cultural thing.

I wouldn't be surprised if his paycheck is ultimately being paid for by redhat, even if it's through a level of abstraction.

I think they are gaining control via a “dastardly power grab”, as you put it.

Software that I have relied on for decades no longer runs, and it is invariably because someone at RedHat consciously decided to break compatibility with the existing Linux ecosystem in some functionality regressing way.

This has happened with the Linux kernel, pulse audio, dbus, systemd, logins, systemd logger, wayland, gtk2->3, and countless others.

Also the main issue I see with 'modern' Linux ecosystem actors, is that they usually do not put on the 'market' a new product that they developed (from scratch or after forking a traditional one); instead they first take control of a an existing piece of software or project, and then they change the way it works, or the direction it takes, or make it un-portable just because.

I wouldn't mind if they released new software, new concepts, new OSes and let the users (the competition? the free market?) choose. If they take the market share, good for them, but they didn't have to come and screw with the ecosystem I picked years (decades, actually) ago. Let the different ecosystems leave their lives. I chose this one 20 years ago especially because I wanted to avoid those things which, now, are put down my throat!

Would changes (switching) take a longer time to occur? Yes, probably, and I don't think it is a problem, considering today's tendencies in software development which exhibit more problems because of going too fast.

For example, I never read any user saying "I moved to a Redhat distribution because it has systemd, that's so much better" before a couple of distro maintainers (soon to be hired by Redhat) decided it had to be imposed on a distro and then another. Nobody really cared about the supposed advantages brought to the table by systemd, nobody demanded it. And yet...

Same thing for major changes of/in GUI toolkits. If they want breaking changes (as toolkit devs), if they want a complete redesign (as toolkit users), just fork the existing project and name it something else at least a little bit distinctive. Let the project as it is a chance to survive (no matter how small that chance is).

But no, they want a monoculture, they want to spread it as much as they can, and force everyone to follow their way, their idea of the day.

In fact it is a bit like globalisation, where a single culture, a single economic system, a single social system is supposed to eat the world and leave it with a single boring monoculture, the same everywhere.

Don't attribute to malice what can easily be explained by just not caring. The Red Hat people are getting their work done. Fixing their use cases for their users. Their salaries don't depend on upholding some holy Unix virtues. They depend on making Red Hat users happy and willing to pay.

Whenever you want to understand why someone does something then you should always ask what their motivations are. What do they want and what do they need? What forces are acting on them? What is motivating them? I cannot come up with a reason why Red Hat people would want to maliciously break the Unix model. But I do see how they don't have much motivation to uphold it either.

Let go of your graphical punched card machine!

Yes, a lot of open source goodness is due to Red Hat, and a lot of open source programmers' livelihoods are and have been due to Red Hat.

Red Hat earned a lot of goodwill among early Linux people, and fortunately they were able to sustain their work with enterprise business revenue flow, of actual dollars (not just goodwill).

It's also true that a lot of people have been implicitly delegating a lot of foundation on which we depend, to Red Hat and a few other organizations. We build atop that, usually with only a little awareness of what's going on, and maybe we should be better informed about that -- as engineers with immediate responsibilities in our own work niches, and/or as altruistic participants in some broader worldwide collective effort.

There's no Red Hat. They got by IBM for $34 billion, I keep seeing a lot of reference to Red Hat in this post. Please call it, what it is. IBM. It's all about money. Much can be said about this, but money has really corrupted and polluted OSS.

Of course the possibility of Red Hat being ruined has been on everyone's minds since the acquisition.

But things akin to the Wayland push happened before that, so I wouldn't attribute that to post-acquisition.

I won't call it IBM, so long as Red Hat retains some autonomy to exercise their know-how, and distinct identity (not kill some of the golden goose for which they paid serious gold), and so long as most of the the most skilled Red Hat people are happy and stay. (If they tried to commoditize everyone as worker drones, that would be unfortunate.)

Also, FWIW, recall that IBM have for many years been a strong supporter of various open source. (Maybe too bad they didn't buy Java/Sun in the end.) For money reasons, of course, but there seemed to be a lot of goal alignment among open source people, and overlapping with libre people.

In the short time I worked at Red Hat (as part of the CoreOS acquisition), several of the redhatters in Raleigh mentioned how much they enjoyed working at Red Hat and how much they hated previous jobs at IBM. This was before the IBM purchase was announced.

I predict a mass exodus as golden handcuffs come off and employees start to chafe under new management.

Where do you think they'll go? Canonical? Or will their man-hours be lost to the FOSS community?

Wherever they go, I doubt most of them will continue to work on open source software.

I'm not sure if it's a bad thing that these man-hours will be lost to the open source community. I think Red Hat’s involvement in open source has been double edged. Yes, they have funded projects that are crucial to the open source ecosystem, but their main source of revenue is support contracts. That means they have different incentives from most of the users of their software. If a big customer wants some feature, Red Hat tries to add it as fast as they can. If a big customer doesn't want to change their software to use new versions of some dependencies, Red Hat keeps a fork around and applies security patches. These behaviors serve to increase complexity and technical debt while also causing more headaches for maintainers of upstream software. It's very frustrating to have someone say, "I have a bug with your tool." and it turns out they're on an ancient version of libxml that has a bunch of custom patches applied.

Also, Red Hat wants to upsell people onto RHEL, which means shoving RHEL into places it doesn’t belong. I ended up quitting because I was tired of pushing back on boneheaded technical decisions made in the service of these incentives.

I don't mean to single out Red Hat. It's just the company that showed me how the sausage is made. I think these criticisms can apply to any company that develops open source software with the goal of making money from support.

It seems like a lot of those projects just aren't interested in accepting pull-requests from outsiders.

If they were more willing to compromise and cooperate I don't think they'd catch nearly this much flac.

Exactly. And for much smaller organizations and individuals, it is much harder to organize an alternative effort to this set of projects backed up by a big corporation (Red Hat).

I only expect this to happen if Systemd and related efforts become really bothersome. Right now it is a big of a mixed situation. A better init system, and some modern basic userland infrastructure was needed. Systemd has brought some good things, but overall changes are concerning for the reasons outlined in my parent comment.

Exactly. And for much smaller organizations and individuals, it is much harder to organize an alternative effort to this set of projects backed up by a big corporation (Red Hat).

There are exceptions. Drew Devault and the rest of the Sway team did write wlroots, an alternative compositor for Wayland, so Wayland is less of a monoculture.

But it is true that it requires a lot of manpower, money, and will to develop an alternative to e.g. Wayland. However, I see the current situation more as the glass being half full. Imagine that we did not have Red Hat, and others pulling the weight of Wayland (and other technologies, such as Flatpak), the Linux desktop ecosystem would in many ways be hopelessly behind macOS, iOS, and Windows.

I think this is a better outcome than being stuck with 80ies/90ies graphics technology forever, even if it is not perfect.

> It seems like a lot of those projects just aren't interested in accepting pull-requests from outsiders.

What kind of pull requests though? Minor fixes or big architectural decisions like ssh forwarding and security features?

Because there's a difference between just accepting PRs and public ownership of future project direction. The second usually doesn't result in a successful project.

>PRs and public ownership of future project direction.

https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

That's kind of the point of open-source, public ownership. Sure, you need someone to be in charge and reject outright bad ideas, but when you're refusing to add options that support other people's personal preferences that's when it's starting to become a problem.

It's all these authoritarians that think they need to own the direction of the project that are causing these issues. I'm sure dirty info-hippies who believe in communal project ownership have their own problems too, and that there's a balance, but it seems like we've over-swung.

Do you have examples of working pull-requests which were rejected for what you consider bad reasons? I’m sympathetic to maintainers choosing not to take on additional technical debt so I’d especially be looking for things like willingness to shoulder long-term support costs and other constraints imposed by accepting a PR.

One thing that comes to mind is gnome's refusal to implement type-ahead in nautilus and the gtk3 file picker. It's a very popular and visible issue that I won't get into here, but suffice to say that there are a lot of people who would really like a more traditional type-ahead.

There aren't any specific pull requests I'm aware of although there are forked versions available.

When asked about it the developers involved just say "no", and any attempt to work on a compromise or discuss what would be necessary to include a flag somewhere deep in gcnonf to revert the behavior is met with a resounding "we're not interested in that feature". Which is fine, but don't keep other people from implementing a feature that they like just because it doesn't fit in with your vision.

That attitude seems pretty endemic to open-source projects involving a lot of (ex) redhat engineers. It's not that the PR is being refused, it's that it's impossible to even have the discussion.

If you don't like the current maintainers' policy on "future project direction", you can always fork the project.

Yes, this involves an increased maintenance burden since you need to actively review what the upstream is doing and figure out how to cleanly pull their changes - but guess what, that's the very same burden that dealing with your proposed changes would have placed on the upstream themselves! "Authoritarianism" doesn't really come into it.

There are ways to architect software so that it can be cooperatively developed, so that you can fork and maintain an individual component instead of an entire stack.

Are those stinky SJW info-hippies getting uppity and threatening Open Source again?

http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruc...

>The Decline and Fall of Eric S. Raymond

>Around the start of the millennium, Eric S. Raymond was one of the philosophical leaders of open source. His essay and book, The Cathedral and the Bazaar was obligatory reading for executives trying to understand open source. Now, after lying low for over a decade, Raymond is getting attention again, this time for two blog entries in which he rants about how so-called Social Justice Warriors (SJWs) threaten open source.

>[...] Raymond's call to defend open source from SJWs is as deceptive as anything he attributes to his enemies. Free and open source software is too widespread to need defending, and his attempt to create an issue does not map well on to actual events. For those who remember his earlier contributions to open source, his recent comments make for a disappointing epilogue.

And their being unwilling to accept contributions from outsiders would be less of a problem if the system weren't so tightly coupled.

scorched earth

Reply on news.ycombinator.com