Infinity future: Pros and Cons of being a KDE project

[shenlebantongying]

Pros

• Bus factor > 1 forever via common ownership (all entrusted KDE devs have access to most repo.). If both of us suddenly disappear, KDE can delegate a new maintainer if someone wants to, instead of the painful process of forking. This will ultimately eliminate the problem of the original GD. I think this single reason is good enough.
• No need to maintain translations anymore
• Auto release service, and we don't care about when to release https://www.google.com/search?q=KDE+gear https://community.kde.org/KDE_Gear
• Able to distribute through Microsoft Store
  • https://apps.microsoft.com/search/publisher?name=KDE%20e.V.&publisher=KDE%20e.V.&hl=fr-cf&gl=CF
  • https://develop.kde.org/docs/packaging/windows/microsoftstore/publishing/
• macOS version notarization Homebrew cask for macOS, help wanted #1141
  • https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/signing#project-specific-settings-for-macos-services
• Cool domain and documentation site like https://ghostwriter.kde.org/

Cons

• Need to host on KDE's infrastructures (changes overtime, currently it is GitLab + Bugzilla) instead of the popular GitHub
• Bloat, requires sharing tech with other KDE components (like depending on KXMLGUI). More complex build process

Anti-Cons

• GitHub is owned by evil corporations. Free software should be developed on open-source infrastructure.
• Bloat is good, KDE frameworks provides various staffs that we don't want or no time to write, such as
  • better colour scheme, instead of Qt stylesheets
  • Shortcut manager, instead of reinventing on our own
  • Free UI scaling Unify "Show small icons in toolbar" and "Alt +/-" into GUI Scaling #1459
    • 

https://manifesto.kde.org/benefits/

@xiaoyifang What do you think? This is my contingency plan. 😅

[xiaoyifang]

Maybe try to bring more maintainer first

[shenlebantongying]

Maybe try to bring more maintainer first

I propose inviting @atauzki to the collaborators list too.

He has been with us since a very early time. He is generally a good person, knows at least the build related code, knows at least mdict format much more than me, able to distribute his own GD-ng build.

Furthermore, he can help maintain and code review build related things.

[xiaoyifang]

@atauzki What's your opinion?

[atauzki]

just packaging only，my need of offline dict is much less than before, so I don't so much care about some new features.

Maybe we can get more enthusiasts on freemdict, and listen to their opinions.

[xiaoyifang]

just packaging only，my need of offline dict is much less than before, so I don't so much care about some new features.

These should be fine, You can do what you are good at .
Added.

[aero31aero]

Not sure if you're open to outside comments, but I as a user would love to see Goldendict as a KDE application. Another advantage is kinda by default getting into more Linux package managers.

Example, I currently use the AUR package for goldendict-ng-git and it sometimes breaks with updates when some libs are not in sync. Its just a small user headache that'd automatically be resolved if Goldendict makes it into the main Arch repos like other KDE projects.

[KonstantinDjairo]

Not sure if you're open to outside comments, but I as a user would love to see Goldendict as a KDE application. Another advantage is kinda by default getting into more Linux package managers.

Example, I currently use the AUR package for goldendict-ng-git and it sometimes breaks with updates when some libs are not in sync. Its just a small user headache that'd automatically be resolved if Goldendict makes it into the main Arch repos like other KDE projects.

how packaging has something to do with being a KDE project or not?
there IS non-KDE projects in the official arch repo.