[TOS] Teaching materials, or textbook?
Ross Gardler
ross.gardler at oucs.ox.ac.uk
Wed May 13 19:05:55 UTC 2009
2009/5/11 Greg Dekoenigsberg <gdk at redhat.com>:
...
> The basic conclusion I've come to, and I'd like to hear everyone's thoughts:
>
> A list of resources about teaching open source development is good.
>
> A textbook about teaching open source development is better.
>
> Given limited resources, I'd rather focus on the latter.
My initial response was "use Fogel's book", but your mail neatly
identifies the difference between this book and Fogels Producing Open
Source. I therefore suggest, a textbook supported by links to
community reviewed/rated resources would be the right way to go. The
initial focus being on the book, but in researching the materials for
the book we should start compiling the initial resources list.
> My second question. How would we begin?
>
> So first, everyone agrees on a structure.
>
> I like the structure of Tridge's course, and I think that it would translate
> quite nicely to a textbook structure. A reminder of Tridge's course, for
> those who haven't seen it:
>
> http://cs.anu.edu.au/students/comp8440/lectures.php
I've not reviewed this (I'm catching up on email in my one day in a
fortnight without email, sorry). What I would say is that if it is
there, in use, and has the support of anyone willing to put the effort
into turning it into a book outline then I like it ;-)
> Second, various people agree to take a chapter.
>
> Third, various people agree to write a chapter.
I have experience of collaborative authorship. Put bluntly it is a
real pain. There will be no consistency between authors on a chapter
and no consistency between chapters. What you end up with is an
unreadable document. There is no opportunity for the reader to "get
into" the style of the book (because there is no consistent style).
In my opinion there needs to be a "content and style" editor involved
earlier then your current fifth step. In fact they should be involved
in the first step. Proof reading and the like can happen later though.
However, the job of "content and style" editing is a hugely time
consuming. Especially when one is bringing together a significant
number of contributors as may be the case here.
> Fourth, we ask professors to review it.
>
> Fifth, we edit it.
Who has final say on content? How are conflicts resolved?
If we appoint a couple of "content and style" editors then I'd propose
the benevolent dictator model, with one of the two editors having
veto.
>
> Sixth, we publish it online under a creative commons license.
Which one? This is a huge question, one I will take up when I have
more time if nobody does so. Things to consider:
- we want maximum take up (implies allowing commercial use and
possibly not requiring share alike)
- which jurisdiction? I'd want UK, the majority here are USA, but
significant numbers are other territories (can we allow the user to
select jurisdiction?)
- reuse of existing materials may dictate a varied licence policy
> Seventh, we take it to O'Reilly and use the proceeds to fund the further
> development of TOS. :)
We should take it to O'Reilly the moment we have a decent book outline
and appointed editors. We should have professional help during the
authoring process.
> I think this plan is quite practical. Within six months or less, we could
> have a damned fine textbook.
I think six months is *very* ambitious for a volunteer developed text
book, I think it will take that long to edit it (even if we pay an
editor). However, this comment is not intended to discourage the
effort to drive forwards. By doing so we increase the chances of
delivering in six months and proving me wrong - I like that ;-)
> The question: who's willing to contribute?
Myself, my team and our existing resources are all willing to get
behind this project (assuming a compatible licence strategy), this is
in line with a work package of our current funded work.
Ross
---
Ross Gardler
OSS Watch - supporting open source in education and research
http://www.oss-watch.ac.uk
More information about the tos
mailing list