[TOS] An experience report....

David Nalley david at gnsa.us
Mon Sep 12 16:21:34 UTC 2011


2011/9/4 Heidi Ellis <heidijcellis at 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


More information about the tos mailing list