:) 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