CodeHosting » History » Version 2
Version 1 (Chris Cannam, 2010-09-20 11:55 AM) → Version 2/5 (Chris Cannam, 2010-09-20 12:20 PM)
h1. The code hosting problem
h2. Assumptions found in my head
* Audio and music research groups in institutions *lack effective access to version control systems*
* This is certainly historically true of C4DM; what about other groups?
* Researchers often want to *share their code selectively* with other researchers in the same field but in other institutions
* Internal code hosting doesn't usually facilitate this
* Individual researchers may be happy to host their code in *existing public hosting services* (e.g. SourceForge, Google Code), but their supervisors are likely to be less keen
* Supervisors External facilities are harder to keep track of; supervisors don't necessarily appreciate these services' like the requirement that everything should be open source, and it's hard to keep track of what work your students are producing
* The opposite dynamic may occur in some places -- researchers may be self-conscious about publishing these facilities won't host private code even when their supervisors encourage them to
_How can we test these assumptions?_
_If these assumptions are correct, how do we solve these problems?_
h3. We could encourage and train institutions to provide better internal code hosting facilities
For example, by providing nice recipes, templates, support etc for setting up well-featured, friendly services. A good code management facility would bring together a version control system with a nice web front-end, project data sharing facilities (wiki etc), a sensible authentication system that doesn't involve a whole new username/password database, etc.
This is certainly likely to improve code development practice in an institution that has no facility at present. But it doesn't really solve the "selective sharing" problem, or help very much with the desire to move toward publication of software and reproduceable research -- unless we can also convince people to make their own internal hosting facility a public one.
Audio and music research groups typically are too small to be successfully running providing their own facilities. To do this well, they really need a horizontal approach -- facilities provided to all research areas by a common CS or IT service. This isn't necessarily the most effective approach if we want to improve search and access specifically to audio-related research code, but it may be the easiest approach to maintain. This is (presumably?) the sort of thing that the general Software Sustainability Institute ought to be exercising itself with.
Some institutions (how many? which?) will have a central system already. How many? Which? Are they happy with it? Can the SSI guess at any of these figures for us? Would the existence of a working, if not ideal, internal facility make a group less likely to accept any other approach that we might propose?
h3. We could encourage this already
_and/or_
# Encourage institutions to make better use of existing external facilities
Researchers are often familiar with services like Google Code, SourceForge, GitHub etc already, and in some cases may use them even for open-source code hosting code that is not really supposed to be published ("yet") if they have a need to share it with one or more individuals at other institutions. If they are comfortable with doing that, why not encourage it -- since it also promotes open publication and has little or no maintenance cost?
The big problem is that it doesn't address private hosting, for projects that are "not yet" ready for publication. It may (perhaps) be attractive to be able to persuade groups that their code should all be public from the start, but it's not very realistic, and in any case it's probably not wise to mix up a technical solution to a practical problem (use of version control during development) with promotion of a philosophical position (code should be published) during advocacy.
Also, keeping track of projects in these external facilities is hard -- both for prospective user/reusers who want to find stuff, and for institutions who want to keep track of the work that their researchers are producing.
All this said, these services work -- we don't want to find ourselves proposing methods that will be less attractive to motivated researchers.
h3. We could provide
_and/or_
# Provide a dedicated middle ground, our own hosting facility
We could provide a new facility that provides private hosting and access control, so that in theory institutions can treat it as an internal facility with the ability to "promote" their projects to (private projects, easily tracked, etc) but can use for public status hosting when desired. they feel able
How could we do each of these?
# Educate decision-makers and about the advantages of open publication,
Advantages and disadvantages of each:
# Takes advantage of free existing facilities, no outlay; *but*
h2. Assumptions found in my head
* Audio and music research groups in institutions *lack effective access to version control systems*
* This is certainly historically true of C4DM; what about other groups?
* Researchers often want to *share their code selectively* with other researchers in the same field but in other institutions
* Internal code hosting doesn't usually facilitate this
* Individual researchers may be happy to host their code in *existing public hosting services* (e.g. SourceForge, Google Code), but their supervisors are likely to be less keen
* Supervisors External facilities are harder to keep track of; supervisors don't necessarily appreciate these services' like the requirement that everything should be open source, and it's hard to keep track of what work your students are producing
* The opposite dynamic may occur in some places -- researchers may be self-conscious about publishing these facilities won't host private code even when their supervisors encourage them to
_How can we test these assumptions?_
_If these assumptions are correct, how do we solve these problems?_
h3. We could encourage and train institutions to provide better internal code hosting facilities
For example, by providing nice recipes, templates, support etc for setting up well-featured, friendly services. A good code management facility would bring together a version control system with a nice web front-end, project data sharing facilities (wiki etc), a sensible authentication system that doesn't involve a whole new username/password database, etc.
This is certainly likely to improve code development practice in an institution that has no facility at present. But it doesn't really solve the "selective sharing" problem, or help very much with the desire to move toward publication of software and reproduceable research -- unless we can also convince people to make their own internal hosting facility a public one.
Audio and music research groups typically are too small to be successfully running providing their own facilities. To do this well, they really need a horizontal approach -- facilities provided to all research areas by a common CS or IT service. This isn't necessarily the most effective approach if we want to improve search and access specifically to audio-related research code, but it may be the easiest approach to maintain. This is (presumably?) the sort of thing that the general Software Sustainability Institute ought to be exercising itself with.
Some institutions (how many? which?) will have a central system already. How many? Which? Are they happy with it? Can the SSI guess at any of these figures for us? Would the existence of a working, if not ideal, internal facility make a group less likely to accept any other approach that we might propose?
h3. We could encourage this already
_and/or_
# Encourage institutions to make better use of existing external facilities
Researchers are often familiar with services like Google Code, SourceForge, GitHub etc already, and in some cases may use them even for open-source code hosting code that is not really supposed to be published ("yet") if they have a need to share it with one or more individuals at other institutions. If they are comfortable with doing that, why not encourage it -- since it also promotes open publication and has little or no maintenance cost?
The big problem is that it doesn't address private hosting, for projects that are "not yet" ready for publication. It may (perhaps) be attractive to be able to persuade groups that their code should all be public from the start, but it's not very realistic, and in any case it's probably not wise to mix up a technical solution to a practical problem (use of version control during development) with promotion of a philosophical position (code should be published) during advocacy.
Also, keeping track of projects in these external facilities is hard -- both for prospective user/reusers who want to find stuff, and for institutions who want to keep track of the work that their researchers are producing.
All this said, these services work -- we don't want to find ourselves proposing methods that will be less attractive to motivated researchers.
h3. We could provide
_and/or_
# Provide a dedicated middle ground, our own hosting facility
We could provide a new facility that provides private hosting and access control, so that in theory institutions can treat it as an internal facility with the ability to "promote" their projects to (private projects, easily tracked, etc) but can use for public status hosting when desired. they feel able
How could we do each of these?
# Educate decision-makers and about the advantages of open publication,
Advantages and disadvantages of each:
# Takes advantage of free existing facilities, no outlay; *but*