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

Greg DeKoenigsberg gdk at redhat.com
Tue Sep 8 13:16:34 UTC 2009


On Sun, 6 Sep 2009, Matthew Jadud wrote:

> Hi all,
>
> This is not meant to be tongue-in-cheek, nor is it critical of MJ
> Ray's comments. I personally think this serves as a wonderful
> highlight of something that students engaging in open projects will
> likely encounter and, potentially, be unprepared for. David H., Chris
> T. or others who have spent substantial time throwing students into
> the *OSS space will know better than I.
>
> On Sun, Sep 6, 2009 at 13:15, MJ Ray<mjr at phonecoop.coop> wrote:
>> Greg DeKoenigsberg <gdk at redhat.com> wrote: [...]
>> and if the current exclusive approach prevails, the book will have to
>> be forked to be useful to my groups anyway.
>
> Should there be an appendix on "holy wars" and zealotry in the world
> of open-source projects? This is something that students coming into
> open projects may not be ready for: the fact that someone, at the
> start of a process, might be willing (or even eager) to walk away from
> the group's work over definitions and terminology, the choice of
> programming language, and so on. Each community has their own
> standards for discourse and contribution, and requires you to be more
> or less fireproof. The Scheme community, for example, requires
> kevlar-plated asbestos on a good day. ;)
>
> What strategies do you use to placate/include/encourage/support
> differing points of view over what are typically considered the topics
> of holy wars? (I'm over-simplifying; please don't take this as a point
> to mince words...) For example, MJ has just suggested that if his POV
> is not honored, he'll walk away from this particular project, and
> perhaps fork it later to suit his own needs.
>
> At the end of the day, this is actually a fundamental part of the open
> culture: you can fork it and have your own sandbox to play in. Some
> projects don't have clear guidelines about participation and
> inclusion, while others do:  for example, I have always liked the
> Subversion team's approach: your name is never in the code, so if you
> submit work and insist on individual attribution in the source, we'll
> throw away your patch. (I think I'm remembering that correctly.) This
> clear, simple project guideline gives the team a way to enforce that
> contributors check their ego at the door, and makes it clear what one
> fundamental rule is for playing in their sandbox.
>
> There's a half-dozen different directions these kinds of conversations
> can go, and being prepared for deeply held beliefs and religion in
> this space is part of the game. Does the text address it anywhere (it
> shouldn't be in the introduction), and would this be a welcome
> contribution that may, or may not, find its way into an appendix of
> sorts?

Yes, this is precisely the angle I hope to take.  This is material for the 
end of the book, not the beginning of the book.

If there's a preponderance of the *authors of the book* who agree with 
MJ's opinion, I'm willing to reconsider.  But until I hear that 
preponderance, the policy as defined in the foreword remains as is.

--g

--
Computer Science professors should be teaching open source.
Help make it happen.   Visit http://teachingopensource.org.



More information about the tos mailing list