In my interactions with people at conferences and in daily life, I have seen that a good number are fascinated with the concept of open source development and are enthusiastic about getting involved in some way. Unfortunately, it seems that most of the time, they have no clue how to actually get started and end up really not taking that first step. They can hardly be blamed, of course, because there really are no generic guides to open source development - most projects have higher-level documentation specific to that project - and getting started in an environment that is filled with motivated and sharp individuals, who don't really do much hand-holding, can be quite intimidating.

I've felt compelled, therefore, to write this document in the hope of filling the gap that currently exists. Much of what follows has been drawn from personal experience and observation of the open source development process.

1. Assumptions
2. What project should I pick?
3. Where do I start?
4. What are automake, autoconf, libtool, etc.?
5. How do I compile applications from source tarballs?
6. How will other applications find something I installed in my own prefix?
7. Where can I find more answers to my questions?
   

Assumptions

For the purposes of this document, I assume that you're working with Linux as your primary OS although much of what is said here should apply straight to OSs such as FreeBSD or an environment like CygWin. It's also assumed that you have some basic UNIX command-line experience.


What project should I pick?

Although there's nothing really stopping you from going and hacking straight on the Linux kernel, try to pick a project that you are genuinely interested in (or involves an area of computer science that you like a lot), know enough about to start off with, expect to learn from, and (in the case of user applications) will use yourself. Doing so will keep you engaged while expanding your knowledge by teaching you new things.

It's also very important to resist the urge to start your own pet project before even looking around. Chances are that what you want to do has already been done and the world could definitely do with one less dead open source project :-) Unless you are absolutely certain what you're trying to do has not been attempted already, you will really be much more useful contributing to a project that is alive and swarming with developer activity. Not to mention that you will also learn a heck of a lot more.

Where do I start?

Start with reading everything you can on the project's website. There usually is a section for those looking to contribute. Once you've done this, getting on the mailing list for developers is absolutely essential.  Follow the discussions on the mailing list and post questions - most project developers are a helpful lot and will answer your queries as long as you have taken the time to read the documentation already available.

At this point, most people tend to get overwhelmed by traffic on the mailing list. This is something that you will have to learn to deal with (using filters, threading, knowing what to skip, etc.). If you're using a sucky email client, use something nicer (like Evolution, Thunderbird or even Mutt) :-)

You'd also want to set yourself up with a separate directory where you compile your applications from source, checkout code from CVS, etc.


What are automake, autoconf, libtool, etc.?

Although detailed explanations are outside the scope of this document, it should suffice to say that they are used in almost every project using the standard set of GNU development tools. They make the process of creating Makefiles, compiling and generating libraries and binaries on different platforms without you having to do anything different, etc., as painless as possible.

They are very useful and usually come installed as part of your distribution. If they're not, you can always install them by yourself (using the package manager for your distro). There are tutorials available which explain how to use them in your project but the best way is to learn by example so look at how your favourite project uses them.

How do I compile applications from source tarballs?

Up until now, you've probably installed applications on your distribution by downloading pre-compiled binary packages. But every now and then, there's a need to compile an interesting application from source code (usually provided as a .tar.gz file). 

Download the tarball to a location of your choice.

Unpack it:

$ tar xzf <tarball file>

Change into the directory that's created.

$ cd /path/to/dir

(Make sure you read the README file as well as the INSTALL file before proceeding. These files usually give package specific information and installation instructions. If there are specific installation instructions, follow those)

At this point, compiling your application should involve precisely 3 steps:

• Configuring the build
• Compiling the code
• Installing the resulting binaries and libraries

To configure the build, type:

$ ./configure

To compile, type:

$ make

To install the application, type:

$ make install

If any of the steps fail, it's probably a non-standard source code distribution.

A natural question to ask at this point is, "Where does make install actually install it?"

An application usually installs different files to different locations. For instance, binary files are installed in the 'bin' directory of what is known as the "prefix"; library files (.so, .a, etc.) are installed to the 'lib' directory; documentation to the 'doc' directory; and so on.

So given a prefix, the directory structure usually looks like this:

$prefix
    |----- bin
    |----- doc
    |----- lib
    |----- man
    |----- include
    |----- share

So you can choose to make your prefix '/usr' or '/opt/devel/src/' or wherever it is you want the application to live.

To specify a prefix for the application you are compiling, type:

$ ./configure --prefix=/path/to/your/prefix

The configure script is what you use to configure your build. Available options can be listed using the --help switch.


How will other applications find something I installed in my own prefix?

It depends on what you're talking about. An application may install binaries, shared library object files, header files, icons, etc. Each type of component is located in a different way.

Binaries are located (as you should know) using the PATH environment variable. So ensuring that $prefix/bin is in your PATH (where $prefix is where you installed a particular package) will take care of finding binaries.

Libraries (let's assume we are only sticking to shared library objects here) are located at runtime by the dynamic linker, ld. There are two ways of telling ld where to look for libraries:

• /etc/ld.so.conf - contains a list of directories that shall be searched. Since this involves root access, we won't encourage it here
• LD_LIBRARY_PATH environment variable - we shall use this method. LD_LIBRARY_PATH works pretty much like PATH - make sure the directory which contains the shared libraries (usually $prefix/lib or its subdirectories) is included in the list.
  

Now if you've just installed a library that some other application you want to compile needs, you will also need to take care of how things are located at compile time.

For libraries that also need to be located at link time, you usually tell the linker to look in a certain place via the -L flag. Alternatively, you can pass in flags via the LDFLAGS environment variable. Header files are typically located by your compiler (strictly speaking, the pre-processor). To tell gcc to look in a particular directory, you need to tell it via the -I flag. The CPPFLAGS environment variable may be used to pass in any extra flags you want to set while compiling some other application.

Typically, you won't need to explicitly pass in LDFLAGS and CPPFLAGS for packages that use the new pkgconfig mechanism. In most such cases, the only environment variable you will need to set is PKG_CONFIG_PATH (typically, $prefix/lib/pkgconfig).


Where can I find more answers to my questions?

In general, read man pages, documentation files and search the web. This should answer most of your queries. If you need more help, join the IRC channel that the developers of your project use. Most people are willing and patient enough to listen to your queries and help you out provided you show that you've taken the time and effort to search for answers by yourself.