大家好，欢迎来到停止重构的频道。
本期我们讨论一个开放问题。
为什么流行的开源项目只是凤毛麟角，且很多有名的开源项目都是背靠大公司的。
但是，为什么还有很多个人开发者愿意开源项目呢？
欢迎大家把自己的想法或开源项目发在评论区，或者给一些想要开源项目的小伙伴一些建议 。
我们按这样的顺序讨：
1、 绝大多数开源项目的现状
2、 开源终归是愿不愿意分享的问题
3、 我们技术群里小伙伴分享的开源项目
4、 给准备做开源项目的小伙伴的一些建议
绝大多数开源项目的现状
从宏观角度讲，开源能让更多的想法和思考得到碰撞，延续前人的成果也更加容易，软件世界会更加缤纷。
如全文搜索引擎elasticSearch和solar都是基于开源的Lucene Ubuntu、Fedora系统都是基于开源的Linux。
开源大大促进了软件行业的发展，很多人也高举拥抱开源的口号。
但是绝大多数的开源项目都是没人关注、没人用的，即使你的开源项目足够优秀或足够好。
而且这跟国内外的环境关系不大，国内也有比较成功的开源项目，如SRS、Mycat、flv.js等。
github上有几亿个项目，没人关注、没人用就是绝大多数开源项目的现状，它可能顶多是求职简历上一条微不足道的亮点。
至于这种现状产生的原因有很多，最重要的是很多开源项目的质量是不够的，不礼貌地说就是垃圾。
所以在往期《开源项目不等于降低成本》中讨论过，使用开源项目的试错成本是很大的。
这种现状让开源项目的推广实质上还是口口相传，流行度、用户基数成了开源项目最重要的指标，也是Apache基金会等组织评估开源项目的门槛指标。
所以流行的项目会越流行，新项目则需要很长的时间、或花很大的推广成本才能积累用户，即使项目足够优秀，很多时候也很难熬过一开始的至暗时刻。
开源终归是愿不愿意分享的问题
但纵使是这样，仍然会有很多开发者发布维护自己的开源项目，包括我们停止重构。
很多人会质疑重复造轮子、项目的价值 甚至有时候会遭到恶意评价。
我们也跟很多朋友讨论过个人开源项目的意义。正如《艺术哲学》这本书说的一样，任何杰出的艺术品或艺术家都不是孤立横空出现的，而只是时代或群体里最具代表、杰出的。
所以失败的、被埋没的开源项目，也一定会给予一些人灵感而再创造，而且不发布公开怎么知道行不行呢？即使只有几个关注者也能避免闭门造车。
当然，无论怎么争辩，都无法改变开源项目大概率无人问津的事实，付出可能会颗粒无收。
那么，就没人做开源项目了吗？归根结底，这不是一个值不值的问题，而是愿不愿意的问题。
你是否愿意分享你的创造、你的所思所为，我们是愿意的，也是这么做的。
我们技术群里小伙伴分享的开源项目
我们的技术群里也有小伙伴分享自己的项目。
首先是我们停止重构自己的开源项目，目前是三套开源框架，包括前端网页、后端、云计算 。前端和后端框架将会在不久推出2.0低代码版本，云计算框架也会推出一个通用云计算任务系统。
接下来是我们技术群里小伙伴分享的项目，也帮忙推广一下。
首先是一个前端工具Glassmorphism，一款生成毛玻璃CSS样式的工具，作者做了完整使用视频，感兴趣的小伙伴可以关注一下。
虽然工具比较简单，但是这种可视化的样式修改需求十分普遍，下次我们做相关模块的时候会认真参考一下。
下一个是go语言的后端框架Aurora 以及数据库操作框架GoBatis，感兴趣的小伙伴可以关注一下。
最后是几个初中生的开发者群体BUGDUCK，他们推出了前端框架tntjs、前端动画引擎newcar，相信后面会做出更棒的东西，毕竟他们现在只有十几岁 我十几岁的时候还只知道玩冒险岛。
还有一些同是创业阶段的小伙伴，他们的项目还在最初始的阶段，还不能分享。
给准备做开源项目的小伙伴的一些建议
接下来我们想给想做开源项目的小伙伴一些建议。当然我们自己也做得很不好，但至少目前我们还在坚持做开源项目。
我们建议开源项目是从实际项目或实际问题而来的，而不是某个知名工具的换皮产品，这样更能得到用户的关注。
开源项目应该持续更新，保持项目活跃。
不要像我们一样，迭代了四五年都十分成熟了再公开。
开源项目的推广也很重要，需要凝聚用户漏斗，形成良性循环。
我们也是刚摸索，没什么实用的经验分享，但是可以分享一本书叫《影响力》，可以帮助大家对推广扩展思路。
总结
最后，看过我们之前架构相关视频的小伙伴可能会感觉我们表里不一 ，一边说着实际项目要谨慎选用开源项目，现在又在变相鼓励开源项目。
这大概不算是表里不一，只是想法和做法不一致，因为很多的人和事教会了我们。
想法是必需大胆、积极、非常规的，但做法是必需谨慎、小心的。
我们在每一个实际项目都会尝试新的想法，但一定会保证它在可控范围内，我们认为稳妥的创新并一定是模仿，而是不断地局部推陈出新，久而久之，必然愚公移山、精卫填海。
聊回开源项目，虽然很多人认为是重复造轮子、灯蛾扑火。
但是我们真心觉得，选择做开源项目的程序员，即使经验可能有限、设计有所局限，但一定都是优秀的程序员。