Reflections

After compiling, adjusting, and listing Wireshark, I decided to check the forum to see if there were any questions about open-source applications. To my surprise, the attention to open source has significantly increased. Seeing some of the recent hot topics, I started questioning many aspects of my current open-source adaptation work. Am I still connected to the essence of open source?

The Meaning of Re-adapting Open Source Applications

In some practical scenarios, there are many instances of "reinventing the wheel," where people start a new project from scratch to achieve the same or similar functionality, despite the existence of other open-source projects that could be used. For example, each major desktop environment has its own file manager: DDE's dde-file-manager, KDE's Dolphin. Strictly speaking, these are not reinventing the wheel but rather integrating better with their respective desktop environments.

Another situation is the adaptation of open-source applications, like what I am doing now. Many of my works can be found in the system's app store. However, some attentive users might notice:

• "Hey, isn't this application already in the system repository? Why waste resources to adapt it again?"
• "Debian 12 has this application updated to 3.6.1, why is the store version still 3.6.0?"
• "Why does the application store need to create a new package name that is incompatible with the official package provided by the software developer for Deepin?"

Thinking about these questions, does your blood pressure rise? Isn't this just redundant work? Hold on, let me slowly explain the small details. I would summarize it with two key points: accessibility and user-friendliness.

Usability

First, a question: setting aside command line enthusiasts, do you find it more convenient to install packages using apt or to one-stop click "install" in the app store while looking at screenshots, application descriptions, and reviews? Although commands can directly install various packages from the system repository, it might be somewhat challenging for novice users. Moreover, not using the app store might mean missing out on various features like periodic app recommendations and changelogs for version updates.

User Experience Optimization

Have you tried Wireshark-4.0.8 recently? Those who have should notice that we thoughtfully prepared two desktop launch modes, one for normal mode and one for root mode. I won't elaborate on the backstory here, but if interested, we can discuss it separately later.

Why set up these two modes? Generally, I preview user feedback in the app store before adapting open-source projects. This time, Wireshark's normal user permission can open the program but only shows a shell, while full functionality requires root permission. After evaluating and testing feasibility, I brought "two desktops + notification window + bilingual support" for an exclusive experience.

"Two desktops + notification window" allows users to open in different modes conveniently, "notification window" displays relevant information based on the mode, and "bilingual support" sets Chinese and English prompts according to the system language, considering overseas users' experience.

I observed that the original Wireshark compiled desktop file does not provide this level of optimization. However, the version in the Deepin app store achieves this level of user-friendliness. Feel free to leave your comments on the details.

Ecosystem Diversity

Strictly speaking, each package has a relatively unique name, as most package managers check the package by its name. But for the same application, especially open-source projects, they can be modified and distributed multiple times. Besides using version numbers to distinguish them, there is no strict requirement for everyone to follow the same package name.

Why do mainstream distributions like Debian retain the package name through version iterations and not easily change it? I think there are a few possible reasons:

• Important projects/libraries in mainstream distribution repositories are maintained by the same maintainer for long-term stability and maintainability, so the package name does not change significantly.
• Significant changes in package names would require adjusting dependencies of related packages/libraries, which is not conducive to user experience and repository maintenance.
• Even though everyone has the freedom to compile open-source projects, most people are conscientious enough not to submit packages that already exist in the system repository.

Additionally, if you install a package with the same name from both the app store and externally, only the newer version will be retained. If you want to keep the local version but upgrade it in the app store, the local package will be replaced.

Stability Testing

Before an open-source application is listed in the app store, it goes through a testing process. It's hard to guarantee which version has critical issues or which version loses expected features. Therefore, after selecting a package, we compile it first, and if there are no critical issues, we proceed with other operations to ensure the best user experience.

The Difficulty of Adapting Open Source Applications

If you think we just convert some binary archives provided by the official source or directly usable deb packages to list in the app store, like Visual Studio Code, I can honestly tell you it’s just a few simple steps, "unpack -- run -- repackage."

But if you read the above content, you'll understand that things are not that simple. It’s not just about compiling from source; the core lies in aligning with end-users and developers. Of course, this doesn’t just mean continually meeting user needs, which might suit a consumer-oriented direction. I hope to help users with strong professionalism to provide satisfactory answers, like this time with Wireshark. Most users may not know they need to run it as root, so we optimized it.

Applications/software packages are just ordinary outputs. The irreplaceable part is the differentiated user thinking that arises during the adaptation process.

Conclusion

I used to think that adapting open-source applications and listing them in the app store was tarnishing the open-source spirit, and I was not making a code contribution to the program's core. These optimizations were at most ordinary suggestions. But later, seeing everyone’s support for open source, I felt relieved.

I hope to have the opportunity to share my stories during compilation and encourage friends using other distributions to use my compiled, optimized, and adjusted open-source applications on Deepin.

I also hope that I am not fighting alone in the open-source community.