I believe this explains why Visual Studio .NET is getting absolutely creamed by Eclipse in such a short amount of time: Eclipse has a lot of iterating (integration builds are released 3 times weekly, and milestone builds every six weeks), lots of testers, feedback from those testers and innovative features delivered in a timely manor. Visual Studio has none of those things. Can it get those things given that it is a closed source product? How many people see the VS beta now? By then the feedback is too late -- the APIs are too solid and only minor changes can be made. It has to go into the next version of Visual Studio, released what, two years later? Eclipse's advantage is that the feedback arrives while things can still be changed. The re-steering process is much quicker, less expensive and gives a product that is much more useful to the users.

What's ironic is that back in the 2.0 days, Visual C++ shipped quarterly, and with real functional changes, not just bugfixes and cosmetic stuff. Eclipse does take advantage of being open source, but I think that MS has already established that a closed source product can have rapid turnaround times. I don't have any special insight into the VS team, but I believe James is dead on - it's a cultural mindset more than a question of source code availability.

It's not the availability of the Eclipse code that is good, it's the regular availability of the Eclipse *product* to actually use and get feedback on. Code is largely irrelevant to anyone but the Eclipse developers and maybe plugin developers. The fact that it is open source just means that they can release test builds on any schedule they want because it won't effect "sales" of the final product. It's a lot easier to release a smaller product more often. I don't think anyone will disagree what Visual Studio .NET is larger and more complex than Visual C++ 2.0. As well, since the whole .NET platform is integrated into most of their products they have to synchronize product releases on a strict schedule so all of the products work properly together. Visual C++ 2.0 was by itself and didn't have that problem ... and neither does Eclipse. Culture may be the root of the problem, but the same culture is built around all of these integrated Microsoft products that depend on each other, causing interoperability headaches. What's ironic is that the same "ease of use" they sell to their customers may tank them in the long run because they can't adapt fast enough. :)

I thought the Jim McCarthy "ship 4 times a year" method that was used with Visual C++ 2.x had been stopped (and perhaps, even discredited) because customers could not absorb so many releases anyway (It takes time to shake out a new compiler), I seem to recall that the VC developers were tired of the test/release treadmill, so these two influences "conspired" to get us the long release cycles again.

Comment on Ship late, ship less stable by Rich Demers

This just says the product update process has to be nearly painless so that people are encouraged to keep up with the fast release cycle.

Comment on Ship late, ship less stable by James Robertson

Not all people have to keep up with all releases - that's not really the point. Frequent, incremental releases allow for moderate change over time - that makes updating easier, yes. However, not all customers will upgrade all the time. But so what? A proportion will, and that proportion helps you improve quality. If many customers only upgrade every 2 years (say), then they gain the quality benefit derived from the early adopters. Meanwhile, the engineering group gains that benefit as well, and Product Management gets an opportunity for course correction on a regular basis. A long release cycle locks everyone into a vision that will quite probably be outmoded the day it ships.

The other side of the coin is that vendors aren't that thrilled to support many older releases (and those customers who didn't upgrade)