Should we revise the GitLab data model to counter the emerging long-term competitive threat of software catalog solutions (Backstage.io) and provide an architecture for making the macro-level user experience best in class?
Hypothesis
As evinced by our initial evaluations of Backstage.io, a Spotify-created open-source project that’s now a CNCF sandbox project, the current GitLab model of groups/sub-groups/projects and the relationships that are derived from that should be reconsidered.
In Backstage.io for example, each group, each service, each component is its own object so this allows for easily creating and visualizing in the UI complex relationships. Adopting a similar construct could provide several benefits.
-
Counter the long-term market and competitive threat of software catalog first products like Backstage.io and Cortex.io.
-
Simplify the development of new features and capabilities to enable the delivery of the secure software supply chain vision and strategy.
-
Enable improvements in the macro-level user experience by creating a foundation that makes it simpler to add innovative, easy-to-use front-end features
Backstage.io has solved a problem that we haven’t solved yet, and that is how they can position their solution as unique. If we, GitLab, had started with a different model of showing ownership and relationships, then it would have made it more difficult for products like Backstage.io to be competitive in the market and start to develop mindshare as evinced by the list of companies that are adopters.
In short, thinking deeply about this now, determining if a change is required, and putting a plan in motion to implement a new construct over the next one to two years, will provide GitLab the foundational pillars, (the stamina), to compete and finish the triathlon ahead of the pack.
Proposal
Assign GitLab staff engineers to work on the following:
-
A deep dive analysis into the Backstage data model. The minimal output of the analysis is a summary of the pros and cons of the Backstage data model approach and a recommendation as to whether we should indeed start work on introducing changes to the GitLab model.
-
If the recommendation is proposed changes to the data model, then map out an iterative development and implementation plan.
Note This proposal assumes that there is likely overlap with already in-flight product development efforts and does not aim to be prescriptive but rather to initiate a broader cross-stage discussion.
What are the GitLab weaknesses identified to date that are addressed in the Backstage model?
Organizational (tech) overview:
-
Our (GitLab) model of groups/subgroups/projects is confusing and does not help users visualize or communicate.
-
Our model only structures “containers” in multiple 1:many levels, whereas Backstage is more deliberate about ownership and properties of each individual, and shows relationships more based on labels than levels.
-
The Backstage approach on the other hand, does a better job of visualizing structure of the team and the technology.
- In GitLab we have the groups/sub-groups/project model that can restrict how aspects can be visualized and communicated.
- This model makes it a one-to-many level type of experience and is very restrictive in the way that you do things. Whereas in Backstage, it seems to be more a flat list and they solve a lot of things with labels, attributes, which gives it way more flexibility and which helps them with visualization.
- For example - as soon as you drop into one project from the UI, how can you make it clear what aspects of the experience, the product, the tech does that team own. This is a big piece that is lacking in GitLab.
-
In the GitLab model we try and solve everything in the tree form. So its very tough to show connections between projects that don’t belong to the same top-level group our sub-group. So we each time have to go into extra solutions when we need to visualize data differently. However, the solution is not baked into how we think about organization and structure.
Dependencies
{placeholder for notes on dependencies}