2011/9/4 Heidi Ellis <heidijcel...@gmail.com>: > 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 >
Hi Heidi, Sorry for the delayed response, I've been traveling a bit, and not had an abundance of time to respond. Sadly, I don't think that your experiences are far outside the norm. My experience, from the other side of the table - helping and watching students, classes, and profs participating in F/LOSS projects leads me to the following conclusions: The F/LOSS project developers you are working with: * Assume you possess a lot of knowledge that you don't, and honestly have no idea what you don't know, so they can't begin to know to tell you. * Assumes that the level of difficulty for any given project is substantially lower than it really is. (related to the above point.) * Typically don't have good documentation of how to most easily get started, or even if they do, it's still filled with assumptions. * Realize that failure is just a part of the 'game' and don't realize the impact of failure to you, in fact they will actively go out of their way to help you fail. (and be perfectly good intentioned in doing so) The professors/classes/students: * Assume (or default to) lots of platform choices - and that the simple things will be so ubiquitous that it won't be an issue to transfer to a different platform. * Don't push back hard enough or soon enough when things start getting hinky. * Don't realize that very often a project's community will _help_ them do things that might be sub-optimal or even inevitable to fail. * Don't communicate enough (in quantity or frequency) I've talked to lots of folks far smarter than I, and with far more experience in this realm (though they might now disown me if I cite their names for my crazy ideas, especially the ones on this list. :) ). I have lots of horror stories that I have contributed to sadly, but I think there are some common themes missing, when I think about the folks I consider fabulously successful, and the folks that have been only marginally so. Now that you are doing everything wrong, or that I know all of the right answers (I've had far far more failures in interacting with academics than I have successes), but I think you need to protect yourself against people who don't understand the differences between the academic world and the open source world. And even those who do grok that difference will occasionally slip. So in your instance, I would likely have asked/done: 1. What platform is best to develop on? (and I don't mean just the OS, what editor are most working with (or at least the person who is liaising with you) 2. Is it ok to virtualize? (in your case specifically, I am imagining that Gnome 3 went to fallback mode, and then there is the entire 'will usb hardware behave the same or even at all' question when virtualized) 3. Can I work in parallel with you(the upstream liaison) on a simple bug related to $project first. 4. Don't ask how to do things - they will give you a literal answer to your question (i.e. how do I shoot myself in the foot? Well, you aim at your foot with the sights, and slowly squeeze the trigger.) Instead, ask far simpler questions, and ask what they would do. (i.e. If you were starting on this from scratch, what would your environment look like? - Oh, you'd use linux, what distribution of Linux would you use?, etc etc) I imagine you spent lots of time asking how to get Gnome3 working on Ubuntu, and probably received great answers, but the question had some implicit assumptions. 5. Constantly update status, talk about what you are doing, and by definition do most of this in the community's IRC channel. I think I suggested that the students/classes that I saw as successful needed to spend 1/2 of their time talking about what they were doing/going to do with that community in IRC and on mailing lists. Incidentally Walter Bender thought that my percentage was ridiculously low IIRC. That does mean that the tasks (because they will be spending so little time actually doing 'the work') will have to be relatively small. --David _______________________________________________ tos mailing list tos@teachingopensource.org http://lists.teachingopensource.org/mailman/listinfo/tos
