Creating a platform that can be built on is the way to go - but it seems very difficult to create one that is simple to use, that can generalize in the right ways, and enable people to build what they want.
But maybe that's not the trick - it isn't that hard to make an overgeneral, loose platform, that isn't specialized towards any particular usage. Maybe the particular platform isn't that critical. Maybe the trick is just to provide access to something that is really cool and exciting (that simple core idea). Developers are clever, they'll work out how to get on the bus.
Well, Rails is focused on this idea of doing things the Rails way. So you lose a lot of that generalization that you'd get by, say, programming everything in Ruby. But in return, you get the ability to develop and iterate extremely quickly, because a lot of the stuff is set up in advance.
I'm not entirely sure what you're saying, though: could you elaborate a little?
ACCESS I was saying two things, one you saw a refined version of elsewhere: "making it exciting is more important than making it easy to develop for". Designing a great platform (in terms of the insides being usable for developers) doesn't matter if the platform does something great. Many sins are forgiven if you have this. I think there are probably many examples of horribly ugly technologies that became wildly successful because they enable access to something exciting (DOS? windows? netscape navigator?)
USABILITY To elaborate on the other idea: it's much easier to make something usable if it has a specialized purpose. Fewer features, fewer interactions/interdependencies, fewer controls, fewer things to go wrong - it's gonna be simpler to use. e.g. ipod shuffle. That is, not being able to do things makes it easier to use.
The big problem with a platform is that you don't really know what the specific use will be, nor the exact nature and parameters of it. A platform, by definition, is general, and not specialized to one specific purpose. And you won't even know the nature of the general use. Except, perhaps, that it will want to be part of whatever the cool, exciting thing you have going is - that's a predictive organizing principle.
Therefore, for a platform, rather than trying to guess at the kinds of uses it will have, maybe just say: (1). what is the cool, exciting thing that we enable? (2). how can we let developers build something that has that cool, exciting thing? That is, an API that gives them access to whatever they need to do that. It doesn't need to be great access, they just need to be able to do it somehow.
This is "overgeneral" in the sense that you can not only do the things you want to do, but you can also do things you don't want to do. This looseness makes it harder to use - if it was an exact fit to the problem, it would be a delight to use. This extra power gives you "enough rope to hang yourself".
RAILS On reflection, I think Rails is a much later stage in the development cycle: webapps are in a more mature stage, and by that I mean that people now know what kinds of things they want to do, and most importantly, what kind of defaults are useful. At an earlier stage, we didn't have enough collective experience to know those things. This knowledge is to do with how webapps appear to users externally, as well as what architectures and internal approaches have been found to work. Webapps are becoming an understood art, when previously, it was a bit of a black art.
Rails represents a systemization of webapps; no longer ad hoc, many design decisions are now captured in a mechanical tool. It is specialized to the task.
But maybe that's not the trick - it isn't that hard to make an overgeneral, loose platform, that isn't specialized towards any particular usage. Maybe the particular platform isn't that critical. Maybe the trick is just to provide access to something that is really cool and exciting (that simple core idea). Developers are clever, they'll work out how to get on the bus.
I'm not sure if this applies to Rails.