Possible Duplicate:
How do you dive into large code bases?

I am currently a student and started programming a few years ago. I am able to write complete working software in many languages. However, there is something that bugs me about contributing to open source projects: how do you understand how the organization structured its source code? I tried to add functionality to Apache Tomcat and found it difficult to find myself in all these source files. Is there something I am missing that makes it easier to understand the organization of the work done?

  • This same question has been bugging me since long and I would like to do somethhing about this.
    – Sid
    Commented May 24, 2011 at 19:06

2 Answers 2


Get to know the people behind the project, participate on the project's mail-list. There are usually a number of bugs reserved for people getting to know he project (these easy-to-fix bugs are usually called bitesized bugs)just search for them on the issue tracker.

Contributing to the documentation is also a good way to start and it will give you a better knowledge of the project.

Open Hatch is a nice place to find projects in need of contributors and to express your willingness to help. Several large projects such as Mozilla use Open Hatch to recruit new contributors. You should definitely take a look at this web site.


When you are using some third party open source sofware in your project, and you feel that it should do something that it actually doesn't, what you can do is:

  • Inspect the code and realize the precise changes you have to accomplish in order to have things done.
  • Do those changes and test if everything works.
  • Do at least a little documentation (for example some sort of javadoc for every new function you write, or a comment for every new block of code you add).
  • Tell the community responsible of that open source software of your changes.

For the last point, it depends on how that community works. For example, if they host their project in GitHub, you can fork their code and then tell them that the changes you made in your fork are worth a look, describing the improvements you made.

In some other projects the code is distributed in the form of a tarball. In that case you can tell the maintainers the files you modified, describing the changes you made and why...

Also you have to bear in mind that in some cases the functionality you needed so much in your project may be of no interest at all for the community that supports the open source project. There have been cases where such a situation was the founding point of a brand new project, with its own personality and goals.