which software are people using for license management (if any?)
What assumptions do you have?
License management is managed by project admins, consumed by developers
it is more important in MR when adding new code rather than once it is merged
Ultimately, what would you like to get out of the research?
Figure out if we should iterate more after the MVP, and in which direction.
What's the latest date that the research will still be useful to you?
We are going to ship an MVP in 11.2, so the sooner the better since we don't want to stop iterating if the research will show that the MVP is not enough.
Progress
Write survey questions
Import survey questions into SurveyMonkey
Test survey logic
Write email to accompany survey
Distribute survey to a test sample of users from the research panel
Review answers and make any necessary amendments [Deadline: Tuesday 4th September]
Distribute survey to the rest of the research panel [Deadline: Tuesday 4th September]
Sarah out of office from 11th Sept-23rd Sept. Will provide an update before vacation.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
do you think it is possible to start this research in %11.3? Thanks!
We have some hefty research efforts planned for the next 3-6 months. @sarahod @katokpara, what are your thoughts here given our current workload and limited capacity?
@sarahod, @plafoucriere says @leipert would be a good resource to reach out to for this issue. He has lots of experience with License Management from what I was told.
Yes, I did license management @ previous employer. Happy to hop on a quick call to support you if needed, or write down details async, whichever you prefer!
Thanks @bikebilly. Unfortunately, I've slipped a little behind on this issue (due to other issues unexpectedly taking a little more time than planned). The good news is that I'm currently working on the script for testing. I should be able to share it with you shortly, it would be great to get your feedback on it to make sure I'm answering all the questions you have.
As License Management is a new feature and limited to Gold and Ultimate users, I suspect that current usage of License Management is possibly quite low. It's worth gaining an understanding of how competitor tools are performing, as we may chose to use these insights to drive improvements within GitLab and ultimately 'win over' users.
- which are the most important features that should be improved?
Questions 8, 9 and 12
- is having blacklists/approvals at project level enough, or do we need per-branch?
Question 4
- is group-level license management something users need?
Question 4
- is blocking pipelines on conflicts something that should be enforced?
Question 5
- is the license-centric approach better than the dependency-centric one?
I'm not sure I fully understand what you mean by this question. Please could you explain it a little further? I want to make sure I address it correctly.
@bikebilly I’m on vacation from tomorrow, 11th Sept until 23rd Sept. The survey is still steadily receiving responses, so I'd like to leave it running whilst I'm away. However, I wanted to provide a quick update on results so far:
License Compliance is the lead name for the feature at the moment (49%), followed by License Management (39%).
64% of users stated that it is very likely or likely that they would use License Management.
The users who stated that they wouldn't use License Management have no requirement / need to use it (88%).
79% of users feel licenses should be approved or blacklisted at a project level (via the merge request widget) as they are now.
61% of users feel blocking pipelines on conflicts should be enforced.
79% of users aren't currently using any form of license management.
95% of users haven't tried GitLab's License Management feature.
I'm very aligned with Allow licenses to be approved or blacklisted at a group level via settings.
Support for additional packages is probably not possible since we are relying on an external tool, but this is a very good feedback since we may want to replace/integrate with something that has those languages included.
I'm trying to understand how important is the name change, as it would impact so many places that we should consider it carefully. The current name is already in place so the cost of the change is higher. What do you think?
I'm very aligned with `Allow licenses to be approved or blacklisted at a group level via settings
Awesome, that's great to hear!
Support for additional packages is probably not possible since we are relying on an external tool, but this is a very good feedback since we may want to replace/integrate with something that has those languages included.
Glad it's of use!
I'm trying to understand how important is the name change, as it would impact so many places that we should consider it carefully. The current name is already in place so the cost of the change is higher. What do you think?
Yes, I completely understand. Given the low adoption rate but a high desire to use License Management, I think the name is potentially deterring users from using the feature - they perhaps don't understand what we mean when we say 'License Management'. Obviously, I'm coming at this more from a UI/UX perspective.
@dangordon - What are your thoughts on this? I know you originally raised some concerns with the feature name. What are the consequences of changing the term in blog posts, our documentation, etc? Can you provide any insight into how you think we're currently performing with the term 'License Management' from a marketing perspective?
This is more a question for @cblake as this feature (License Management/Compliance) currently falls into her realm of product marketing I believe.
However, I'll echo my thoughts from before that it would be a problem (cause confusion) to call it license management, as this already means something else in IT circles, and it's not what we're offering. Now there is seemingly more evidence to support this. The cost to "fix" this will only get higher and higher the more we use the wrong term. So yes, it might be costly now, but it'll be more so if we continue to wait. And there won't be any more clear an indicator that we need to change it. The feature will just quietly not get used and/or provide the value it is meant to, customer-wise and marketing-wise.
From this perspective, I'll strongly re-iterate that we should be deciding what to call this from the outside-in perspective (i.e. what do prospects/customers think/expect). If the feature dies on the vine because customers don't understand what it is (or worse, think it's something else that they don't need) then we've done a disservice to the feature and everyone who's worked on it.
I agree with @dangordon . License management would normally be employed by the software vendor to ensure compliance with license agreements.
Wikipedia has a good explanation: "A license manager is different from a software asset management tool, which end-user organizations employ to manage the software they have licensed from many software vendors. However, some software asset management tools include license manager functions. These are used to reconcile software licenses and installed software, and generally include device discovery, software inventory, license compliance, and reporting functions."
Wiki also explains Software Asset Management as "Software asset management (SAM) is a business practice that involves managing and optimizing the purchase, deployment, maintenance, utilization, and disposal of software applications within an organization."
In my mind, we need to decide if we want to play in the category of Software Composition Analysis. Wiki does not yet have that term and Whitesource, Blackduck and Veracode are pushing the term to mean security of open source components. For example and Whitesource gives a definiton: "Software Composition Analysis (SCA) is a relatively new industry term for a set of tools that provides users visibility into their open source inventory."
To summarize, I believe License Management is incorrect relative to what we do and our vision. We should either use License Compliance, Software Asset Management, or Software Composition Analysis. If we are not pressed for time, perhaps @Tompsett could arrange an inquiry for us with an analyst to get their take on it? I would ask both Gartner and Forrester as Gartner will be a laggard and Forrester (or 451?) more of a thought leader.
This should give you a definition of what Forrester means by it, and more importantly the criteria by which Forrester considers vendors to be providing this capability. I would start there and then go with a follow up inquiry to Forrester.
Gartner says this: "Application security testing evolves from supporting basic web app testing to enabling DevSecOps, and securing mobile and single page apps. Security and risk management leaders must select AST solutions focusing on SDLC integration, software composition analysis, automation and speed." As @cblake suggests - they don't really have a lot on SCA at the moment. It gets lumped into Application Security Testing.
If we are not pressed for time, perhaps @Tompsett could arrange an inquiry for us with an analyst to get their take on it? I would ask both Gartner and Forrester as Gartner will be a laggard and Forrester (or 451?) more of a thought leader.
@bikebilly What do you think? Would this provide some more reassurance?
Just to provide everyone with a bit more context about how we tested the name of the feature:
Users were provided with a description of the feature which was paraphrased from GitLab's documentation.
We asked users: Based on the description, what would you name this feature? We received 100 responses and the full results were as follows:
License Compliance: 49%
License Management: 38%
Software Composition Analysis: 4%
Other: 9%
The most common 'other' response was: License Validation.
It seems more and more clear that this topic deserves to be addressed. We are even having confusion internally in our issue tracker, where the ~"license management" label has been misunderstood and misused to label issues in the ~"devops:manage" area (cc @jeremy_), see for example this list.
From the research license compliance seems the best candidate (49%), even if the current one (license management) is not so low (38%). So probably the market trend could be the main factor to go for the name change.
SCA is interesting, and we absolutely want to provide this functionality. Anyway, this is a "composed" category where dependency scanning and license management (compliance) are considered together. We mention it here.
The main problem with it is that we are focusing on many security features, and license management (compliance) is not related to security at all. If we use SCA, we should package togethere dependency scanning and license management, but this will make harder to keep dependency management also packed with SAST, DAST, etc. That's why I'd prefer to use a specific name for license management (compliance) instead of using SCA, still advertising SCA as a composed feature that we support.
Forrester mentions license risk management as the "subfeature" of SCA in their wave. It seems that there is still no well recognized name for the feature, even if the definition is quite clear.
I suggest to go with the inquiries and then take a decision based on those.
Thanks for pointing this out, I'll create a ~subscriptions label so this term isn't as overloaded Sorry for the noise!
I think that's a more relevant term for ~Manage issues, which are mostly related to billing and subscriptions (how customers pay for GitLab). These involve GitLab licenses and the license app, but are not nearly as related to the term as ~"license management" features are in Secure.
I moved all Manage ~"license management" into ~subscriptions. I also just noticed that there's a project-level ~license label in gitlab-ee that I'm deprecating now.
@sarahod since the name change is now addressed in different issues and will require more discussion and some time for the inquiries, I suggest report the results in the issue description, finalize the last unchecked boxes and close this issue.