Lots of people also crunch on the new project in a race to see who can get the first badge, then gold and then to see who is the first to reach 1 year and 2 years. Even after that people with many system try to get 4 or 5 years or possibly 10years in the hope that someday new badges will be released.
If this DDDT2 project had been further subdivided say into three phases, some people would miss out on a badge let alone their tartget badge. So it is as well kept as one project.
I would have preferred this part was kept with the first project, until the main phase of many releases. So I and many others could get the badges we wanted. People with 2years would have stopped crunching for it, knowing they would not get any further, as there would only be a few tasks. This project is still only 1% complete, and some people have no badge while others have gold and red badges. Such disparity in visualisations of wealth can only be limited at the planning and implementation levels.

There have been many wrong assumptions made in this thread:
Regarding the size of a project there is no particular relationship with their number. Among the recent ones some are big (HCMD2), some are smaller (CEP1, IADS1, DDDT1). And regarding their duration, obviously, the more concurrent projects, the longer they are lasting.
Because of the manpower needed to evaluate, select and implement a new project one of the current conditions is that a submitted project will provide work for at least 6 months under normal operating conditions.
Most WCG contributors don't care about badges. Either they let their devices crunch under the all-projects default selection, or they select the projects they are interested with and I wonder if they even check their statistics on a regular basis. Never forget that the forum population is only a very small subset of the whole WCG population.Badges are not part of the decision to go on with the same project name or to create a second phase, they are only a consequence of the decision. This decision is mainly based on the application (software) used to compute the tasks.

Sure. Even 20 or 200 cores.
Our team Decrypthon is much dedicated to HCMD2, 2/3rd of its daily production for an average 5 years daily runtime on this project. Still, this is only between 5 and 6 % of the daily total for the HCMD2 project.
So I doubt that the virtual "Badge Hunters" team can do much harm to a project running steadily.

That seems logical and predictable and it confirms that there are enough all-projects members for the load balancing to work correctly.
When you add one new project to a set of n old ones the share of each of the old ones becomes (n-1)/n of what it was before.

@skgiven- just cause I do not want a particular project crunched doesn't mean that I don't care what other people crunch.

sure there might be a project or 2 i do not want to do but it doesn't mean i don't want to see every project advance cause i know it will

as for load balancing yes if you have multiple projects selected then WCG will work all of those projects and probably use your computer to work ones with higher amounts in the loader. realize that WCG is a company and they agree with there partners who supply them with work that they will get the work done. so of corse if there is a ton of people working every other project but 1 or 2 then the people who are selected all projects will get some of those work.

It is just like in real life.. just cause i may support or not support some organization doesn't mean i need to picket the area or run thousands of support banners around myself cause of it. and if i dont picker or whatever corse others will use the facility.

it is kinda like saying BP is responsible for the oil spill so i will not support them by buying gas from them... did you know that most gas refineries get there gas from multiple companies when they refine it then the output gets divided by need and additives added to make it whatever brand of gas.
SO ....
this is also an ENFORCED SYSTEM OF FALSE CHOICE. unless of corse you are not using gas at all.