The first time I ever met Joel Oleson, I was SharePoint team’s first Technical Product Manager, and he was working for Microsoft’s IT division. I went to them trying to get them to allow custom Web Parts on the SharePoint 2003 servers they used to provide team sites to all of Microsoft worldwide.
His response (and his boss’)? “No. We have no way of knowing whether a custom Web Part is poorly written and could crash our servers.”
When I was trying to advocate building on SharePoint to “regular” Web developers, their usual reactions went something like “Nice portal. How can I show my web site inside of it?” or “What? To develop for this thing you want me to bolt on components and modify its behavior?”
When did research with customers to see if they’d make use of a public Web Part gallery, a near-universal response was: “Are you going to vet what’s in there? If not, how will we know it’s not malicious?”
SharePoint still became a success, but extending SharePoint became a specialized area of knowledge, and the goal was (usually) controlling SharePoint, not contributing to it. Solutions were built, but they never really became a self-service thing.
Fast forward to 2013.
There’s now a means to (a) surface web content you created *any way you want, with any tool you want* inside of SharePoint, (b) a way to pass context, identity, and requests back and forth, and (c) a way to display apps in a curated catalog for self-service purposes.
It’s what you wanted.
It’s not perfect. Some things need to be finished. Some things really ought to be redone. But it’s still the right approach to take.