User:Quaid/Textbook/Introduction to Free and Open Source Software

From The_Open_Source_Way

< User:Quaid(Difference between revisions)
Jump to: navigation, search
(testing what it would be like to copy in TOS content so I can render from here)
(final content)
 
Line 1: Line 1:
 +
By Greg DeKoenigsberg
 +
__NOTOC__
__NOTOC__
-
= 1. Introduction to Free and Open Source Software =
+
== Introduction ==
-
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.
+
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 will examine these details later in the book.  For now, we will focus on this simple idea: the freedom to share source code is the essential element of free and open source software.
+
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:
At the end of this chapter, you should:
-
* Understand the difference between "source code" and "binary code";
+
* Understand the difference between ''source code'' and ''binary code'';
* Understand some of the benefits of using FOSS;
* Understand some of the benefits of using FOSS;
* Understand some of the benefits of participating in FOSS projects;
* Understand some of the benefits of participating in FOSS projects;
Line 15: Line 17:
* Have the beginning of your own FOSS portfolio.
* Have the beginning of your own FOSS portfolio.
-
+
== Why does FOSS matter to me? ==
-
== 1.1. Why does FOSS matter to me? ==
+
-
Free and Open Source Software matters because it's real, and because you, the student, can see into the guts of it.  And when you go out into the real world, looking for a job as a Real Software Developer, you will have a tremendous advantage if you can prove that you have experience in real software projects -- ugly, messy, confusing, gigantic software projects.
+
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 permission, to source code.  For students, that access is usually limited to those who can get internships or co-op programs, and not everyone will have access to those opportunities. (Also, once you get an internship, your work is only visible to people in that one company.)
+
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 large software projects.
+
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.
-
For example: how do fifteen programmers work on the same piece of software together?  When two programmers decide to change the same line of code, what happens?  Without version control, it's a disaster.  Which is why we will cover version control in the chapter entitled "Getting the Code: Source Code Management".
+
=== 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".
-
Or another example: complex software is built in different modules.  One software project may import dozens, or even hundreds, of previously build 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 will cover build management in the chapter entitled "Building the Code: From Source to Executable".
+
=== Build Systems ===
-
There's also a lot more to good software than code. How do you make sure people have the resources and knowledge that 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 will cover documentation in the chapter entitled "Explaining the Code: the Art of Documentation".
+
Complex software is built in different ''modules''. Those modules have different names in every language -- ''packages'', ''libraries'', 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".
-
Also: most code is buggy.  Even the very best code can still have bugs, which means that 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 will cover bug hunting in the chapter entitled "Debugging the Code: Finding and Reporting Bugs", and we will cover the mechanics of fixing code in the chapter entitled "Fixing the Code: Patches Welcome".
+
=== Documentation ===
-
One of the greatest things about FOSS is that you have the freedom build upon a piece of software to make it do new and interesting things. Which is why we will cover the addition of new code in the chapter entitled "Expanding the Code: Adding New Features".
+
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".
-
By the time you've gone through this textbook, you will be familiar with the basic tools of the trade for open source software projects -- which also happen to be the tools of the trade for all large, complicated software projects.
+
=== Tracking Bugs ===
-
Will these skills be valuable? That depends on how you choose to use them.
+
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".
-
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.  
+
=== 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.
The key is to find a project that interests you.
-
=== Exercise 1.1. Finding a cool project ===
+
=== 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.  Find a project that you might be willing to work on, and then write a blog post about it, explaining why it's interesting to you.
+
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.   
-
If you don't have a blog, set one up for free!  Visit blogger.com or wordpress.com; setting up a new blog is easy and fun, and a great way to share what you're doing in the FOSS world.
+
# 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.
 +
# 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.
 +
# 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.
-
== 1.2. What is source code? ==
+
If you don't have a blog, set one up for free!  Visit [http://blogger.com Blogger] or [http://wordpress.com 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!
-
Let's start with an explanation of "source code".  One cannot understand "open source" without first understanding "source".
+
== 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.
Source code is a set of instructions for computers that is meant to be read and written by humans.
Line 56: Line 64:
Here's an example of source code, in the C programming language, for a simple, but complete, program.
Here's an example of source code, in the C programming language, for a simple, but complete, program.
-
<code>
+
<pre>
#include <stdio.h>
#include <stdio.h>
main() { for(;;) { printf ("Hello World!\n"); } }
main() { for(;;) { printf ("Hello World!\n"); } }
-
</code>
+
</pre>
 +
 
 +
In order to run this program, it must be compiled into machine code.  First, we save the program into a file called <code>hello.c</code>. Then, we compile it:
 +
 
 +
<pre>
 +
gcc -o hello hello.c
 +
</pre>
 +
 
 +
The command is <code>gcc</code>, which stands for "GNU Compiler Collection." The flag <code>-o</code> sets the name of the program that we are about to generate; here, we've decided to call it <code>hello</code>. The last argument is the name of the source file that we want to compile (<code>hello.c</code>). After compiling the program, you should be able to run it. To run the program, type:
 +
 
 +
<pre>
 +
./hello
 +
</pre>
 +
 
 +
at the prompt. This says "run the program called <code>hello</code> that is in the current directory." When run, this program will print <code>Hello World!</code> 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: <code>hello.c</code>, the source code,  and <code>hello</code>, the program binary. That binary is a piece of that machine code. You can open it with a program called <code>hexdump</code> that will let you see the binary in a hexidecimal form. You can do this yourself on the command line:
 +
 
 +
<pre>
 +
hexdump hello
 +
</pre>
-
In order to run this program, it must be compiled into machine code.  Here's what a piece of that machine code, also called a program binary, looks like when viewed in hexdump, after compilation by the GNU C compiler:
+
We've reproduced some of what it looks like when <code>hello</code> is viewed in <code>hexdump</code> after <code>hello.c</code> has been compiled by <code>gcc</code>:
-
<code>
+
<pre>
0000000 457f 464c 0101 0001 0000 0000 0000 0000
0000000 457f 464c 0101 0001 0000 0000 0000 0000
0000010 0002 0003 0001 0000 8300 0804 0034 0000
0000010 0002 0003 0001 0000 8300 0804 0034 0000
Line 96: Line 124:
00001e0 0000 0000 0000 0000 0012 0000 001a 0000
00001e0 0000 0000 0000 0000 0012 0000 001a 0000
00001f0 848c 0804 0004 0000 0011 000f 5f00 675f
00001f0 848c 0804 0004 0000 0011 000f 5f00 675f
-
</code>
+
</pre>
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.
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.
+
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.
+
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 1.2.1. ===
+
=== 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.
+
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.
-
=== Exercise 1.2.2. ===
+
=== Optional Exercise - Change the binary code ===
-
Change the binary code to print out "open source is awesome" instead of "hello world". Spend no more than half an hour on this exercise.
+
Change the binary code to print out "FOSS ROXORS!" instead of "Hello World!". Spend no more than half a day on this exercise.
-
== 1.3. Source Code: To Share, or Not To Share? ==
+
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 <code>hexedit</code>. 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 <code>hexedit</code> by reading the manpage, which you can get to by typing <code>man hexedit</code> on the command line, or pressing '''F1''' while running <code>hexedit</code>.
 +
 
 +
== Source Code: To Share, or Not To Share? ==
Obviously, not all software is FOSS.  
Obviously, not all software is FOSS.  
Line 116: Line 146:
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.
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 now, but if it breaks, or if you think of a way to make it better, there's no good way to start fixing 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.
+
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, many companies who are selling commercial software don't want that to happen, which is fair enough.
+
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.
-
Still, the world of programmers gets bigger every day, and more and more programmers are writing software that isn't going to be shrinkwrapped in a box and sold to someone else.  More programmers than ever are writing software to solve their own problems -- and for these programmers, sharing can provide a distinct advantage.
+
=== The value of sharing ===
-
That's not to say that programmers who write open source software can never make money.  Some of the most successful companies in the world use open source software to power their businesses.  Google, Amazon, Wall Street -- some of the world's largest and most innovative companies and industries are writing software using the FOSS every day.  They don't sell that code; they share it, and by sharing, create more value for their businesses.
+
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.
-
FOSS development practices can provide many clear advantages over proprietary software development practices.  Among them:
+
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 often doubly expensive.  In the FOSS model, the cost of writing and maintaining the software can be spread out over several individuals and/or companies.
+
* '''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.
+
* '''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.
-
* (Potentially) 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 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 that has many developers, both commercial and independent, which creates better software than any of its proprietary counterparts.  
+
* '''(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 [http://news.netcraft.com/archives/web_server_survey.html demonstrably more popular] and arguably better software than any of its proprietary counterparts.  
-
* The software can outlive the 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 could continue to extend them for 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 the programs anymore.  There's a word for this kind of software: abandonware.  In open source, 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.  
+
* '''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 developer resources and confuse users.  However, a number of FOSS projects have benefited greatly from forks; the X.org server and Inkscape are notable successful forks.
+
* '''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 [http://en.wikipedia.org/wiki/XFree86#Forks_of_XFree86 X.org server] and [http://en.wikipedia.org/wiki/Inkscape Inkscape] are notable successful forks.
-
=== Exercise 1.3.1. ===  
+
=== Exercise - List of software ===  
-
Create a list of all the software that you use on a regular basis.  Which is FOSS?  Which have FOSS equivalents?  What are they?
+
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 1.3.2. ===
+
=== Exercise - Compare and contrast similar proprietary and FOSS software  ===
-
Choose one piece of proprietary software product that you use regularly, and find its FOSS equivalent. Write a blog post comparing the two.  Don't just look at the code - look at the entire experience. What about the UI, the documentation, the bugginess of the software (can you find complaints on forums, bug reports, etc?) What would it take to switch?
+
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?)  
-
=== Exercise 1.3.3. ===
+
What, in your estimation, would it take for a new user to switch from the proprietary, closed-source software to the FOSS equivalent?
-
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 will come in handy during later exercises.
+
-
== 1.4. Climbing Contributor Mountain ==
+
=== 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.
-
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 newbie takes up Contributor Mountain.
+
== Climbing Contributor Mountain ==
-
=== Figure 1.4. 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.
-
[ FIXME: image of mountain with user / seeker / collaborator / contributor ]
+
[[Image:Contributor_Mountain-0.1.png]]
-
=== 1.4.1. User ===
+
=== User ===
-
Everyone begins at the base of the mountain, as a user of software.  
+
Everyone begins at the base of the mountain as a user of software. Let's take our hypothetical friend Alice as an example.
-
Here's a point that developers sometimes forget: users are why software exists.  The best developers always understand why users need the software they write -- which is why contributors in the FOSS world almost always begin as users.
+
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.  
-
 
+
-
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.  
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.
+
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.
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.
-
=== 1.4.2. Seeker ===
+
=== Seeker ===
-
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.  There's a reason that the word "Google" has become a verb.
+
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's got 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 Inkscape document, Inkscape crashes.  Sometimes, anywayIt's starting to be annoying -- so Alice goes to her favorite online anime discussion forum to ask her friends if they're seeing this problem.  
+
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.
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.
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.
-
 
+
 
-
=== 1.4.3. Collaborator ===
+
=== Collaborator ===
This bug still bugs Alice.  
This bug still bugs Alice.  
Line 185: Line 211:
This crucial step is what makes FOSS unique: it's the step at which Alice decides to become a collaborator.
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.
+
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.  
+
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!  Alice looks through all of the bugs, largely filled with stuff 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.
+
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.
+
Even a seemingly small collaboration can be useful.
-
=== 1.4.4. Contributor ===
+
=== Contributor ===
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.
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 the software itself.  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.  
+
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.
-
Every FOSS project can use more of these kinds of contributors.
+
All of these contributors are making their projects better -- and '''every FOSS project needs more of these kinds of contributors.'''
-
The entire purpose of this book is to help guide you, the reader, to the top of Contributor Mountain.
+
It is our hope that this book will help guide you, the reader, to the top of the Contributor Mountain.
-
== 1.5. Building Your FOSS Portfolio ==
+
== Building Your FOSS Portfolio ==
-
Perhaps the greatest benefit of contributing to FOSS projects: you will 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 will be working on FOSS projects for a living.  If you can help them solve their problems, they will be inclined to help you solve yours -- with advice, contacts, recommendation letters, and maybe even job offers.
+
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, will all be available for anyone's inspection.
+
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 is 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 will point out portfolio building opportunities.
+
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 will build itself.  
+
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 1.5.1. ===  
+
=== Exercise - Learn about a project's leaders ===  
-
Revisit the project you blogged about in 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?
+
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 1.5.2. ===
+
=== 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.
+
Find an online wiki provider -- [http://www.wikispaces.com/ 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.
-
== 1.6. Supplemental Materials ==
+
== 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.
+
[http://www.catb.org/~esr/writings/homesteading/ 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.

Latest revision as of 19:50, 26 March 2010

By Greg DeKoenigsberg


Introduction

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 -- packages, libraries, 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".

Documentation

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:

./hello

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 X.org 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.

File:Contributor Mountain-0.1.png

User

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.

Seeker

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.

Collaborator

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.

Contributor

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.

Personal tools