Re: A bit of bomb throwing....
 
I am not advocating that research communities drop everything and  
start hacking on open-source projects instead of publishing papers.   
I'm trying to find a way for experimentation and R&D tool development  
already being done (SIMILE, DSpace) to be more closely aligned with  
the existing early adopter communities (Drupal, Wordpress,  
Microformats).
-Zack
On Jan 18, 2006, at 8:09 AM, David Karger wrote:
> I've seen several mentions in this thread of the idea that while  
> the goal of the open source community is to build stuff (clearly a  
> sign of brains and productivity), the goal of academics is to  
> publish papers (clearly some vain form of social parasitism).  As a  
> parasite---er, academic---I assert that in fact both communities  
> have the same goal, which is to make things better than they are  
> now.  We simply have different horizons.  Open source is about the  
> software that you can build right now.  Academia is about the  
> software that you might be able to build 5 or 10 years from now.   
> The reason we write papers is that, by definition, the thing we are  
> describing can't really be built right now.  While research  
> invariably involves building prototypes (such as my group's  
> Haystack client), those prototypes are typically too fragile to  
> deploy for broad use, because they are trying to do something that  
> we don't fully understand how to do yet.
> Some may argue that if you can't build it for real now then there's  
> no point in working on it at all, but I would say this is a lot  
> like driving at night with your headlights off---sure you can see 2  
> feet in front of the car, but is that really sufficient?  You need  
> to try out ideas to see them fail, so you can fix them, and it  
> would really slow progess down if we only tried out ideas that were  
> practical right now.  Under the current research system, by the  
> time something becomes practical, researchers have (hopefully)  
> played around enough with it in its impractical stages to let us  
> know how to build good solutions quickly.  Just to snag one example  
> that appeared on this thread, Timbl's creation of the web didn't  
> just happen; it arose from a background of plenty of previous  
> research on hypertext that did not result in broadly deployed  
> systems, but that did produce a background of ideas that others  
> could draw upon to build new artifacts.
> So yes, academics may suffer enough human vanity to be disappointed  
> when their "pet algorithm is discarded in favor of something better  
> for the product", but that is irrelevant to the broader goal of  
> getting that algorithm out there so that it can be picked up and  
> used 5 years from now when it is just the right thing for the next  
> product.
>
> David Karger
> Professor, EECS
> MIT Computer Science and AI Laboratory
> 32 Vassar St.
> Cambridge, MA 02138
>
> Michael McDougall wrote:
>
>> Zack Rosen wrote:
>>
>>> On Jan 17, 2006, at 1:44 PM, Prokopp, Christian wrote:
>>>
>>>
>>>> It sounds like you are fighting windmills. The modern economy  
>>>> works the
>>>> way it does (early adopter problems etc.) and the university have
>>>> totally different interest than open source communities,  
>>>> companies or
>>>> you and me. No one will change that (soon) for good reasons - it  
>>>> is not
>>>> perfect but the best we know of.
>>>>
>>>
>>> I have yet to hear an explanation for why academic research  
>>> should not be applied towards real world problems in partnership  
>>> with open-source communities other than 'this is just not the way  
>>> things are done in academia'.   Can someone please lay out the  
>>> reasoning for me?
>>>
>>>
>>
>> I thought I made it pretty clear.
>>
>> - Different goals: academics want publishable advances in science,  
>> while open source communities want to create usable tools. Quite  
>> often, you don't need scientific advances to create usable tools,  
>> you just need good engineering and design, which is not at all the  
>> same thing. So an academic may work on the project just to see  
>> their (scientifically legitimate) pet algorithm discarded in favor  
>> of something better for the product. Or conversely, the open- 
>> source developers may feel like they have to include complex  
>> technology that users don't care about just to keep the scientists  
>> happy. Open-source communities generate code, academics generate  
>> papers.
>>
>> - Coordinating with an outside group brings in extra overhead and  
>> extra risk. I mentioned a couple scenarios above. You need to  
>> monitor the mailing lists, and track all the changes that might  
>> impact your research. If something needs to be implemented to fit  
>> with your research project you have to convince other people to  
>> merge that into the project. Like I mentioned above, it's possible  
>> that the community will decide to move the project in a direction  
>> that's bad for your research--what do you do then? What if the  
>> head of the open-source community starts trashing your funding  
>> agency in the national media?
>>
>> I've seen research projects destroyed by these kinds of issues.  
>> It's much easier for a researcher to create a small environment  
>> where they own the code, they know all the people involved, and  
>> everyone is working towards the same end (publishing papers).
>>
>> I'm not saying academics should always hide from the world. If  
>> their research project has common goals with some open-source  
>> community, then maybe the extra overhead and risk is outweighed by  
>> the benefits of real-world experience and users. Certainly, I  
>> would rather see academics extend existing projects than duplicate  
>> existing tools--and this seems to happening more often (there's a  
>> ton of academic projects making Eclipse plugins, for example).  
>> However, I understand that it's not always feasible for an  
>> academic to align their research interests with the interests of  
>> some open-source community.
>>
>> Michael
>>
>> Michael
>>
>
>
Received on Wed Jan 18 2006 - 19:44:52 EST
This archive was generated by hypermail 2.3.0
: Thu Aug 09 2012 - 16:39:18 EDT