Right now the EE license check uses the historical maximum to determine whether an admin has enough seats for the license. Let's say a customer has a 5-seat license, and sometime during the year he had 20 users. If he trims back to 4 users, the 5-seat license won't work anymore. Right now the workaround is to issue a license for 20 users.
This has come up several times this year, so I think we need to figure this out. We could just use the current active user base as a measure of how many licenses are needed. Admins could temporarily block users who get their license count down, but I think in keeping with the True Up model we shouldn't assume this is normal behavior.
Checking the historical max was explicitly added to prevent admins from tricking the license upload check by temporarily blocking users. I do agree that that probably won't happen that often if we just check the current count.
I would prefer to use the active user number. Once we have https://gitlab.com/gitlab-org/gitlab-ee/issues/380 completed, then we can check and see when they go over their active users during the year.
@stanhu feel free to ping me on chat if you need my opinion this month.
If people added users they will have to pay for them. It doesn't make sense for us to only count users at renewal. It is very easy to temporarily deactivate users when installing the license.
Customers already have two options:
You add users as you need them (renew early)
You pay for the users you added later (our true-up model)
But never paying for users you did add to the installation doesn't make sense to me.
link the word 'true up model' to a comprehensive true-up FAQ with clear examples, pay attention to the fact that you have to buy for the maximum number of users in the last year, not the current amount
This issue seeks to address the case where companies actually downsize their user base ("true down"?). It follows from the above statement that for every customer that trims his/her user count, he/she must pay for the maximum number of users used in the last year. What's happening now is that we reissue a license that fits their historical maximum, which circumvents this. Should we discontinue this practice and insist customers pay for users they no longer need?
On a customer call we had a very good suggestion about displaying the total amount of users that GitLab sees and that will get billed. Can we include this?
Customers need to pay for the maximum number of users in the year for true up. At renewal, I think they should renew at the level they need, which may mean less than maximum. They should renew at their active user level. @sytses@stanhu what do you think?
@stanhu So if the customer had 60 people during the last year, has 50 now, and buys a license of 50, adding 1 user would put both numbers over the limit, and block their GitLab access? Wouldn't that be incompatible with true-up?
I assume the goal of checking the historical_max at all is to ensure that the customer is being truthful about the historical use they reported when paying the true-up?
On 2016-01-28 we bought a license for 40 users, since then, we had a maximum of 36 user that used the system at the same time. Right now, our company has shrunk a bit so we do not need more than 30 licenses.
What would be the best way to proceed for license renewal?
we had on our gitlab instance a peak of 6 users, purchased the license for 4 users, but removed 2 user after we've purchased the licesen.
@pidge sounds like you need to apply a true-up first and manually send a license key for 6 seats, unfortunately we don't have a fix for it yet.
@ChadMalchow@francisaquino I'm going to add a new field where the customer will enter the max historical users, this will be shown when the customer is renewing his subscription but I think we're going to have some trouble with subscriptions with the Auto Renew flag enabled. When the renewal is processed the customer will not be able to use the license key if the historical users count exceeds the current active users count (same problem that we have today), do you have any ideas for this?
I've updated the body of the issue with the tasks needed to complete this issue.
@rdavila@francisaquino@ChadMalchow for the auto renewal part, is that a problem? If everything is done automatically, the only use case we'll have to manage is when the customer wants to actually downgrade the number of seats - and in this case, he will have to stop auto-renew anyway. Am I missing something?
Should we consider enforcing the user limit in our license keys so true-up and historical max become the exception rather than the norm? Customers are then forced to purchase additional licenses in advance.
@regisF Assume by downgrade you mean customer wants to reduce their user count at renewal to something less than their historical max - if every customer had to purchase users in advance, then we can remove the requirement that any new license must meet their historical max. The only reason we enforce historical max now is because customers aren't obliged to purchase licenses in advance of use (they can just create new accounts and pay later).
@Haydn I would say that if we asked customer to purchase users in advance, it would actually slow down the increase of seat counts. What I like with the true up model, is that customers don't have to "think" twice before adding users in their GitLab instance.
Moreover, we would still have the problem about auto renewal when they want to have less seats than the current max.
But I also see that, for up to a year, customers can add users for which they would only pay half for (potential loss of revenues for us). @francisaquino@ChadMalchow do we have a sense on how many customers take advantage of the true up model?
I agree @regisF having the ability to create user accounts in advance of purchase removes a big obstacle to adoption which is why Sytse didn't want to enforce the user limit originally.
Regarding the the issue of auto-renewals, if we did enforce the user limit these scenarios would be uncommon since auto-renew would only be for the customers original quantity plus any users added during the term. They also get renewal notifications well in advance which gives them time to renew for less if needed.
Re customers taking advantage, I think we're seeing more and more situations where new customers who understand the true-up model sign up for a very low quantity knowing they can add more users the next day and pay 50% at their first renewal.
@Haydn in any case, this is another problem. The current problem that we should solve first is to make sure people can downgrade if they want, and actually pay for the usage they had in the previous cycle. I think the steps defined above (and reflected in the body) will solve that.
The second problem that we should investigate is: do people abuse the system, if so, can we quantify that. If this is a real thing, we should perhaps even revisit the conditions of the true up model.
@regisF agree that we should separate the problems/issues. This issue is about addressing paying for max users and renewing for less than max users. Let's solve that.
I plan to create a new issue discussing the true-up policy.
@ChadMalchow@regisF I'm wondering if the new max_historical_users field should be present only when customer are manually renewing their subscription through the portal or they also should be able to apply a True Up at anytime? I'm thinking in the case when the subscription has been automatically renewed and the license key is invalid, should customers contact sales in this case? Sales can manually generate a True Up and the new license key will be automatically delivered with the right data.
I would prefer to have this only available when renewing the subscription otherwise is going to be a bit tricky to know what was the original number of seats.
@rdavila agree that the true up should be at renewal. Customer should be able to add more seats at anytime via the web portal. When they renew, we should show them what they need to true up and then ask what they would like to renew. If their license key is invalid the messaging should be to go to the web portal and add more seats, or they can always contact GitLab at renewals@.
Where I see this causing the most amount of support requests is coming from CE. After using CE for a few years and creating an account for every employee, contractor, customer and a few pets, an admin would legitimately trim their user base before signing up for EE. In this case, the historical Max makes no sense. Can we revise it to be the Historical Max EE Users?. So we only start keeping track of it after they install EE?
@DouweM@stanhu the above ticket is related to a migration from CE to EE. I'm wondering why we're populating HistoricalData on CE, also do you think is a valid work around to telling this customers to delete all the HistoricalData records before applying the first license to their EE server?
@stanhu you're right, I didn't checked well if we were doing this in CE, my bad. Then I think the problem is that some customers are trimming users after upgrading to EE and after the cronjob to populate HistoricalData has been run.
To add feedback: this makes the licensing rather confusing. We added a couple of operations folks to see if we could get them to use issues and the wiki because we thought it was relatively low risk. The section on blocked users in the faq (https://about.gitlab.com/license-faq/) really looks like it's implying that you can block a user if it turns out not to work out.
Basically, we were surprised at license renewal, and it felt like a surprisingly bad experience from gitlab.
@estsauver I'm sorry you feel that way and that you've encountered this bad experience. I'll update the FAQ in order to avoid this confusion in the future.
We switched to Gitlab (EE trial) last month, during which quite a few of the employees who aren't using gitlab signed up just to check it out. We've trimmed these down but now have to pay forever for them? even though they only signed in once at the beginning of the month?
@stanhu@ChadMalchow@DouweM Can we have a call to discuss this as it is still on going and has not been resolved. I think that people are getting confused between the purpose of "True-Up" and the problem we are discussing here. Should I speak with @DouweM or @stanhu.
@pidge@DouweM was a conversation had here and are their next steps on how we move forward so customer can renew properly, meaning pay for what they used the year prior and pay for what they need for the coming year.
@ChadMalchow Will book sometime in with @DouweM to discuss what the real problem here is as it has nothing to do with true-up and is causing an admin / resource headache.
Example scenarios (e.g. I had 100 users this past year, but I only need 50)
Stan Humarked the checklist item Update license validation to become max_historical_users <= historical_limit && current_max <= current_limit as completed
marked the checklist item Update license validation to become max_historical_users <= historical_limit && current_max <= current_limit as completed
Stan Humarked the checklist item We'll add a max_historical_users field in the payment_app and the customer will be required to indicate this field when renewing their license. as completed
marked the checklist item We'll add a max_historical_users field in the payment_app and the customer will be required to indicate this field when renewing their license. as completed
Stan Humarked the checklist item For old licenses, we preserve the old max historical check to preserve backwards compatibility as completed
marked the checklist item For old licenses, we preserve the old max historical check to preserve backwards compatibility as completed
Customers who are downgrading and haven't exceeded the limit of seats for the previous period.
e.g: For period 2016-2017 the customer bought a license for 100 seats and the historical max was always below that. Now the subscription is about to expire and the GitLab instance has only 50 active users so the customer only wants a license for 50 seats for the period 2017-2018. When the customer was going to upload the license a validation error was being raised because of the difference between the seats authorized by the license and the historical max.
Customers who added extra users in the previous period and need to downgrade at renewal.
e.g: For period 2016-2017 the customer bought a license for 100 seats, some months after the start of the period the Customer added 15 more users and a couple of months before the end of the period the Customer removed 30 users of his instance. Now the subscription is about to expire and the GitLab instance has only 85 active users so the customer only wants a license for 85 seats but he's also paying the true-up for 15 (115 - 100 from the previous period)seats. Without this fix the only way to make a license work is to generate it with 115 seats, now it's posible to extend a license for 85 seats and include the quantity (15) and date range (dd/mm/2016 - dd/mm/2017) of the true-up in the license key. The true-up info included in the license key can be read by GitLab and it will execute the proper validations based on it.