是时候维护一个属于自己的开源库了

发表于 分类于 阅读次数： Waline： 本文字数： 3.1k 阅读时长 ≈ 3 分钟

使用 GitHub 很久，除了无脑 star、fork 大神们的仓库、输出一些学习代码以外，对于 GitHub 本身的贡献似乎寥寥。Arctic Code Vault Contributor 的勋章我受之有愧。如果你也有和我类似的想法，那么，是时候可以尝试一下维护一个自己的开源库了。

维护一个开源库，听起来很简单，但是真正要开始动手，似乎颇有些千头万绪，无从下手。那让我们来捋一捋，首先我们碰到的第一个问题可能是：我们可以去维护一个怎样的开源库？

目的和意义

该维护一个怎样的开源库，讨论这个问题之前。我们先把维护开源库这件事当做一个项目来分析，首先我们来思考这个项目的目的和意义——这个思考的结果有利于我们对于这个项目的持续维护，也可以当做一项工作开始前的心理建设。

我们的目的除了上面提到的增加一些对 GitHub 的贡献，我们所选择去维护的开源库类型也可以从另一方面确认我们这个项目的目的，比如如果你打算维护一个你所对应的开发语言的工具类框架，那你们目的就是把这个框架完成，并且好用。

而在这个过程中，你的技能水平有所提升，是附带产生的收获，也是可以在这个阶段当做我们的目的之一。

另外如果你期望你的框架可以满足了一部分人的需求，可以帮助到别人，得到一些 Star 和 Follow，那么获得他人认可也是作为这个项目的目的之一。

最后，当我们选择去维护一个开源库，这个开源库必然是我们最想去维护的，那这个过程中我们必然是开心和满足的，获得自我满足感也可以当做我们的目的之一，这点也是我认为最重要的。

以上几点，既可以当做目的，从结果上也可以当做我们维护开源库所具备的意义。

选题

进入正题，我们该维护一个怎样的开源库？对于大神来说，这个问题很简单，基本就是输出一些自制的小工具或者简洁优美的代码轮子，但对于一个还在自己的知识领域里辛苦耕耘的朋友来说，要独立维护一个技术含量比较高的开源库也许会略感吃力，甚至有可能是劝退性的。对于这类心里打鼓的朋友，也许前面干巴巴的文字无法成功完成第一轮的心理建设，也许需要一些更直观的东西来把退堂鼓换成锣鼓，比如：

这两个链接里面有许多技术含量不高，但很有趣也有很多 Star 的项目，比如这个nocode

没有一行代码的应用程序，看起来像是一个愚人节玩笑。

Write nothing; deploy nowhere.

OK，maybe it is the most secure and reliable applications.这个项目在 GitHub 有四万多的 Star，颇有几分不着一字，尽得风流的意味。

总之，从以上例子来看，其实我们无需局限于技术，在开源库的类型选择上，我们可以有更开放的选择，总结如下：

确定一个方向后，然后在此基础上从自己擅长或者感兴趣的入手，相信你很快就能找到一个合适的项目。当然别忘了开始前在 GitHub 上检索一下，看看是否有类似的仓库，避免重复造轮子。

维护

确定好要维护一个怎样的开源库后，接下来就是怎样去维护一个开源库了，即是走一遍创建仓库，拉取部署和维护的流程。——这里默认所有想维护开源库的朋友对 GitHub 的基本操作都熟悉。

创建仓库 Tips

创建仓库这里有个小 Tips，是公司同事分享的，就是一个比较正式的开源库，通常会挂在一个组织底下，比如：

比如：

再比如

由以上例子可见，挂在组织底下的项目会比挂在个人底下的项目看起来更会正式。哪怕我们是个人维护的，但让他看起来正式一点也没什么错误。另外在被搜索和在 url 路径展示上也相对会工整一点。

维护和一些设定

创建完一个仓库以后，拉取部署等常规操作略过不提，说说维护。步入正轨的维护，其实就是持续的 push 就好，根据仓库类型不同，有的也许是周期需要维护的，有的也许上线已接近完成，需要做的只是抓虫和偶尔更新。这个时候需要注意：

  1. 对项目保持一定的关注，给自己固定一个周期性的时间检查项目，以防止时间断层导致项目失去维护。
  2. 每次 commit 的描述，清晰直观的提交历史可以让人对你的表述能力有大概了解，也方便给潜在的，想要一起维护的开发者一个直观的项目过往，有利于增加与你一起协作维护的吸引力。
  3. 项目结构的条理性，原因同上。

除了步入正轨的维护，在创建时，还有项目本身的一些设定也很重要：
qKgJbv1x2cGzk7e

  • 项目 logo
  • readme 文件的书写
  • 项目描述
  • 开源声明

项目 logo 如果动手能力强的朋友可以考虑自己设计一下，网上也有在线工具可以用符号排列组合生成属于自己的 logo。

readme 文件作为一个项目的头脸，描述清晰直观的重要性远远超过上述提到的 commint，需要注意的主要有内容排版，头部和尾部信息。

细心的朋友可能注意到许多项目的 readme 文件的头部会有类似于这种website展示仓库属性信息的小标签，这种标签可以使用 Shields.io 这个网站来制作。

以我的仓库为例，在网站首页填入仓库地址，点击 Suggest badges 会自动生成几个标签，不同的标签代表着不同的含义。
pcHKt3e9LRv1jdV

如果想展示更多的内容，可以上拉网页自己定制。

readme 的底部信息，没有标准，有的仓库会把作者的个人信息挂上，有的会列出贡献者名单，也有的会把自己的收款二维码贴上，供人打赏。全凭个人喜欢。

关于仓库 About 的描述，力求简洁，明朗，最好一句话能说清楚是干嘛的。而一个有网站可以浏览的仓库体验也会相对好点，这方面使用 GitHub 提供的服务——GitHub Pages 已然可以满足。实现起来有两种方式：

  1. 可以在仓库设置界面点击 Change Theme，在进去的二级页面选择好主题后，GitHub 会自动帮你生成一个网站分支，自动拉取你主分支的内容更新。
    s6yAmwq84ZRFkoz
  2. 如果不喜欢产生多余分支，有强迫症的朋友也可以尝试在仓库主路径底下增加 _config.yml 文件，在里面添加主题配置： 
    1
    theme: jekyll-theme-cayman
    并在设置中选择，通过主分支来构建网站，即可生成仓库网站。
    Mmc8NQbY4g5Tw3q

给仓库设置标签有利于检索，比如我给我的仓库设置了一个 awesome 的标签，那么如果有人搜索相关字段，或者直接在 Awesome Lists 这个列表里找，会有相对较高的曝光率。

关于版权声明，如果在创建仓库时勾选了生成版权声明的文件，创建后会自动生成该文件。如果没有后面自己加也可以，添加后侧边栏会自动生成版权声明的描述。我这里选择的是 CC0-1.0 的版本。关于不同版本声明的区别会在后续文章中更新——本来想更新一篇关于不同版本开源声明的区别的文章，在网上检索资料时发现一个开源库可以帮助开发者选择不同的软件开源声明：Choose a License。

最后

要维护好一个开源库需要做的事情远比上面列举的还要多，只是对于一个刚开始维护一个开源库的新手来说，不至于劝退，这些内容已经足够。

而在步入正轨以后，你可能需要回答 Issues 里提出来的各种意想不到的问题，也可能要甄别 Pull requests 下的提交是否有益，利用好 GitHub 提供的额外功能 Actions、Projects 则可以大大提高维护和协作的效率。另外你还可以在 Insights 看到自己仓库的各种统计信息，仓库的贡献曲线图，浏览次数，被下载次数等等。

最后，无论你的开源库是否因为代码优美而获得许多 Star，还是持续维护仍无人问津，都祝你好运。最后分享一句孔子的一段话，也做自我勉励：

芝兰生于空谷，不以无人而不芳。