Enclosed is a first draft of the first chapter -- which is perhaps more
foreword than introduction. Will be working on the real First Chapter
later today, with hopes of having a draft done within a few days. At
which point I'll move on to another chapter.
Comments imperiously demanded. :)
* * *
(Assigned To: GregDeKoenigsberg)
(Status: First Draft Completed)
WHY IS THIS BOOK NECESSARY?
In March 2006, David A. Patterson wrote an article for entitled "Computer
science education in the 21st century". In this article -- which, sadly,
you cannot read unless you are an ACM member -- he advocated a few
fundamental changes to computer science education. One of the changes he
advocated: the inclusion of courses in open source software development in
the standard undergraduate computer science curriculum.
David A. Patterson was, at the time, the president of the Association for
Computer Machinery, the world's largest educational and scientific
computing society. One might think that such a clarion call, made by
someone of such obvious influence, would generate a groundswell of
enthusiasm. When such a luminary proclaims "time to teach open source
development," the world of academia must certainly follow, yes?
It's a little more complicated than that.
We've spent a lot of time over the past few years talking to computer
science professors. Mostly we've asked lots of questions -- actually, the
same ones over and over.
1. Do you use open source software in your classes? (Increasingly.)
2. Are your students interested in open source? (Increasingly.)
3. Do you or your students participate in open source software? (Rarely.)
4. Do you teach open source development practices? (Almost never.)
For these last two, the follow-up question is, invariably, why not?
And the answer is, invariably, ''because it's hard''.
There are good reasons why professors don't teach the practice of open
source. It's easy for open source advocates to explain away these reasons.
At a certain point, though, one must accept the idea that most professors
are well-intentioned, but bound by circumstances that make it
frustratingly difficult to introduce students to open source development.
So why bother?
The answer is simple: the skills required to succeed in an open source
software project are the exact same skills required to succeed in any
large software project. The biggest difference is that, with just a bit
of guidance, anyone can build their programming skills in the open source
world.
Our hope is that this textbook helps to provide that guidance to a whole
generation of students.
WHY TRADITIONAL STUDENT PROJECTS ARE INEFFECTIVE
Almost every modern computer science degree program requires its students
to complete a Big Project. Sometimes it's the "Senior Project," and
sometimes it's the "Capstone Project". Whatever it's called, the purpose
of this Big Project is to expose students to "real" software engineering
practices.
In other words: coding with other people. Which, up until this point in a
student's education, is usually strictly discouraged as "cheating".
The problem is that these Big Projects actually tend to focus on extremely
bounded problems. Most of the time, a small team of students works on a
small project for a semester, and the result is, quite naturally, a small
project. Which actually does very little to teach students about Real Big
Projects.
To find Real Big Projects, one must venture out into the world, where
there are Real Big Problems. The real world is full of gigantic
applications that require build systems and revision control and defect
tracking and prioritization of work. They are written in languages that
one may or may not know, by people one may or may not ever meet. And in
order to successfully navigate through these Real Big Projects, the novice
developer must possess one skill above all others: the ability, in the
words of co-author Dave Humphrey, to be "productively lost".
The great advantage of open source, for the learner, is that the Real Big
Projects of the open source world provide unparalleled opportunities to be
"productively lost". Complex codebases are immediately accessible by
anyone who wants to participate. Which is crucial to the learner, since
participating in an activity is by far the most effective way to learn
that activity.
Sooner or later, the coder aspirant must work at scale, with teammates.
Open source provides that opportunity when nothing else can.
USING THIS TEXTBOOK TO GET STARTED
This textbook exists because professors asked for it, but the textbook's
fundamental approach -- teaching the basic skills of open source
development incrementally, through real involvement in meaningful projects
-- should make it suitable for self-learners as well. In either case, the
student should follow three principles to get the most value out of this
textbook.
First, always be contributing. The majority of exercises in this textbook
are designed to lead to direct and useful contributions to a project, no
matter how small. Even a simple act, like adding comments to a part of
the code you don't understand, can add real value to a project; that's the
great thing about community developed software. Contribution matters, and
legitimate contributions, no matter how small, are always welcome.
Second, ask for help when you're stuck. If you have trouble with an
exercise -- and at some point you will -- look to your fellow contributors
for help. Your chosen project will have mechanisms for getting in touch
with the more advanced developers: mailing lists, or IRC channels, or
forums, or all of the above. Communicating with those around you is not
only "not cheating," it's key to establishing greater understanding.
Remember, though: in the real world, people are most likely to help those
who are trying to help themselves. Before you ask someone a question on
IRC, ask the same question of Google. A good rule of thumb: if you can't
figure something out in 15 minutes of searching, it's probably okay to ask
for a bit of help.
And third, be bold. Try things. Break stuff. Don't be afraid to play
around with the code; it's only code, after all, and if you break
something, you can always revert to the previous version. The one
exception: don't commit known broken code to the repository (and don't
worry if you don't know what that means yet; we'll get to that crucial
detail later on.)
A NOTE ON TERMINOLOGY: "FREE" VERSUS "OPEN SOURCE"
This is, first and foremost, a textbook about how to create software
collaboratively, using a community development model.
Some people call the result of such work by the name "free software".
Some people call it "open source software". Some folks call it both:
"free and open source software". Some people throw in "libre" for good
measure, and call it "free/libre open source software". Frequently one
will see these abbreviated into the terms "FOSS" or "FLOSS".
There are valid reasons for the usage of these different terms in
different contexts, but for the sake of simplicity, we will use the term
"open source" exclusively in this book, with the following rationale:
1. The meaning of "free" can be ambiguous in English; it can be read as
either "gratis" (free of charge) or "libre" (liberated). "Free software"
refers to the latter, but is often confused with the former.
2. Acronyms are bad.
3. The difference between the terms, while important from a philosophical
point of view, are negligible from the point of view of the practitioner.
The "why" of participation may vary among the various communities, but the
"how" does not.
In closing, let us offer the wisdom of Richard Stallman:
The term “open source” software is used by some people to mean more or
less the same category as free software. It is not exactly the same class
of software: they accept some licenses that we consider too restrictive,
and there are free software licenses they have not accepted. However, the
differences in extension of the category are small: nearly all free
software is open source, and nearly all open source software is free.
Enough of the pep talk. It's time to get started.
--
Computer Science professors should be teaching open source.
Help make it happen. Visit http://teachingopensource.org.
_______________________________________________
tos mailing list
[email protected]
http://teachingopensource.org/mailman/listinfo/tos
