[TOS] Bridging research and implementation in open source

[Greg Hislop]

Dave - 

I like your three groups model.  I think it's sensible and worth pursuing. 
 Having said that, I think the motivation issues for the faculty still 
remain.  While those of us that lean toward practical application might 
think that your "research" group would want to advise on how to implement 
their results, many researchers simply do not care about implementation. 
And perhaps more importantly, any time spend advising for implementation 
is likely to take away from further research, and not likely to advance 
tenure and promotion cases.  Similarly, for the third group, the teachers, 
time spent on open source may be hard to come by for a teaching faculty 
member.  The root problem here is that most faculty are pretty stretched, 
and the reward systems faculty work under are very narrowly defined.

I'd also note that your three group model reminds me of Boyer's 4 
scholarships model.  (Boyer, Ernest L. “Scholarship Reconsidered: 
Priorities of the Professoriate” The Carnegie Foundation for the 
Advancement of Teaching.  1990.)  Your group 1, researchers, lines up with 
Boyer's scholarship of discovery; Group 2 with Boyer's scholarship of 
integration, and Group 3 is related to scholarship of teaching.  Your 
group-spanning "connective tissue" people even relate somewhat to Boyer's 
fourth scholarship, scholarship of integration. 

The Boyer work was triggered to a large extent by the narrowing of the 
reward system for higher education faculty that occurred starting around 
1940.  The result is to define "scholarship" as being almost exclusively 
"research" (scholarship of discovery).  Boyer argues for recognition of 
his other 3 scholarships as being equally valid as scholarship that should 
be rewarded.  The Boyer model is highly cited, but it hasn't had the major 
impact on higher education that one might have hoped.  If this model had 
been widely and sincerely adopted, we might not be having this discussion.

Cheers,

Greg Hislop

tos-bounces at teachingopensource.org wrote on 03/20/2009 10:25:45 AM:

> 
> We've been discussing this in the Mozilla context for a bit now, and I 
> have some thoughts, again inspired by the fact that I think we want to 
> leverage what we are/have in order to build what we need.  Here are the 
> facts as I see them:
> 
> 1) Many profs/researchers are doing specific work on X, and aren't 
> particularly interested in applied work--they write papers instead of 
> code (this isn't universally true, I know, but it is the general case).
> 
> 2) Many projects (I'll speak for Mozilla) are working on hard research 
> type problems (JIT, static analysis, cache architecture, HCI) 
> specifically from an implementation/engineering point of view.  That is, 

> they often don't write papers but code.
> 
> 3) Many profs/students are looking for project work in open source for 
> their students.
> 
> I have observed that these three groups often remain separate.  I know 
> open source developers who are working on things you'd think researchers 

> would care about, but can't attract attention.  I know researchers who 
> are doing work that should find its way into open source projects, but 
> doesn't.  I know profs/students who work on toy projects instead of real 

> work.
> 
> Now I leave the realm of fact for an idea :)  What if we help bridge the 

> gap between these worlds, and connect them?  What if we help to create 
> partnerships where we take on the "engineering exercise" that flows from 

> primary research?
> 
> Let's say you're a researcher with interesting ideas about cache 
> architecture, and over here is Mozilla with a vehicle for your work to 
> reach hundreds of millions of users *and* over here is a group of 
> students in India and some more in Toronto and Denmark who want to work 
> on something real.  These groups currently can't work together very 
easily:
> 
> * The researcher (typically) doesn't want to do implementation.  It's 
> hard work (hard in a different way than the paper she just wrote), and 
> won't necessarily further her career at the university.  But, she knows 
> all the theory and could explain it to someone else.
> 
> * The open source project would be interested in the project, but 
> doesn't have the resources to try the experiment.  They do have the 
> knowledge of how you'd do it though, and could advise people.
> 
> * The prof/students studying software engineering or doing a capstone 
> project don't know the researcher or the open source project, and 
> certainly can't connect those dots on their own.  But they have energy 
> and the need to write some code (i.e., they are being marked).
> 
> What's needed here is a body that knows all 3 groups, and can provide 
> the connective tissue to make this partnership happen.  From experience 
> doing partnerships between the 2nd (open source) and 3rd (students) 
> groups, I know that this can work.  I've never tried with all three, 
though.
> 
> This idea would depend on collaboration between a large and diverse 
> group: you need people who know the researcher and can speak her 
> language; people who know the project and can determine if this has 
> value and would get accepted; people who know how to get answers to 
> implementation questions within the project; people who could work with 
> students to do the actual work.
> 
> I'm someone who is capable of working at the bottom of that stack, but 
> I'm not a CS researcher.  I know there are those on this list who are.
> 
> What do you think?
> 
> Dave
> 
> _______________________________________________
> tos mailing list
> tos at teachingopensource.org
> http://teachingopensource.org/mailman/listinfo/tos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://teachingopensource.org/pipermail/tos/attachments/20090320/b192b14b/attachment-0002.html>