Designing frameworks is hard (by all accounts). Once you ship something it’s like pouring cement - it becomes really, really hard to change if you later decide something isn’t the way it should have been. The only non-breaking way to expand is out, adding more classes or another abstraction layer over the thing you just built. Once approach favoured by Microsoft is to release beta versions of the framework, allowing potential consumers of an API the chance to use it before the cement sets. On the surface this seems like a great way for API designers and framework teams to get feedback, except when it doesn’t work. Let’s say your framework is designed to help people doing “industrial” development - building the highrises, skyscrapers and superdomes of the software development world. The very beta-ish nature of your framework is going to make it practically impossible for them to test it for you. The best you could probably hope for is some people in the field taking a look at your stuff and saying “yeah, that looks kind of like the sort of thing we could use (or which we had to already build for ourselves)”. Now you can understand the issues facing the Acropolis team at Microsoft.
People doing non-trivial projects (as opposed to single-person side projects and proof-of-concepts) are less likely to use your framework because it’s beta. They know it is likely to be unstable, there isn’t a wealth of knowledge on how to work around the issues, and they know the API they’re building on could change on them. Paradoxically these are exactly the type of people that will come up against the real-world issues with your API and could give the great feedback. Sadly this also happened with WPF - Longhorn/Vista and WinFx/.NET3.0 seemed to be incubating for so long there was a sense that they wouldn’t be released “for ages” and there was still lots of time to fix any issues. People held back using WPF in anger until around beta 2 and by then it was too late to make any changes. WPF is a great framework, but some parts - most notably the validation - suffered because problems with the API were spotted to late in the development cycle. I’m as guilty of this as the next person who downloads something new and shiny from Microsoft - plays around with it, comes across a problem (be it a design bug or implementation bug) and then shrugs and says optimistically “well, it will hopefully be fixed in the next version“ (either that or I screen-cast the bug and tear the team a new a$$hole).
A friend of mine is suffering similar problems on a smaller scale - he has developed a very cool library which he intends to sell as a component. The problem is that people are put off by the “beta” status of the library and thus aren’t using it, meaning that he can’t get much feedback and it will take him longer to eventually get out of beta. What are the answers? Well, having an internal customer that is either forced or madly gung-ho enough to bet the farm on your library, regardless of the risk must be a godsend for API designers. Expression Blend was likely that “customer” for the WPF team (as well as the Max project to a lesser extent). ASP.NET and the BCL team were/are for the CLR team. Sadly not everyone has this luxury, but clearly there is a lot to be gained from “eating your own dog food” API-wise.
I dont think its all related to it being beta. I mean, who would invest a lot of time, effort, and essentially, their reputation, in a product if it might not fit the bill. So we use what we know works, and test out new stuff on mickey mouse projects that dont fully exercise the product and therefore provide enough valuable feedback to iron out everything. Its a really hard sell, but I guess there must be some incentive for the early adopter crowd, more so than just, you get to use some new stuff. However this might actually fly for microsoft in some respects as people clamour to know the new stuff early, and get a jump on everyone else, but for the component devs like your friend, their needs to be something more.