最近在与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" ](https://words.filippo.io/full-time-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](https://opensourcepledge.com/) and the [Sovereign Tech Fund](https://www.sovereign.tech/). 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.

A letter to open-source maintainers

2025已经到来，下面是我对2024年的个人总结，以及对2025年的未来展望。





# 2024总结——峰回路转

2024大概是我大学这几年收获最满的一年，我不仅收获了丰富的技术内容，也提高了例如情商、管理能力、团队协作、开源思想等技术之外的事情，让我开拓了眼界，不再拘泥于自己的一亩三分地。


这一年，我收获了：

## 实习
虽然从7月到8月这两个月的实习只是打杂活，但是也培养了我的团队协作能力，让我融入了企业文化，体验到了打工人的生活👀，并且在与同事的交流中了解到诸如vercel、pnpm这种课本上、视频里学不到的内容，这也让我体会到了我与真实开发者的差距。

## 开源

在6月的开源之夏报名活动中，虽然我失败了，但是这也让我看到了我的差距。我在大一大二还是太沉浸在网上教学视频一步步带你走的学习方法了，脱离开我自己就很难完成某些任务，这也是我要克服的。在11月的开源年会也让我见识到了我们国家的开源力量，以及我深深地被开源思想所陶醉，开源确实是对程序员来说最浪漫的一件事。

## 社团

从入社团给社团做项目到现在也差不多正好一年了，因为我的技术相对较好，我被选为“组长”，这一年来也锻炼了我的管理能力、情商以及我的团队协作能力。我需要能合适的分配任务、与老师交接需求等，这些也都增长了我的见识，提高了我的个人素养。

## 比赛

因为社团，我接触到了很多比赛，例如科技立项、产教融合揭榜挂帅大赛、崇实班等等，我也参加了多次这种比赛，并且演讲了几次，虽然结果不是完美的，但是也让我明白自己的差距：“技术是最不值钱的”，我们其他能力，例如社交人脉、个人素质都是要得到提升的，否则会德不配位。

## 技术

2024的这一年我接触的技术不多，主要是为社团做项目、给学校做项目，在项目中提升我的能力。同时我也是对一些框架、中间件的底层实现原理感兴趣，也在不断发掘其中的奥妙，我也发现“不能急于求成”，技术这块如果要研究底层的话是不能一口气吃个胖子的，一定要有兴趣或目标所导向，再扎进去。

## 思想

这一年也是我在考研与就业抉择的一年，曾经刚升大学，也有过对自己学历的不满，想通过考研去再搏一次，包括我家里人也是希望我考研。但是我也想明白了，如果考研考不上985 211的话那还不如不考，浪费三年，还花着昂贵的学费。况且，计算机方向的研究生大部分都是去研究人工智能、硬件、音视频等，如果我是Java这种软件开发方向似乎并没有什么实质性意义，而且研究生也是在赌，赌你遇上的导师是好还是坏，包括考研本身就不是付出了就一定成功的，这些不确定性太多了。

我对自己也是有了认知，我没必要花一年考研去学一些相对没有用的数学和政治，可能我的格局还是不大吧，但是我可能是进不了大厂的，既然进不了大厂，那我就没必要去提升学历包装自己，况且如果我在这1年里去多做项目、充实技术等等，未必我就没有竞争力，**去做自己眼下的，不要好高骛远**。



# 2025展望——否极泰来

2024我也经历过很深的低谷期，但是我还是克服了过来。我要吸取教训，不断成长。

2025，我希望能完成以下目标：

## 个人提升

- 学好英语的基础沟通，提升英语听说能力，达到日常交流无障碍。
- 提升自己的演讲能力，不怯场、自信，多锻炼。
- 提升自己的人脉，多参加网上或线下的会议，提高自己的眼界。
- 多锻炼，身体是革命的本钱，得过大病的人才知道这句话的含金量。

## 技术提升

- 提高自己的技术深度，培养自己的架构意识，多看技术文章。
- 学习Go语言，了解Go的框架、项目。
- 为开源项目提issue、提pr。
- 深入开源项目（FastExcel、Dubbo、RocketMQ），学习中间件、工具类、框架的底层实现以及尽可能的为其开源项目提issue、做贡献。


最后也非常感谢社团中在我低谷期给我打气、给我机会去提高自己的社长，以及和我们参加项目开发、参加大赛的所有小伙伴们。因为有你们，我才能收获这么多不平凡的经历。


**梦虽遥，追则能达；愿虽艰，持则可圆。**

2024年度总结&2025展望

Ubuntu安装docker及安装docker常用中间件

这两天，我有幸跟随我们社团开源鸿蒙社的脚步，参与了由开源社精心筹备的2024中国开源年会。在社长的带领下让我感受颇多，这不仅仅是一场技术的盛宴，更是一次心灵的洗礼。🎉




年会现场，大咖云集，他们分享着前沿的技术动态和宝贵的开源经验分享，让我这个初出茅庐的学生受益匪浅。每一场演讲，每一个话题，都激发了我对技术的无限热爱和向往。❤️


在开源的世界里，我看到了中国开源的繁荣，感受到了各位技术大牛的热情。在这里，没有学历的界限，没有职业的隔阂，只有对技术的共同追求和热爱。🤝


这次年会，让我更加坚定了自己的方向，也让我明白了开源的真正意义。它不仅仅是一种技术模式，更是一种精神，一种态度。很多时候，我们都是带着功利性的态度去学习一门语言一门技术，但是我们应该认识到兴趣才是最好的老师，我们应该有一定的格局，以兴趣为导向，去为开源事业做贡献！🌟


最后，非常感谢社长的带领，让我有机会参与到这场盛大的宴会，让我从技术上和思想上都有了一定的进步，同时也让我感受到了团队的力量，期待未来与开源的每一次相遇！🚀

2024中国开源年会参与感想

## 问题背景

在做项目时遇到了要对接统一认证的需求，但是由于框架的不兼容性（我们项目是springboot3，jdk17，springsecurity6.1.5）等因素，不得不使用抽离服务的方法，将统一认证服务抽出去形成一个中介系统，统一认证服务使用jdk8的版本。




这样可以兼容统一认证服务器，认证流程图大致如下：


![image.png](http://47.94.183.162/static/img/9489128b902d53a101765a8968eb465c.image.webp)

也就是说，我们的任务变成了这样：中介系统会传入一个工号和一个密钥，主系统需要解密密钥并且将根据工号直接登录。一开始我想直接在这个第三方登录方法中就解密密钥，然后复用正常的登录逻辑，正常的登录逻辑是通过工号和密码，框架才会颁发token，密码可以直接从数据库里查出来，所以直接一股脑塞进去：


![image.png](http://47.94.183.162/static/img/662104ad9759366695f2aa807ba79c1e.image.webp)
但是我们发现框架底层的鉴权流程是：将传入的密码加密，然后查询数据库中存储的密码，而数据库存储的密码本身就是加密后的，相当于匹配这两个字符串是否一致即可（因为这个加密方法是无法逆向解密的）。

这也就是说明我们如果直接从数据库查询密码塞到token里是不行的，因为框架会将你传入的密码再加密一次，就是原来的值了。

在网上看到有说在密码前加入{noop}就可以使得框架不对密码进行加密，但是我尝试后发现没有效果...

没办法，这时候只能自己去实现一个登录流程了。

## 尝试

在网上查阅了相关文章，找到了SpringSecurity中正常使用账号密码登录走的流程吧：


![image.png](http://47.94.183.162/static/img/1929b395b44f1ffeaa016b9e66363fbf.image.webp)

根据这个认证过程，我们应该可以大致去效仿一下：

首先我们提供一个实现了AbstractAuthenticationProcessingFilter抽象类的过滤器，用来代替UsernamePasswordAuthenticationFilter逻辑，然后提供一个AuthenticationProvider实现类代替AbstractUserDetailsAuthenticationProvider或DaoAuthenticationProvider，最后再提供一个UserDetailsService实现类。

大致流程是这样。但是别忘了，我们这是springboot3，网上大部分文章都是springboot2的，我们很难找到参考...

因为我们这个项目本身是想整合cas登录的，所以后面很多鉴权逻辑类的起名都跟cas有关。

照猫画虎，根据框架的UsernamePasswordAuthenticationToken我们也自定义了CasAuthenticationToken，大致就是把字段改改，剩下就是完全照搬。

````java
public class CasAuthenticationToken  extends AbstractAuthenticationToken {

    private static final long serialVersionUID = SpringSecurityCoreVersion.SERIAL_VERSION_UID;
    //对应工号
    private final Object principal;
    //对应验证码
    private Object credentials;

    public CasAuthenticationToken(String empId, Object credentials){
        super(null);
        this.principal = empId;
        this.credentials = credentials;
        setAuthenticated(false);
    }

    public CasAuthenticationToken(Object principal, Collection<? extends GrantedAuthority> authorities, Object credentials){
        super(authorities);
        this.principal = principal;
        this.credentials = credentials;
        super.setAuthenticated(true);
    }

    @Override
    public Object getCredentials() {
        return this.credentials;
    }

    @Override
    public Object getPrincipal() {
        return this.principal;
    }

    public void setAuthenticated(boolean isAuthenticated) throws IllegalArgumentException {
        if (isAuthenticated) {
            throw new IllegalArgumentException(
                    "Cannot set this token to trusted - use constructor which takes a GrantedAuthority list instead");
        }

        super.setAuthenticated(false);
    }


    @Override
    public void eraseCredentials() {
        super.eraseCredentials();
        credentials = null;
    }
}
````

然后需要写一个Provider，参考SpringSecurity的AbstractUserDetailsAuthenticationProvider，我们也可以照猫画虎一下。注意一下：Provider里面的authenticate方法是鉴权核心代码，比如我们将如何判断密钥合法、根据工号查询用户信息及是否有这个用户等，这里的逻辑需要你们去个性化实现。

````java
@Component
public class CasAuthenticationProvider implements AuthenticationProvider {

    @Autowired
    private UserDetailsService userDetailsService;

    public CasAuthenticationProvider(UserDetailsService userDetailService) {
        this.userDetailsService = userDetailService;
    }

    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        CasAuthenticationToken token = (CasAuthenticationToken) authentication;
        String empId = (String)token.getPrincipal();
        //首先，验证验证码是否正确
        String code = (String)token.getCredentials();
        //这里应该写一下如何解密的逻辑
       -----------------
        //然后，查询对应用户
        UserDetails user = userDetailsService.loadUserByUsername(empId);
        if (Objects.isNull(user)) {
            throw new InternalAuthenticationServiceException("根据工号：" + empId + "，无法获取对应的用户信息！");
        }
        CasAuthenticationToken authenticationResult = new CasAuthenticationToken(user, user.getAuthorities(), token.getCredentials());
        authenticationResult.setDetails(token.getDetails());
        return authenticationResult;
    }

    @Override
    public boolean supports(Class<?> authentication) {
        return CasAuthenticationToken.class.isAssignableFrom(authentication);
    }
}
````

值得注意的是，返回新的CasAuthenticationToken中第一个参数user信息要是一个对象，这样便于后面解析成LoginUser对象。

看网上大部分文章还需要配置专门的第三方过滤器、专门的登录成功类和登录失败类，一开始我也根据这个创了好多，最后打断点才发现根本都没进到这些代码里来。

大部分文章还要求在SpringSecurity配置类配置下：

````java
@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .antMatchers("/error","/login/**","/login/goLogin","/login/doLogin","/login/code","/login/authorization_code").anonymous()
            .anyRequest().authenticated()
            .and()
            .formLogin()
            .loginPage("/login/goLogin")
            .loginProcessingUrl("/login/doLogin")
            .failureUrl("/login/error")
            .permitAll()
            .successHandler(new QriverAuthenticationSuccessHandler("/index/toIndex"));

	//这里我们省略了一些配置 ……

	//应用前面定义的配置
    http.apply(thirdAuthenticationSecurityConfig);
}
````

但是我的项目是springboot3+springsecurity6，不能这么写，已经从configure方法变成了filterChain方法，像一个链子一样调用不同的过滤器来实现统一过滤。

看到过滤器链里有这个UsernamePasswordAuthenticationFilter，我也不假思索的觉得应该弄一个CasAuthenticationFilter并且插入进去，但是不知为什么弄完后，填入过滤链项目就无法启动了，报错：The Filter class org.**.ThirdAuthenticationFilter does not have a registered order....网上搜了一下说加@Order的仍然还是一样报错。哎，那还是注掉吧


![image.png](http://47.94.183.162/static/img/ff3d7cb1c1d8407ded4da6d8d8a30eac.image.webp)

嗯，那就算了？要不就先这样试试能不能成功

满怀期待的启动项目测试，结果报错：No AuthenticationProvider found for org.***.CasAuthenticationToken

根据资料显示，是由于我定义了一个新的AuthenticationToken，在

````java
authenticationManager.authenticate(authenticationToken);
````

时候发现authenticationManager的parent属性是null，他不知道如何对我们这个自定义的token进行鉴权。哎不对啊，我前面明明写了个Provider为什么还不行！

看一些可能是SpringBoot2的文章说要弄filter，但是我弄了但是根本不走代码，放到SecurityConfig里又报错无法启动项目。应该是不同版本写法已经不一样了。

其实首要问题就是AuthenticationManager的parent属性是null，应该从这里入手。但是我走错方向了，不停的在SecurityConfig配置上、过滤器上改....

后面我想到了这个AuthenticationManager，偶然在SecurityConfig看到了：


![image.png](http://47.94.183.162/static/img/df93fc38fb5533775bff8d0953fdd91a.image.webp)

还记得账号密码怎么登录的吗，他用的DaoAuthenticationProvider！这里他给ProviderManager注入了！

点进去看了一下，他可以注入多个Provider！那我们直接把CasAuthenticationProvider注入！!

![image.png](http://47.94.183.162/static/img/5e1a6cf584ac0d9ab20b1aafd3a8e799.image.webp)
那我们就可以照猫画虎！注入！


![image.png](http://47.94.183.162/static/img/fa18da72c564614b3abdfc8466a53664.image.webp)
最后测试一下，能成功返回token了！

参考文章：

[一文理清SpringSecurity中基于用于名密码的登录认证流程-腾讯云开发者社区-腾讯云 (tencent.com)](https://cloud.tencent.com/developer/article/1981162)

[SpringSecurity自定义多Provider时提示No AuthenticationProvider found for问题的解决方案与原理（二）-CSDN博客](https://blog.csdn.net/u012760435/article/details/126577799)

[SpringSecurity系列 之 集成第三方登录（包括默认的用户名密码、短信验证码和github三种登录方式）_springsecurity第三方登录-CSDN博客](https://blog.csdn.net/hou_ge/article/details/120291287)

[Spring Security authenticationManager()返回null，必须定义authenticationManagerBean的原因分析-CSDN博客](https://blog.csdn.net/Hey_JC/article/details/124422427)