The future of Upscaler - name change and expansion to media restoration
Greetings everyone,
I created this project as my last assignment for CS50x. It was specifically meant to upscale images. After I completed and submitted the assignment, I decided to turn it into an actual project. However, in the past few days, I've been thinking of expanding the application to a fully fledged, media (image and video) restoration program that leverages Vulkan, or, with obvious limitations, the CPU. Users have been suggesting to support algorithms that solve problems unrelated to upscaling, which I'm personally in favor of that. As such, I created the Next - Media Enhancer label for its successor. I'm proposing a name change and expansion of Upscaler. Upscaler was just released a week ago, and taking long term decisions early in its life would hinder less as possible. "Upscaler" is a good name for upscaling specifically (essentially what the app does right now), but may be misleading for a fully fledged image restoration program. Right now, I'm keeping Upscaler, but as soon as we start adding more algorithms, "Upscaler" will become misleading, so I'd prefer to change its name at that time.
Here are some things we need to consider:
- Name change. Since I'm proposing a name change, what should the name be? We should focus on complying with GNOME's App Naming guidelines.
- Flatpak app ID. The application ID is
io.gitlab.theevilskeleton.Upscaler
. If we decide to change its name, then the app ID will become "outdated". I noticed that Element (formerly Riot) kept its app ID (im.riot.Riot
). So, should we keep the app ID or resubmit the application under a new ID?- One downside I can think of with resubmitting: Most articles and videos that reference Upscaler will become outdated. This will become more difficult for users to install its successor, as they'll have to take an extra step. What I can do to "address" this is to push a final update that recommends the user to install its successor.
- One downside I can think of with not resubmitting: The app ID will become outdated, and thus, misleading and inconsistent with the application name. This shouldn't be a problem for the majority of users, but I dislike inconsistency. It's not a big deal, though. The benefit outweighs its downside.
- Hosting on GNOME GitLab. One of my goals is to get this app on GNOME Circle, and hosting it on the GNOME GitLab instance. By hosting it on GNOME GitLab, we should receive more translations/translators, moderation from the GNOME moderation team, and access to the GNOME Nightly Flatpak remote for testing purposes.
- Sustainability. If this project genuinely gains a lot of traction, to the point we want to keep maintaining for a really long time, then opening up a donations and ask for sponsorships would this project's future a lot. I have no knowledge with finance within an organization, so I'd have to do a lot of research here. But I would definitely love to make this project sustainable. I don't have a job, so eventually I'd need a way to get money to maintain my future self. If the project is unsustainable, then there's a risk of me stepping down this project. Furthermore, I'd want to invite people who have contributed to the project to make it more maintainable, too.
- Chat. I want to open a chat for this project eventually. I do not want to support proprietary services/applications, so I prefer to use Matrix. I believe GNOME might provide us a room if we get it to GNOME Circle, so we could use advantage of that. We might lose potential contributors, but I'm willing to sacrifice for ethics.
- Extensions. Upscaler isn't really designed to be modular, as it was only meant to be for Real-ESRGAN ncnn Vulkan. However, a utility might work completely differently than another, so we will need to split up modules to interface with different backends.
Here are things I want to keep as is:
- Mirrors. I do not support GitHub, as it is a proprietary and closed source platform that recently started to exploit free and open source projects (Source). As such, I do not want to mirror to GitHub, as we'd be forced to accept their terms of service for this project otherwise. Even if GitHub "improves" its ethics, its history of exploitation permanently damaged my trust. We may lose potential contributors and hinder discoverability, but I'm okay with sacrificing these for ethics. I created a placeholder repo that links to GitLab, so the most we can do is create a placeholder repo for its successor, too. I support Codeberg's mission and trust its future, so I want to keep a mirror there, perhaps backup too.
- Copyleft license. Copyleft licenses prevent entities from forking a free and open source project and redistributing proprietary forms of it. To preserve openness and freedom (especially openness), I want to keep GPLv3.
- Open source libraries and computing only. I plan to not support CUDA, as it's proprietary. I prefer to entirely promote and focus on open standards, like Vulkan.
- Flatpak as first class. Flatpak has a much wider scope than AppImage and Snap combined, so I prefer to stick with Flatpak for that reason.
- Linux as first class. I'm not interested in other platforms and don't really have the resources. When I say Linux, I mean the Linux desktop and the Linux mobile space, excluding Android.
- User friendly by design. By expanding the app, it will likely become more difficult to use. However, my priority is to be as user friendly as possible.