【唐诗】《宮詞二首 一》 張祜：故國三千里，深宮二十年。一聲河滿子，雙淚落君前。

永夜

没有不值得去解决的问题，也没有不值得去学习的技术！

Beyond Ads: How Community Projects Survive Long-Term — I Added Support to the A Tour of Go Multilingual Project

[Figure 3: Simplified Chinese site Support page]

作者：

永夜

在

Post Views: 0

Recently, I added a feature to the A Tour of Go multilingual project that I had been hesitant about for a long time:

Support the project.

The Simplified Chinese site offers WeChat and Alipay; the language sites for international users offer USDC, USDT, and internal transfers on platforms like Binance and OKX.

From a technical implementation perspective, this is not the most complex feature in the project.

What I spent a long time considering was actually another question:

Is it appropriate for a free, open-source community project to add a “Support the project” entry on its pages?

The final decision to add Support this time was not an isolated one.

It is actually closely related to my recent re-examination of the community translation projects in the history of A Tour of Go.

1. This starts with the community translations that have already gone offline

On September 3, I wrote an article:

“From 553 commits in French to two generations going offline in Korean: Why is the A Tour of Go community translation so hard to maintain long-term?”

After re-investigating the historical projects, what impressed me the most was not how many languages there used to be, but rather:

Many community translations had a lot of time and effort invested in them, only to eventually stop being maintained or go completely offline.

The French project is a very typical example.

In the repository history, you can see:

Plaintext
553 Commits
61 Contributors

After further excluding the identifiable official upstream history, the fork-only history I counted at the time still had:

Plaintext
162 fork-only commits
14 fork-only Git author names
An activity span of over 11 years

In the end, the repository was still archived, and the production site is offline. (永夜)

The Korean project left an even deeper impression on me.

After the first-generation project went unmaintained for a long time, someone re-established a second-generation project:

Plaintext
First generation offline
→ New maintainer re-translates and migrates
→ Establishes new Production
→ Re-enters the official language list

A few years later, the second-generation Korean site went OFFLINE again, and the official link was removed once more. (永夜)

So later on, I increasingly agreed with a certain judgment:

The real difficulty with community translation is often not translating a language for the first time, but whether, five or ten years later, there are still conditions for it to continue existing.

2. The “maintenance” of a translation project is far more than just continuing to translate

If you only look at the final result, it’s easy to interpret the offline status of historical projects as:

The maintainers stopped translating later on.

But the actual problem is far more complex.

Historical A Tour of Go community translations have collectively faced:

Plaintext
Continuous upstream changes
runtime deprecation
App Engine deployment failures
production ownership
Deployment permissions
Technical debt
Bus Factor
Maintainer time changes
Infrastructure costs

In the past, Go officials even had to specifically handle the issue of community Tours being unable to redeploy after the App Engine runtime was deprecated.

The translated text might still be sitting safely on GitHub.

But what breaks first might actually be:

Plaintext
runtime
→ deployment
→ hosting
→ production site
→ official link

Once a certain link in this chain goes unattended for a long time, the translation effectively “disappears” for the average learner. (永夜)

This is why the current go-tour-i18n invests a lot of effort into things beyond translation:

Plaintext
Translation Workflow
Quality Check
Locale Surface Review
Production
CDN
Automated acceptance
Upstream sync
Official documentation
Search engines

What I want to leave behind is not just:

This site is now live.

It should also try to leave behind:

Years later, there are still conditions for it to be maintained and taken over.

3. Historical Chinese community maintainers also felt helpless about business models

In the previous article, I also recorded a detail that resonated with me.

I had previously seen Chinese community maintainers express a similar helplessness:

It’s hard to talk about a business model for this kind of project.

I didn’t track down the original source of that quote at the time, so I didn’t include it as a verifiable direct citation, only keeping the general gist. (永夜)

Continuing to work on this project now, I increasingly understand this feeling.

Community translation usually means:

Plaintext
Free access
No memberships
No courses sold
No software sold
No subscriptions
And stable enterprise contracts are hard to come by

From a learner’s perspective, this is of course great.

But for long-term maintenance, it naturally raises another question:

What does the project rely on to keep running?

This question isn’t obvious when the project first goes live.

After one year, five years, or ten years, the difference becomes increasingly significant.

4. A free community project doesn’t mean it has no financial costs to run

Open-source code can be hosted on GitHub for free.

Translated content can also be provided to everyone for free.

But a truly live, running multilingual project still requires ongoing financial investment.

Taking my current A Tour of Go multilingual project as an example, it involves behind the scenes:

Plaintext
Servers
Overseas network nodes
Domains
Public network bandwidth
CDN
DNS / network services
Monitoring and logging
Production storage
AI tools

Some of these capabilities can indeed use free tiers.

For example, many community locales currently use Cloudflare Free.

But:

Plaintext
Some infrastructure being free ≠ the entire project has no running costs

When you add up servers, domains, networks, and various maintenance tools, it still requires long-term investment.

These are relatively easily quantifiable financial costs.

But in practice, there is another part that is often more easily overlooked.

5. Harder to quantify than bills is the long-term investment of time and energy

As the number of languages grows, what truly needs continuous investment is no longer just money.

For example, a single upstream sync might involve:

Plaintext
Check upstream
→ Determine TranslationUnit changes
→ Translation / revision
→ validation
→ Quality Check
→ promotion
→ Locale Surface Review
→ preview
→ Production
→ browser acceptance

When issues arise, it might also require further handling of:

Plaintext
systemd
Nginx
CDN
DNS
TLS
Playground
Browser compatibility
Search engines

None of these will appear on any cloud service bill.

But they are real costs nonetheless.

For a community project, this kind of long-term manpower and energy investment is often scarcer than the servers themselves.

So long-term maintenance actually involves at least two different types of costs:

Plaintext
One type is directly calculable:
Financial investments like servers, domains, CDN, and tools
The other type is very hard to price directly:
The time, attention, knowledge, and energy maintainers continuously invest

The former requires the project to have the means to keep running.

The latter determines whether someone is willing to keep this in their priorities long-term.

Both ultimately affect whether a community project can persist for many years.

6. The sustainable method I initially thought of was still advertising

The A Tour of Go multilingual site has always remained free to access.

So the most natural way to operate it is:

Plaintext
Free content + ads

Users don’t need to register or pay course fees.

If we can secure steady organic search traffic in the future, ads can help cover a portion of:

Plaintext
Servers and networking
CDN and domains
Maintenance tools
Long-term Production operations

In other words, its significance isn’t just about generating a revenue number.

More importantly, it lets:

The traffic generated by users using the project offset some of the project’s own long-term operating costs.

This way, the project is no longer entirely dependent on a single maintainer continuously investing money.

However, I’m also not inclined now to simply describe adding multilingual versions as:

Plaintext
More languages
→ More pages
→ More ad revenue

Because that frames the project’s goals too narrowly.

A more accurate logic would be:

Plaintext
More languages
→ More developers can learn in a language they are familiar with
→ More users and search engines in different regions can discover this content
→ The community project's reach expands
→ Simultaneously increasing the possibility of long-term sustainable operation

The priority is still making sure the content is actually discovered and used by people.

Revenue is part of the conditions for the project’s long-term operation, not the only goal.

7. Current AdSense data is still very limited

Looking at the data from the last 7 days, the go-dev multilingual project currently earns very little through AdSense.

[Figure 1: AdSense data for the go-dev multilingual site over the last 7 days]
[Figure 1: AdSense data for the go-dev multilingual site over the last 7 days]

Many of the language sites still show:

Plaintext
US$0.00

However, this shouldn’t be directly interpreted as:

These languages have no traffic value, or the project is meaningless.

First of all, many locales have just gone live.

More importantly, I have already disabled ad displays for the 4 sites that have been added to the official Go translation list.

Therefore, the current ad data inherently mixes two different states:

Plaintext
Some sites:
Continue to share operating costs through ads
Other sites:
Have stopped showing ads to enter the official language gateway

This also brings up a very practical trade-off.

8. Between official links and ads, I ultimately value “being discovered and used” more

For a community translation project, being included in the official Go A Tour of Go language list is extremely valuable.

What it solves first is not a revenue problem, but rather:

Discovery.

Even if a new language site has already:

Plaintext
Gone live
Has a sitemap
Been submitted to search engines
Completed SEO

It doesn’t mean target users immediately know it exists.

An official link is completely different.

Developers visiting the official A Tour of Go can directly see:

There is a version in my language here.

This is exactly what community translations want to happen the most.

So currently there is a very clear choice:

Plaintext
Join the official links
→ Easier to be discovered and used by target developers
→ But requires removing ads
Don't join the official links
→ Can continue to keep ads
→ But getting stable exposure for the new site will be much harder

If you only look at short-term revenue, you might lean towards the latter.

But if you return to the very meaning of community translation:

It’s made so that people will actually use it.

Then the value of the official gateway cannot be calculated solely by ad impressions.

So even if ads are removed for these 4 language sites, I still believe joining the official links is the more valuable choice.

9. This also means ads cannot be the only sustainable method

This trade-off also made me rethink a question:

If a community project only has ads as a revenue source, then precisely on the most valuable official exposure channel, it might be completely unusable.

This doesn’t mean we should abandon official links.

It also doesn’t mean we should try to sneak ads back in.

A more reasonable direction is:

Not letting the project’s long-term sustainability rely on just one method.

That’s when I seriously started considering:

Support.

10. Why have I always felt some psychological burden about Support?

In the open-source world, voluntary support is actually very common.

GitHub Sponsors, OpenCollective, and the sponsorship pages of many independent projects are nothing new.

But when it comes to my own project, I still felt a bit awkward.

How much of this psychology is related to traditional Chinese culture is something I wouldn’t dare to simply conclude.

If I directly attributed it to:

Confucian culture looks down on commerce.

I feel that would be too arbitrary.

“Righteousness vs. profit,” “scholars vs. merchants,” and “the position of commercial activity in traditional culture” are in themselves a major historical and social topic, and it’s not appropriate to draw simple conclusions in a technical project article like this.

But at least from my own feelings:

In a Chinese context, publicly discussing income, sponsorship, and support often carries an extra layer of psychological pressure compared to just discussing technology.

It’s easy to worry about:

Plaintext
Will it seem too utilitarian?
Will people think I'm just asking for money?
Is it appropriate for an open-source project to talk about these things?

That’s why I used to be more accepting of ads.

Because ads appear to be:

Plaintext
Users continue to use it for free
Advertisers bear the cost

While Support requires directly facing:

Are you willing to support this project?

Later, I gradually realized that these two things don’t need to be opposed.

11. Allowing users to voluntarily support does not mean changing the project’s open nature

Adding Support to the A Tour of Go multilingual site will not change how it is used.

People who don’t support the project can still:

Plaintext
Access for free
Learn for free
Use the Playground for free
View all courses

There will be no:

Plaintext
Chapters unlocked only after supporting
Code running only after supporting
Full features available only after supporting

And the project source code itself remains public.

If someone doesn’t want to use the Production site I deployed, or doesn’t want to see the ads on it, they can still:

Plaintext
View the source code
Deploy it themselves
Continue to share it

Support doesn’t turn open-source content into paid content.

It just adds a new option:

If this project is valuable to you, and you are willing to participate in its long-term maintenance, you can provide voluntary support.

12. So I ultimately built Support formally into the project

This feature wasn’t completed all at once either.

The Git history shows the process of it gradually being refined.

[Figure 2: Support feature evolution timeline]
[Figure 2: Support feature evolution timeline]

Initially it was:

Plaintext
feat: 添加多语言项目支持入口

Then it was:

Plaintext
feat: 完善多语言项目支持方式

Finally, I added:

Plaintext
feat: 增加英文 README 并优化项目支持展示

From a simple entry point, it gradually became a formal feature that needed to account for:

Plaintext
Different languages
Different regions
Different payment habits
UI
Mobile
Copy interaction
Translation
Production

and more.

13. Is it “supporting the entire project” or “supporting a specific language version”?

I specifically considered this question later on as well.

If every language page had a Support section, it would easily make people feel:

Why is it asking for support everywhere?

So the hierarchy needs to be made clear.

Looking at the project as a whole:

Support is aimed at the continuous maintenance of the entire go-dev multilingual project.

The GitHub README also uses:

Plaintext
Support the project

Because a lot of the infrastructure is shared:

Plaintext
Code repository
Production tooling
shared assets
Maintenance processes
CDN / network capabilities
AI tools
Long-term engineering maintenance

But when a user actually enters a specific language site, they are looking at a specific locale.

So the on-site pages express Support as:

Support the continued maintenance and development of the current language version.

For example, the Simplified Chinese site says:

Plaintext
支持简体中文版本

The Korean site corresponds to the Korean version.

The point of this isn’t to split the whole project into dozens of completely independent “mini-projects.”

Rather, it’s to let users clearly know:

Which community language version they are currently using, and that support will help this version and the shared project behind it continue to be maintained.

So the two-layer relationship can be understood as:

Plaintext
GitHub / project level:
Support the entire multilingual project
Specific locale page:
Provide a Support entry from the perspective of the current language version

This way, it doesn’t make the project hierarchy look messy, and it lets users on every language site understand how this entry relates to them.

14. The Chinese site first provides the most natural domestic methods

The Simplified Chinese site currently mainly offers:

Plaintext
WeChat Pay
Alipay
[Figure 3: Simplified Chinese site Support page]
[Figure 3: Simplified Chinese site Support page]

The core message on the page is:

Help this language version continue to be maintained and developed.

What is emphasized here is not a one-off “tip”, but rather linking Support to the long-term operation of the project itself.

It corresponds to the continuous work behind this language version, such as:

Plaintext
Translation updates
Upstream sync
Production
Infrastructure
Long-term maintenance

In other words, Support is placed within the context of “continuous project maintenance” on the page, rather than existing merely as a standalone payment entry.

15. A multilingual community project can’t only provide domestic payment methods

Since the project targets international users, offering only WeChat and Alipay is clearly not enough.

So in the international version, I added:

Plaintext
USDC — Base
USDT — Tron (TRC20)

As well as optional:

Plaintext
Binance
OKX

Internal platform transfers.

[Figure 4: Support the project in the English README]
[Figure 4: Support the project in the English README]

If a user and the project maintainer happen to use the same platform, internal UID transfers can reduce the inconvenience of small on-chain transfers in some scenarios.

Of course, actual availability and fees should still be subject to what is displayed on the platform at that time.

16. Support finally made it into the actual multilingual Production pages

Later on, I didn’t just leave this content in the GitHub README.

Support also officially entered the various language sites.

For example, the Korean site:

[Figure 5: Korean production site Support page]
[Figure 5: Korean production site Support page]

The following on the page:

Plaintext
Title
Description
Assets
Network
Address
Minimum amount
Risk warning
Internal platform transfer

are all localized just like the rest of the UI.

This means Support is no longer just:

Plaintext
A snippet of payment info attached to a README

But a formal multilingual surface.

So it also needs to go through:

Plaintext
Locale Surface Review
Production
browser acceptance

This is also why I now prefer to call it:

The project support feature.

17. Who might actually use Support?

Tutorial sites are a bit different from regular software services.

A Tour of Go is not a tool that users need to open every day.

Many people’s usage path might just be:

Plaintext
Search for a tutorial
→ Learn once
→ Solve a problem
→ Occasionally review later
Or recommend it to others

So I no longer imagine Support as:

Something only “long-term, high-frequency users” will use.

A more reasonable scenario might be:

Someone only used it once, but felt this translation was genuinely helpful, and therefore is willing to show their support once.

There might also be people who follow the project long-term.

It’s also possible that the vast majority of users just use it for free and leave.

All of this is normal.

Support isn’t aimed at a fixed “paying user persona.”

It just keeps an entry open for anyone willing to give back to the project.

18. Ads and Support solve different problems

Ads are suited for:

Plaintext
Large volumes of regular traffic
→ Each visit contributes a tiny amount
→ Aggregating into a portion of operating revenue

Support is more like:

Plaintext
A small number of users actively validating the project
→ Voluntarily providing one-time or multiple support

They correspond to completely different behaviors.

And official links are a third dimension:

Plaintext
Letting more target developers actually discover and use the project

So my thinking now is less and less about:

Choose ads, or choose Support?

But rather:

Plaintext
Official gateway
→ Improves discovery and usage
Ads
→ Shares a portion of operating costs on sites suitable for showing ads
Support
→ Provides an entry for those willing to actively give back to the project

These methods can coexist, each solving different problems.

19. Support itself doesn’t create users

This also requires keeping very realistic expectations.

The project adding:

Plaintext
WeChat
Alipay
USDC
USDT
Binance
OKX

won’t automatically generate any revenue.

If:

Plaintext
No one discovers it
No one uses it
No one finds it valuable

Then even the most complete Support page is meaningless.

So Support is not a traffic growth strategy.

What truly matters remains:

Plaintext
Translation quality
Language coverage
Official links
Search engine discovery
Production stability
Long-term maintenance

What Support does is just:

When someone actually wants to support it, the project already has a suitable entry point ready.

20. I still hope the project gradually forms sustainable revenue, but this should be built on community value

Not talking about revenue at all is unrealistic.

For a project requiring long-term maintenance, if it can gradually generate stable revenue in the future, it means maintainers can invest more time, and it means the project is more likely to receive long-term continuous maintenance.

But the order matters.

I prefer it to be:

Plaintext
Project is valuable first
→ More languages are actually used
→ Community impact gradually expands
→ Forms a certain amount of sustainable revenue
→ Continue investing in maintenance

That is to say, revenue should first help the project:

Plaintext
Bear operating costs
Reduce long-term maintenance pressure
Increase the conditions for continued investment

If one day the project’s scale is truly large enough to provide more stable returns for the maintenance work itself, I think that would actually be a healthy outcome.

Because a community project doesn’t only count as one if it’s “completely unpaid.”

Being continuous, stable, and having people willing to invest long-term is equally important.

21. Beyond financial costs, we also need to make maintainers’ time investment sustainable

Earlier, we distinguished between two types of costs:

Plaintext
Financial investment + Time and energy investment

What revenue can most directly help with is the first type.

For example:

Plaintext
Servers
CDN
Domains
Network
AI tools

But if a project gradually gains stable operating capacity, it will also indirectly affect the second type.

Because maintainers will no longer have to face:

Plaintext
Project getting bigger
+ All costs borne by themselves
+ All maintenance time still having to be constantly squeezed out

This kind of structure.

In other words:

Economic sustainability is not meant to replace community value, but to create better conditions for long-term maintenance.

This also brings us right back to those historical projects.

22. This reconnects to the problems that caused the French and Korean sites to go offline

The historical French project had:

Plaintext
553 commits
61 Contributors
Years of maintenance history

Yet it was still archived in the end.

Korean even went through:

Plaintext
First generation
→ Offline
Second generation
→ Rebuilt
→ Back online
→ Finally offline again

The offline status of these projects certainly can’t be simply attributed to “no revenue.”

There isn’t enough evidence to support this direct causal relationship.

The more realistic situation is likely a combination of multiple factors:

Plaintext
Bus Factor
Maintainer changes
runtime deprecation
Deployment permissions
production ownership
Upstream changes
Lack of time
Technical debt
Infrastructure costs

But economic factors are also hard to rule out entirely.

Because if a project long-term requires:

Plaintext
Someone continuously contributing time
+ Someone continuously bearing financial costs
+ Without any feedback mechanism

Then as the maintainers’ own work, family, and life change, this project’s priority will naturally drop.

So I now prefer to view Support as:

A small addition to the long-term maintenance system.

It won’t solve all problems.

But it at least adds one more possibility for keeping the project running.

23. What truly matters isn’t Support itself, but reducing absolute dependence on a single maintainer

If a community project wants to run for a few months:

It’s usually not hard for the maintainer to bear all the costs themselves.

But if the goal is:

Plaintext
Continuously sync with official Go
Keep adding languages
Still be online in 5 years
Still be maintained in 10 years

Then you have to consider longer-cycle issues.

For example:

Plaintext
Can the documentation be left behind?
Can Production be taken over?
Can the code continue to be maintained?
Can permissions be transferred?
Is there a long-term source for operating costs?

I now hope go-tour-i18n can try its best to ensure:

Plaintext
Processes can be inherited
Code can be inherited
Production can be inherited
Documentation can be inherited
Operating costs don't always have to rely entirely on one person

Support is just one attempt at that last item.

24. A community project’s sustainable methods don’t need to be just one kind

What I can think of so far might include:

Plaintext
Ads
Voluntary Support
Potential future corporate sponsorship
Community resource support
Technical partnerships

Not every one of these will necessarily emerge.

And there’s no need to build them all out in advance just to have a “complete business model.”

At this stage:

Plaintext
Ads + Support

is already enough for a long-term real-world validation.

If new real needs arise later, we can continue adding them.

I increasingly don’t want to pursue:

Finding the single correct revenue model.

What’s more important is:

Is there a combination that doesn’t compromise free and open access, yet increases the probability of the project existing long-term.

Finally: Support is not an isolated payment page, but part of a long-term maintenance system

So adding Support to the A Tour of Go multilingual project this time, I now prefer to understand it back within the context of the project’s entire history.

It isn’t a sudden new “revenue feature.”

Rather, it continues to answer a long-standing question:

How can community translation survive for longer?

History has proven:

Going live the first time is not the end.

For a project to truly exist long-term, it needs:

Plaintext
Language quality
Upstream sync
Technical maintenance
Production ownership
Deployment capability
Documentation and knowledge transfer
Infrastructure
Time investment
Economic sustainability

Missing any part of this could become a new risk a few years down the line.

This is also why the current go-tour-i18n not only has to solve:

Plaintext
How to translate?
How to validate?
How to go live?

But also gradually answer:

Plaintext
How to get more people to actually discover and use it?
How to let future maintainers take over?
How to give the project the ability to bear a portion of its own long-term costs?

Ads are one way.

Support is another way.

Official links help community translation actually reach the people who need it.

They don’t need to be mutually exclusive.

For me, the principle I most want to maintain is still very simple:

Plaintext
Free
Open
Multilingual
Continuously maintained

If one day, this project can continue to help more developers while gradually forming stable enough operating conditions to let the maintenance itself carry on long-term, that would be a very ideal outcome.

After all, looking back at those community translations that have already gone offline:

Creating a language version was already not easy.

But what’s harder, and perhaps always has been:

Ten years later, it is still online, and there are still people willing and able to continue maintaining it.

系列导航

需要长期技术维护或远程问题排查？

我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：

  • ✅ PHP / Laravel / Yii2 老项目无人维护
  • ✅ Go / Gin 后端接口需要排查或优化
  • ✅ WordPress 网站访问慢、报错或插件冲突
  • ✅ Nginx / MySQL / Redis / Linux 服务器异常
  • ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
  • ✅ 需要长期远程技术支持或兼职维护

更多介绍请查看：关于我 & 合作

微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan

更多文章