Introduction
To state my conclusion upfront: I hold a pessimistic view of the domestic open-source environment.
This stems from a post on V2EX: 【Domestic Open-Source Environment】- V2EX1, and I’ll also share some of my thoughts on open-source projects.
What is Open Source?
Open source originally originated from the free software movement2. Note that the free here does not mean “free” as in gratis, but rather “freedom.” Free software refers to the freedom to run, study, modify, and share (distribute copies, whether modified or not) the software.
Open source refers to a computer program whose source code is available for public use or modification of its original design. The code is released under software license terms. According to these terms, others can download, modify, and release their versions (forks) back to the community3.
Alright, now let’s take a look at what the domestic “largest” “open-source community” Gitee is actually like?
[How to view the May 18th Gitee repository open-source audit, with some already open-source repositories temporarily closed, to be reopened after passing the audit? - Zhihu] 4
Of course, I registered with Gitee quite early. Not using it doesn’t mean it’s not good; after all, in terms of speed, it’s definitely stronger domestically than GitHub, but this is largely due to some personal bias of mine. Mainly, there are too few projects, and the quality is too poor. The functionality at the time was average, and there were no features like GitHub Pages back then. It was also always, always many steps slower than GitHub. Another point is the various restrictions on repositories, such as capacity limits. I also know that Gitee officially answered this, saying this move was out of helplessness5. Since it has been prohibited by policy, the so-called “free software” no longer exists.
Domestic Open-Source Projects
First, let me share my understanding of the term 开源项目. I believe the most fundamental requirements for an open-source project are README and LICENSE. These two files form the foundation of an open-source project, directly explaining how the project can be used and distributed. Meanwhile, Awesome-List should not be considered part of the open-source project scope; at best, it counts as open-source documentation. A complete open-source project should have a relatively complete workflow and standardized contribution methods, such as CONTRIBUTION.md, which tells the community how to contribute and submit code, along with basic coding standards. Most importantly, there should be complete documentation and version numbers; even better would be milestone or roadmap, so that the community can better participate and see the future development plans of the open-source project. Of course, someone must also be available to address issues in issues and Discussion. Additionally, there should be some basic test cases and CI/CD configurations to ensure project quality.
I have to admit that there are actually many excellent open-source projects in China, with many being incubated by the Apache Foundation.
But if you observe, you’ll find that these excellent open-source projects are almost entirely undertaken by enterprises, while excellent projects by individual developers are extremely rare.
Open source in China belongs to enterprises; there are no individual developers. There is open-source software, but no open-source community.
Environment for Individual Developers
In China, an open-source project has two possible fates: one is being acquired by an enterprise (which I believe is the best outcome for an open-source project), and the other is the creator founding their own company.
Let’s discuss the first point first. Of course, most enterprises are unwilling to do this, as it represents a significant expense. What benefits does it bring to the enterprise? Since it’s open source, it can already be used freely, so… the difference between acquiring and not acquiring is merely making the roadmap better aligned with the enterprise’s project needs. Moreover, in the current domestic pandemic environment, layoffs and “graduations” have become commonplace. Funds and personnel previously allocated to internal open-source departments within enterprises have mostly been shifted to business departments, making acquisition even less likely.
If the first path is not viable, what about the second? The difficulty is self-evident: how to achieve profitability? Naturally, it would be 2B (business-to-business), integrating with enterprise APIs. This is essentially similar to the first point. As for how to execute 2B, that’s where the real challenge lies. What you need to do is use your open-source project as your business card, showcase it to companies, and then proceed with cooperation. However, as an open-source project, if you want to maintain this business card and ensure its long-term survival, you will inevitably need to go 2C (business-to-consumer).
Is there any other path besides focusing solely on 2C? Yes, Sponsor. Oh, right, I forgot to mention that developers in mainland China cannot register as Sponsors on GitHub. This means you can only achieve sponsorship by placing your own QR code, and you won’t be able to use many of GitHub’s Sponsor features. Gitee seems to lack a Sponsor system entirely; the domestic review process for this will likely take some time, given it involves tax issues. However, Sponsorships can still provide some help. In reality, whether domestic or international, the outcome is often similar. The truly effective approach should be to use a Pro version to create differentiation and guide users to pay. I believe this is the best path an individual developer can take on their own.
I wonder how many people still remember the colors.js incident6. The author chose the MIT License, hoping to generate revenue or job opportunities through Sponsorships. However, the result was that enterprises used it, but no one paid. Eventually, the author injected malicious code, causing numerous projects to malfunction, and the author’s GitHub account was even temporarily banned. As a developer, I can easily understand the author’s feelings, but I don’t understand why they chose such an open-source license in the first place. If you want to profit once, either create differentiation or simply avoid using such an unrestricted open-source license. hcaptcha-challenger This project is similar; many people use it to scrape Discord tokens or engage in gray-market activities to make money, yet no one is willing to open-source their work or comply with the GPLv3.0 License provided by the project.
China is gradually strengthening its legal framework regarding open-source licenses. There have been legal disputes arising from open-source licenses that have been adjudicated, demonstrating the validity of open-source licenses under Chinese law. I hope that similar incidents triggered by open-source licenses can be properly resolved within China’s open-source projects.
User Environment
A very simple question: if you are not a high-intensity GitHub user (like me, who browses GitHub more than their Qzone and WeChat Moments…), visiting GitHub is usually purposeful, such as looking for experimental code or finding existing projects to use. It’s not common for beginners to use it smoothly (after all, you need to bypass the Great Firewall to download releases and view images in READMEs), let alone expect them to comply with open-source licenses. They might not even know what an open-source license is. Of course, some beginners not only know nothing but also refuse to read the code, directly opening issues to ask questions without checking the Wiki, and they have a terrible attitude, as if open-source developers exist solely to serve them.
This is evident from the hcaptcha-challenger project. Myself and another developer frequently receive emails ‘greeting’ us. Why should I solve problems unrelated to the project for you? For instance, I once received an email asking me to help solve a CAPTCHA for a specific website. Let alone the fact that the project’s original intent was to combat hCaptcha, not target their ‘specific website,’ the code is open-source, yet they are unwilling to even understand the project structure, purely seeking results. I certainly won’t help people like this. I don’t believe that someone who needs translation software just to reply to an email ‘greeting’ me can bring any future value. It’s inherently a gray industry, and I have no desire to get involved.
Of course, this isn’t specific to the domestic environment, so I might be slightly off-topic, but many domestic users share the same attitude. For example, the controversy surrounding YOLOv7 made me feel embarrassed (I can’t find it now, but someone used Chinese to verbally attack the original YOLOv7 project’s naming in an abusive tone). Therefore, I advise everyone to use English when communicating on GitHub. Do not reply using web translation plugins. When asking questions, communicate politely and use honorifics. Respect the developers’ work; developers are not your employees!!!
Conclusion
That’s basically the entire content of this article. I sincerely hope that China can build a robust open-source community, at the very least ensuring that it doesn’t hinder product and project iterations, and that audits do not become a burden on developers, limiting the development of open-source projects. Additionally, I hope to see a well-established Sponsorship system, allowing excellent individual developers to pursue their interests, maintain their open-source communities, and support themselves financially.
