Hi Greg, I totally agree with your perspective on Heidi's and others' concerns about support and time commitments for teaching a single software course using FOSS as a medium.
When I first taught the software course at Bowdoin using the Ronald McDonald House FOSS project in 2008, I spent huge amounts of time in the "ramp-up" phase -- there was no support, and in this case there was no project or code base to rely on. In fact, if I hadn't been just "retired" from my other teaching and faculty duties at Bowdoin, I would have got about as far as Heidi is now, and then would have quit and gone back to a standard Software Engineering textbook with all the exercises built in. But I was lucky not to have anything else on my mind (others who know me would verify that I've been in this state for a long time :-), so my students and I slugged it out and ended up with a successful project. But it was done with about 3 times the amount of work that I would have given to a "normal" CS course. I was also lucky to reconnect with Ralph Morelli at about the same time. Since then, Ralph and I have talked about this experience a lot -- the whole question of sustainability for these types of courses is huge. Among other things, we decided to write a textbook that would sort of "bridge the gap" between the old way of teaching software engineering and the new FOSS way. (You know about the textbook, so I won't go on about that.) The ancillary materials at the book's website myopensoftware.org/textbook are part of the package. Together, they try to help instructors set up a FOSS development team environment for a 1-semester course with relatively little work. The down side of using this textbook and these supporting materials is that they are focussed on only two particular FOSS projects and development platforms -- RMH Homebase and Homeroom, XAMP, Eclipse, and Mercurial. That's not for everyone, but it is fairly useful for a wide range of students who know something about OOP and data structures coming in. And the two FOSS projects are not toy projects -- both are still in productive use at the Ronald McDonald House(s). In any case, I do relate to the pain of teaching such a course but I don't want to appear to be just pitching our textbook! So my suggestion to this discussion thread would be to start a small, quiet TOS working group of instructors who want to work together to find concrete solutions for other instructors in the form of reusable teaching materials, student-friendly FOSS projects, and short guides for setting up different development tools. Maybe that would be a self-selected subset of this TOS list? Is there such a thing as a "TOS working group"? Hope this helps, Allen cc Heidi, Ralph, TOS List On Sep 4, 2011, at 7:13 AM, Heidi Ellis wrote: > Hi Folks, > > Let me start by saying that I’m torn. In the spirit of being open, I was > going to blog these thoughts. But upon reflection, I decided to post them to > this group. I want to use my experience to highlight problems that I think > are major roadblocks for instructors teaching open source, but I really don’t > want to discourage instructors who may read my blog. I also want to state > that I’m posting problems for which I don’t really have any answers. > > I am teaching a software engineering course this fall. I was approached by > the GNOME Assistive Technology community with a cool project involving > magnification of video using Cheese. I decided to explore the project and > initially my concern was lack of knowledge about how video is processed. The > platform for Cheese is GNOME 3. Note that I wrote my dissertation on Unix and > have had some form of Linux on VirtualBox for two years now. I wouldn’t call > myself a Linux expert, but I am relatively knowledgeable. > > So here are the roadblocks. The first is time. I spent at least 80 hours in > August trying to get VirtualBox on XP to host Ubuntu 11.04 with GNOME 3. > After countless installs and uninstalls of VirtualBox and Ubuntu and lots of > banging my head against the wall, someone from the GNOME A11y community > kindly pointed out that Ubuntu and GNOME 3 don’t play well together. OK, > time to retrench… > > I have now spent some 20 hours installing a Fedora 15 guest on VirtualBox. > This only required four different install attempts, but I have at least been > successful. I’ve also spent four hours installing Cheese and I still haven’t > been successful. Panic is setting in. > > The second roadblock is lack of concrete directions. Let me explain. I have > found FOSS communities to be very supportive within that community. However, > what I’m trying to do is get a variety of applications from different > communities to play together. I got my original idea for the project from the > A11y community. In order to get as far as I did with VB/Ubuntu/GNOME 3, I had > to join the VB community, interact with both the Ubuntu and the GNOME > communities. I am also interacting with the Cheese community to get that > installed. I have also spent many hours Googling my specific problems. While > all of these communities have been helpful, many of my questions remain > unanswered. > > The third is changing application during development. I want my students to > be able to make a contribution to a FOSS project. In order to do so, they > must be working on the most recent version of the product. However, this > means that I can’t stabilize the application before class starts, creating a > risk that I’ll be trying to teach students with an application that I can’t > get working. In addition, Updates tend to break things, requiring more time > to figure out what to fix. > > OK, so I am now starting my second week in the semester and I have a working > platform, but have been unable to install the application that I want > students to use and get it running. In addition, I haven’t had any time to > work with the actual application. I consider myself more tolerant of risk in > teaching than many of my peers and much more likely to let students learn in > an environment where I don’t know the answers than most of my peers. This is > definitely panic time!!! > > These are some of the reasons why instructors get a text and follow the > exercises at the end of the chapter and have students work on toy projects. > And I find myself pondering where to go from here. Without any way to know > how much more time and effort it will take to get Cheese to work, I can’t > tell whether to risk continuing. If I don’t continue, what do I do for a > project? I don’t have time to handle the learning curve for a new FOSS > project…. > > It is not my intent to deter folks from involving students in FOSS. Quite the > opposite. But I also think that if we don’t identify and find ways of > handling these sorts of issues, We won’t be able to get more instructors on > board. > > Heidi > > > > > _______________________________________________ > tos mailing list > [email protected] > http://lists.teachingopensource.org/mailman/listinfo/tos On Sep 6, 2011, at 9:30 AM, Gregory Hislop wrote: > I think the evaluation issue for untenured faculty is an excellent point. > But the issue that actually occurred to me first is teaching efficiency. > Time spent learning FOSS or solving FOSS problems takes time away from other > tasks, and faculty time is scarce. Teaching courses as already developed, > and teaching straight out of a text just takes less time. Too much time on > the bleeding edge is likely to leave faculty with not enough time for other > aspects of teaching and scholarship. > > Some faculty are willing to take higher risk paths and pursue things like > student FOSS participation because they see the potential high payoff. Many > faculty will not do that. > > Greg Hislop > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of C. Titus Brown > Sent: Monday, September 05, 2011 11:05 PM > To: Matthew Jadud > Cc: [email protected] > Subject: Re: [TOS] Fwd: An experience report.... > > On Mon, Sep 05, 2011 at 10:58:07PM -0400, Matthew Jadud wrote: >> Hi Ralph, >> >> 2011/9/5 Ralph Morelli <[email protected]>: >>> widespread acceptance of this approach.?? If experienced faculty, such as >>> you and Allen and I, have problems incorporating FOSS into our courses, >>> it's even worse for young faculty who have to worry about tenure. >> >> Could you explain more, for this community, why it is "worse" for >> untenured faculty attempting to integrate FOSS projects into their >> teaching? > > Hi Matt, > > because generally us untenured schlubs are more susceptible to negative > student reviews like "this prof had no idea what they were doing". For > tenured profs, the consequences are generally not so bad unless performance > is consistently bad; for untenured profs, bad performance is (or can be) > factored in to promotion, raises, and teaching assigments more strongly. > > If you have to worry about whether or not your ability to compile *this* > version of the Linux kernel on the fly in front of class is going to > have consequences, along with simply trying to get it to work in the > first place, life will be stressful. > > Personally I've found that my students are pretty happy to watch me fail, > and that they learn the right lessons from it -- that every success is > founded upon many failures. But it's something I work hard to convey, > and if I failed a lot in class I suspect it would make its way onto > evaluations and hence be a subject of my annual review. > > cheers, > --titus > -- > C. Titus Brown, [email protected] > _______________________________________________ > tos mailing list > [email protected] > http://lists.teachingopensource.org/mailman/listinfo/tos > _______________________________________________ > tos mailing list > [email protected] > http://lists.teachingopensource.org/mailman/listinfo/tos _______________________________________________ tos mailing list [email protected] http://lists.teachingopensource.org/mailman/listinfo/tos
