Thanks for posting the FAQ, it was quite interesting.

The problem of Olli in 1999 with the 'patched' code raised some questions 
for me, as the SETI team seemed to be happy to provide less efficient 
code as they were unable to increase the rate of WU creation/results:-
   "The effect of a faster client on this bottleneck 
    would be a higher rate of rejected connections 
    and a lower system efficiency". 
As a Capacity Planner, for more years than I care to remember, this is a 
strange approach to 'system efficiency'. If you make the client code 
twice as efficient but can't support the results coming back twice as 
fast, then give them out only at a rate you can support. You can give the 
users the same WU's and let them have back half their CPU cycles - 
nothing forces you to keep them fully occupied!  CPU cycles are a 
resource and it is NEVER a good idea to waste a resource.

My worry is that I would like to use my spare CPU cycles efficiently to 
support several good causes, but if SETI(or any other project) is going 
to 'waste' them then perhaps other projects should get higher priority. 
In light of the new BOINC initiative is there going to be any focus on 
the code efficiency? I've already noticed a significant increase in the 
processing per WU with BOINC, and hope that this will be addressed.

However, this is likely to be a problem for all the distributed projects, 
as they will all feel that time on their part to make the code more 
efficient is a 'cost' to them, whereas the users CPU is a 'free' 
resource.  Perhaps if users are willing to contribute on the coding side 
then projects need to consider how to manage such support? Anyone have 
any thoughts?