Reduce EE Cost Barriers

On a more personal note... I GitLab and I think they deserve money for their hard work. I hopethe folks there take this as a plea to let us give you more money without hitting our budget ceilings.

mentioned in issue #928 (closed)

Do you know of any existing successful SAAS which has this type of add-ons pricing model? I mean, a quick look at Atlassian and GitHub shows they don't have this model at all.
According to JIRA pricing model (Cloud offering) it's 10$ per user, up to 10 users. So if EEP costs 16$ per user, which includes both issue tracking and git repo hosting (which costs 9$ per user), it's quick reasonable pricing to me. What am I missing here?

@asafm Actually, Jira cloud pricing is $10/mo flat for up to 10 users -- or as little as $1/user/mo if you are at exactly 10 users. After you hit the 11 user mark, it goes to $7/mo/user.

I'm not clear on where the $9/user price for git repo hosting is coming from... BitBucket (again cloud) is priced at $2/user for standard (https://bitbucket.org/product/pricing?tab=host-in-the-cloud)

@asafm I feel like Atlasssian actually does something similar. The distinction is that all their offering is broken down around the crown jewel that JIRA is.

You want issue management, get JIRA.
You want a VCS, get BitBucket.
You want a wiki (pages), get Confluence.
You want a CI server, get Bamboo.

Where as, for GitLab, it revolves around VCS. But you don't get to choose your bundle. Which is limitative.

In terms of a SaaS company that silos their features, Atlassian could be treated as a corollary. In their case, they silo from the ground up and name each set of features as a separate product. That means that you can buy into any one of their silo's without the other. By contrast GitLab chose to produce a monolithic, all-in-one product... And that's fine... but from that base, the only way I can think of to silo your advanced features is with something resembling what I described.

To reiterate my point in the original post. I think the high-end pricing is very competitive -- if not underpriced -- when you roll in support, high-availability, auditing, advanced CI, "advanced" issue workflows, and (I assume eventually) "advanced" review workflows. It just does not hold its value when you don't use entire subsystems like the high-availability, support, and CI.

I'm hoping that there is a way to bridge that value gap so that people don't need to start turning to external, focused services.

changed the description

In my opinion, a bigger problem in the Gitlab pricing model is that you have to pay for every kind of user the same amount. Let's assume a business with two developers which is willing willing to pay for EEP (that shouldn't be the problem because the license is part of the business fix costs and the salary of a developer is much higher than the Gitlab license for them). But guessing you have 20 customers and each one needs 5 users with access to their projects issues for reporting bugs, these 100x EEP license costs would kill every small business. And I don't think that any of these 20 customers would be willing to pay 1000$ only to be allowed to report bugs. In general, solving bugs are part of the software warranty which the customer isn't willing to pay for, so they will be extremly angry to pay for the "privilege" of bug reporting!

This situation is in my opinion more unacceptable than the pricing scheme between EES and EEP. I'm also convinced that solving this problem would open Gitlab a wider market which leads to more profit.

Thanks @crussell52 for the well-written issue. Let me start by saying that we really appreciate the feedback, and will need and use it for any change we might or might not make in the future. It's only with feedback like yours and everyone else in this issue that we can continue to make decisions to the benefit of everyone.

Before I go into detail about our pricing model, I should also preface this by saying that making pricing changes is disruptive for both our customers and our organisation. So even if we'd want to change pricing model, we're likely to take our time doing so. You can imagine that with every change, a subset of our customers will ask for refunds as they might've paid more in the past, whereas another subset will be hit by pricing increases.

Now about the pricing for EES and EEP. We choose this model for a number of reasons, one of which is that it follows our product philosophy: we want everyone to be able to enjoy the full power of GitLab and we believe that an integrated approach can be superior to loosely-coupled parts. We also believe the pricing itself is reasonable for what we offer. A price per user of $16.59 per month for a critical piece of infrastructure seems doable to me.

We do understand that EEP might not offer you the benefits you'd need to be able to defend an upgrade. That's something we want to change. As you've surely noticed, we're working hard on building features and services around EEP that are helpful, in particular to larger organisations.

To be able to charge separately for separate parts of GitLab, we'd have to make very significant changes to our product and I'd personally worry about the high threshold that I see in other products of moving between stages in software development: something that ultimately impedes a short time to value and that makes sharing information much harder. We'd risk losing many of the advantages of an integrated product.

But, as Justin Bieber says never say never. We're not closing any doors here to how we might structure pricing in the future, but we're unlikely to make any significant changes on the short term.

@JobV I think there is no doubt, that the specific features between EES and EEP are its money worth and are payable in a professional business environment. But there are also so many non-feature things, which a lot of users are not able to pay, e.g. 4 hour support response, 24/7 emergency support, live upgrade assistance, and so on.

I think that the Gitlab pricing could be much more fair, if EES and EEP has the same feature set and additional services will cost extra. A large business have no problem to pay thousands of dollars to have 24/7 emergency support, because the costs of downtime are so much higher compared to the additional license costs. This would also clean up the current code base, reduces costs and increase profit.

As I tried to explain in my previous post https://gitlab.com/gitlab-org/gitlab-ee/issues/3317#note_39170138, in my small 2 people business (where I have to give my customers access to the Gitlab server for bug reporting via issues) there is no chance to upgrade to EE, because I can't tell my customers that they need to pay 200$ per year and per login only for being allowed to create issues for bug reporting. Having these costs as business fixed costs is also no option (for only 2 developers).

I'm pretty sure that there is a way to bring EE to more CE user if the pricing will fit their needs better. there is no doubt that EES and EEP have some great USPs and users are willing to pay for them. But it's hard to do or impossible under the current circumstances.

@ttobsen Hmm... maybe that's it... maybe there is just an enterprise tier missing that has all of the advanced team features but not the the 24/7 support and high-availability features. Like you said the support is a no-brainer for a larger organization which has a more complex setup (e.g. high-availability) and a larger downtime cost.

Still a simple model, but would make the jump to "advanced workflow" features more obtainable while keeping a the existing low bar of entry of folks just edging into it.

@JobV Thank you for the very thorough reply -- and I do empathize with the disruption factor. I just don't see a reasonable path upwards for my team (and similar others) as it stands now. If we use GitLab for our issue tracking, then we have to raise our user count to include the product owners, QA and maybe even our support team. With the combination of increasing the user count and cost per user going up significantly it would be a tough move to make. That's why I hope this conversation turns out to productive

Surely with regards to https://gitlab.com/gitlab-org/gitlab-ee/issues/3317#note_39170138 licensing for this could be based on the user account only having the "reporter" role not being charged/charged less & the developer/master/... users being charged full EES/EEP pricing.

That is most definetely the biggest barrier for us to upgrading to EE.

@JobV

As you've surely noticed, we're working hard on building features and services around EEP that are helpful, in particular to larger organisations.

I appreciate that point, but we aren't a large organization. We are a small organization trying find the highest quality tools to make us productive in a cost-effective way. I'd say that when it comes to features that improve "productivity", team size is irrelevant -- if anything the smaller the team the stronger the need.

I do think you should target those large organizations and I think you do a good job of it with your High Availability options, support agreements, auditing, etc. features within EEP. I think the key difference here is that those are infrastructure features as opposed to team productivity features.

@crussell52 @aspark21RVC thanks for the comments. I have no intention of coming over defensive here, in the end I just want everyone to be able to enjoy all features of GitLab. But directly in reply to some of the comments:

Even the productivity features we built, we built from the needs of larger teams. Of course, that doesn't mean they wouldn't benefit smaller teams as well, but they are aimed at the needs of larger teams. I.e. you can't do without them if you're a bigger team.

It would not be sustainable for GitLab if we'd only offer infrastructure features in higher tiers. Considering our subscriptions are per-user and do not require packages anymore, I hope that in time we can convince you that $16.59 per user is worth the value we're offering with EEP.

@JobV Thank you for the clarification on the matter. As always, I truly appreciate the openness that GitLab holds at its core.

I do remain a bit concerned about how obtainable features will be going forward since I see in your (product handbook)[https://about.gitlab.com/handbook/product/#enterprise-edition-tiers] that EEP features mainly targets teams of 750+ whereas EES is at the 100+ mark. However, I will continue to keep an eye on the feature sets and make decisions, appropriately.

@JobV As an EES customer, I implore you guys to reframe the internal narrative around large vs. small teams and how features apply. Having followed the group-level issue boards issue over the last year, I saw the feature evolve significantly based on community feedback -- many of which were, as stated in their comments, members of small teams. When the community is helping shape a feature with feedback and ideas and they work in teams of all sizes, can you really say the feature was built for larger teams? From the outside-in, that notion feels to have been plucked out of the air. Just objectively, how can one justify that a feature needed by teams of 750 users isn't also needed for teams of 75, 25, or 5?

I've worked in very large enterprise organizations and I've worked in very small start-ups and I've seen the same needs everywhere I've gone. The needs for features such as these productivity features have much more to do with how a team works--not how big they are.

Take the planned epic feature, for example. It's currently slated for ee ultimate. But the need for epics has strictly to do with the process a team follows, not the size of the team. Small teams shouldn't follow a different agile process than large teams. In fact, any certified ScrumMaster (like many of us in my company are) don't enforce a different agile process for teams of 20 than we do for teams of 200, or 2000 (good luck keeping that scrum meeting timeboxed). Granted, epics are most useful in projects of high complexity and multiple work streams, but that has to do with complexity/size of the product, not size of the team. I've run projects with 5 people that were 1000x more complex than projects I've run with 500.

I'm a big fan of Gitlab. But I, like many, have very big concerns about how feature stratification is evolving. I'm very encouraged to see much more back/forth over the topic in the last few days and I hope that trend continues.

Personally I'm eager to see how the features of https://gitlab.com/gitlab-org/gitlab-ee/issues/3254 will be spread among the different EE versions. As said by @trsmith features like epics, boards or burndown charts on group level are vital tools for Scrum and it seems fair to say that EES should allow developers to live a basic (starter ) Scrum process.

Anyhow I'd say that moving to EEP would be worth the money if https://gitlab.com/gitlab-org/gitlab-ee/issues/3254 is completely available there but as it's completely unknown what EEU is and how expensive it will be I feel like we won't be able to part away from Jira. I can only hope that the mysterious EEU and its focus will be soon officially announced... or is there already an announcement and I just missed it?

That's a really interesting issue and I'd love to give my 2 centers to it.

I run a (very) small business and recently bought a silver (/EEP) subscription for the two people. While I think it's worth it (I'll get into why) there have been a few things that are painful about the pricing, especially for the hosted version and especially for a small business.

Let's start with why it's worth it, as otherwise, I'd not have invested into gitlab ;), it allows combining a few things, with group-wide issue boards, support desk, groups, nesting and CI it eliminates quite a few other things, and being hosted matters a lot for a small team as time is a very very rare resource. Also since my business is run open source I know the other side of the table well and believe that it's fair to pay for using software that gives you a benefit (you know act the way you wish people acted around you)

Now a few things that were painful to swallow:

given nearly all my code is open source I could have went with the free solution, with the exception of group issue boards not being available there, however they're quite buggy as it stands. That said, as mentioned before I actively want to support open projects like gitlab, the price tag of $19/mo/user for currently broken issue boards is hefty.
In small organizations everyone wears all the hats. In a 100 ppl org not 100 ppl need access to the tools, there is marketing, there is accounting, payroll, assistance etc that will not have a something like gitlab. In a small org, everyone does. Effectively this makes the per employee cost of something like gitlab a lot higher for a small organization than for a big one.
The advantages that the EEP gives over EES do are not the same that the Silver subscription gives over the Bronze one. for the hosted solution everyone gest clustering/backups/scaling etc as it's part of the base system. So subscribers do pay a lot more per feature in the end.

That said I do not regret the decision to pay for gitlab, but it wasn't a purchase where I felt it was a 'fair' price. I stand corrected after two days of using git lab I regret the decision and requested a refund. There are too many features broken, I would say support answers only after 24h instead of 4h but it doesn't so I can't even say that. bottom line, the silver plan is a shame.

Reduce EE Cost Barriers

Proposal

Designs

Child items ...

Activity

Admin message

Admin message

Reduce EE Cost Barriers

Proposal

Activity