Hacker News Reader

How about using some of that revenue to pay the project maintainer to incorporate the patch upstream and make a release?

I've seen this very often in my personal experience that a company says exactly like you're saying now, "We have paying customers who demand certain patches, but the upstream project may be unable or unwilling to patch and release...so we downstream only." Alternatively, some downstream consumers simply "throw code over the wall" in the form of an upstream patch. However, those patches are sometimes duct-tape solutions which may not fit into the overall architecture/vision of the project maintainer(s). It's not fair to say, "accept this or else..." where the 'or else' is a downstream deviation (which in turn sometimes forces the upstream's hand).

The ethical way to do this work with upstream, whether it be direct compensation or more back-and-forth vice code-over-the-wall.

I think it's a incredibly unfair to assume that I'm not acting in good faith when I send patches upstream. I was contributing to the free software community long before I was getting paid to do so. I spend almost all of my working hours doing upstream maintainership work or writing patches. I have PRs that are several years old and I still am working on getting them merged upstream. I'm also just a developer, I'm not in a position to start spending money on projects on behalf of my employer. I do happen to donate to plenty of upstream projects and foundations, but that's money out of my own pocket.

The issue is that there are some (rare) cases where upstream is completely unwilling to merge a patch for philosophical reasons.

If you want me to be blunt -- the example I'm thinking of is Docker (which doesn't have a cash-flow problem), and has refused outright on many occasions to merge patches that allow for build-time secrets. On SLE we need this because in order to use a SLE image on a SLE machine you need to "register it" and the only way to sanely register it automatically is to bind-mount some files into all containers on-build as well as on-run (which you cannot do with upstream Docker today). Red Hat spent a long time trying to get a patch like this upstream, as did we.

To be clear, I'm not say you personally. I don't know you, or anything about your work so I'm speaking in purely a general sense about a position that you were representing.

I don't think all upstream contributions are in bad faith. I'm just saying there tends to be competing priorities which leads to some instances of hostility.

As for the Docker example, I don't know what the right answer is without digging deeper. My naive thought is to write a SLE/RHEL shim/plugin style component to allow functionality that's missing. This allows keeping the upstream vanilla, while not having to fork into something without the brand recognition. If that doesn't work, forking as `rhel-docker` or `sle-docker` doesn't seem that bad to me. Ubuntu does this with all the bcc-tools.

This is of course predicated on having tried all previous solutions first (paying an upstream developer, work with upstream with a good back-and-forth to incorporate a patch, etc). In the end, if the project decides something against their philosophical viewpoint, they're perfectly entitled to not accept patches. It's at that point, I think it's not the best solution to fork, downstream patch, and release as if it's the vanilla upstream.

All these problems are very easy to solve. Suse and Red Hat could stop trying to have it both ways: either you get the flexibility of a fork, or you get the brand recognition of the upstream project. But you want both - the upstream brand to get users, and the downstream flexibility so that you can “differentiate” and sell support.

This problem is entirely created by distributions and their “packagers know best” philosophy.

You say downstream patching is necessary. Go ahead and strip the upstream trademark from every package which you patch downstream, replace it with new Suse-specific trademarks, and let’s see what users prefer!

This isn't a SUSE or Red Hat caused issue, it's a users thing. Users want it both ways. Users want the flexibility to assume a project is the same as the upstream (but maybe feature frozen at a specific version), while also wanting all the security and bugs to not exist. Users are paying to have it both ways, and whether or not it's feasible, the market for it exists, and Suse/Red Hat are just trying to fill the gap.

If it was entirely the vendors, then we would see significantly more adoption in fast moving OSes, but that's still not a very popular model for production servers, even in the age of the cloud, containers, etc.

Fork the project, prefix the command with your company name and tell them to use that command with the patch applied if they need it today. This solves all your problems.

I think you're over-estimating how many users are willing to change their workflow or scripts to accommodate things like this. They will switch away from your distribution to one which patches the actual package.

I also don't agree this would result in fewer upstream bug reports -- "suse-foobar" will still result in bug reports for "foobar" (I've seen some cases of this happening). You'd need to rename the project entirely so that users don't know what the upstream GitHub repo is, and that's even more anti-community than any other suggestion.

> and that's even more anti-community than any other suggestion.

Shipping a fork that is different from the version that is created by the original author is also very anti-community. At least make it clear that you ship something different from the program that the author maintains.

The key phrase was "even more".

I disagree that all patches are somehow ethically wrong (bugfixes and security patches are obvious counterexamples). Not to mention that if the author felt otherwise, they wouldn't have released the code under a license that allowed you to modify and redistribute your modifications.

But making massive changes to a project that are incompatible with upstream is definitely not a good thing to do without reason.

> I disagree that all patches are somehow ethically wrong (bugfixes and security patches are obvious counterexamples). Not to mention that if the author felt otherwise, they wouldn't have released the code under a license that allowed you to modify and redistribute your modifications.

The fact that the author does not forbid it does not mean that he/she wants changes or even encourages them. It just means that the author believes that the downsides of completely disallowing changes are even worse.

There are free software licenses that require you to rename the project if you modify it.

But I digress. This whole discussion is about trade-offs -- if you cannot get the patch upstream but you need to ship it what is the next best thing. I would contend that patching it is better than patching and renaming because renaming doesn't help solve the problem (unless you are very radical and rename the project entirely) and makes things less convenient for users.

And note that distribution users are part of the community of people using the software.

The solution is to either 1) patch it and rename your fork completely, or 2) ship upstream unmodified and use the same contribution process as everyone else to get patches in.

That is how everyone else does it. Only distributions are somehow exempt from fork etiquette. Hold yourself to the same standards as everyone else, and the problem goes away.

I disagree that everyone else does this except distributions.

Companies apply their own patches to projects all the time (as an upstream maintainer I've been asked several times to help debug a patch that some company has used internally). Almost every company using Linux has patches on top of it that are for their specific project (all versions of Android have a forked Linux kernel). GitHub uses patched versions of Git (though one of their engineers is also incredibly prolific upstream). And so on.

The reason why people think distributions are the only ones doing it is because we maintain all of the software that is available for a full Linux system. So instead of only having patches for just one or two projects, we have patches for (probably) ~50% of packages in our distribution (most are bugfixes but there are plenty of not-just-bugfix examples). I think some folks just like to bash distributions because no matter what decisions we make we're going to piss someone off.

But again, we don't apply downstream patches because we like it. In fact downstream patches are an outright headache because we have to rebase them on version upgrades and so on.

Of course companies patch open-source software for their own use. But they either don’t distribute it, or they do so under a different trademark.

Just to focus on your own examples:

- Github patches Linux for their own private use. They do not distribute any Linux derivatives, and they don’t profit from the Linux trademark.

- Android does distribute a Linux derivative, and it is heavily patched, but it is distributed and marketed under the trademark “Android”. Google does not profit from the Linux trademark.

And that’s the difference. People don’t buy Android phones because they’re running Linux. But they buy Suse and Red Hat distributions specifically to get Linux.

So Suse and Red Hat are the only businesses which I know of, that are allowed to fork upstream software, modify it aggressively, and still profit from the upstream trademark.

The vast majority of free software projects do not have a registered trademark. In cases where a free software project does have a trademark, distributions usually will rename the package (distributions do have lawyers and they will usually kick up a fuss in cases like this).

The case of the Linux mark is really weird, because basically all distributions are given license to use it but almost everyone still specifies that the trademark is owned by Linus.

(Also my example for GitHub was their fork of git, not Linux.)

Didn’t you mention elsewhere in this thread that Suse and Red Hat patched Docker, not just to backport fixes but to add features which upstream explicitly didn’t want merged? Surely Docker has a registered trademark. So following your reasoning, Suse and Red Hat should have stopped using the Docker trademark. Yet they didn’t. That example seems to contradict your argument that distributions are very careful to respect registered trademarks, while considering unregistered trademarks to be basically a free-for-all.

This is meant to be temporary. If it is truly crucial they will update happily. If it's not they can wait. Submit the patch upstream, if it is accepted you can then deprecate your code and create an alias, if it's not congratulations you get to maintain a fork.

This changes the culture from you clobbering the original package maintainer, to one where you can adapt when necessary but are still a good community member. The "foobar" people can point people to use "suse-foobar" as a solution until everything has been resolved.

It's not the number of bug reports that matter, it's that you can easily and quickly come to a speedy resolution as an end user.

This is also how non-standard and standards-track CSS features work . The vendors promotes CSS keys like -webkit-marquee-rainbow-animation-spectrum while waiting until all the browser vendors agree on the final spec for marquee-rainbow-animation-spectrum.

For unix tools, downstream vendors could choose to rename the binary (redhat-procps) or rename the flags (procps -- rh-c) if it wasn't incredibly ugrent to choose a single-letter flag name.

https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Pre...

How happy would you be to use a system where 50-75% of commands start with "debian-" or "ubuntu-" or "redhat-" or "suse-" (assuming that all patches have to obey this renaming rule)? As a user, I personally wouldn't want to use a system like that and I would switch distributions to one where I don't have to repetitively type out the name of my distribution into a shell.

I think you've completely missed the point. It should be very rare to need to ship a fork of a project to end users. Patches should first be targeted at the upstream project, but in the rare case where it needs to be used today you should follow this path instead of messing up the API. By doing this you can explicitly set expectations that the changes you are making are temporary and will be deprecated immediately once you get back in sync with master.

As an end user this is ideal, I can get a fix shipped today with the tradeoff that I will have to do a bit of maintenance in the future. Any other way leads to long waits, or chaos.

If you would personally not use a system like this and would prefer one that didn't rename things, even if they were missing the patches, I think that goes to show that the patches are not that valuable.

I'm not an open source developer, but it seems like a good solution is for the original publisher of the package to maintain their vision, take whatever feedback they deem useful, and ignore what they don't feel is useful. If RedHat or the other distributions want to keep maintaining their patches, let them; that's what they're being paid for. If it ends up fragmenting the Linux ecosystem, which IMO it does, then the distributions should do more introspection and cooperate more to reduce fragmentation.

While distributions give variety and diversity - sometimes a good thing - I would love it if Linus would get all distributions in a room and force them to agree on a whole set of issues to eliminate silly differences between distributions. And if they don't/won't agree, they don't get to use the Linux trademark.

It's human nature to think your way of doing things is best. But I'm not sure the multitude of idiosyncratic differences between distributions is really advantageous to users. It does lock users into a distribution, because as you said, who wants to go through all their scripts and rename every instance of ps to rh-ps, then go back and rename everything again when the patch is accepted.

I do think the idea of paying the original maintainers (from the company, not from you personally), has a lot of merit. After all, that's where the stuff was born; it's RedHat's "raw materials" supply.