On Tue, 2004-07-13 at 00:00, Adrian Midgley wrote: > On Monday 12 July 2004 09:01, Tim Churches wrote: > > This may be of interest to Openhealth list subscribers. > > ... from the release announcement ... > > > > The CVS is at present only 'download enabled' so you can only read and > > > download the source but not upload any of your development work at this > > > time. In the future, it is expected that developers who want to utilise > > > the CVS will apply for a password and 'manage' their work as a project > > > under the CVS with assistance from Foundation or ArgusConnect > > > development staff. > > ... > I can see why they feel a need for this, for accountability reasons that > probably apply or need an equivalent solution in any healthcare project that > will eventually run into regulatory oversight.
Most successful FOSS projects restrict who can check code into the CVS, and then have a review mechanism before that code is merged with the main tree. That's certainly the way Linux kernel development proceeds, as well as development of the Python language. Seems sensible to me. > But any community that developes, or perhaps in order to develope a community > one would need a means of feedback and sharing of code modifications, which > would amount to another parallel CVS... CVS access is not all or nothing - contributing developers can be given access to part of a CVS tree. If they are not happy with that, then they can fork the project and establish their own independent code base. > I think it is good news and I'm pleased the project is not lost, but I think > there is at least that one general problem to be solved for this and similar > projects. Let's see, but given the fairly specialised nature of the code, I don't think there will be any practical problems with regard to collaboration. The biggest problem will probably be lack of collaboration, since fairly high level Java skills are needed to contribute code. However, I think they will gain through having an army of now willing testers, and possibly documentation and training material writers. > None of us AFAIK have done any of the work, and the conditions of the GPL > appear to have been satisfied, therefore this and I hope any other comment > should be seen as comment and on a theoretical point fo general relevance, > not as criticism of the decision or release method. It is a good example of a project which was primarily publicly-funded (about 65%), but which, contrary to previous understandings, was under no contractual obligation to open source. But they did anyway, recognising that as a way to distinguish themselves in the local secure health communications market, where they are competing with a somewhat larger and better established company which offers a proprietary message delivery service (which includes their own proprietary software clients). Of course, Argus hope that 99% of their users will opt to pay for the supported version of their product (and most users would be crazy not to do so), but now everyone is much happier about going with the product of a small company, knowing that the product is open sourced. I'll endeavour to provide progress reports on Argus to this list from time-to-time. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
