In my opinion, this is nicely pointing out two items:
- The main point of criticism about Formula BOINC sprints, that project operators don't have a chance to prepare for them, was not the problem in this particular case. Even with advance warning, the admin would not have known if and which problems would occur now, after the enhancements which were implemented since the last sprint. This is different from project admins who either look rarely at their project or know beforehand what parameters they need to tune, but neither of these is applies to RakeSearch.
- It is not that project operators would dislike such short-term peak loads. The statement of the RakeSearch-Admin, that only the peaks reveal what in particular can be improved, is something which I heard in Pentathlon related communication with the operators of other projects too. Even if some users claim beforehand that a project could never cope with the load, and then sometimes see themselves proven true, there is actually little way of really knowing this in advance. (Even PrimeGrid, who master each of their own challenges today seemingly without effort, had to take several attempts until this worked).
Therefore, there are practically no project operators who reject such competitions because of an expectation of stability problems. (In the preselection for the upcoming Pentathlon, there are exactly two projects missing because of objections of the respective admins, both because of clearly foreseeable shortage of WUs which could not be remedied even with the advance notice. Four more projects are missing because of no response to my inquiry; a minority, even if they did not care to respond because of expected problems).
From the participants' point of view, it surely may be annoying when a project does not work stable because of a competition. Be it because one wanted to run in the competition, or because one only wanted to peacefully crunch along in this project. (But for cases like this, there is always the simple solution of adding a backup project with 0 resource share, at least to avoid idle times.)
From the scientific point of view, damage would be done only if a project breaks down for longer time. (Out of lack of interest, I cannot assess how often that happens at Formula BOINC sprints. Out of the past 9 Pentathlons, I remember only one project in which less work than normal was completed due to longer down-times.)
One could argue that long-term damage is done because regular crunchers could leave a project due to such problems. I do not have any evidence though that this really happens. (The best counter-example is SETI@home, which repeatedly has problems even during normal operation but has got a stable base of participants regardless.) I even would argue that many regular crunchers of a project do not even notice much of such problems, if they are not drawn out over weeks. One could keep this in mind, before getting too upset. ;-)