欢迎关注：DevUI开源的故事，并加入到DevUI开源生态的建设中来！
以下是DevUI开源优秀贡献者TinsFox参与DevUI开源的一些思考和感悟。
序言
本文来聊一聊近几年在开源里面遇到的一些事儿跟启发，分享一下从接触开源、了解开源、使用开源、贡献开源的历程。
1 接触开源
为什么会接触到开源呢？
我第一次接触开源还是在大一的时候，那时候处于一个比较猎奇的状态，就啥都想要玩玩看，那时候使用Linux 搭建自己的hexo博客和配置FTP等等，这些都是一些比较成熟的开源项目了。
而翻开开源项目的源码还是从微信小程序的一个组件库开始，Color UI。
大二的时候接了协会的一个小程序的项目去做，那时候啥也不会，甚至是js都没有学过，完全就是靠着C语言的基础去写js🙈，逻辑部分还算是勉强凑合，但是UI可怎么办呢？
翻来覆去之下在GitHub找到了Color UI这个开源组件库，在接下来的几年里，一直是各种微信小程序的开源库深度用户，但是因为自己CSS菜嘛，所以就没想过源码在我手里，我可以做些什么。
2 了解开源
要使用开源，有几点我觉得是要先知道的：
2.1 第一是开源协议
社区中的开源项目不都是MIT协议开源的，对于非MIT协议开源的项目使用起来需要特别留意开源许可证，万一使用了一些要求比较严格的许可证的项目，如GPL，这就会要求你的项目开源许可也是GPL，还有些项目虽然是MIT，但是会对商业使用有另外的声明。
这时候就要认真斟酌这个项目的许可是否满足了，在公司项目里使用开源项目一般都是MIT或者是Apache的。
2.2 第二就是使用者都是伸手党
可能这个不会被大家认同，但是我个人理解而言，每个想要去使用开源项目完成自己的一些事情的时候，就成为了伸手党。
因为你要去做的事情其实无论如何你自己完全独立去做都是可以完成的，就我自己而言，我以前就只知道font-size、color、background-color，什么是塌陷、BFC？
经过了两三个月的学习及锻炼，我觉得大部分的css布局及实现我掌握了60%～80%，起码在拧螺丝的过程中不会有太大的问题。
但是为什么社区里面还是那么多的库呢？
CSS原子库，bootstrap、tailwind，组件库element、vant、vue-devui。
因为这些库可以大量节省时间精力，可以让你把更多的时间花在业务的逻辑上而不是UI的构建。
讲真的做前端只要硬下心来，哪些css实现是做不了的呢？
无非是投入与收效不成正比而已。
现成的社区库有那么多人的实践，有人去维护，API的暴露经过了深度的思考，就算是满足不了也可以进行二次封装后再使用。
2.3 插一个小故事
这里插一个小故事。
就前两周，有组件库刚刚开源出来，有一天晚上在交流群里面有位项目维护者在收集意见。
当天晚上我是生气又平静，生气的是我觉得我回答这个问题回答的就算是不怎样，就算是多余，也不应该收到这样的反响吧，我说的东西难道不是通解吗？
这三种场景，组件自身、应用自身的实践、开源项目中的学习这三个不是希望一个组件库可以持续发展所应该具备的吗？
社区当中那么多同类型的竞品，随便拿一个过来抄改改风格就是一个新的库，但是你凭什么留下用户，靠性能的提升吗？
还是风格有多清新吗？
那也没错，这确实是很吸引眼球，但是也就是吸引而已。
在现在的快餐开发中，对于这类的组件库难道不是拼谁的实践方案完善、相关的生态齐全、社区的活跃度、issue的解决效率吗？
我就成了一丢丢思考能力都没有、学会拉屎还没带纸的人了吗？
但是我也挺平静的，求同存异嘛。
在前端的百花齐放百家争鸣的背景下，每个人的思考都不一样，我不能说企图说服谁去认同我的观点，但是我可以发表我的意见（读者们要是不喜欢这篇文章轻点骂，反正我是不改的哈哈哈🤪）
提问：
我的回答：
群友的意见：
3 使用开源
沉浸在开源社区的几年里，我发现使用开源也是有一定的技巧的。
3.1 善用社区反馈
开源社区的项目一般都会在GitHub或者是Gitee居多，在这两个托管平台都会存在一个叫做issues的入口，就是专门去记录这个项目的问题的，可以说是一个交流区吧（GitHub新增了Discussions讨论区）。
在上面我们可以对这个项目的时候进行交流，文档中模糊的表述或者是发现了Bug需要作者提供修复等等，在这里反馈的效率一般是最高的，因为这里面会有记录并且会给仓库的相关贡献者推送邮件提醒。
有些项目为了方便会建立QQ、微信、钉钉等交流群，方便使用者去进行沟通交流，提升沟通效率。
但是吧，在一些项目更新到了一定程度的时候，没有频繁更新，或者说是基本完善了，开源嘛总想着会有没有更加接近使用的东西出来。
比如UI库，基础的组件库出来完成后就会想着会不会有一些模板出来，上手直接改改就能用满足现在的快餐开发时代。
几个比较典型的催更例子：Color UI、uview、Lin UI，这些组件库要不就是成熟了，要不就是可能存在一些兼容性的问题，开源作者或多或少都在准备重构工作。
在这些交流群里面各种阴阳怪气的言论就铺天盖地，什么2.0明年上线、3.0明天发布诸如此类的。
作为使用者，希望自己的需求可以进一步满足，这无可厚非，但是这样子去阴阳怪气（起码在我看来这类表述实在阴阳怪气），假设自己是作者，看到这样的反馈，你还有心思继续坚持下去吗？
这样付出换来的是什么，还是说贴几个赞赏码收到了几杯咖啡就给你绑定打工了吗？
我想不是的，贡献开源的人一般都是从开源社区里面得到收获，根据自身的能力想要回馈社区，让社区能够得到发展。
虽然这个看起来是很清高，说白了就是想让自己的简历好看的，有个多少多少star的开源仓库。
这也没错，参与开源贡献的人或多或少都会有这样的心理（当然也会有大佬不在乎的，技术过硬🌝 ）。
正面的反馈才会让作者有东西去坚持！
当然也不是说社区上就全都是这样的歪风邪气了，正面的还是存在的，给作者打赏几杯咖啡，主动参与组件的内测，甚至是参与到开源项目的建设当中去，这也是大把大把的。
3.2 如何正确的反馈
这个问题其实就见怪不怪了，很多人上来就问，大佬在吗？有没有用过xxx，有没有遇到xxxx，截图截了局部，甚至是解决问题所需要的信息都不全。
这一类我称之为无效提问，也就是水群用的。
我是回你在的，我用过xxxx，有深度的使用经验，请提问，然后等你个几分钟发问题出来吗？
发的截图跟要钱一样，截图多了一点仿佛就泄漏了商业机密一样。
还记得中学的几何结题吗？
要证明啥啥啥的，条件摆在那里的然后做的过程当中总觉得少了一条件，那个条件知道了就所有问题都迎刃而解。
那些题目好歹是有办法做出来的，条件是足够的，可能是隐藏比较深。
但是你这是压根就题干就没有给完全啊。
遇到这类问题，有空的人呢会慢慢引导你去把错误怎样正确的提问，把报错信息截图以及你做了什么操作尝试去解决。
但是大部分人都是没空的呀，都在上班或者是学习。
我遇到这样的问题在没空的时候一般都是扫一眼，然后关闭窗口。
其实我在（虽然我不是大佬），我用过xxx，但是我的使用下没遇过xxx，你的截图信息不足以解答问题，请学会正确提问——请阅读 提问的智慧，这真的不是在阴阳什么，是在有效正确的提问下获取问着问着问题就解决了，可能是自己写错什么了，大小写不对，思路错了等等，正确提问是一个自省的过程！
4 贡献开源
为什么我会想着给开源项目贡献，起因是公司在做一个新的react 移动端项目，社区在这方面的组件库比较少（不是没有，只是少而已，好的要么国外的要么在重构），而我自身的能力也还达不到说实现一个基础的组件库，特别是项目还是一个ssr的项目。
起初我是有尝试着去写Button这些组件的，但是写下来发现成本太大，而且props的暴露也不是很好，后来就在社区里面去找啊找，然后发现了react-vant这个库。
这个组件库我在接触的时候还是在0.x版本，但是作者非常活跃，现在已经到了1.3.x版本了，在issue的沟通以及后来微信交流群的交流中觉得这个组件库的维护力度还是挺大的，就决定使用这个组件库进行开发了。
因为在ssr的使用上，组件会存在一些服务端与客户端的一致性问题，就那个脱水合水的东西，我花了两天时间把所有的组件搬过来ssr框架上进行测试，在测试的过程中，就开始了我对开源项目的第一个PR，一开始是一些简单的TS类型的警告，到组件文档的小修改，再到组件的一些bug修复，后来结合对工程化以及cli的研究，
发起了create-react-vant-cli-app子包的PR。
从这个过程中是一点一滴的提升自己，把自己的所学进行输入。
这也是一个提升自己的过程，就跟学生时代的题海战术一样，你会了不代表你熟练了，只有经过一次输出才会发现有哪些不足，编码、设计思想等等。
偶然在掘金上看到了 vue-devui 发布10个组件的文章，就对这个组件库留意了起来，因为这个组件库是基于 vite + vue 3+ ts实现的，虽然现在我不用vue了，但是看到华为的背书，我还是抱着学习的对 vue-devui 的源码进行了一番探索。
发现 devui-cli 还没有剥离开来，与组件库的耦合在一起。
这不是刚学了ts，在react-vant中也实践了一番，然后就想着要不把 devui-cli 用ts重构一下吧，顺便抽离子包让组件库的结构可以清晰一点。
pr 在此。
在这个pr里面，devui-cli的创建者 iel 同学给我提出了很多review的意见，包括一些暴露方式的思考甚至是别的项目拷贝过来的代码都有被review到了，这种感觉就是学生时代上课做题目老师站在身旁的感觉。
体会了一波代码被review的感觉，在review的过程中真的是渴望又害怕的感jio，希望可以指出一些做的不好的地方，但是又担心会暴露自己菜的事实🤪。
在提交了PR的当天晚上，Kagol 老师在交流群里面对我说了这样的一句话
我是瞬间感觉得到了认可，以前的学习终究还是派上了用场。
后来跟 Kagol 老师交流之后我们觉得一个生态里面的基建是比较重要的，所以开了个 devui-cli的仓库对cli进行孵化，可能现在就只有个空的架子在，里面的功能都还没有开始去实现，但是技术嘛，就是折腾，有了目标才知道自己需要学什么？
参与一个大型的开源生态建设，基本上跟大厂经验没啥区别。
大厂提供的也无非是规范化的流程以及大牛的指导，但是这些在 devui 的生态实践中，我觉得都有机会获得！
挖个坑
devui-cli road map，devui-cli 的一些构想，有兴趣的伙伴们可以一起共建😀。
开源贵在坚持、贵在追求完美、贵在折腾，让我们与 devui 一起学习吧！
DevUI 招募贡献者啦
目前Vue DevUI和Ng DevUI都在大量招募社区贡献者，欢迎加入我们！
添加小助手微信：devui-official，拉你进DevUI技术交流群。
欢迎关注：DevUI开源的故事，并加入到DevUI开源生态的建设中来！
