Copy Link
Add to Bookmark
Report
d1_0x02_How_to_start_contributing_to_or_using_Open_Source_Software
[* *] DO NOT FUCK WITH A HACKER [* *]
| - | #3 File 0x02 | - |
| * |How to start contributing to or using Open Source Software| * |
| - | By Shlomi Fish ,shlomif(at)iglu.org.il | - |
| * | Original link | * |
Contents
1 Introduction No. 1 - What is Open Source Software
1.1 What is software?
1.2 What is "shrinkwrap" software?
1.3 What is open source software?
2 Why open source software?
3 How to start using open-source software?
3.1 Using Native Windows Open Source Software
3.2 Playing with Linux
3.3 Which Linux to Choose?
4 Should you aspire for "sainthood"?
5 Contributing
5.1 Some Mental Preparation
5.1.1 Consider Finding a Mentor
5.2 Choose some Projects to Contribute to
5.3 How to Survive as an Open Source Contributor
5.3.1 The UNIX/Linux Command Line
5.3.2 Build Systems
5.3.2.1 perl's Module-Build
5.3.2.2 perl's ExtUtils::MakeMaker
5.3.2.3 GNU Autotools
5.3.2.4 CMake
5.3.3 Version Control Systems
5.3.4 Bug tracking
5.4 Learning How to Program
6 Summary
7 Where to go from here
8 Authors
--[ 1. Introduction No. 1 - What is Open Source Software
This introduction will explain what open-source software is in a series of answers to questions. You may wish to skip or skim parts of it depending on your knowledge.
----[ 1.1 What is software?
While many of the devices and tools we encounter in every day life (e.g: hammers, refrigerators, CD players, pencils, microwave ovens) serve a limited amount of purposes, a computer is a multi-function device, which one needs to instruct what to do. This is done by programming it and the end result is called software which is composed of individual programs and applications.
If we take your home computer (a stationary machine, a laptop, a netbook, etc.) as an example, then you can use it to run a web browser, a word processor, a spreadsheet program, some games, and other programs - often at the same time. You can also download for free, purchase or even experience directly through the Internet (say on web-sites containing online games) other programs that you can also run on the computer. Sometimes you can run several alternative programs.
Software naturally does not come out of thin air: it has to be programmed by programmers. Some software is distributed in the native computer's processor machine code and is run directly on it. Some software is distributed directly in modifiable source code (in case the computer already has a different program that can run it directly from there). Some programs take an intermediate approach of implementing a machine-independent bytecode sometimes called a "P-code" which is generated from the source code and then executed. In any case, the source code of the program always exists (or at least existed) somewhere, and is used to prepare it for use and distribution.
----[ 1.2 What is "shrinkwrap" software?
Shrinkwrap software is software that its programmers have written for other people to use "in the wild". It can be sold in shops, bought through the Internet, downloaded free of charge, or whatever, but it is still expected to be of general use to a substantial number of people who would like to use it. You can find a lot of programs like that on Software development hubs ("Forges") such as SourceForge, on software directories such as Freshmeat.net, and on many other sites.
It may seem surprising to some people, but the vast majority of the source code in the world is not intended for shrinkwrap software. A lot of the code out there is used in-house: by banks, governments, companies and individuals and a lot of it is intended to power various embedded devices. Let's suppose you've opened a spreadsheet and wrote a simple formula (such as "=$A1+B$2"). This little formula is code, and unless you're going to share your spreadsheet with the world (which most people won't for various reasons) it will remain in-house code. A UNIX command-line user may write many small programs at the command line prompt every day, (such as "grep -F hello *" to search for files containing the word "hello") and not only are these programs not going to be released to the public, they are likely going to end up being thrown away after they became functional, ran and yielded the correct results. It is likely that the amount of in-house or throwaway code written in programmable tools like multiplies the amount of code in the original tool pretty quickly.
Open source software is one type of shrinkwrap software which like we said is intended to be used in the wild by other people, which may actually be sold commercially or otherwise give some commercial benefits to its developers, and as such be considered "commercial software". Other types include commercial software that is not open-source (sometimes called "'proprietary software'") which needs to be bought for money, non-open-source software which does not cost money (often called "freeware"), and shareware which can be downloaded free-of-charge but requires money for enhanced use, such as using beyond a trial period, getting rid of a nag screen, or enabling extended features.
Now let's see what makes open source software different.
----[ 1.3 What is open source software?
For the sake of the explanation, you'll also hear people refer to open source software as free software (where "free" means "libre" and not "gratis"), "free and open source software" (or "FOSS" short) or even "FLOSS - free, libre, and open source software". All these names refer to the same phenomenon with some different semantic and ideological associations.
The "Free Software Definitions" is possibly the most succinct definition of how open source software needs to be licensed in order to be considered open source:
The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Basically, a piece of open source software ships has its original human-readable and modifiable source code available, can be run and used for any purpose, and can be modified internally or externally and even "forked" (i.e: span-off as a competing project).
Nevertheless, this definition still gives some room to maneuver for licensing. Sometimes, downloaded copies of FOSS can be converted into a different licence by any third party (these are called "permissive licences" or "BSD-style licences"), but often code that includes the FOSS code or even just calls subroutines from it needs to be licensed under a similar, free licence. The latter is referred to as "copyleft" and is the foundation of such licences as the GNU General Public License (GPL) or the GNU Lesser General Public License (LGPL), and many similar licenses.
In any case, one should understand that being open source does not stand against commercialism or Capitalism. There are many commercial companies which publish a lot of their code under open-source licences (many of which are profitable), and many individuals are making a decent living out of working on open-source code. One can sell support and services around open-source code, and as some people like to say "our code is free - our time (and yours) isn't.".
--[ 2. Why open source software?
There are several aspects that make open source software superior:
Usually, one can legally download the open-source applications, use them or even modify and adapt them for different needs, legally and free of charge. Despite all that, it is perfectly legal to sell open-source software (or services that relate to them), but in this day and age of cheap, common, and fast Internet, many people will opt not to pay for it.
Many open-source projects make a smart use of the Internet for getting input from users, customising the software according to it, or even accepting contributions from co-developers. (This has been referred to as the Bazaar style of development.)
Open source software can be adapted to overcome its limitations (such as bugs, missing features, or broken compatibility), either by oneself, or by hiring or convincing someone to do that for you. Source code tends to be much more adaptable to changes in the deployment platform than binary executables.
Open source software encourages a culture of "freedom", "openness" and sharing, which stands as opposed to the helplessness and resentment that users of proprietary software often feel.
One can point to one's contributions to open source software as a portfolio of previous work which is both free and legal to examine and be impressed from. Furthermore, often other people on the Internet will contact you about your open-source project which will allow you to gain more recognition.
Naturally, there may be many important downsides to the open source development model, but we believe that it is advantageous in many cases.
--[ 3. How to start using open-source software?
Now that we've understood what open source software is, and assuming you think it's a cool idea that you'd like to contribute to (or just benefit from), let's see how you can start to use it, which is normally a prerequisite for contributing to it.
----[ 3.1 Using Native Windows Open Source Software
Assuming you're still using Microsoft Windows, you may wish to play with some open-source software that can be installed and run on Windows. For this head to the "Open Source Windows (software)" site and install and play with the applications featured there, and possibly use them in production. There is a lot of other open source applications for Windows listed on The List of Open Source Programs (LOOP).
----[ 3.2 Playing with Linux
After you've installed many open-source applications for Windows, you may wish to perform the next logical step and play with Linux, which is a close-to-entirely-free operating system usable as a comfortable and stable desktop for one's PC. Linux is an operating system and as such serves as a host for other programs, similar to the fact that Microsoft Windows is an operating system that hosts many applications each as different processes and as different windows.
Linux is not entirely compatible with Windows, but the graphical user interface (GUI) is similar enough to become comfortable with it. Despite common prejudice, Linux is not exclusively intended for programmers or only for "computer geeks" and common people can become comfortable with it. In fact, it tends to work better, and be more transparent, reliable and secure than Microsoft Windows.
The good news is that you can install Linux while being able to keep your Windows installation and continue using it, and switch from Linux to Windows (or even use them at the same time). The ways to install Linux from the most intimidating to the least intimidating one are:
Repartition your hard disk. This means that an installation of the Linux operating system will be installed side by side with the Windows installation, allowing you to choose which one to use during boot. This process normally progresses fine, but may result in data loss if the computer loses power or you've done something wrong with the installation, so it's advisable to backup first.
LiveCD/LiveUSB - a Linux LiveCD, LiveDVD or LiveUSB is a self-contained Linux distribution that boots up and runs directly from the CD drive or USB stick without requiring installation on the hard-disk, and while leaving the host system in tact. The downside is that any changes not saved on the hard-disk will be lost after a reboot, and reportedly using a LiveCD for prolonged periods tends to ruin the CD-ROM drive.
Virtual Machine (VirtualBox, qemu) - in this scheme, one runs Linux inside a virtual machine, meaning an emulated computer running inside a window on the host system (Microsoft Windows in our case). The virtual machine still has networking and can communicate with the host system, but otherwise does not interfere with it. The downside is that Linux will likely run slower this way.
Of these, it is recommended to start by installing Linux inside a virtual machine inside a good virtual machine emulator such as the open-source and free VirtualBox.
----[ 3.3 Which Linux to Choose?
Since the Linux operating system and its individual components are all open-source and can be freely packaged and distributed, this spawned a proliferation of Linux distributions, which after being installed, provide similar functionality but with different packaging, different distribution-specific modifications and customisation to the components of the system, and somewhat different philosophies. Most Linux distributions are pretty niche, or otherwise not ready for general use (if not no longer actively maintained or went out of fashion). Here is a short list of the most recommended distributions:
Ubuntu Linux - probably the most popular desktop distribution, Ubuntu has semi-annual releases and aims to provide a polished desktop experience.
Fedora - a free distribution from Red Hat Inc. with semi-annual releases, and good desktop polish.
Mandriva Linux - a free desktop-oriented distribution with semi-annual releases, good integration between the components and good desktop polish.
MEPIS - a desktop-oriented distribution based on Debian.
These are all intended to be installed on the hard-disk or on a virtual machine.
Some recommended Live CD / Live DVD distributions are:
Knoppix
Mandriva One
PCLinuxOS
Whatever you do make sure you avoid the "distribution hopping"-syndrome where you hop from one distribution to another after running into a few difficulties with one distribution. Choose one distribution and stick with it, as you are likely to encounter different issues in a different distribution.
--[ 4. Should you aspire for "sainthood"?
Some ardent supporters of open-source software will claim that using non-open-source software is immoral, and that one should aspire for "sainthood" by using open-source software exclusively, up to not using non-open-source operating systems such as Microsoft Windows. While such stance may be appealing to some, we recommend that you don't follow it, at least not right away. You will likely still need your Windows partition, in part so you can test that the open-source applications of you or others work there properly and are well-supported. Furthermore, the main issue is open source software vs. proprietary software, not Linux vs. Windows.
--[ 5. Contributing
OK, you've been using open-source software, have played with Linux (or even are using it daily), and now you're interested in contributing to some open-source applications you like. First of all, welcome aboard, we could use all the help we can get and we hope you find it a pleasant experience.
----[ 5.1 Some Mental Preparation
Contributing to open-source software can be fun and rewarding. Yet, it will likely be a bumpy road, as you may find that some people you interact with are rude or insulting. The important thing to remember is not to give up.
It's OK to become insulted and discouraged for a while. Lawrence Lessig, a law professor who has written several books about the free culture of the Internet, and has projected the Creative Commons, had this to write in his book "Remix":
I find it insanely difficult to read these comments [to my blog posts]. Not because they’re bad or mistaken, but mainly because I have very thin skin. There’s a direct correlation between what I read and pain in my gut. Even unfair and mistaken criticism cuts me in ways that are just silly. If I read a bad comment before bed, I don’t sleep. If I trip upon one when I’m trying to write, I can be distracted for hours. I fantasize about creating an alter ego who responds on my behalf. But I don’t have the courage for even that deception. So instead, my weakness manifests itself through the practice (extraordinarily unfair to the comment writer) of sometimes not reading what others have said.
So then why do I blog all? Well, much of the time, I have no idea why I do it. But when I do, it has something to do with an ethic I believe that we all should live by. I first learned it from a judge I clerked for, Judge Richard Posner. Posner is without a doubt the most significant legal academic and federal judge of our time, and perhaps of the last hundred years. He was also the perfect judge to clerk for. Unlike the vast majority of appeals court judges, Posner writes his own opinions. The job of the clerk was simply to argue. He would give us a draft opinion, and we’d write a long memo in critique. He’d use that to redraft the opinion.
I gave Posner comments on much more than his opinions. In particular, soon after I began teaching he sent me a draft of a book, which would eventually become Sex and Reason. Much of the book was brilliant. But there was one part I thought ridiculous. And in a series of faxes (I was teaching in Budapest, and this was long before e-mail was generally available), I sent him increasingly outrageous comments, arguing about this section of the book.
The morning after I sent one such missive, I reread it, and was shocked by its abusive tone. I wrote a sheepish follow-up, apologiz- ing, and saying that of course, I had endless respect for Posner, blah, blah, and blah. All that was true. So too was it true that I thought my comments were unfair. But Posner responded not by accepting my apology, but by scolding me. And not by scolding me for my abusive fax, but for my apology. “I’m surrounded by sycophants,” he wrote. “The last thing in the world I need is you to filter your comments by reference to my feelings.”
I was astonished by the rebuke. But from that moment on, I divided the world into those who would follow (or even recom- mend) Posner’s practice, and those who wouldn’t. And however attractive the anti-Posner pose was, I wanted to believe I could fol- low his ethic: Never allow, or encourage, the sycophants. Reward the critics. Not because I’d ever become a judge, or a public fig- ure as important as Posner. But because in following his example, I would avoid the worst effects of the protected life (as a tenured professor) that I would lead.
So even if you, like Prof. Lessig, have a thin skin, and can get discouraged by a bad comment, it's important not to give up completely. It's OK to feel down for a while, but understand that the feeling will pass and you will eventually be recognised for the work you invest in contributing to open source.
There is some good advice on handling Internet criticism on the "Unarmed but still Dangerous" blog, which builds upon the excellent advice given by Dr. David D. Burns in the book Feeling Good: The New Mood Therapy, which is a self-help guide for Cognitive Therapy, and which discusses how to handle criticism and avoid becoming affected by it.
------[ 5.1.1 Consider Finding a Mentor
Some people will find it easier to survive as open-source contributors by having a person whom they can consult with and who can guide them. There are several ways to find a mentor:
Find one on OpenHatch
See the Teaching Open Source Intitiative's List of FOSS Mentor projects
----[ 5.2 Choose some Projects to Contribute to
The next step is to pick up projects to contribute to. You can choose to contribute to open-source projects that you are actively using such as your distribution, or its various comprising components (the web-browser, the office suite, the Instant Messaging client, the mail client, your favourite text editor, your desktop environment, etc.). Alternatively, you can monitor software announcement sites such as the Linux and open-source oriented Freshmeat and find interesting projects to work on there. More recently, the OpenHatch site started as a way to connect between wannabe contributors and projects.
You may be wondering how you can contribute. There are several ways:
The first way, and the first one that comes to most people's minds is by programming. We'll get to how you can learn programming later. However, it's not the only way, and there are many ways you can contribute while still learning how to program.
The second way is to frequent the projects' online forums (such as their Internet Relay Chat channels, their mailing lists, their web-forums, and so forth) and answer questions or try to find people who can.
Another way is to help maintain the project's wiki, in case it has one.
Some projects may be interested in providing translations and localisations for the project into non-English languages, so if you are fluent in a foreign tongue, you can volunteer to help maintain the translations.
It is also useful to help the project with bug triaging - trying to reproduce bugs, finding bugs that should be closed, replying to the reporter of the bug or the other project's maintainers with your findings, etc.
There are probably other ways to contribute, but the important thing is to pick a few projects to which you wish to contribute and start.
----[ 5.3 How to Survive as an Open Source Contributor
In this section, we will try to briefly touch on various technologies you'll need to understand in order to effectively contribute to open-source projects. We will refer you to material for further reading.
------[ 5.3.1 The UNIX/Linux Command Line
While Linux is perfectly usable using a graphical user-interface (GUI), it has a different interface called the command line, in which one types commands using the keyboard and receives feedback using a console / terminal output. To use it you can use KDE's so-called "konsole" console window, or GNOME's "gnome-terminal". In order to work on most open-source projects, you will need to have some familiarity with the Linux command-line. Here are some resources to get you started:
UNIXhelp for users is an old, but likely still pertinent guide to the UNIX (and ergo Linux) command line.
The Linux Documentation Project's Guides contain some books that may also prove helpful.
There's a Wikibook page titled "Linux Guide - Using the shell" and some other resources on Wikibooks
The important thing to realize about the UNIX command line is not to be afraid of it. While it may seem intimidating at first, most people will quickly find it to be very convenient and a very powerful tool. Furthermore, it is often a requirement for people who wish to contribute to open-source projects, as many tasks can only be done or are better done there.
------[ 5.3.2 Build Systems
Open source software is normally distributed as packed and compressed archives of the source code, which need to be built in order to be installed and deployed on the host system. Downstream distributors tend to take the source packages and prepare binary and ready-to-install packages out of them, which are specific to only one particular package manager (such as rpm or dpkg). However, if you plan on contributing to an open-source project you'll need to know how to build its source code.
Here's a coverage of some popular build-systems and how to build code from them:
--------[ 5.3.2.1 perl's Module-Build
Module-Build is Perl 5's newer build system, which is not dependent on the idiosyncrasies of the system's shell and its make implementation. To use it one should do something like:
$ perl Build.PL
$ ./Build
$ ./Build test
$ ./Build install # as root or using local::lib or some Build.PL arguments to install locally.
--------[ 5.3.2.2 perl's ExtUtils::MakeMaker
ExtUtils-MakeMaker is Perl 5's older build system, which generates makefiles and system-specific shell scripts. To use it one should run the following commands:
$ perl Makefile.PL
$ make
$ make test
$ make install # as root or using local::lib or some Makefile.PL arguments to install locally.
--------[ 5.3.2.3 GNU Autotools
GNU Autotools are a popular choice for creating cross-platform build systems for C/C++ and similar programs, but they are pretty old, and cause many problems and so many people recommend using something else instead. To build a program that uses GNU Autotools you need to run:
$ ./autogen.sh # Or similar - if building from the raw source.
$ ./configure --prefix="$HOME/apps/myapp" # And possibly other flags.
$ make
$ make install
--------[ 5.3.2.4 CMake
wikipedia:CMake is a new cross-platform build-system that aims to be a better alternative to GNU Autotools and sports many enhancements. To build a CMake-based project, use something like:
$ mkdir build
$ cd build
$ cmake-gui ..
$ make
$ make install
------[ 5.3.3 Version Control Systems
Reading from an earlier article that Shlomi Fish who also contributed to the document you're reading now had written:
A version control system enables developers to keep historical versions of the files under development and to retrieve past versions. It stores version information for every file (and the entire project structure) in a collection normally called a repository.
Inside the repository, several parallel lines of development, normally called branches, may exist. This can be useful to keep a maintenance branch for a stable, released version while still working on the bleeding-edge version. Another option is to open a dedicated branch to work on an experimental feature.
Version control systems also let the user give labels to a snapshot of a branch (often referred to as tags), to ease later extraction. This is useful to signify individual releases or the most recent usable development version.
Using a version control system is an absolute must for a developer of a project above a few hundred lines of code, and even more so for projects involving the collaboration of several developers. Using a good version control system is certainly better than the ad-hoc methods some developers use to maintain various revisions of their code.
So if the project you're trying to contribute to does not use a version control system, it should start right away. You can read more about the motivation for version control in the mentioned article and a presentation that Sawyer X gave. Here's some introductory material on the various popular version control systems in use today:
For CVS, which is an old version control systems, and now largely unloved (but can still be found in use), see the online book "Open Source Development with CVS".
For Subversion, a centralised version control system that aims to be an improved and corrected CVS, see the online book "Version Control with Subversion".
For Git, a distributed version control system that has been gaining popularity, see the online book "Pro Git"
For Mercurial, a distributed version control system written in Python, see the online book "Mercurial: The Definitive Guide".
For help with Bazaar, another distributed version control system written in Python, see its documentation.
------[ 5.3.4 Bug tracking
As defects (a.k.a "bugs") and requests for enhancements are introduced to the project, one needs to track them using a bug tracker. "Joel on Software" gives the motivation and how-to of bug-tracking in an essay which you should probably read.
Most bug-trackers nowadays have a web-based interface, which one can use from the browser and is mostly self-explanatory. So try to use it and if you run into problems consult your co-developers for help. There are too many different implementations of bug trackers to cover them all here, but being web-based, they should not be too hard to use for active contribution.
----[ 5.4 Learning How to Program
Once you start contributing to open-source, you probably would like to advance your contributions to the next logical level, by learning how to program. Now the topic of what should be the introductory programming language is a topic of ongoing debate (see for example this essay by Shlomi Fish). We recommend that you start by learning either the Perl programming language or the Python programming language and then learning the other one.
To learn Perl, refer to the Perl Beginners' Site which provides many good resources. To learn Python refer to the book How to think like a computer scientist - in Python and there are other Python introductory books listed on the Python wiki. You then may be able to contribute to a project written in either language , but continue learning other programming languages and topics.
It takes many years to become a good programmer, and good programmers are constantly trying to improve their skills and expand their knowledge.
--[ 6. Summary
Using open-source software can make your computer work more enjoyable, give you more freedom, and supply you with many important technological advantages such as lack of vendor lock-in, lower costs, and the ability to contribute. In addition, contributing to open-source software may be fun, and it also has the advantage that you're also helping you and other users of the open-source applications.
We hope this document has given you the information and pointers necessary to start your journey into the world of open-source software. Feel free to contact us if you feel anything is amiss, so we can improve it.
--[ 7. Where to go from here
This section aims to list some additional resources about contributing to open-source. The first one is the essay "Open Source, Free Software, and Other Beasts" by Shlomi Fish (who also wrote most of the first version of this essay.), which provides an introduction to the world of open source software for those who are not very familiar with it. It is available online under the open-content Creative Commons Attribution licence.
Another good resource is Eric Raymond's "How to become a hacker" document followed by his the "Cathedral and the Bazaar" series. They are both very enlightening resources, but note that they suffer from a certain amount of arrogance.
The Philosophy section of the Free Software Foundation (FSF) site contains some interesting articles. While they are written from an extremist and uncompromising view, which you may choose not to adopt, but they are still a useful food for thought.
Some good resources about software management for open-source programmers include:
Paul Graham's Essays
The "Joel on Software site by Joel Spolsky.
Rick Moen's resources
Extreme Programming
The aforementioned resources by Eric Raymond.
You can find many additional resources on open source software by performing web searches or by perusing the various Wikimedia resources (such as the Wikipedia or Wikibooks), and on Wikia.
--[ 8. Authors
Primary Author: Shlomi Fish - also see his homepage
Some contributions from other users of the Teaching Open Source wiki including Erkan Yilmaz and NeoPhyte Rep .
