2009/2/20 Janne Jalkanen <janne.jalka...@iki.fi>: >> My pet hypothesis (or maybe I'm just looking for excuses) is >> this: UIMA is heavily used in academia. Now academics have no >> problems with open source, to the contrary. But they have an >> overwhelming need to publish and build up a reputation. So >> they like to publish their source code on their own web site, >> where it's clear it's their work, rather than contribute to >> some community effort. If you look around, you'll see all >> manner of university efforts around UIMA, but very little of >> that code finds its way back into the ASF repo. > > FWIW, I've noticed this with JSPWiki too - there are at least three > (maybe four-five) separate forks of the JSPWiki codebase within the > academia, with little contribution back to us.
I'm the manager of an open source advisory service for the UK higher and further education sector. So I have frst hand experience of the problems in academia. The analysis as expressed above does not match my own findings (for the UK). There is more to it than this. Academics do indeed rely on reputation and publication and this does, in some circumstances, result in code being held back. However, where code is published on their own site this has nothing to do with publication and reputation and everything to do with a lack of understanding about how open source works. It's a cultural issue. In the academic world it is felt that they know how to do open development, after all they've been doing it for tens of hundreds of years in the scientific disciplines. However, in scientific research the openness is in crediting the authors of the initial work, not in building on the body of work directly. Thus the culture is to fork open source code rather than work with open source code. A second issue is that academic funding is short term. Typically a project wil be funded for 1-2 years at a time (possibly with extension funding). This has two effects. Firstly, there is no interest in long term sustainability of the project outputs (other than published papers) and secondly there are no resources to work with the original donor project. These two things combined mean that there is no motivation to engage with the original project. My organisation is trying to address this directly in the UK. If any ASF project finds that a UK academic project is working with their code but not with the community please feel to contact us via i...@oss-watch.ac.uk. We have resources to help bridge this divide. > There are a few additional reasons for this: > > * The authors feel that their code is not mature enough for inclusion, > and often they may be right - code is created to solve a specific > problem and on a proof-of-concept level with little regard to > e.g. maintainability. This is also true. We (the ASF) need to work directly with academics to make them understand that some code is better than no code in many situations. We need to make them feel comfortable in our environment. > * Often, the forks are not maintained after the paper is completed and > published. The authors move to different subjects, and have little > interest to keep working on the codebase (which might be needed in > case of invasive modifications) Yes, see my similar comments above with respect to funding periods. > * It brings them no benefit to contribute back, since there is little > attachment to the project itself. What's important is their > modifications; the project itself is just necessary noise which > allows them to tinker with their grand ideas. Again, this is largely true. Although it is changing slowy (at least in the UK). My day job focusses on community engagement and recognition within the academic sectors. As above any project that is attracting interest in the UK education sector should contact my day job tream - i...@oss-watch.ac.uk. We may be able to help. Ross -- -- Ross Gardler OSS Watch - awareness and understanding of open source software development and use in education http://www.oss-watch.ac.uk --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
