[TOS] First draft of textbook: introductory chapter (foreword?)

Matthew Jadud mjadud at allegheny.edu
Fri Sep 4 17:46:26 UTC 2009

2009/9/4 Greg DeKoenigsberg <gdk at redhat.com>:
> 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

A student membership is $40, roughly. While I am generally down on
content behind walls, the ACM has done a better job than most in
making their content accessible. Maybe someday it will be completely

In the meantime, could we use the book as an opportunity to get the
ACM to release the article under the CC? Would that be a productive
conversation to have with someone in the ACM? Wearing my "Random J.
Reader" hat, I don't know what your beef is with the ACM, what the ACM
is, why you have to highlight it in the first sentence of the book,

I might be able to do the digging on that, if it doesn't fit on
someone elses. Regardless, I'd stick to a positive/constructive tone.

> David A. Patterson was, at the time, the president of the Association for
> Computer Machinery, the world's largest educational and scientific computing

Perhaps start here. Introduce David first, as it also introduces the
ACM. Then go into the material for the first paragrah.

David A. Patterson was, at the time, the president of the Association
for Computing Machinery... In 2023, he wrote an article...

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

This is where we establish the audience. Is your audience strictly CS
profs? What if I'm CSE? (I suppose the title catches that.) Is the
book going to be of broader interest (eg. to people involved in open
documentation efforts)?

Just checking, really. Mostly, I am noting this was the callout of the audience.

> are well-intentioned, but bound by circumstances that make it frustratingly
> difficult to introduce students to open source development.
> So why bother?

There's a bit of a jump here. But, for the intro, that's probably fine.

> 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

Actually, the skills are those that are required to succeed in any
large project that involves a high degree of communication. But, that
might be the meta-takeaway.

> Our hope is that this textbook helps to provide that guidance to a whole
> generation of students.

I was part of a group that wrote a book called "Studying Programming."
It wasn't about learning to program in Language X---instead, it was a
book about how to go about the activity of learning to program,
regardless of language. Is this a textbook about how to do the
detailed steps of each thing in the outline, or is it more about the
processes? I'm just wondering about the word "textbook." Not a
fully-formed/well-formed thought, either...


They're not ineffective. They're very effective. Just not for what you
want them to be effective for.

They meet ABET guidelines. They don't get you in trouble. They, in a
word, "work." I don't know if you've so firmly established the context
yet that you can claim that the practice of most every reader who
picks up your book is "ineffective."

> it's the "Capstone Project".  Whatever it's called, the purpose of this Big
> Project is to expose students to "real" software engineering practices.

Perhaps just drop "real". " to expose students to software engineering

I like where the rest of this section goes, though.

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

This might address my questions from above.

> Enough of the pep talk.  It's time to get started.


That's some feedback, at a variety of levels. Is this the right space
for this, or should I constrain feedback to the talk page on FLOSS
manuals? For today, I'll make the (possible) mistake of spamming the


More information about the tos mailing list