我的书签
添加书签
移除书签第 1 小节：有了开源的想法后从何开始
开源的选题
如果你有开源的想法，面临的第一个问题应该就是要做一个什么样的项目。这一步至关重要，很多想要开源的同学就因为这步选错了，导致了项目刚开始或者做到一半就放弃了。
很多人会问的一个问题：开源选题是否要和工作内容有关系？我们应该如何把握？
首先，我们应该从自身能力出发。
- 如果你是未参加工作的学生，建议你以学习内容为轴心，丰富的理论知识可以让你在相关项目的实践上大展拳脚。
- 如果你是其他行业的人士，请确定自己感兴趣的方向，掌握必知必会的技能，开源指日可待。
- 如果你是一个初次参与开源的“新手玩家”，熟悉的领域比较少，建议你从工作相关的内容入手，可以更好地开启你的开源之路。
- 如果你是一个有丰富经验的开发者，但各个领域并不精通，请尝试从自身技术栈出发，解锁开源的第一步。
- 如果你是一个开源界的「老炮」，知识面广泛且深入，相信你已经不需要再依据这篇文章来进行开源的抉择了，欢迎你更积极地「发光发热」，帮助更多的人晋升为「老炮」。
其次，可以从自身需求出发。
- 想要了解的技术，建议你针对性地学习开源项目。
- 开源项目在工作实际落地场景遇到了问题，请针对特定开源项目深入研究。
- 多种开源项目的技术选型，你需要横向对比多种开源项目的原理和特点，了解他们的优缺点。
- 自研开源项目，如果已有类似项目，那你需要了解同类型项目。
小贴士：关于开源选题，一定是你有所了解的。哪怕是从零开始，也要掌握一定的知识储备。否则，你的开源之路不会很顺畅。开源就像读研究生，能够参与进来的人，一定是掌握一定基础且对研究方向感兴趣的人。
如果你已经选择好了项目的赛道，先别慌着动手，建议在开源社区内寻找下你这个赛道里其他的开源项目。
一开始最好去找开源社区里最活跃的同类型项目，评判一个项目是否活跃，一是看这个项目的 Star 数，二是看这个项目是否一直在更新，三是看 Issue 数量和评论数量。找到这样的一个项目后，可以去看看这个项目的特性，这会帮助你在设计你的项目时了解所需要关注的点，有可能有些特性你是没有想到的。然后最好去 Clone 这个项目的代码到本地，如果有时间，最好还是仔细的去阅读下人家的代码。如果读不懂，一般成熟的项目总有例子和单元测试。最好亲自去跑下别人的例子和单元测试，再结合项目的特性，能帮助你对这个项目有更好直观上的理解。
然后再去找一下这个赛道里其他的项目，挑一些 Star 数相对比较高的项目看看。再和最活跃的那个项目，进行一个横向对比。思考下为什么这个赛道里排名最高的那个项目会得到使用者的青睐。这样总结一番，你会对在这个赛道里如何脱颖而出有一个大致的判断。这会对你的项目要做成什么样有很大的帮助。
同时也建议去看看赛道里高 Star 项目的 Issue，Issue 基本能反映出一个项目历史的迭代过程和目前的进展，这当中有用户提出的改进，有作者自己加的一些特性。每个 Issue 有一个标签，能反映出这个 Issue 是 Bug 还是增强，还是新特性。建议你只过滤出增强和新特性。这基本上就是一个项目迭代的历史过程了。如果一个项目都没有 Issue，只能说明迭代度比较差，或者受到的关注度使用度比较少。这种项目也基本没有看的必要。
如果你发现在这个赛道里有一大批活跃高 Star 的项目，他们也各有特点。基本上可以解决所有的这个领域的痛点。那么还是建议你换一个赛道。你的项目一定要有自己的特点，如果你的项目的特性，使用方式都和其他项目差不多或者还不如其他项目，那为什么指望用户用你的项目呢。
那有些同学就会说，现在开源项目那么多，在每个领域都有很多已经做的非常好的项目了，我怎么做都感觉是在造轮子，既然造轮子无意义，那我也没有做的必要了。
首先我觉得造轮子并不是无意义，造轮子是有意义的，但是造轮子的意义是在于你自己可以通过造轮子来获得对技术的剖析和理解。但是如果你做开源项目的目标是想把项目推广给社区，让社区里的人来用的话，那么造一样的轮子是没有意义的。每个领域的确有一些做的非常好的项目了，绝大多数情况下，你也不太有机会去新开辟一个领域去做。但是不见得每个领域里的项目都面面俱到。正如前面开头说的那样，可以做差异化竞争。
就像洗发水一样的，这个品牌的洗发水主打清香的功效，洗完可以飘香十里，那么它对于需要增加回头率的女孩子就是十分有吸引力的。那个品牌的洗发水主打夏季的清爽，洗完感觉有薄荷的那种凉凉的感觉，那么它对于汗多油腻的男孩子们就相当有吸引力了。这就是差异化竞争。
同理可以类比于我们的项目，比如这个领域里头部的项目是一个功能非常全的项目，但是某一个功能点可能用的不那么爽，你就可以针对这个点做一个小而精的项目，在这个功能点上做到极致，让使用者觉得很爽。差异化是一个比较好的思路，相信如果你对这个领域的项目作出足够的研究后，一定能找到一个差异化的点去挖掘。
短期目标 & 中长期目标
如果你已经选好了赛道，你需要为你的项目制定一个短期目标。
所谓短期目标其实就是你的项目第一个稳定版本应该达到的预期。在做短期目标的时候，应该以实际为主，切勿目标定的很宏大，过大的目标会消耗你太多的开发周期，正所谓一鼓作气，再而衰，三而竭。一口气吃不成胖子，长周期的开发本身就是一件需要毅力的事情，而很多人会在这漫长的周期内会被消耗掉原先的激情。
相对确定，短小的目标可以令你缩短开发周期，迅速达成。本来开源软件就是一个漫长的迭代过程，假设你有一些宏大的目标，都是可以通过慢慢迭代实现的。而快速放到开源社区的另外一个好处是，可以通过社区的正向反馈来调整你的迭代的过程。毕竟开源项目一开始的所有特性和功能基本上都是你一个人拍板的，但是开源之后，你可以了解到更多人的反馈。有些一开始的想法会随着反馈的增加而进行改变。这也是自我思想迭代的一个过程。
对于中长期目标我的建议是，在你第一版的时候可以先计划下大概的方向，在项目架构层面留好可以扩展的方向。但是细节点可以不用在这个阶段过多考虑。
设计好你的项目架构
开源项目的初始架构至关重要，你之后的迭代都是围绕这个整体架构进行的，当然中间也可以进行重构，但是付出的成本要大很多。在设计项目架构时，有以下几点建议：
- 尽量选择较新比较流行的选型。老旧过时的选型在用户使用时可能会碰到兼容等各种问题，选择一个流行的选型会最大程度上降低这种问题的发生。
- 精简你的依赖，只选择你的项目必须的依赖。过多的依赖也会导致兼容性的问题。
- 一开始就要考虑到扩展性，模块之间的松耦合做好，边界定义清晰，这对项目之后的良性循环很重要。
- 在设计之初就要考虑到使用者环境的多样性，比如同一个选型的不同版本，不同操作系统等等。
为你的项目定一个名称
一个好的项目名称能让你的项目更加引人关注，虽然起名字没有什么讲究，随你的喜好，但是为了能使你的项目被人所关注，还是建议尽量起和这个领域有关的单词，最好简洁，不要过于复杂，容易让人记住的名字。
还有就是起名字的时候不易太精确，这样不利于扩展。比如你想做数据库的性能监控框架，如果你起名为 mysql-monitor，那你之后迭代万一想兼容其他数据库，那这个名字就有点局限性了。如果叫 db-monitor，就比较贴切点。
项目名是项目的门面，就像一个人的名字。在定名字的时候，也不要过于花哨，以贴切简洁为主。
为你的项目写一个 README 文件
基于 Git 规范的代码托管平台，一般 README 都能直接展示在你的项目首页，可以起一个快速介绍，快速上手的作用。
一个好的 README 应该包含以下几点：
1）项目的名称和简介，基本上简短概括为主，说明你的项目主要用在哪些领域，能解决哪些问题。
2）项目的特性，也是以简洁的语言进行概括几点。
3）简单的快速开始用例，这部分旨在用最快的方式让别人通过用例了解你的项目。你项目中细节的说明和配置不应该放到这里。否则就会显得太冗长了。
4）个人不太建议把项目的文档写在 README 中，因为文档本身是项目使用的详细说明，会涵盖各个方面，放到 README 里面不太妥当，如果你有自己的文档页面，应当在 README 里面放一个超链进行跳转。当然如果你的项目非常的小，基本上一页纸就能说完的事情，放到 README 中也是可以的。
5）作者的介绍和联系方式（或者提供提 Issue 或者 Pull Requests 的方式等）。让别人碰到问题时能快速联系到你。
建立严格的版本号规范
如果你想做成一个成熟规范的开源项目，那么版本号应当遵从开源项目的规范，对你的迭代也有帮助。
版本号建议为 3 位数字，比如 1.1.0，1.5.1 这样，但是我们经常看到在版本号后面还有一些修饰词，比如Alpha、Beta、Release 等等，对于这部分的规范如下：
Alpha（如1.1.0-alpha）：内部测试版本，Bug 可能比较多，一般用于开发人员内部使用Beta（如1.1.0-beta）：用户测试版，Bug 相比 Alpha 少一点，但同样不建议用于生产环境，一般用于面向急于使用新功能的群众进行公测，并向开发人员进行反馈RC（如1.1.0-rc）：Release Candidate，即将作为正式版发布，Bug 较少，正式版之前的最后一个测试版GA（如1.1.0-ga）：General Availability，首次发行的稳定版，比较稳定，可以用于生产Release或者留空（如1.1.0-release、1.1.0）：最终发布版，可以面向广大的一般用户
那对于 3 位数的版本号的管理策略如下：
- 项目初始版本可以是
1.0.0 - 项目进行 Bug 修正时，最后一位加 1，比如
1.0.1 - 项目有新特性发布时，中间一位数加 1，同时最后一位复位为 0，比如
1.1.0 - 项目有重大特性发布，同时结构可能不向下兼容时，第一位数字加 1，其他位数复位为 0，比如
2.0.0
完善测试用例
我们在做企业级项目的时候，测试用例是必不可少的。同样我们在做开源项目的时候，测试用例其实更为重要，测试用例能检查出你的任何改动是不是对其他功能产生了影响。这从根本上就保证了你的项目质量。
在企业级项目上做测试用例，很多同学可能只是针对于功能点进行做。确保每个接口都能正常运行。但在开源项目中，测试用例可能就变得更加苛刻了。
你不仅要建立对功能点的测试用例，还要考虑到兼容性，边界情况，使用者的环境这些因素。针对于这些情况同样要建立相应的测试用例。
一份完善的测试用例，能够使你的开源项目质量成倍的提高，当然你在这之中所付出的时间精力也是巨大的。
为你的项目建立一份使用文档
首先得清楚，使用文档是给用户阅读的。所以在你的使用文档里面，你应该尽可能的避免阐述你的一些实现细节。
一份好的使用文档应当是能让用户和你的项目快速建立连接的，这里有一些写作文档的建议：
1）使用主动语态：尽可能使用“你可以这样更改配置”，而避免过多的使用“配置可以这样更改”，这样在阅读体验上会更加容易，反之就会显得你的文档比较拗口。
2）使用简洁明了的句子：写文档不是写小说，不是写诗歌，不需要用过多的修饰词，能让用户明白你想表达的意思即可。
3）保持条理性：你可以再文档中通过写标题，划重点，引链接等方式，把各类信息划分为不同的部分，避免将所有内容都揉在一大段冗长的文字当中。
4）提高可读性：除了文字之外，使用图标也是众多种角度表达的方式之一。
5）注意拼写和语法：必须检查文档中是否有词语的拼写错误和语法错误，尤其是程序的关键词语。
只要在文档的写作和编辑过程中应用到良好的技巧，你就能和读者建立起沟通和信任，读者会觉得你的项目很专业，印象上也会加分不少。
开源项目可以和自媒体结合
如果开源项目分值数太少，可以和开源课程、自媒体、公众号、短视频、写书等结合在一起，既可以为项目加分又可以传播开源项目知识，增加开源项目的流量访问，同时也贡献了自己的一份开源力量。
