Thomas, Your previous messages have made me aware of and interested to know more about GEHR and Eiffel. How far is GEHR from being fully Open Source? Why not design it to compile under SmallEiffel? Thomas Beale wrote: >Wayne Wilson wrote: > >> Thomas Beale wrote: >> > >> > In our judgement, the use of good formalisms and tools makes for a significantly >> > better result, and does not unduly harm the economics of development (since >> > development has to be funded from somewhere - nothing is really free, and the >> > cost of wages dwarfs the cost of tools), so we prefer the "quality" approach, >> > even if it costs something. >> > >> I am sympathetic to your issue here, but open source makes another >> argument about quality and robustness which is that the more people who >> have access to the source code, can examine it, make changes in it, put >> it out to test, the higher the quality of the end product. > >Agree. But consider this: the more specialised a product/project, the fewer people who >will work on it. I think it is reasonable to say that far fewer people than work on >Linux will work on (e.g.) the GEHR kernel. If you are talking about current workers on any internet enabled project versus potential workers in the near future, then I must disagree. I think we are still in an early stage of the growth and development of the internet and in the realization of its effects on the economics of Open Source software development, especially with regard to software for health care. Projects like Linux and Apache belong to an early stage of this development since they appeal directly to software developers interested in the development of the internet and Open Source in general, while the vast majority of the people who could become interested and involved in GEHR, or any other open source health care project, are very likely not yet aware of it or of such projects in general. If you continue to make a good case for GEHR and Eiffel it could materially affect the number of people who get involved and when. >And for most people on this group, there >will be no need to compile the GEHR kernel - if they are building applications, they >just want to link to it in a binary fashion (e.g. via .lib, COM etc). The source will >still be available of coruse - no problem there. But I think it is worth always >considering the actual facts of the general argument here. How many people does it >really affect? I think we should be prepared for explosive growth of interest in this area. I believe that most IT professionals involved in health care are presently at most lurking on lists such as this. >And the other side of the coin is that if we are only allowed to use e.g. C++ or Java, >we have compromised the on the eventual quality of the thing. Those of us who are currently working primarily with MUMPS and who believe in the future of Open Source, must either support the development of an Open Source version of MUMPS and/or find a way to transition our existing systems to a different platform and programming language. Consequently, SmallEiffel is looking very interesting to me. >Believe me, the >deliverables of an EHR project - requirements, architecture/model, implementation are >nothing like the Linux kernel. The thing is requirements driven, and information >centric, whereas Linux (unix) is (still) largely task/function-centric. For us, the >compromises forced by C++ (cost of development due to complexity) and Java (semantics >too weak) were too big for the GEHR model and kernel. But I have no problem whatever >with people developing Java applications which talk to the kernel. In fact, I think it >is a good thing to do - it uses the strengths of the language in the right place. > >In any case, I have a feeling that the kernel itself will compile under Small Eiffel - >it is the Matise binding which will not (but whcih can be supplied as a binary .lib). >So I don't think the situation is all that difficult. If was important for people to >be recompiling the source of the GEHR kernel all the time, I would try to ensure that >it could be done under SmallEiffel. Why not target SmallEiffel now? As I understand it SmallEffel will optionally compile to Java Bytecode. Is there any reason why I would want to work with Java instead? >> The collective cost of the community contributed wages dwarfs any one >> organizations wage costs. >> >> It has turned out that having a very powerful C,C++,Java environment >> for free running on other free environments (gcc and linux for example) >> creates such a scenario. That this environment is not what we would like >> means that if we are to have open source projects thriving using our >> preferred tools, we must make a similar effort to get those tools freely >> available to everyone. > >As I say, not "everyone", just the interested parties. It will be a much smaller >number. This "smaller" number could still be incredibly LARGE. Now is a good time to make the case for Eiffel. >> While $750/developer may seem like a pittance to those of us >> professionally employed in the US, it may seem like a mountain to a >> volunteer in another country. There is another subtle sub-text here that >> is built in to the high cost western way of doing business, that if you >> can't keep up with our expenditures, you can't play in our >> neighborhood. I don't think anyone is conscious of this message so I am >> not accusing anyone of deliberate intent. > >Yes, I understand this problem, and sympathise. (Actually I do other work in community >informatics for free or on a grant basis, with developing world and academic people >in mind; I am quite aware of the problems...). > >I feel that time is of the essence, and that we should get something of good quality >built, which most people can link into their application, which may be built with free >Java tools or whatever. If developments over time lead us toward more people modifying >the GEHR kernel or the Matisse work I have done, then it will clearly be worth making >efforts to ensure those people are not penalised by tools costs. > >- thomas beale > > >-- >--------------------------------------------- >Deep Thought Informatics Pty Ltd >Information and Knowledge Systems Engineering > >mailto:[EMAIL PROTECTED] >http://www.gehr.org >phone: +61 7 5439 9405 >--------------------------------------------- > > --------------------------------------- Jim Self Manager and Chief Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself)
