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<[email protected]> wrote: >> Greg DeKoenigsberg <[email protected]> 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. _______________________________________________ tos mailing list [email protected] http://teachingopensource.org/mailman/listinfo/tos
