I a student and have good knowledge in C programming and like to contribute any open source project which is developed in C. I searched sourceforge and selected 7-Zip because its widely used one and developed using C.

I thought to start first by fixing bugs (which was suggested by many people in their websites) and gone through few bugs but couldn't understand how to respond to them and how to start fixing them.. I didn't understand anything.
Could you please explain how to approach this.. I have even gone through some files in the source code which I downloaded but didn't understood anything. Please help me!

You should write to 7-zip's maintainer and ask him...
–
Federico CullocaJul 9 '11 at 15:55

+1: You've set yourself an excellent challenge. Outside of school, a lot of programming involves working in code other people wrote to add features or fix bugs. Also, you can learn a lot by seeing how other programmers did things.
–
Bob MurphyJul 9 '11 at 17:05

@suryak: In 7-Zip source code, only the core compression algorithms are written in C. Everything else is written in C++.
–
rwongJul 9 '11 at 17:48

4 Answers
4

I have even gone through some files in the source code which I downloaded but didn't understood anything.

This is the first bug you should fix. You need to understand the code base before you start fixing bugs. Otherwise, how will you know if your fixes will break anything else?

There are different methods of becoming familiar with the code in a project you're joining. My favorite method is to read through all of the code once, then go back and look at sections in more detail.

Fixing bugs might not be the easiest thing. It's easier than adding new features of course. But even easier is updating the documentation or testing a new release. Both of these will get you to become more familiar with the code so you can know enough to fix a bug. It also gives learning about the code a sense of purpose that helps others.

In my opinion, a very important thing that many people who have ambitions to contribute to open source people overlook, is communication with the other developers on the open source project.

If you want to contribute to an open source project, the first thing you should do is follow what is happening in the project. If there is a mailing list, forum, Google Group or other way in which the developers communicate, join there. Find out what contributions are most needed. Ask questions about how the software works, etc.

If you just download the source code, try to understand it all by yourself then it will cost you much more time. If you fix something or add a new feature and then suddenly present it, it's less likely to be accepted.

So, talk to the other developers, find out what are the highest priority bugs or missing features, etc.

Can you change behaviour of 7-zip to
use "move" instead of "copy" when
7-zip unzips the files. Issue is with
single HDD systems and big files, this
will speed up things significantly.
WinRAR does it right now.

And I will explain why I pick this bug as example.

Before you decide to pick this project...

Are you comfortable with this project's source code?

Can you understand both the C code (mainly the core compression algorithms)?

And also the C++ code (most of the "application", GUI and command line, and also all interactions with the operating systems)?

And also the coding style (typical to Win32 programming; not using MFC/ATL)?

To choose a bug to work on, one needs to be able to reproduce the problem on a similar computer environment.

This bug will require you to test on a computer which (1) the temp folder has low free space (1-2 GB), (2) the extraction destination is on same drive as temp folder.

How much time needed to "setup" the environment for reproducing it?

Choose bugs that are easy to reproduce and easy to fix.

Is the bug really a bug?

Always try to reproduce it yourself. Don't just rely on other's words.

As a software engineer/programmer, see if you can explain the bug's behavior in terms of your understanding. Sometimes users have unrealistic expectations of how software/hardware systems work and make impossible feature requests.

How do I confirm my understanding? How do I know if it is copying or moving the file?

You'll need diagnostic tools, like Process Monitor. You may also tweak your test machine setup to test different scenarios.

Second step: Can you locate the code responsible for this behavior?

A rough overall understanding of the project is needed, according to Larry Coleman's answer.

It is best if you have Visual Studio (an integrated development environment and debugger) so that you can set breakpoints and understand the program's flow.

Third step: Make modifications and see how it affects the program's behavior.