[TOS] What's Wrong With the American University System
William Cohen
wcohen at redhat.com
Tue Aug 3 20:36:18 UTC 2010
On 08/03/2010 09:57 AM, Joel Sherrill wrote:
> Hi,
>
> Out of curiosity, are there guidelines for how FOSS projects and
> research groups could work together better? For RTEMS, I have
> been thinking in terms of finding ways for our processes and
> deliverables to better integrate into those of our end users.
> In our case, it is a mix of safety critical system developers,
> researchers (CS and general science doing experiments), and
> commercial users.
>
> GCC has had similar discussions in terms of trying to make GCC
> more attractive to compiler researchers.
>
> It is of course possible for a long-term university research project
> to have its own FOSS project but it is just as likely that they are
> leveraging an existing project.
>
> What are the "best practices" in this case?
>
> Or put another way... what would make researchers happy? :-D
One issue that I have seen personally is that many universities have technology transfer offices that often work to convert research results into revenue for the university, e.g. license patents, software, or technologies to companies. Those technology transfer offices may not be happy with software licenses that don't allow them to license the software and directly generate revenue from the university's contributions. The researcher many not mind the open source licenses because they see the benefit from not having to build everything from scratch. However, the university technology transfer office may see using an open source license as losing possible revenue rather than maximizing the productivity of the researchers.
GCC requires copyright assignment for inclusion of patches into the upstream. Usually the researchers are not the ones that sign off on that. The people in the organization who sign off may have a different perspective on the copyright assignment (e.g. people in technology transfer office or grants/contracts). Having some explanation why things are done that way and how it benefits their organization would be helpful.
>
> --joel sherrill
> RTEMS
>
> 2010/8/3 Luis Ibanez <luis.ibanez at kitware.com>:
>> On Mon, Aug 2, 2010 at 4:21 PM, William Cohen <wcohen at redhat.com> wrote:
...
>>> Hi Luis,
>>>
>>> Rather than pitting researching against teaching would it better to get
>>> the research-oriented professors to the point where open source software is
>>> the preferred way of implementing their research? Help the research-oriented
>>> professors embrace open source software and make them advocates of teaching
>>> open source software.
>>>
>>
>>
>> Excellent point.
>> +2
>>
>> Most of the open source toolkits that we develop at Kitware are used in
>> research related applications.
>>
>> Our experience has been that researchers love to use open source software.
>> They have a basic need for knowing what is it exactly that the software is
>> doing and how.
>>
>>
>>
>>>
>>> There are many researchers that use open source software as a starting
>>> point for their research projects and they certainly see the benefit to
>>> using open source software. However, the main objective for those research
>>> projects is to produce publishable results, not to produce a polished piece
>>> of software.
>>
>> Fully agree,
>> We actually have an entire pipeline dedicated to converting "research
>> quality" software into software that is reliable and usable by larger
>> communities.
>>
>> See for example
>> http://www.itk.org/Wiki/ITK_Procedure_for_Contributing_New_Classes_and_Algorithms
That URL is an excellent writeup to give people guidance on how to contribute to the project.
>>
>>
>>
>>>
>>> The result is they often end up with a set of patches that never make it
>>> into the upstream version of the software. There are benefits for
>>> researchers following the complete open source development model and getting
>>> their implementation ideas into the upstream open source software: upstream
>>> reviews can improve the quality of the research results, merging their
>>> patches upstream reduces future maintenance costs, and the software can be a
>>> portfolio showcasing their work for future funding.
>>>
>>
>>
>> Absolutely,
>>
>> This is a preaching activity that we do on a daily basis.
>> (That is my daytime job)
>>
>> Most research groups start getting it when they get exposed to the reality
>> that their developers (grad students, research assistants, and professors)
>> have a relatively short life cycle (2~4 years), and it is common for them to
>> leave behind a large body of legacy code that is rarely documented, tested,
>> or even stored in a revision control system. There is a lot of code out
>> there that get rewritten over and over in research institutions under lax
>> engineering practices, and that continuously goes to waste. Porting such
>> code to common open source platforms is a very important mechanism for
>> moving entire fields of research forward.
>>
>> NIH is starting to require researchers to explain in grant proposals how
>> they anticipate to share the data gathered using public funds, as well as
>> sharing the software that is developed in the course of a publicly funded
>> project. There is also a favorable attention paid to grant proposals that
>> include an open source component as a mechanism for disseminating the
>> benefits of the research to be undertaken.
Luis, is there a pointer to NIH mentioning the use of open source software in grant proposals? Are there other grant agencies that have similar requirements? Making university technology transfer offices aware of this type of requirement would probably help researchers have an easier time getting approval to work in open source software.
>>
>> --
>>
>> You have an excellent point in that the wide acceptance of open source in
>> research is an asset for bringing FOSS into the educational tracks.
>>
>>
>> Luis
-Will
More information about the tos
mailing list