[EMAIL PROTECTED] wrote: > Quoting Tim Churches <[EMAIL PROTECTED]>: >> Horst Herb <[EMAIL PROTECTED]> wrote: >>> Minix and Linux to me illustrate the battle between academia and >>> pragmatic engineering. Of course the pragmatic engineer will take a leaf >>> out of >>> the academic book and benefit from teachings and research, but what they >>> do >>> and how they do it is very, very different from academic "solutions". >> >> I suppose we are most interested here in solutions which see the light of day >> and can thus be used by many people, not just their genius progenitor - >> regardless of where such solutions come from. > > Gentlemen, please! ;-)
Sorry, but frankly I am still smarting from being accused by Horst of spreading unfounded FUD, just because I dared suggest that it might be worth double checking Horst's take on RoR as the ant's pant's of Web application frameworks. > Both of you are quite right: Linux from the get-go was no way a Minix clone > (32- vs 16-bit for starters). > However Linus clearly used Minix as a requirements model in the early stages, > and as a bootstrap system. > More interestingly, he intended Linux as a 'stop-gap' measure while we > wait for the 'offical' GNU kernel, the HURD, to emerge. > HURD parallels Gnumed in many ways: ambitious projects, totally new design, > very complex, poor governance, and no working result so far (actually gnumed > has done better than the HURD) > > The lesson I draw is that volunteer free-software projects can achieve > complex > industry-ready outcomes, I would qualify that lesson with the adverb "eventually" - it took the Linux kernel the best part of a decade to become "industrial strength" (and it still leaves a bit to be desired when really hammered, although it is now good enough for most purposes and vastly better than Windows for any purpose). > this has been done with Linux and many others, it's > hard to see what's so special about medicine. The difference is that Linux, and Python, and Perl and Apache and Ruby and almost all of the other FOSS projects which have been developed through the classical "bazaar" model of volunteer development have all been things of direct interest to programmers and computer scientists - scratching their own itches. To date, very few people capable of creating software have had a medical information system itch to scratch - that's why at any one time there have been no more than a handful of people around the world working on, say, GNUmed, as opposed to the thousand or more simultaneously active developers of the Linux kernel, or the hundreds or (or at least one hundred-odd) developers of the Python language and its libraries. > But they all had a humble > starting point and grew features organically, it's true no-one in the Free > World has built a 100% system from scratch. I refer people to Raymond's "The > Cathedral and the Bazaar" for more around this idea. Yes, Raymond's description of FOSS development was seminal but not actually based on any empirical research. It played its part at the time (about 8 years ago now) but should be taken with a grain of salt - it now seems clear that the "bazaar" model is not the only way in which FOSS is created, or even the dominant method any more. > This ties in with how I would view interaction with academia. AFAICT what > academics (and possibly other players) want is a fairly basic but open base > system, on top of which they can install the 'research' features such as > decision-support, natural language coding, etc. that they want. > > So, IMHO a "small target" is in order, not the best, just usable, focussing > on the bread-and-butter stuff that Jon et al. isn't interesting in. Perhaps, although I think that Jon and his colleagues might also interested in issues of how such systems should be engineered, and such considerations necessarily involve the bread-and-butter, meat-and-potatoes aspects of the system as well as the fancier "add-ons" or "plug-ins" which you mention. For example, hand-crafted data entry screens/pages are probably not the ideal in terms of maintainability and dynamic system re-configuration to meet changing or multiple needs, but all of the automatically generated data entry screens I've ever seen leave a lot to be desired. Closing that gap is an area of applied research in which academic participants or partners might be quite interested, and it is an area in which a funded person-year of work by the right team of people can make a real difference. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
