Regarding user interface modularity you can already turn on and off many parts in the front end https://imgur.com/a/aIRkDmt
Eh.. I think the comments here are telling otherwise. I'll admit I haven't used Gitlab in over a year now. But I know the entire team I worked with really despised the switch to Gitlab internally. So much so we dragged our feet as the only team staying on Github while the rest of the company moved to Gitlab as long as we could.
It was a really unpleasant experience using Gitlab. The diffing in particular was truly awful by comparison. And in general everything was slower with Gitlab.
You should rethink this mindset of doing both at the same time and focus more on making what you have now better. It would likely benefit you greatly.
To me, more features and ease of usability can’t coexist. There must be compromises. I’ve heard the argument that it’s possible by hiding the advanced features, and I would agree in the short term. But internally, as teams grow and have to maintain multiple documentations noting depreciations, it creeps on the user’s end. It becomes harder to read documentation and there’s also the burden of trying to understand what it’s for because it was something that replaced a previous feature which I don’t have context for.
Please add features responsibly, and stop rewarding new features that seem helpful in a handful of use cases. But who am I kidding here
Any examples of features that we probably shouldn't have added and should consider removing?
We intent to replace the DIY DevOps toolchain with GitLab. Something that consists of many applications and interfaces. Just having it in a single application would already be a big quality of life improvement for the users. And so far the most common hurdle is being able to match the functionality of the point solutions.
I feel gitlab's is now mainly aiming at large enough companies which actually use all of these features.
Zawinski's Law:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Versioning the yaml specs/apis is the correct move. I hope future CI systems take note.
I haven't had any older yamls break and I wouldn't say the yaml schema is worse off because of backwards compatibility. Not sure a version would change much atm.
I first started thinking hard about this when they recently cancelled their bronze tier subscription. Gitlab is clearly ducking out of a brawl with Github for the individual/consumer $5/month tier; that makes sense as there is no way Gitlab can win by taking on the incumbent on their own turf. Instead Gitlab seems to be shifting focus to targeting larger enterprise customers; those who are fine paying $20/mo or ideally $100/mo for a one-stop solution to the full SDLC. (The counterargument here would be that they _are_ still targeting the $5/mo customer, they are just trying to replace a $5/mo Github subscription plus a $10/mo CircleCI sub plus a $10/mo Jira sub etc. -- I'm not sure I see that end of the userbase being as amenable to bundling though).
The largest enterprise customers will keep asking for more boxes to be ticked, because it's usually easier to add features onto your existing solution than to stitch multiple solutions together, and because the more features/config options you have, the more complex configurations/requirements you can satisfy. However that means you get feature bloat, and pricing becomes more challenging; you need to charge more for "all the features" tier, but as you broaden the offering, fewer customers actually want to pay for everything. "What do we keep in the $100/mo tier?" is a challenging question to get right as the feature-set grows.
As you get into enterprise sales, you start to need more customization/unbundling. Before I moved back to Github I paid Gitlab $20/mo per engineer on my team and would never dream of jumping up to $100/mo, but would absolutely have paid more for a la carte access to certain features from the $100/mo ultimate tier. (For example I have no interest in their issue tracker, but I'd love to have been able to use their DevOps / Kubernetes tooling).
I believe this sort of a la carte pricing is less developer-friendly because you tend to need to talk to a sales person vs. just having the developer sign up, but then I don't believe that "developer first" is your sales strategy in enterprise; see Okta vs. Auth0 for a good example:
https://auth0.com/pricing/ https://www.okta.com/pricing/#customer-identity-products
Auth0 keeps it as simple as possible. Even within customer-identity (their competitor to Auth0) Okta has way more configuration for add-ons like MFA, SSO etc.
(I know @sytse / Gitlab folks post on here regularly so I'd love to hear their feedback on whether I'm completely off-base in how I'm thinking about this stuff!)
It isn't so much about the customer but about the product. Our ambition went from being a source code tool to a complete DevOps platform delivered as a single application.
I think a lot of the changes you see can be explained from that.