如何加入开源项目？
发布网友
发布时间：2022-03-29 01:25
共2个回答
热心网友
时间：2022-03-29 02:54
首先，有很多加入开源项目的动机。排在第一的可能是“酷”：）当你告诉你的朋友“嘿，我在XYZ项目开发团队! 我很潮吧？”
但是这并不是一个很好的原因。加入一个开源项目的首先需求是你需要使用它。如果你自己不会实际使用，那么就不会有很强的动机去加入一个项目。
其它一些加入开源项目的原因可能是：
§ 获得写权限，将你自己的特性或者bug修订加入到基础代码中。
§ 你认为自己能够对项目带来很大的提升。
热心网友
时间：2022-03-29 04:12
为什么加入一个开源项目？
首先，有很多加入开源项目的动机。排在第一的可能是“酷”：）当你告诉你的朋友“嘿，我在XYZ项目开发团队! 我很潮吧？”
但是这并不是一个很好的原因。加入一个开源项目的首先需求是你需要使用它。如果你自己不会实际使用，那么就不会有很强的动机去加入一个项目。
其它一些加入开源项目的原因可能是：
§ 获得写权限，将你自己的特性或者bug修订加入到基础代码中；
§ 你认为自己能够对项目带来很大的提升；
§ 你有很多空闲时间：）
初始方法
因为如下两个原因，第一次加入一个开源项目可能需要慎重对待：
首先，没有标准的方法，没有“加入此项目”这个按钮。你需要直接联系项目的所有人（或者维护人），同他交谈。
对起步者来说，另外一个可能导致加入过程有点困难的事情是缺少课题。
在你尝试加入一个开源项目之前，你应该尝试自己启动一个项目。即使这仅仅是一个小项目或者只是一个Lib库，或者是一些简单但有用的东西，然后在你自己的Blog或者社交网站上宣告项目。如果你幸运的话，一些人会发现项目的价值，然后开始使用它。
通过做这件事情，你将学会两件事：首先是如何运转一个开源项目，其次是你的发明被很多其他人使用时是什么样子。当你意识到可能有成百上千的人使用你的代码，有的人检视它并反馈意见、想法、补丁包给你的时候，这是一件很令人激动的事情。
除了这些，你也可以看到社区是如何运转和发展的，你将开始从不同的环境不同的角度来看你的项目。
它将为你打开新的视野!
即使你已经做了这些事情，或者感觉自己已经做好无论如何都要加入一个开源项目的准备，也还有其它前提条件：
§ 你必须熟悉掌握项目使用的VCS（Version Control
System）工具。例如，如果项目使用Subversion（SVN），你必须知道如何提交、合并、回退、修补等等
§ 你必须知道可读的代码和文档的重要性
§ 你必须知道如何注释你的代码
如果你觉得所有这些你都没有问题，第一步就是开始“玩”项目：将代码Checkout，然后一头扎入代码中，去学习代码如何工作以及代码完成什么功能。
同时也要关注项目使用的编码风格，你不需要完全按照当前项目维护者那样编码，但至少要保证是相同的风格。你需要考虑到总会有人将要阅读和修改你的代码。
就像有人说的：编码的时候你要想象那个最后维护你代码的人是一个知道你住在哪里的暴力精神病患者!
当你感觉已经做好要加入的准备，你可以进入下一步：联系项目维护者！
初步联系
如果你准备运行自己的开源项目，你可能已经有了一个如何让你的Email被尊重和别人看到Email的时候如何想的好主意。
这个不是什么高深复杂的事情（原文为rocket science）：
§ 这个家伙加入了许多开源项目，而且可能在项目中担任全职工作，所以Email要短、要令人愉快。
§ 这个家伙根本不知道你是哪根葱。所有运行开源项目的家伙至少知道一件事情：好心未必有好报（Hell is paved with
good intentions）。
§
展示你项目有关的知识，而不是你的*。换句话说，向项目所有者证明你具有成为项目一部分的资格。如果你加入了，你有足够的时间来展示你的动力和*
好的，我已经加入了，现在干嘛？
根据经验，有两种类型的人将加入开源项目：一种是推动项目前进的人，一种是不会推动项目前进的人。
与展示实际的资格相比，那些不会推动项目前进的人总是更加倾向于展示自己的*。他们加入项目，然后从不提交任何东西，或者提交新的代码，或者提交新的功能，因此也不会带来任何Bug。
当加入一个项目的时候，问问自己是否有足够的动机去实际做一些事情是重要的，但不要做得太多也同样重要。
一个新的程序员在某种意义上来说有点像一个新的经理，要想成功，必须具备相似的品质。
一个真正优秀的经理将谨慎的接受一个新的工作职位。即使他的最终目标是将公司*过来和优化整个流程，他也会以完美的模仿前任经理来作为开始。
为什么？
设身处地的想象一下：如果你是新经理的下属，或者新经理的上级，他们得到一个新的经理：
A经理：加入公司，试图将公司业务*过来，打破正在运行的流程，阻止人们进行工作。但是经过一些列的困难工作后，前景将如此美好!
B经理：加入公司，完美地深入细节地工作，同时给工作流程带来小的增量的改进，最终起草并向上级提交详细、完整、通过*原有流程来优化的计划。
谁将有更大机会获得成功？
很明显是B经理，因为首先他通过带来一些微小的改进来证明他更有竞争力，然后在他尝试去实施大的改进之前，提交一个清晰和完整的计划。
给一个开源项目带来很大改变不是不可能的，但首先你要证明你能够完成它。
一个成功的开源项目很像一个成功的商业：如果不毁灭它，那么很难带来很大的成功的改变。
所以特别小心你的大的改变。
事实上当加入一个开源项目后最好的开始的地方是非常基础的：在那些你只会带来很小危害的地方开始!
改进项目的文档或者注释、添加单元测试、或者做一些检视，这是一个了解项目、项目的缺点、项目的优点的好机会。项目维护者非常乐意你做这些，这也是获得他们的信任以及展示你是认真帮助项目的好机会。
创建你自己的分支也是一个好主意，这样你就是在一个沙箱（译者注：供儿童在其中玩耍的一个环境，类似于在海滩上堆城堡，可以随便推到从来，也不会带来什么危害）环境中，对项目来说，这样你就几乎没有可能做错事或者破坏项目。
尽管将主干版本合并到你的分支，这样就可以使得你的代码与时俱进。
*环境
我不认为有任何成文的规定，但是你必须知道一些关于大部分开源项目的一个重要的事情：
没有民主!
随便你怎么说，但最终只有一个权威：项目所有者。
不喜欢这样？忘掉它吧（原为是Fork it）。
