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

From The_Open_Source_Way

You do not have permission to edit this page, for the following reason:

You can view and copy the source of this page:

__NOTOC__ = 1. 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 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. 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. == 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. 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.) 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. 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". 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". 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". 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". 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". 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. Will these skills be valuable? That depends on how you choose to use them. 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 1.1. 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. 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. == 1.2. 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. <code> #include <stdio.h> main() { for(;;) { printf ("Hello World!\n"); } } </code> 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: <code> 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 </code> 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 1.2.1. === 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. === 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. == 1.3. 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 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. 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. 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. 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. FOSS development practices can provide many clear 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. * 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. * 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. * 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. === Exercise 1.3.1. === Create a list of all the software that you use on a regular basis. Which is FOSS? Which have FOSS equivalents? What are they? === Exercise 1.3.2. === 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? === Exercise 1.3.3. === 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 == 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. === Figure 1.4. Contributor Mountain. === [ FIXME: image of mountain with user / seeker / collaborator / contributor ] === 1.4.1. User === Everyone begins at the base of the mountain, as a user of software. 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. 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. 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 === 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. 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, anyway. It'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. 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. === 1.4.3. 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! 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. Even a seemingly small collaboration can be useful. === 1.4.4. 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 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. Every FOSS project can use 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. == 1.5. 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. 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. 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. 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. === Exercise 1.5.1. === 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? === Exercise 1.5.2. === 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. == 1.6. 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.

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