Re: [FreeMedForms] Creating a global "Linux Medical Team"
:) This is quite some cross-posting.
On 11/25/2011 08:39 PM, Eric Maeker wrote:
> Le 25 novembre 2011 17:32, Karsten Hilbert <Karsten.Hilbert@gmx.net> a écrit :
>> On Fri, Nov 25, 2011 at 05:05:31PM +0100, Eric Maeker wrote:
>>
>>>> While I agree the logical and lofty goal would be to create
>>>> a "Linux Medical Taskforce" I also know that doing so will
>>>> not achieve anything tangible.
>>>
>>> Not sure, Debian Med is getting bigger and bigger, MedFloss too.
>>> May be we can go one step further !
>>> There are volonteers but they scattered on multiple projects while a
>>> more unifying project can arise.
>>
>> What would be the precise, medically relevant goal of this project ?
>>
>> Without one it'd be useless.
>
> The very basic reflexion can be the following.
>
> This kind of project involves a too heterogeneous population that we
> need to precised in more details. I propose two very simple dichotomy:
>
> * The first dichotomy:
> - the end user
> - the developper
>
> * In user/developper we have another dichotomy :
> - working in a (or for a) medical area
> - not working in a (or for a) medical area
>
> This lead to four profiles that have different needs and wishes.
There are of course idealistic developers that we can guide to find
themselves a place in the biomedical world. Yes. Will work. Somewhat.
But what we truly want are collaborative full timers that work
for maintaining something locally and have difficulties in separating
local adjustments (which they are paid for) with long term development
(which they happily do) - of the software, of local students and of
external volunteers. So, get the Open Source bits used in the
real world and with some luck we are set. <rant>The actual platform
(I mean Linux/Mac/Windows, not the Linux flavour) should be a non-issue,
at least when we take that Freedom of our software seriously.</rant>
My personal perception of a Linux distribution's role is that of
a connector of upstream developers among themselves but of course
also between them and their creative users. Traditional end user
support I would happily see covered by our distros' commercial
variants, which is a bit far from happening, I presume. This is why
I am so excited about the participation of the most-Open-Sourcy company
Eagle Genomics in our January Sprint. Whoever has a problem can talk
to them about their biomedical or biochemical issue and have a partner
who truly knows how to address things for consultancy or outsourcing.
This is for the long term benefit of us all.
The Open Source pure medical side is far less
developed from my perception, since the field never got that enormous
public funding for Open Source developments. After all, it is about
individuals' data and not about public data, but I know I can ask
Karsten and Sebastian about everything and they provide Open Source
solutions for local doctors themselves. Would be great to see that
dispersed nationwide, actually.
To conclude and to give that interaction of upstream developers some
extra life, I would like to quickly mention some personal weekend
interests of mine:
* save energy and increase performance for routine bioinformatics
and cheminformatics services with a push of FPGA computing
- ztex.de has its Open Source API in Debian
- sciengines.com present theirs at our Sprint
* get Linux distros closer to volunteer distributed computing
- BOINC server package with functional wrapper
- manual proof of concept for AutoDock
- Debian package combining the two stalled (any takers?)
* get bioinformatics workflow tools to work with the Linux distros
so we can bring public web services with local developments/needs
together more easily
- Taverna joins the Sprint, collaboration on specification
of external tools
- Tim works on packaging Galaxy
- mgltools-vision is in
- Laszlo brought Predictprotein.org to Debian
* Cloud computing with Debian
- Eucalyptus.com joins our Sprint
- (Cloud)Bio-Linux organises our Sprint
And then there are various biological ambitions of mine for which
I plan using those technologies. I once blogged about them, nothing
overly tangible, yet. And everyone brings something in, from which
I happily benefit. You may observe that above list contains nothing
special about Debian. What is special is us is the community. And
when you follow the discussions of mine with the Google Summer of Code
organisers of Debian, then you will find that Debian does not like
above projects too much. They kicked them out. Google then adopted
the BOINC+AutoDock one themselves in their academic partnering
organisation of the GOSPO itself, for which they then got a big
acknowledgement in the accompanying paper for the PDP 2012. So, we
thank the Debian Society for co-funding our Sprint. I think we give
quite something back. To Debian, its derivatives, and from above
list alone you see that also the other distros immediately profit
from our event and from our community.
Your cross-posting is an indication that our community is indeed
such: a community. I suggest to wait with any explicit separation for
Linux flavours until you receive too many "off-topic" complains. With
Debian, we have over a decade kept the Bioinformatics <-> Medical
Informatics divide. We are about to close that next yearish with
lab information management systems, I presume. And the Debian <->
Ubuntu divide we have closed last year, I think. Let's see what
happens respective the .deb <-> .rpm divide. I do not say there
are no differences or even difficulties, but those we mostly know
or they do not hinder or collaboration on so many fruitful pieces
of software.
Best,
Steffen
Reply to: