Introduction to Free and Open Source Software


Free and Open Source Software, or FOSS for short, is software for which the source code can be freely shared, with anyone, for any purpose.

There are more rigorous definitions, and there are many licenses that help to ensure these freedoms in subtly different ways. We examine these details later in the book. For now, focus on this simple idea: the freedom to share source code is the essential element of free and open source software.

At the end of this chapter, you should:

  • Understand the difference between source code and binary code;
  • Understand some of the benefits of using FOSS;
  • Understand some of the benefits of participating in FOSS projects;
  • Have an idea of some FOSS projects that might interest you, and why;
  • Have the beginning of your own FOSS portfolio.

Why does FOSS matter to me?

Free and Open Source Software matters because it’s real, and because you, the student, can see in to the guts of it. And when you go out into the real world, looking for a job as a Real Software Developer, you have a tremendous advantage if you can prove that you have experience in real software projects — ugly, messy, confusing, gigantic software projects.

Without FOSS, getting experience in real software projects requires access, and probably permission, to see the source code. For students, that access is usually limited to those who can get internships or positions in co-op programs. Not everyone has the opportunity to spend the summer interning with a company that does large-scale software development, meaning that a vanishingly small number of students have the opportunity to work with large (closed) codebases. And even if they do, those students typically cannot show their work to anyone outside of the sponsoring company.

In the world of FOSS, the source code is available to anyone who wants to see it. Not only is the source code available — also available are all of the interesting challenges that go with managing large software projects. In this book, we explore a number of these challenges and help you engage in them in direct and practical ways.

Source Control

How do fifteen software engineers work on the same piece of software together? When two software engineers decide independently to edit the same line of code, what happens? In the world of FOSS, we make use of version control systems to help avoid these kinds of problems. Without version control, it’s a disaster, which is why we cover version control in the chapter entitled (XREF) “Getting the Code: Source Code Management”.

Build Systems

Complex software is built in different modules. Those modules have different names in every language — packageslibraries, etc. — but modularity is always introduced to help manage the complexity of large projects. One software project may import dozens, or even hundreds, of previously built software modules. What happens when one of those modules changes? If you don’t know how those modules fit together, it’s a disaster. Which is why we cover build management in the chapter entitled (XREF) “Building the Code: From Source to Executable”.


There’s also a lot more to good software than code. How do you make sure people have the resources and knowledge they need to find and run (and contribute to) the software that you make? Beautiful code that doesn’t get used is just as useful as code that was never written. Which is why we cover documentation in the chapter entitled (XREF) “Explaining the Code: the Art of Documentation”.

Tracking Bugs

Most code is buggy. Even the very best code can still have bugs, which means the ability to find and eliminate bugs is a critical skill for all software engineers. If you don’t know how to find the bugs your users find, you’re in trouble. Which is why we cover bug hunting in the chapter entitled (XREF) “Debugging the Code: Finding and Reporting Bugs”, and we cover the mechanics of fixing code in the chapter entitled (XREF) “Fixing the Code: Patches Welcome”.

Experiencing the Software Lifecycle

There’s a saying about software programs: they’re never finished, only abandoned. There’s always more work to do to improve any software project. The thing that makes FOSS so unique, and so interesting to the aspiring programmer, is that anyone can participate in a FOSS project. Most large projects can benefit from contribution by even novice programmers. There are also more FOSS projects than ever before, with an almost unlimited number of interesting problems. Want to learn how web browsers work? Hack on Firefox. Want to put together an awesome multilingual book reader for the blind? Hack on espeak.

The key is to find a project that interests you.

Exercise – Finding a Cool Project

Imagine that you have just been hired as a programmer for FOSS Inc., and your manager has told you that you must spend 20% of your time to work on a FOSS project that matters to you.

  1. First, search the web and find sites that host FOSS projects. There are many. Bookmark these so that you can come back to them later.
  2. Second, browse through several of these sites and find one or more projects that are interesting to you. You might be interested in projects that benefit others. You might be interested in tools that support work that you do. Or, it might be that you might find something strikes your fancy that you never considered before! Take this as an opportunity to explore broadly.
  3. After you find a project, write a blog post about it. At this point, the most important thing you can probably do is to explain why the project is interesting to you.

If you don’t have a blog, set one up for free! Visit Blogger or WordPress; setting up a new blog is easy. Blogs are widely used in the FOSS world by project members to share what they’re doing. Your voice will become one of many, and who knows — your blog might become a resource that other students later look to for inspiration when they are looking for projects to get involved in!

What is source code?

Let’s start with an explanation of source code. One cannot understand open source without first understanding source.

Source code is a set of instructions for computers that is meant to be read and written by humans.

Here’s an example of source code, in the C programming language, for a simple, but complete, program.

#include <stdio.h>
main() { for(;;) { printf ("Hello World!\n"); } }

In order to run this program, it must be compiled into machine code. First, we save the program into a file called hello.c. Then, we compile it:

gcc -o hello hello.c

The command is gcc, which stands for “GNU Compiler Collection.” The flag -o sets the name of the program that we are about to generate; here, we’ve decided to call it hello. The last argument is the name of the source file that we want to compile (hello.c). After compiling the program, you should be able to run it. To run the program, type:


at the prompt. This says “run the program called hello that is in the current directory.” When run, this program will print Hello World! until we kill the program. Hold down the CTRL key and press the C key to kill the program’s execution.

At this point, you have two files in your directory: hello.c, the source code, and hello, the program binary. That binary is a piece of that machine code. You can open it with a program called hexdump that will let you see the binary in a hexidecimal form. You can do this yourself on the command line:

hexdump hello

We’ve reproduced some of what it looks like when hello is viewed in hexdump after hello.c has been compiled by gcc:

 0000000 457f 464c 0101 0001 0000 0000 0000 0000
 0000010 0002 0003 0001 0000 8300 0804 0034 0000
 0000020 0820 0000 0000 0000 0034 0020 0008 0028
 0000030 001e 001b 0006 0000 0034 0000 8034 0804
 0000040 8034 0804 0100 0000 0100 0000 0005 0000
 0000050 0004 0000 0003 0000 0134 0000 8134 0804
 0000060 8134 0804 0013 0000 0013 0000 0004 0000
 0000070 0001 0000 0001 0000 0000 0000 8000 0804
 0000080 8000 0804 0518 0000 0518 0000 0005 0000
 0000090 1000 0000 0001 0000 0518 0000 9518 0804
 00000a0 9518 0804 00fc 0000 0104 0000 0006 0000
 00000b0 1000 0000 0002 0000 052c 0000 952c 0804
 00000c0 952c 0804 00c8 0000 00c8 0000 0006 0000
 00000d0 0004 0000 0004 0000 0148 0000 8148 0804
 00000e0 8148 0804 0044 0000 0044 0000 0004 0000
 00000f0 0004 0000 e550 6474 04a4 0000 84a4 0804
 0000100 84a4 0804 001c 0000 001c 0000 0004 0000
 0000110 0004 0000 e551 6474 0000 0000 0000 0000
 0000120 0000 0000 0000 0000 0000 0000 0006 0000
 0000130 0004 0000 6c2f 6269 6c2f 2d64 696c 756e
 0000140 2e78 6f73 322e 0000 0004 0000 0010 0000
 0000150 0001 0000 4e47 0055 0000 0000 0002 0000
 0000160 0006 0000 0012 0000 0004 0000 0014 0000
 0000170 0003 0000 4e47 0055 ac29 394b 26bf 01f1
 0000180 e396 f820 3c24 f98c 8c5a 8909 0002 0000
 0000190 0004 0000 0001 0000 0005 0000 2000 2000
 00001a0 0000 0000 0004 0000 4bad c0e3 0000 0000
 00001b0 0000 0000 0000 0000 0000 0000 0001 0000
 00001c0 0000 0000 0000 0000 0020 0000 002e 0000
 00001d0 0000 0000 0000 0000 0012 0000 0029 0000
 00001e0 0000 0000 0000 0000 0012 0000 001a 0000
 00001f0 848c 0804 0004 0000 0011 000f 5f00 675f

That’s only a small chunk of the program binary. The full binary is much larger — even though the source code that produces this binary is only two lines long.

As you can see, there’s a huge difference between source code, which is intended to be read and written by humans, and binary code, which is intended to be read and written by computer processors.

This difference is a crucial one for programmers who need to modify a computer program. Let’s say you wanted to change the program to say “Open source is awesome!!!”. With access to the source code, making this change is trivial, even for a novice programmer. Without access to the source code, making this change would be incredibly difficult. And this for two lines of code.

Exercise – Change the source code

Change the source code to print out “Open source is awesome!!!” instead of “Hello World!”. Spend no more than half an hour on this exercise.

Optional Exercise – Change the binary code

Change the binary code to print out “FOSS ROXORS!” instead of “Hello World!”. Spend no more than half a day on this exercise.

This is actually a tricky exercise, and it could take you a fair bit of time. We included it here because you might be curious and want to go poking around in the binary. Under most flavors of Linux you should be able to find or install a program called hexedit. To get you started, you use TAB to switch from hex to ASCII, / to search, and F2 to save your changes. You can read the rest of the documentation for hexedit by reading the manpage, which you can get to by typing man hexedit on the command line, or pressing F1 while running hexedit.

Source Code: To Share, or Not To Share?

Obviously, not all software is FOSS.

Most software developers do not share their source code — especially companies that produce software with the intention of selling it to their customers. Microsoft, for example, does not share the source code for the Windows operating system.

Even freeware — programs that are downloadable for free from the internet — may not share their source code with the world. You can get the program for free, but if it breaks, or if you think of a way to make it better, there’s no good way to fix it. For example, you can get the Flash Player from Adobe for free, but if you find a bug that crashes Firefox, you’re stuck with that bug until Adobe fixes it.

There are definite advantages to keeping source code hidden, especially if your goal is to sell the software itself. It’s harder to sell a software program when anyone is free to take the source code and use it for any purpose. If Microsoft were to release the Windows source code under an open source software license, anyone would then be able to take that source code, build “Bob’s Own Operating System,” maybe make a few changes, and then re-sell that product as a competitor to Microsoft Windows. Obviously, most companies who are selling commercial software don’t want that to happen.

The value of sharing

That’s not to say that programmers who write open source software never make money. Some of the most successful companies in the world use open source software to power their businesses. Google, Amazon, Wall Street, the US Department of Defense — some of the world’s largest and most innovative companies, government agencies, and industries are writing software using FOSS every day. They don’t sell that code; they share it, and by sharing, create more value for their organizations.

The amazing thing about contributing to FOSS software is that you don’t have to work for a large company to see the benefits of working in a free and open manner. As a developers, you might write a utilities that solves a particular problem. By sharing it, others might discover the utility of your tool. Others might extend it and help see it grow. At this point, what started as a hack has become something valuable for many. At this point, we begin to see how FOSS development practices can provide demonstrable advantages over proprietary software development practices. Among them:

  • Shared development cost. Writing software can be expensive, at least in terms of time. Good software takes time to develop, and time is money. And if writing software is expensive, then maintaining it is even more expensive. In the FOSS model, the cost of the writing and maintaining the software can be spread out over several individuals and/or companies.
  • Users can fix their own bugs. This is not a freedom that is obviously useful to everybody. Not every software user is knowledgeable enough to fix a bug when they find it. That’s fine; FOSS also means that users can find other people to fix their bugs for them. Not everybody who owns a car is competent to change their own oil, but the freedom to change your oil, or fix a flat tire, or rebuild your own brakes — or the freedom to be able to go to any mechanic or any mechanically inclined friend and ask them to do it for you — is a crucial freedom to car owners. FOSS extends that freedom to software.
  • (Arguably) better software. Allowing users to fix bugs can often lead to better software. One of the problems with proprietary software is that there’s a limit to the number of people you can pay to fix code — that limit is usually directly proportional to how many software licenses the company can sell. FOSS projects have the potential to build a huge base of participants, far greater than the number of developers that any one company could pay. The Apache HTTP server project is a great example of a FOSS project with many developers, both commercial and independent — that has created demonstrably more popular and arguably better software than any of its proprietary counterparts.
  • Software that outlives its creator. There are literally thousands and thousands of pieces of software, written for outdated computers, that are no longer useful for any purpose. If we had source code for these pieces of software, we might be able to extend them to new computers, making them continually more useful and more interesting — but because we don’t have the source code for these programs, we have very little use for them anymore. There’s a word for this kind of software: abandonware. In FOSS, there’s no such thing as abandonware. Sure, people may stop working on a piece of software, but the source is always there, ready to be picked up and carried forward by anyone who has the time and interest to do so. Every dead FOSS project has a chance to be reborn.
  • The freedom to fork. Sometimes software projects go wrong. If a project is proprietary, no one has any recourse if they don’t like the direction of the project: the owner of the project decides the direction of the project, period. But because FOSS guarantees everybody the right to redistribute and modify the source code, developers can always take a FOSS project and move it in a new direction, without anybody’s permission. This process is called forking. Forks are usually regarded as last resorts, since contentious forks can divide scarce developer resources and confuse users. However, a number of FOSS projects have benefited greatly from forks; the server and Inkscape are notable successful forks.

Exercise – List of software

Create a list of all the software that you use on a regular basis. Which software is FOSS? Which applications have FOSS equivalents? What are those equivalents?

Exercise – Compare and contrast similar proprietary and FOSS software

Choose one piece of proprietary software that you use regularly and find its FOSS equivalent if it has one. (If not, pick another program.) Write a blog post comparing the two. Don’t just look at the code; look at the entire experience. How are the user interfaces different or similar? What about the user’s experience overall? Is the quality of the documentation comparable? Is one buggier than the other? (This may take some spelunking in forums, looking for bug reports, etc?)

What, in your estimation, would it take for a new user to switch from the proprietary, closed-source software to the FOSS equivalent?

Exercise – Install a new FOSS tool and blog about it

Go find a new piece of open source software that interests you. Install it, and blog about any problems that you have. Bear in mind that your notes may come in handy during later exercises.

Climbing Contributor Mountain

Participation in FOSS projects is similar, in many ways, to an apprenticeship. It takes some effort, and some help, to work your way to the top. Let’s watch the path a typical newbie takes up Contributor Mountain.

Contributor Moountain


Everyone begins at the base of the mountain as a user of software. Let’s take our hypothetical friend Alice as an example.

Alice is a budding artist, and she likes to share her work with friends online. She’s a big fan of anime. One of her friends suggests that she might be interested in a program called Inkscape, a cool illustration program.

So Alice goes and downloads Inkscape and installs it on her computer. She plays with it. She doesn’t understand it very well, but it seems kinda cool.

Then her friend points her to a couple of Inkscape anime tutorials online, and Alice’s opinion of Inkscape changes from “kinda cool” to “incredibly cool.” Within a few short months and a lot of practice, Alice becomes a devoted Inkscape user. As it happens, developers sometimes forget that users are the reason that software exists. Alice, in becoming a devoted and expert user of Inkscape has taken the first, critical steps to being a valuable contributor to the Inkscape project.

Note: Alice may not yet know, or care, that Inkscape is FOSS software; in fact, she probably doesn’t even know what FOSS is. It’s irrelevant to her. She loves the fact that Inkscape is freely available, which is one of the great features of FOSS software — but beyond that, the concept of FOSS just isn’t meaningful to her. Yet.


The Internet has changed the way we ask questions. Billions of people can now go to a web page, ask almost any imaginable question, and get some kind of response — maybe right, maybe dramatically wrong, but some kind of response. It is this experience that is, in no small part, why the word “google” is now a verb. Alice, without realizing it, will quickly move from a “User” of Inkscape to a “Seeker” of information.

Our friend Alice has a problem. She has an Inkscape file with lots of cool images that some of her friends have made, and she wants to use them as part of a new illustration she’s working on. But when she opens that file, and then tries to cut and paste into a new document, Inkscape crashes. Well, it crashes sometimes. And this unpredictability is becoming annoying — so Alice goes to her favorite online anime discussion forum to ask her friends if they’re seeing this problem.

One friend recommends that she go ask on the Inkscape developers mailing list. Another friend recommends that she file a bug. A third friend asks for more details: when does it happen? Does it happen randomly, or can she make it happen by doing a particular thing over and over? Then another person pops up and says that yes, he’s had that problem too, but he works around it by opening his documents in a certain order. After some back-and-forth with this new friend, trying to figure out exactly what he means, Alice figures out the workaround: no more crashes! Alice thanks everyone for their help and gets back to her project.

Alice has become a seeker. By looking for answers, Alice has discovered a broad community of people who are willing to help her figure out how to do things a better way.


This bug still bugs Alice.

When she forgets about the workaround, the bug still bites her. Lately, some of the other people who hang out on her anime forums have been complaining about this bug, too, and she always points them to the forum thread where she learned about the workaround. But still she wonders: when is it going to get fixed?

And then she wonders: is there anything I can do about it?

This crucial step is what makes FOSS unique: it’s the step at which Alice decides to become a collaborator.

Why? Good question. Contributors to FOSS have many different reasons — but a frequently heard rationale is the desire to “scratch an itch.” Alice loves Inkscape, but she hates this bug.

She thinks back to the forum discussion in which one of her friends advised her to “file a bug.” She’s not even quite sure what that means, exactly, but now that she’s decided she wants to help, she starts looking around. After a bit of googling and sorting through some stuff that doesn’t make any sense to her at all, she finds a page on the Inkscape wiki that tells her what to do.

One sentence stands out: “Check the bug tracker first; your bug may be already there.” So she goes to the Inkscape bug tracker and searches for “crash”, and finds a ton of bugs — seems like software crashes a lot! She tries a few more search terms (like “copy” and “paste”), and the number of bugs she has to look through starts to drop. Alice’s search through the bugs uncovers a great deal that she doesn’t quite understand… until she finds a bug that looks almost exactly like her bug! She sees some comments on the bug that say things like “I’ve confirmed this on my Ubuntu system” and so on — so she creates an account for the Inkscape bug tracker, and adds her comment, confirming that she, too, has experienced this bug on her Mac Powerbook. Two months later, she receives an email that the latest version will contain a fix.

Even a seemingly small collaboration can be useful.


The line between collaborator and contributor can be a blurry line, and there are many ways to define contribution, but here’s one good way of thinking about it: a contributor is a person that a FOSS community actively relies upon for help.

Of course, some contributors focus on writing code — but for the most successful projects, this is a comparatively small percentage of contributors. Some contributors maintain a wiki and help keep it up to date. Some contributors test every new beta version the day it’s released. Some write documentation about the project. Some go through bug reports, to make sure that bugs are useful for developers. Some blog about the new features to help spread the word.

All of these contributors are making their projects better — and every FOSS project needs more of these kinds of contributors.

It is our hope that this book will help guide you, the reader, to the top of the Contributor Mountain.

Building Your FOSS Portfolio

Perhaps the greatest benefit of contributing to FOSS projects: you have the opportunity prove, to yourself and to others, that you can usefully contribute to real software projects. You will meet and interact with other developers, some of whom work on FOSS projects for a living. If you can help them solve their problems, they are inclined to help you solve yours — with advice, contacts, recommendation letters, and maybe even job offers.

One of the big differences between working in FOSS and working on proprietary software is that your work is visible to anyone who cares to look. Every mailing list post you write, every blog entry you post, every bug you file, every wiki page you edit, and every line of code you write, are available for anyone’s inspection.

This a huge potential advantage, if you know how to use it. In the coming chapters, as you begin to engage with your chosen FOSS project, we point out portfolio building opportunities.

Really, though, the portfolio should be a side effect. If you choose a project that matters to you, and if you work hard to help that project achieve its goals, then your portfolio builds itself.

Exercise – Learn about a project’s leaders

Revisit the project you blogged about in (XREF) Exercise 1.1, and spend some time figuring out who some of the project leaders are. Read through the project wiki, mailing lists, and so on. What can you find out about the project leaders? What information do they make available about themselves? Given what you’ve read, what do you think about their work?

Exercise – Write your own FOSS bio

Find an online wiki provider — Wikispaces, for example — and create a wiki page that will become your online FOSS portfolio. Write a little bit about yourself. Link to content: your resume, your blog, your Twitter account, or anything that might be relevant to potential employers. You will use this portfolio extensively over the course of this book.

Supplemental Materials

The Cathedral and The Bazaar is a great story about the FOSS principles in action. Written originally in 1998 by Eric S. Raymond, it’s considered a must-read by many FOSS practitioners.