现在非常多的人都想涉足开源的，但不知道从什么地方入手。这里有几种方法可以帮帮忙，即使你缺乏信心，你但仍然能够让你挑起技术大梁。
开源软件改变了计算乃至整个世界，也许你也想为这样一件事做出贡献。但不幸的是，很多人认为参与这样的项目具有很高的门槛。我经常听到人们说，他们很乐意贡献但不能的原因有三个：
“我不是一个很优秀的程序员。” “我没有太多的时间投入进去。” “我不知道什么项目值得去努力。”我从开源代码的新手中观察到最有害的想法是，想要做一名优秀的有贡献的开源编程人员必须具有极高的天赋，这是不正确的。当然，还有那些在开源世界谁被认为是摇滚明星的，他们可能确实是天才程序员。可是，我们中的绝大多数都不是，但我们仍然为改变世界做着自己的贡献。
开始听
在开源代码的一切涉都及到其他人。要是你想加入一个团队，这意味着了解社会，了解它是如何工作的。进入一个项目中，并说：“这是我认为这个项目应该做的事”，这通常不视为一件好事。有些项目可能会喜欢这样的想法，但是要是项目已经运行了一段时间，那这种态度被接受的可能性就很小。听是要知道这个项目需要以什么样加入方式为最佳。
1.加入邮件列表
对于许多项目，邮件列表都是关于项目开发沟通的主要渠道。在大型项目中，有许多邮件列表可供选择。例如，PostgreSQL的项目有不少于12个面向用户的列表和6个开发人员的邮件列表。我建议主要从面向用户的列表和核心开发者的邮件列表开始听。
2.关注博客
由核心开发人员维护的博客往往会给出在将来的版本当中出现的一些信息，以及什么时候能够得到那些信息等等。
3.加入一个IRC频道
很多开源项目都有专门的互联网中继聊天（IRC）的渠道，开发人员和用户挂出问题以及讨论项目的进展等等。
入门工作
代码是任何开源项目的核心，但编写代码并不是帮助入门的唯一途径。代码以及周围代码系统的维护通常都容易被忽视，这些地方不仅能修正错误而且能够创新功能，可以从这些地方入手来参与一个项目。
4.诊断错误
诊断和筛选一个错误可以帮助开发人员节省更多的时间来找出问题的细节。要是用户反映到，“当我做x工作的时候软件不工作”，那么这时候你应该检查这个问题的细节。是否这个问题是重复的，要是是你可不可以创建一组解决这类问题的步骤，将此类问题缩小。即使你不知道是什么原因造成的问题，你可以把问题的范围缩小从而减少其他人员解决问题的时间。
5.关闭修复的错误
错误往往是固定在代码库的，清理这些东西可能非常的耗费时间，但是对整个项目非常有价值。检查项目发布的更改日志，看看错误是否是固定的，要是是可固定的，注意版本号并将其关闭。
处理代码
所有有经验的程序员都可以在整个项目的代码当中起到很大的作用，你不必认为只有天赋异禀的程序员才能对项目起到作用。每个项目都有自己的工作流程,所以在提交代码之前询问清楚如何做。当你修改代码时，请确保你作为项目当中的一员，并保持你的代码风格和代码库的其他代码是相匹配。
6.测试一个测试版或发布一个候选版
任何项目运行在多个平台都可能遇到各种各样的兼容性问题。当测试版或候选版发布后，该项目负责人希望它会由很多不同的人在不同的平台进行测试，你可以负责这个工作来帮助项目能够顺利的完成。
7.修正bug
这通常都是代码工作者刚开始想从事的工作，这很简单：在interesting-sounding系统中找到错误并且尝试修复代码，并检查代码的放置是否合适。同时添加测试的套件来测试那些固定的代码。有些项目需要bug修正并且测试。
8.编写一个测试
大多数项目都有一个测试套件的测试代码，但很难想象一个测试套件不能附加给它更多的测试。使用类似于gcov或者C的测试工具来检测到未通过测试套件的源代码领域，然后添加一个测试套件来掩盖它。
9.无声的编译器警告
构建许多以C为基础的项目往往会在屏幕上出现奇怪的编译器警告标志。这些警告通常是没有问题的指向的，这时你应该检查是否该代码实际上有隐藏的错误。
10.添加评论
当你开发过的代码你感到疑惑时，别人也可能在同样的地方感到疑惑。此时你应该记录这样的代码同时提交一个补丁。
使用文档
文档在一个项目中往往是遭到冷遇的一部分。文档可能是以熟悉项目的角度来编写的，而不是以一个刚接触项目的角度。因此很多项目的试用文档并没有被重视起来。
11.创建一个示例
没有一个项目有太多的示例，无论是web API，还是一个GUI应用程序都没有使用的较好的示例，也没有可以更明显和迅速解释正确使用的程序的示例。对于一个API或库，创建一个使用的示例程序，这甚至可以从你写的代码提取出来。因此我觉得创建一个使用的示例是非常必要的。