2: "Small" userbase: changes produce grumbling, community adjusts over time, old code is successfully forgotten (deleted + no nostalgia)
3: Very Large™ userbase: even TNT won't change the language
Each of these is relative: (3) has happened with Python (famously explosively), Rust, Go... and also Lua, awk, FORTH. Language size ("volume") seems to have no impact; once a language becomes known for a certain way of doing things beyond a certain scale, trying to go against that (even as the language creator) will land you in a strange, undefined uncanney valley that's not precisely un-idiomatic, but... everyone will still try and steer/corral/etc you back to the "established way".
Obviously (2) represents the perfect ideal here. (Well it wins by default, since (1) is socially depressing :) )
So, one approach could be to try lots of ideas (at a pace that keeps up the creative energy to enjoy the effort) early on.
The key in this case seems to be figuring out the magic threshold point where the community is
- large enough to provide constructive feedback and help the project substantively grow
- small enough to stomach fundamental, relearn-everything-you-learned, changes
- cohesive enough not to be disbanded by the impact of said changes
and carefully ratelimiting publicity and knowledge spread to control ecosystem growth, in a way that does not rein it in.
The dynamics of what defines this balance seem to be specific to each project.
1: No users: infinite flexibility
2: "Small" userbase: changes produce grumbling, community adjusts over time, old code is successfully forgotten (deleted + no nostalgia)
3: Very Large™ userbase: even TNT won't change the language
Each of these is relative: (3) has happened with Python (famously explosively), Rust, Go... and also Lua, awk, FORTH. Language size ("volume") seems to have no impact; once a language becomes known for a certain way of doing things beyond a certain scale, trying to go against that (even as the language creator) will land you in a strange, undefined uncanney valley that's not precisely un-idiomatic, but... everyone will still try and steer/corral/etc you back to the "established way".
Obviously (2) represents the perfect ideal here. (Well it wins by default, since (1) is socially depressing :) )
So, one approach could be to try lots of ideas (at a pace that keeps up the creative energy to enjoy the effort) early on.
The key in this case seems to be figuring out the magic threshold point where the community is
- large enough to provide constructive feedback and help the project substantively grow
- small enough to stomach fundamental, relearn-everything-you-learned, changes
- cohesive enough not to be disbanded by the impact of said changes
and carefully ratelimiting publicity and knowledge spread to control ecosystem growth, in a way that does not rein it in.
The dynamics of what defines this balance seem to be specific to each project.