为什么突然想写这个？
先自我介绍一下，作者是前端开发者，同时也是一个小破开源项目的维护者，项目协议是MIT。从认识开源到现在经历了快两年时间了。昨天日常对项目的issue进行处理的时候，看到了一条这样的 issue。
其实作者对于这样的信息已经屡见不鲜了，虽然在晚上睡觉之前看到一条这样的信息感觉心里不是很舒服，但是作者还是第一时间开始尝试帮他解决问题，毕竟他十分的着急。。。至于这个问题的细节就不在这篇文章中展开讨论了。
简单来说就是提问题的人本身并没有正确的使用组件，在他的使用场景下并没有非常简单，而且这个组件在某些设计上确实还存在可以优化的地方。但这些都不是重点，重点是下面的对话，味道逐渐坏起来了。
haoziqaq 是作者，作者把问题发起者打码了，后面他也表达了歉意，我们对事不对人，只谈论事情本身。
作者此时心里已经不是滋味了，虽然我能理解他急切的心情，但我依然有一点破防。。。语气也变的不好了。。。
作者的态度在上图中已经表达明确了。我周围几个积极参与开源建设的小伙伴也有类似的遭遇，作者觉得有必要写一篇文章，希望能给大家提供一点启示。并且分享一下我们应该如何参与或者使用别人的开源项目，以下内容仅供参考，作者也是才疏学浅，抛砖引玉，不希望类似的情况越来越普遍。
什么是基于MIT协议的开源项目
开源项目是指开源者把代码共享出来，让大家可以学习，分享，讨论，贡献，属于一种共创型的项目。 那什么又是 MIT协议 呢？ 它是目前限制最少的开源许可协议之一，只要程序的开发者在修改后的源代码中保留原作者的许可信息即可，说简单点就是鼓励白嫖，想怎么用就怎么用，都是合法合规的。
以怎样的心态去参与别人的开源项目
尊重项目，遵循引导
大部分的开源项目都会提供一个开源指南，一般存放在.github目录里，也有可能就在项目的官方网站里。你可以在那里找到一些项目对你的引导，项目的启动方式、贡献的流程、代码的规约等等。也可以通过邮件，issue找到核心的开发者去提出你想参与的诉求。
顺应你的兴趣，做这个项目中你最感兴趣的东西
可能一些小伙伴会把在企业里工作的模式代入到开源工作中，会去等待任务的派发，会去询问有没有什么需要帮忙的。实际上这并不符合开源精神的本质，就好像 antfu 大佬推特上说的。
I don't have anything for you. You know yourself the best, and I don't. I can't come up with a task that fits your interest and skills out of nowhere. It's best for you to find the thing you really want to do, and will enjoy working on, by yourself.
大概意思就是，你需要找到你感兴趣的地方，并且去实现它，并让你自己感受到快乐。
所以你并不需要等着任务出现，你想做什么你就做什么就好了，哪怕你就是喜欢把for 改成 forEach，因为你觉得这样提高了可读性......（但是不鼓励在流行的项目中这样做，因为他们的 review 压力很大，最近尤大在推特上也说明了这一点。不过我们这个小破项目是无所谓的）
充满好奇心，保持学习
一般来说开源项目使用到的技术都是相对前沿的，参与其中的开发者也是五花八门，这其实是一个很好的相互学习的渠道，比看任何的书籍、视频、课程都有用，同时也可以认识许多朋友，一起做很多有意思的事情。
以怎么样的心态去使用别人的开源项目
不要把自己当成甲方，把开源维护者当客服
我们日常的工作任务中已经完全离不开开源项目了，在使用百花齐放的开源项目解决自己问题的同时千万不要把自己当成消费者、当成甲方。并且认为开源团队有义务对你的项目负责任（供应链恶意攻击除外），甚至可以不断满足你的定制需求。
必须要以合作共创的心态去跟每个开源项目相处，友善的，彼此尊重的交流。要知道开发者们使用的开源项目有很大一部分都是开源作者们利用自己的休息，陪老婆孩子的时间做出来的，这样才或多或少的帮助到了开发者们。所以，务必友善，不要让别人寒心！
遇到问题，首先思考我能帮忙做什么
使用开源项目的过程中肯定会遇见问题，跟预期不符合的情况，这个时候可以首先到 issue 列表中搜索关键词看看有没有人遇到跟你相同的问题。如果没有，你可以提一个 issue 寻求解决方案（务必友善！）。并积极提供报错信息、环境、在线运行信息、期望的结果（可以用图片或者视频的形式）。有能力的可以直接去定位问题所在、直接提供解决方案、或者直接发一个 pr 解决，毕竟我们都关注在怎么更好的解决问题上，而不是宣泄自己的不满情绪。
不要先入为主，应该站在维护者和使用者两种角度考虑问题
有些时候一些项目的设计可能会让人觉得不如人意。比如。。。
“这个API设计的怎么跟我想的不一样啊！”、 “这里我觉得应该是这样的行为，为什么运行结果跟我想的又不一样啊！”、“我记得我以前用过类似的东西，他们都是那样的，这个库为什么不是！”。我们不得不承认的一点是，有些可能是维护者的设计失误，有些可能是 设计权衡的结果，一些设计思考可能是使用者无法考虑到的。有疑问可以友善的跟维护者讨论，不要武断，不要先入为主的思考问题。
最后
这篇文章就当成作者发的一个牢骚吧，希望国内的开源氛围能越来越好，大家工作能越来越轻松，钱越赚越多。 顺便打个广告，这是我的小破项目，觉得还凑合就 star 它一下吧！感谢～
Varlet Material Design Vue3 组件库
GITHUB: github.com/varletjs/va…
文档(Vercel): varlet-varletjs.vercel.app
文档(Gitee): varlet.gitee.io/varlet-ui