I understand your critisism, and I also would like to see a more detailed plan. Since this is a pilot project, some things will have to be worked out during the planning phase.
1. If this doesn't catch on and people want it to continue, this could be a significant ongoing cost for running this project above and beyond allocating what people might think are one-time NRE charges. None of this appears to be detailed enough on that site so I'm not sure how far they've thought through this. Who are the target vendors, and have they tendered bids? Costs vary greatly, and I'm not at all ready to throw money when there appears not to be an "open source" plan with sufficient detail to make this real, nor with open listing of the credentials of the individuals involved. If you're gathering up to $250k for a project and you want my money, I had damned well better know that you're able to execute and that you have a real plan and definitely not just an FAQ.
As it is stated in the FAQ, the more money donated, the smaller process opencores can afford. That will also decide the possible ASIC vendors that can be used. I'm a bit curious about what other costs than the NRE that you are thinking of
2. How did they define the product? Is it based on market needs? If so, what markets and where is the information on said markets? If it's for hobbyists, I get that, but did anyone do even a rudimentary survey to say how many timers or UARTs might be necessary, whether they should embed an MMU so you can run a more advanced OS, or what the max CPU clock speed should be? If *I* am going to put my money in it, then why not ask *me* what I want? And yeah, I know I can contribute, but how have all of those contributions been managed, organized and synthesized into what is being built AND make it sufficiently relevant for enough time that this would be worth doing before technology moves on? I don't see a single place for that around their site.
The OpenRISC has been used in many projects before. The IP cores that are going into the ASIC should cover most basic needs. There is also a PCI bus included to cover some additional uses. A MMU will most certainly be included, since it is targeted towards running standard Linux. The CPU speed will be limited by the process, and the current design. Still, I agree that there should be a place for these kinds of discussions. I'm guessing there will be one. For now, slashdot will have to do :)
3. Frankly, why bother when there are many other vendors such as Microchip who offer 32-bit micros with fully-documented architectures and better capabilities that you can run Linux on? I know, I know, this is what open source is about, but we're not just talking about someone's spare time on a machine they do other things with; this is a real product with real implications. I seriously don't buy how they're going to change the industry since the successful players in the industry guarantee supply to their customers.
I think there are a lot of use cases for this. You can buy these cheap ASICs and build a system. If you need to hardware accelerate something, then you can replace the ASIC with a FPGA and extend the design. Come to think of it, it seems kind of backwards to prototype on an ASIC and then implement it in a FPGA :)
I know I'm going to get flamed and down-voted for this post, but the open source hardware world is much tougher than the software world, and ASIC designs are steadily dropping because ASSPs are taking their place. I think people's efforts need to be focused on software, and this is coming from a guy who's been on Slashdot more than a decade with a hardware background (and hence my name) and has switched to the software and systems world...
I really hope that you are wrong here. Open source efforts should be able to handle as much criticism as other projects. Regarding your other point, what I see is that the borders between hardware and software are changing. Things that used to be done in ASIC is now done in software and the other way round. There are also many cool ideas how to decide what is going into hardware and software at compile time.
