FOSS thinking vs academic thinking

March 7, 2012 – 11:32 am

I want to come back to Seb’s blog post here because he’s given the best summary of the open source mentality in one paragraph that I’ve seen yet.

“I’m going to try to build a totally great new thing. It’s going to be a lot of work, salve but it will be worth it because it’s going to be so useful and cool. Gosh, it would be helpful if other people worked on it with me, because this is a lonely pursuit and having others work with me will help me know I’m not chasing after a windmill.

If somebody wants to work on it with me, I’m going to try hard to give them what they need to work on it. But hell, even if somebody tells me they used it and found six problems in it, that’s motivating; that gives me something to strive for. It means I have (or had) a user. Users are awesome; they make my heart swell with pride. Also, bonus, having lots of users means people want to pay me for services or hire me or let me give talks.

But it’s not like I’m trying to keep others out of this game, because there is just so much that I wish we could build and not enough time! Come on! Let’s build the future together!”

I wonder what the academic version of this paragraph looks like. Here’s my attempt…

“I’m going to try to build a totally great new thing. It’s going to be a lot of work, but it will be worth it because it’s going to be so useful and cool. Gosh, it would be awful if other people came and stole my idea, so this is going to be a lonely pursuit and having others work with me will only happen if I really trust them; I already know I’m not chasing after a windmill.

If somebody wants to work on it with me, I’m going to figure out if I can trust them, then work out the arrangements of our secure, long-term commitment, then give them what they need to work on it. And we have to keep this secret – if somebody tells me they used it and found six problems in it, that might keep us from getting published. Users are awesome, but only when we’re ready for them; when they do things we expect, they make our CVs swell with papers. Also, bonus, having lots of papers means people want to give me tenure or let me give talks.

But it’s not like I’m trying to keep others out of this game, I’m just making sure they do it properly and in a way that doesn’t hurt me, because there’s so much to do and not enough time to deal with crap if it comes up! Come on! Let’s build the future together!”

Know someone who'd appreciate this post?
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • email
  • Identi.ca
  1. 9 Responses to “FOSS thinking vs academic thinking”

  2. Hmm, so I don’t think it’s necessarily that bad (probably worse for industry R&D where you don’t actually own your ideas and can be legally held responsible for so much as leaking meeting notes or a paper draft) but that’s one of the reasons academia is so hard to work with, I think, that there’s such little effort made towards collaboration. Though to be fair, I think only a small part of it is fear of info-stealing. A bigger part may be just reduced effort… like, it requires effort to find someone who actually has the exact same interests as you, who is trying to answer the same (really obscure and probably useless) problem, and then figure out how to carve out work so you don’t step on each other’s toes, but don’t set up too much structure as to impede creativity, but oh wait now he’s/she’s basically gone off in a totally different direction well good for him/her I guess but I don’t want to deviate from my direction… and finally you conclude that wouldn’t it just be easier to let him/her do what he/she wants and you do what you want and you guys just publish different papers and pretend you never saw each other?

    By yifan on Mar 7, 2012

  3. I think you may have a biased view of academia (and a rather unrealistically rosy view of FOSS developers).

    Much academic work is done through collaboration (albeit the complexity of academic research usually precludes casual helpers). Many FOSS projects are run by ***s who no-one would want to work with.

    DDD

    By DDD on Mar 7, 2012

  4. One issue is that academics really aren’t the right people to release and support production-grade software. In part, this is because no academics at any stage of their careers are judged by the quality of software they wrote. Pretenure faculty are judged by papers, and grad students are judged by finishing their dissertations. Very few tenured faculty know how to and are willing to write good open-source software (I have met one or two — Tim Davis at U Florida is an extraordinary example). Writing good software is hard and takes dedication and willingness to learn.

    The way to force academics into the open-source mindset is for journals to require reproducible results, and give their editors the time and resources actually to verify results (as best as possible — obviously this has limitations for performance results on big non-open supercomputers) by downloading, building, and running the code. That way, open-source code actually leads to publications.

    By Mark Hoemmen on Mar 7, 2012

  5. Mark nails it, Mel. Sadly academics aren’t judged by the software they produce no matter how useful and well-designed. If tenure committees started taking into account high quality software developed and not just papers published about it, the situation might change. Meanwhile, time spent on software development instead of publishing is actually detrimental to tenure-track careers.

    By Tanya on Mar 7, 2012

  6. Disclaimer: My experience in academia is primarily in machine learning, with a little bit of robotics, and some substantial time observing biology (genetics).

    While getting scooped on a grant or a paper (or, worse, a thesis) is no fun, I’ve run into a lot less reluctance to share on that front than on others: “Gosh, if anyone want to work with me on this I sure hope they already know what they’re doing, because I’m not really interested in teaching them, writing documentation, or writing reusable code.” It’s not that academic work is any more complex than canonical open-source projects, it’s that the people doing the work are so intensely focused on the frontier. Status and unsupervised communication happen primarily through published works, which are generally limited to describing only the thing that is new — and not any of the building blocks.

    Describing building blocks in a way that fosters unsupervised collaboration (which seems to be the norm for oss? explicit mentorship strikes me as unusual) wastes pages that you could be using to describe “the important part” of the idea. If you don’t have to describe any building blocks, the building blocks don’t have to be of particularly high quality. If the building blocks suck, then if someone else wants to be able to use them, you either have to spend time training them (that you could be spending exploring new ideas) or you grow impatient with anyone not willing to do their own homework.

    By Katie Rivard on Mar 7, 2012

  7. @Mark: Well, there’s jstatsoft. But I think the journal method is limited to software that can be perfected in a relatively short time, like the algorithms which are published there.

    By Alex on Mar 7, 2012

  8. Katie and Mark,

    Yes the publish or perish mentality inherent in the academic culture is a core problem.

    However, the hard reality is until we establish community norms of peer review on scientific analysis software then we as an academic community are failing to adequately peer review all those publications. The peer review process is failing and that failure is accelerating as our dataset get larger and our digital tools more complicated.

    We a standing on top of a house of cards built up over the last 20 years and the result is a lot of junk science output that has simply not be adequately reviewed and is impossible to quantifiable test for repeat-ability.

    There was a great editorial in Nature recently:
    http://www.nature.com/nature/journal/v482/n7386/full/nature10836.html

    It seems that younger tenure and tenure track faculty understand the necessity of peer review of digital tools. There solution here is partly generational turn over in the community and that takes times. The academic community will continue to lag behind a bit, but change is coming.

    -jef

    By Dr. Jef Spaleta on Mar 7, 2012

  9. @Dr. Jef: One collaborator has been leaning on our open-source project to back-patch bug releases more aggressively, since their journal requires source code. (They mean that they have to be able to go to a public web site and download it somehow. We only do tarballs for public releases and don’t (yet) offer public access to our git repository.) I see this as a promising sign, since he’s a physicist, publishing on physics research.

    My mentor is editor-in-chief of ACM Transactions on Mathematical Software (TOMS). TOMS “algorithm papers” (see http://toms.acm.org/Authors.html) submissions must include source code, with strict requirements: http://toms.acm.org/AlgPolicy.html

    By Mark Hoemmen on Mar 11, 2012

  1. 1 Trackback(s)

  2. Mar 8, 2012: Academia vs. FOSS: The Good, The Bad, and the Ugly « Digifesto

What do you think?