> they reached feature creep and I'm pretty sure they will never get "usably fast"
Feature creep only really results in poor performance if both a) the product is poorly architected to handle the added feature creep or b) the product is correctly architected but is poorly deployed, and is struggling with the limited resources provided to it.
The first step is to define clear interfaces: design a plugin architecture, and migrate user-facing features to use it. This can allow users to disable features which they are not interested in, and see immediate performance and UX benefits. For users who are interested in enabling all the features in a product, migrate plugins to run in their own networked nodes, so that enabling features requires horizontal scaling instead of vertical scaling.
Architecting for horizontal scale when the project is new, unproven, and simple is just overengineering, and should be avoided in the outset, but as the product matures and more and more usecases are supported, not architecting for horizontal scaling just turns into technical debt.
To the Gitlab folks reading this: remember that some of your users are lusers. You will have customers running on-prem 10,000 user instances off a single server with a couple of cores and less RAM than the workstation that you donated to your local grade school five years ago. Yes, that's their fault and not yours for grossly under-provisioning. But their users aren't going to say "damn these servers are slow," they're going to say "damn, Gitlab is slow." They're going to think it's your fault and not their infrastructure team's fault. So how can you combat this misunderstanding?
Build in applicative monitoring. Define what "responsive" means, give end users a page with a list of browser-side tests to check responsiveness by, and if something fails, maybe provide some context ("looks like memory usage is really high and it's going to swap, Gitlab probably needs more RAM!", "looks like the database is slow to respond", "Go talk to whoever set up your Gitlab instance for you about these results"). If you really stand by your product and think that it's responsive, well, prove it - don't ask your users to prove it.
Feature creep only really results in poor performance if both a) the product is poorly architected to handle the added feature creep or b) the product is correctly architected but is poorly deployed, and is struggling with the limited resources provided to it.
The first step is to define clear interfaces: design a plugin architecture, and migrate user-facing features to use it. This can allow users to disable features which they are not interested in, and see immediate performance and UX benefits. For users who are interested in enabling all the features in a product, migrate plugins to run in their own networked nodes, so that enabling features requires horizontal scaling instead of vertical scaling.
Architecting for horizontal scale when the project is new, unproven, and simple is just overengineering, and should be avoided in the outset, but as the product matures and more and more usecases are supported, not architecting for horizontal scaling just turns into technical debt.
To the Gitlab folks reading this: remember that some of your users are lusers. You will have customers running on-prem 10,000 user instances off a single server with a couple of cores and less RAM than the workstation that you donated to your local grade school five years ago. Yes, that's their fault and not yours for grossly under-provisioning. But their users aren't going to say "damn these servers are slow," they're going to say "damn, Gitlab is slow." They're going to think it's your fault and not their infrastructure team's fault. So how can you combat this misunderstanding?
Build in applicative monitoring. Define what "responsive" means, give end users a page with a list of browser-side tests to check responsiveness by, and if something fails, maybe provide some context ("looks like memory usage is really high and it's going to swap, Gitlab probably needs more RAM!", "looks like the database is slow to respond", "Go talk to whoever set up your Gitlab instance for you about these results"). If you really stand by your product and think that it's responsive, well, prove it - don't ask your users to prove it.