最近在与fastexcel开源维护者交流开源贡献的问题时，了解到此文。

本人看完有较深触动，将其转载。

原文地址（如构成侵权，请联系本人删除）：https://xuanwo.io/2024/10-a-letter-to-open-source-maintainers/

A letter to open-source maintainers

Here is a letter to all friends who are or aspire to be open-source maintainers. I have repeated many of these core ideas in various places. I believe it’s better to write them in a letter so that I don’t have to repeat myself again. This letter includes everything I want to share with NEW open-source maintainers. I hope all of them can find happiness and thrive in the open-source community. I wish for none of them to leave the open-source field with regret or sadness.

This is a letter written with my utmost kindness. It may or may not align with your perspective. Nevertheless, thank you for reading, and remember, you are not alone, someone still loves you.

Hi, Dear Friends.

First of all, welcome to the open-source community. Thank you for dedicating your time, effort, thought, and passion to your projects. You may have come here for various reasons: inspired by Richard Stallman, aiming to change the world, supported by employers, eager to share something new, or encouraged by teachers or colleagues… Whatever your reasons, they are all valid. Every contribution is valuable. The world is a little better because of your efforts.

Baseline

The first thing I want to discuss is this: All work was completed when it went open source.

This means you are not obligated, nor can anyone require you, to do the following things:

• Continue maintaining this project
• Triage issues and review pull requests
• Write clear and concise documentation
• Ensure timely releases
• Dedicate yourself to meeting the community's needs.

Please always remember: That's okay. That's fine. That's good. Stop if you're no longer happy with it.

This is the baseline for everyone. We all have high expectations for every project, and we all strive to do our best. However, people are not machines—there are countless reasons why an individual might fail to meet the expectations of the community. They might lose their job, fall ill, or experience a significant personal loss. We need to establish a baseline for everyone—a healthy, sustainable, and inclusive baseline. We should foster an environment where following the best practices of open-source projects is encouraged but not mandatory. It's okay if someone wants to step away; it's not a failure or a wrongdoing to let go of a project.

Bad Reasons to Stay

A baseline is simply a baseline. I'm not suggesting that everyone MUST conform to it. There are many reasons why people dedicate significant effort to open-source projects. For example:

• They are paid by companies to maintain the project.
• The project is a core dependency for their business, so some companies fund its maintenance.
• Maintaining the project aligns with their personal interests.

As long as you're satisfied with the reason, they are valid reasons. However, I am here to highlight some unfavorable reasons and hope you can avoid using them:

“only I can do”

Sorry, friends, but this is incorrect. You are not the only one capable of maintaining this project. There are many reasons why others might not have stepped forward, such as:

• The project is already in a good state, with no new features to add or bugs to fix.
• You have been so actively maintaining it that the community might not even realize you are nearing burnout.
• The project lacks enough users, which might suggest it doesn’t provide sufficient value to the community.

So, when you feel burned out, unhappy, or exhausted from debating with random users on GitHub issues, please take a moment to reflect. If your reasoning is “I’m the only one who can do this,” reconsider your perspective.

Taking a step back, even if you are the one chosen to maintain the project, you don’t have to. You’re not obligated to be a superhero, even if you have the capabilities, as long as it’s not something you genuinely want to do.

“people will be sad or angry”

That's true, my friends. I also feel angry when I see maintainers abandon a great project without providing any explanation. But it doesn't really matter.

What other people think about you doesn’t matter. What truly matters is whether you are happy and if your family is happy. Don’t try to satisfy others—focus on satisfying yourself. If you are employed by a company, you might need to satisfy your boss as well. But remember, you can leave the boss if you’re not happy with the situation.

“I’m changing the world”

Accept my respects, friend. Please remember to revisit my post whenever you feel tired.

Things to do before leaving

Now, you are tired, busy, and hurt, so you finally decide to leave. There are some things you might want to consider before leaving. Depending on your remaining energy, you can:

0%

You are completely burned out. You don't want to visit that project ever again.

Just leave and disable all notifications related to it.

30%

You are burnt out, but still have some energy left to write a letter.

You can create a public issue and pin it to the project's README to announce that this project is being archived and will no longer be maintained. If you still have the energy, you can include links to alternatives for users to explore. If you don't do that, it's fine—users will find their own solutions. Either way, it's no longer our responsibility.

60%

You are fine for now, but you have some concerns about the future or are no longer interested in this project.

You can create a public issue to look for co-maintainers. Gradually, you can hand over maintenance tasks to them, eventually allowing the new maintainers to take over all responsibilities. During this transition period, which may take some time, you will still need to pay attention to the project. However, once the new maintainers are managing everything effectively, you can step away completely.

Things to do after staying

You are my hero, as Romain Rolland once said:

There is only one heroism in the world: to see the world as it is and to love it.

I truly respect your decision to stay on this project after giving it such serious thought. It’s a great loss to witness a hero’s tears. Here are some pieces of advice you may find worthwhile to follow:

Always Ready to Leave

Ensure your projects can continue to operate smoothly even after your leaving.

For examples:

• The core architecture should be well-documented.
• There should be multiple maintainers besides yourself, preferably from other companies.
• Essential workflows, such as release processes and integration tests, should not rely on your personal account.

This is also the standard for a healthy open-source community project. Keep this in mind as you build the community. Once the community has matured, consider stepping back for a month to see if it functions effectively without your active involvement.

Sustainability Aware

If your project aims to achieve its goals, please ensure it is sustainability-conscious. A healthy open-source project typically requires at least 10 users to maintain its momentum. We need user feedback to continually grow the project and its community. Among these 10 users, we can usually identify at least one active contributor. If your project is complex, a larger user base may be necessary.

Therefore, don’t focus solely on your project. Try reaching out to potential users and encouraging them to use your project. This can help improve your project and attract more users.

Pick up right license

It is your right to choose the best license for your project. You can opt for a permissive license like MIT or Apache 2.0, a copyleft license like GPL, or a restrictive license like SSPL to prevent cloud vendors from using your projects. The license you select will influence how your project is utilized and how it develops. Be sure to fully understand the implications of each license before making your decision.

If you rely on this project to generate profit, consider not making it open source from the start. It’s entirely acceptable for someone to use your MIT-licensed projects to make money without even acknowledging your name. Don’t complain if others don’t compensate you for using your Apache 2.0 or MIT-licensed projects. Building a business is far more challenging than maintaining open-source projects.

Instead, establish a clear baseline. Engage with your business users and aim to sign contracts with them for paid maintenance work. Visit Filippo's "I am now a full-time independent open-source maintainer" for further inspiration.

The Very Last

Dear friends, you might think I’m so upset about open source that I almost always encourage maintainers to give up. That’s not true. I do love open source. I deeply appreciate open source maintainers. Many efforts from the entire community aim to make the lives of open source maintainers easier, such as the Open Source Pledge and the Sovereign Tech Fund. However, as maintainers ourselves, we need to establish our baseline clearly.

It’s okay to step away if you’re not happy. Don't become a hero who bleeds and weeps.

I wish you find happiness in open source.