I am curious, at what point will the features stop? Do we keep adding features until Gitlab becomes impossibly complex to use or onboard anyone? Why isn't Gitlab built like a modular app - add what you want but core should be simple as possible and feature complete. I am afraid but this is how a lot of applications die. Gitlab is starting to get bulky and obese already.
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.
I’m curious what are some products that successfully do this? I honestly can’t think of any at the top of my head.
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
I'm inspired by products like Zoom, Chrome, VScode, and Slack that are both user friendly and full featured.
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.
Yeah, I was an avid user of self hosted gitlab previously, but the pace of added bloat^Wfeatures was just too much and I ditched it for gitea about 1 year ago.
I feel gitlab's is now mainly aiming at large enough companies which actually use all of these features.
Not sure why you feel that added features result in "bloat". We've been on Gitlab for 4 years now, and our core workflow not only hasn't changed, but also has not been impacted by any of the new features. On the other hand, we've expanded our usage beyond it, and it's always nice to need a feature and find out that it is right there under a menu and just needs some configuration to get it to work.
With them dropping the lowest license tier, you better start using all the features...
We have been Enterprise users since 2015, but are evaluating our options.
I feel like it's already .. kind of there. There are so many features that I'm lost in them, and some of them feel like they've been abandoned already.
Just take a look at the gitlab ci reference. It is huge. And there are competing features in there that are intended to "deprecate" the older feature but this doesn't happen. They are also constantly held back on providing backwards support. For instance, adding dpeendency-like flow as opposed to stage based flow has been added but it's not possible to model dependencies from same stage making the whole thing kind of useless.
Versioning the yaml specs/apis is the correct move.
I hope future CI systems take note.
Seems trivial to add a version field to the root object if they ever go down that route.
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 think this is a real strategic challenge for Gitlab; I think the answer is "the features never stop", and that is OK, as long as you understand their target customer/market.
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:
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!)
Thanks for inviting me to comment. I think we still cater to individual contributors with our Free offering.
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.
