Hi, I will try to address some of those points. It's honestly a lot, and dealing with them will take quite a while, considering the complexity.

However, let's start from the beginning:

1. I will talk with a few folks and try to get awareness going for it, sorry about that :D
2. This would be possible if zypp saved its history and related bits in a database like dnf does. However, this will take months if not years to actually get in the codebase if anybody starts it.
3. Look at 2
4. Sounds fairly easy to support, I will try to implement that next time I have the chance
5. YaST windows aren't aware of what they are in the first place, they don't have any app id set, they have no idea about desktop file they belong to, they know nothing about which module they actually are. I did initial patches to help with that underlying issue, but I got stopped by absolute hell of a fork that is YaST Control Center. It's KDE Control Center from KDE 3, just in Qt5, with nothing removed, just stuff randomly added, it's really hard to work with.
6. This breaks and gets fixed fairly often, unfortunately, you would need to talk with KDE stack maintainers on matrix in #opensuse-kde:matrix.org room to discuss why and how
7. Look at 2
8. I would argue that's not an incorrect assessment that SUSE's UX expert pointed out, if we decide to have those options be saved, we need to ensure users are aware of the options that are set currently. The defaults are made to be safe, everything outside of this will fall under "user has to know about it in every step of the way" category. This requires further development in the area however. I would jump on this and ask YaST team for widgets designed for notifying users in app about non-default selections in their UI improvements thread on Github.
9. This will require extensive talk with the lawyers, which is why nobody is willing to start it right away. Unfortunately the structure of the project requires everything related to making it easier to use licensed codecs and certain proprietary software to be thoroughly discussed with the legal. This process is only automated in case of packaging, and we have not found any reasonable way outside of discussions to fix the communication issues that arise from that.

Wow, I didn't expect anyone to see this, let alone comment on it. Nevertheless, I appreciate your thoughtful responses.

The GTK beep situation would be resolved if someone accepts this patch: https://build.opensuse.org/request/show/728598 :)

On the subject of Zypper, have you considered just using DNF instead? It's mature and compatible with your packaging format. You would benefit from its modern codebase and all the work that the Fedora people have already put into it. You could share documentation and development resources, much like how both Ubuntu and Debian both use Apt. Might be a winner if Zypper's codebase is buggy unmaintainable spaghetti code that nobody wants to touch.

For media codecs, I understand the legal complications, but I thought Europe didn't honor software patents? My impression was that this is how Canonical (another European company) can get away with shipping them. I wonder what's different about SUSE.

The YaST stuff is minor because you don't have to use it. Probably not a huge priority IMO.

The dnf in openSUSE is a taboo subject mainly for SUSE. Sure, we could embrace it (with some changes, it requires some maintenance to add some zypper stuff in there), however the tooling is already zypp centric enough, that it would take a reaaally long time to port everything over.

Are zypp and zypper unmaintainable? Far from it. Compared to voodoo magic in apt and friends (and I'm counting them in just because the package resolving is done in the frontend for no good reason), it's easy as pie, it's only slightly more challenging than dnf. Main issue is that nowadays it's maintained by 1.5 people + random contributions here and there, so getting features in is a challenge. Moreover, the packagekit backend is a major mess of things, so I have taken care of making it actually fairly usable. SUSE doesn't care about desktop at all, so features of the package manager aren't built for whatever is useful for desktop UX at all. That's openSUSE's role entirely, and for contributors, that's usually a waste of time if there is no guarantee SUSE will be interested (thankfully pk is maintained by hughsie).

We honor software patents, because of trade agreements between different countries in US as well as SUSE having been HQ'd in US for some time. Also keep in mind, openSUSE downloaded in Germany is the same as openSUSE downloaded in the US.

As the maintainer of the DNF package manager in openSUSE, I can speak a bit about this...

It is definitely possible to replace Zypper with DNF on a running openSUSE system. I've done it quite nicely for over a year now. I maintain an OBS project where I continually integrate on Tumbleweed some work I'm doing to improve integration of DNF and PackageKit on openSUSE¹. One of the things I want to have done before I'm completely comfortable with merging this into Tumbleweed is getting the DNF upstream CI working on openSUSE. There's some quirks in openSUSE that need accounting for, and that's an effort I'm undertaking.

Replacing Zypper entirely with DNF would involve doing work in YaST, which is unfortunately a bit difficult for someone like myself who contributes primarily in his spare time.

The maintainability of the Zypper codebase isn't necessarily terrible, but it's going to be very hard to fix some core design decisions that hurt it without rewriting the whole thing. And I don't think that's going to happen anytime soon.

If you're interested, I did give a talk at the openSUSE Conference last May about DNF vs Zypper². It's probably worth a watch. 😄

If more folks in openSUSE are interested in replacing Zypper with DNF, it's definitely a conversation worth having in the openSUSE community.