GitLab Version Control & Collaboration, 23 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: VC&C Market Requirements

Description

Definition of Market Requirements, where they are sourced from and which ones apply to the VC&C use case.

A

Hello, uh let me explain what market requirements are in general and uh specifically the ones that apply to the virgin control and collaboration use case. So, as you all know, the use case is a customer problem or initiative doesn't have to be negative. That is attached attached to it. A a dollar sign, a a will to solve it, and it's defined in cost customer terms um in in real life, conversations with clients or prospects talking about the version, control, collaboration use case or any other new use case.

A

You don't get the full version of it, not usually clients or prospects or or anyone interested in this use case does not have the need for all of it, or at least they don't express it that way right.

A

So that's uh why we came up with the with the definition of market requirements, so those are the comp, the basic components of each one of the of the use cases. uh In the case of the version, control and collaboration use case, you will find them listed here in the table that uh titles them in a very, very dull way by the way. That's that's my uh those are my titles mostly, and they could be. They could be better a description of what uh the market requirement is.

A

The typical features in git lab that serve that requirement and the value obtained by the client by solving by serving being served that market requirement.

A

Beware: market requirements are sourced from the market, so gitlab might not be there yet we might not be serving or solving all of the market requirements listed here here, uh which is okay. uh Market requirements are sourced from analysts. We meet with plenty of analysts that uh tell us what the meetings with the rest of their clients uh uh are are making them see what the requirements are. So analysts work for us as aggregators of of the demand side of the market of they represent many many potential clients and many many potential uh prospects.

A

uh We we source them from competitors. We know that competitors, let us know through public documentation what they are, what they consider market requirements and how they are serving them.

A

uh We know this through uh meetings with clients, etc. So this is an outside in exercise. So again, you might see that some market requirements have a very short list of features that serve them or solve them in gitlab, which is okay, we might not be there, we might not even never serve them. That doesn't mean uh that gitlab must go this way, so the seven market requirements for version, control and collaboration are protecting secure assets.

A

So one of the main things that uh someone seeking for a virgin controller collaboration uh solution is is to have their ip protected and secured, and by iop I mean mainly source code. Yes, but not only source code could be binaries, it could be.

A

It could be uh images, it could be anything that is required to build the software they are delivering has to be enterprise ready. So it has to be solid, uh scalable at a global continental scale, uh always available, or at least as available as possible, with disaster recovery uh solutions, etc.

A

It must support numerous assets, so it should be able to be an integrated solution again, not only source code and the workflows required for source code at which, for example, gitlab excels, but actually uh design and new workflows to collaborate over designs data and the workflows required to collaborate on data.

A

It should foster collaboration, so it should be designed to minimize manual tasks when when, when we're talking about notifications or stuff, that should not require brain cycles uh and it should be able to connect the different partners, the different roles, uh the different permissions uh in an orderly fashion, to foster collaboration, approvals, etc, etc. Cooperation reviews all those types of activities that happen at a group level with different uh uh with different with it, with a hierarchy among the group.

A

Those should be those those activities should excel at a version, control and collaboration uh solution. It should also allow for secure development so again pre-compile activities that bring security to the source code.

A

Those would be secret scanning, license scanning static, scanning, etc, and it should also be able to allow the description of a software or systems architecture so via diagrams and so on, and the ability to define that or to trickle down into into a reality. So any software defined element of that architecture should be able to be hosted in a repo in a package registry wherever it may be.

A

A