Of course, think about the relationship between Ubuntu and Debian. The idea is the upstream would be a fully open-source project that vendors build off of downstream. This way we can prevent vendors from subjugating a distribution like with Red Hat and CentOS and if a vendor pulls out of the market or goes out of business it doesn't take down the ecosystem with it.
Why do you think this? OSes like Debian don’t just pull packages from upstream automatically. Packages have actual maintainers affiliated with the OS, not the upstream community, and it’s those maintainers who build packages for the OS repos.
I think it would help if distributions could snatch a piece of real estate in upstream software. Something like, "in every project, the debian/ root folder belongs to the debian project and follows their rules". The packaging could then verify this folder and put their patches, build scripts, etc. there. This would help upstream communication a lot, I guess.
Because they were started by, and are still mostly (unless I'm gravely mistaken) developed only by the same people that develop for Ubuntu. If they were more autonomous, I'd be more willing to consider them "upstream".
Dealing with the upstream linux community is a painful, time-consuming process. A lot of hardware vendors would rather just not bother, and release their source code to maintain GPL compliance, but never attempt to upstream anything because the process is so time consuming, with little to no immediately apparent upside. This is especially true if they are a parts supplier with a handful of large customers who don't care about upstream support.
Sadly more and more upstream wants to have their cake and eat it to. Just look at Flatpak, that is all about moving the updating and distribution from distros to upstream.
Opinion: the 'perfect solution' is to keep up with upstream and avoid backporting. It takes more work, but it reduces the separation between distro and upstream.
I suspect that they want to keep their infrastructure and processes loosely coupled to the upstream to maintain independence. Given the fate of certain open source projects affiliated with large corporations (Sun's ones in particular come to mind) I think this is a prudent course of action.
Separate projects like this is how a lot of these "RHEL Enterprise $FOO" are actually made.
RedHat / Suse / Ubuntu / $Vendor take the upstream project, tidy it a bit, package it, get it integrated in their ecosystem, and add an easy installer.
Having it in a vendor neutral foundation means that all the vendors can colaborate, and not have one group with a massive advantage or complete control over a roadmap.
I think it's quite important to have a good relation with upstream developers. You don't want to get into the situation that Manjaro got in with Arch Linux.
In my experience the types of developers building this stuff are personally fans of open source and companies are willing to let them submit upstream due to PR wins and limited downside.
Also, upstream may have different concerns. For example, they want to be built on various versions of the distribution while Debian will usually only target unstable.
I am upstream for some of my packages and I don't provide the same debian/ directory upstream as I use for Debian.
> Those days are pretty much behind us. Sure, you can compile code and tweak software configurations if you want to--but most of the time, users don't want to. Organizations generally don't want to, they want to rely on certified products that they can vet for their environment and get support for. This is why enterprise open source exists. Users and organizations count on vendors to turn upstreams into coherent downstream products that meet their needs.
> In turn, vendors like Red Hat learn from customer requests and feedback about what features they need and want. That, then, benefits the upstream project in the form of new features and bugfixes, etc., and ultimately finds its way into products and the cycle continues.
"and when the upstream is tainted, everyone drinks poisoned water downstream, simple as that!"
In my experience distros attempting to keep things as close as possible to packages upstream (except for bug fixes) are always the most useable, stable, etc. So I sort of prefer the "authoritarianism" from upstream.
Additionally, an upstream package has authority only on ONE component. The distro has authority on ALL components. That makes ALL the difference.
Red Hat "fork[ing] most of the upstream" is not telling the whole story. Yes, Red Hat works with upstream code, does additional QE/QA and certification as needed and make that available to customers on a subscription. Changes, improvements, bugfixes etc are all also sent back upstream. It is a two way street. Not a one way "take from upstream only" model. If that was the model, Red Hat would have not survived to thrive. Upstream First is the default for Red Hat.
Red Hat's code base is a mix of GPLv2/v3, MIT, BSD, Apache - ie, it spans the entire open source licensing spectrum from protective copyleft (GPL) to non-protective (BSD, Apache, MIT). Red Hat is only obligated to release code to GPL code that it ships to customers, but Red Hat goes above and beyond and ships all code that it worked on or otherwise to customers. There is ZERO value in holding back code/fixes etc. Pushing that upstream empowers the whole global community (yes, including competitors). Not doing so will result in fragmentation of the various open source code bases and downstream products.
Trademarks are not the same as copyright. Trademarks tell the receiver who it represents. It is the identity of the entity. So, that is protected and I think that is very fair.
Not sure what "open-source upstream" means, but in software, there is the complaint that companies like Google can add a lot of complexity to software projects, which serves Google, but not the classic home user of Linux. That can make it effectively their own corporate project and drown out more casual developers.
All distros are beholden to upstreams, this is a fundamental attribute of all of them. Unless the distro develops all of their own interface components and keeps them the same, or forks an existing upstream project wholesale and prevents UI changes. Some of them are starting to do that, but usually they do that so they can change the UI more rather than keeping it the same.
reply