I spent some time reviewing GitLab features and determined that, by our Buyer-Based Open Core model, eighteen features that appear in seven different stages of the DevOps lifecycle ought to be open source.
When we rolled out our Buyer-Based Open Core model in , what we laid out is that features are assigned to each of our four individual tiers based on who the buyer of the feature is. Features that serve an individual contributor land in Core / Free. Features for managers land in Starter / Bronze, for directors in Premium / Silver, and executives in Ultimate / Gold. As we explain the reasoning on our pricing page ,
The feature is put in the plan based on what champion is most likely to care about it. Buyers make sense, since a higher-cost plan needs a higher-placed buyer.
This pricing model has served us well, and we’ve been committed to it. But, somewhere along the way, we failed to do an audit of many existing features. That’s what I did last month, and now I’m excited to share that after personally reviewing all features in each of our tiers we are open sourcing an unprecedented number of GitLab features .
This marks a major milestone in our efforts to empower the community to collaborate more robustly and to take our single tool for the DevOps lifecycle to the next level. From design management to package managers, managing multiple Kubernetes clusters to connecting related issues, we’re making it easier than ever for an individual contributor to have everything they need to plan, build, deploy, and secure their appication with GitLab.
It’s not enough to talk the talk – we need to walk the walk.
If we’re saying that our features are based on the buyer , then we need to make sure that the right features are in the right place. We’ve always been committed to our stewardship of GitLab as an open source project. By auditing the tier of features, we can better serve our open source community while more accurate aligning our business model. Our commitment to the open source community is why we will always work to move features down our tiers and doing so quickly and consistently.
We hope to unleash the power of everyone’s creativity
Our mission has always been that everyone can contribute . With new functionality available to all users, it’s easier than ever to contribute – contibute with GitLab, contribute to GitLab the application, or contribute to GitLab the company. See something, submit a Merge Request (MR).
We recognize that many users in our community have creative ideas on how to make GitLab an even better product. By partnering with the open-source community, we can open-source features even more quickly.
What’s moving?
Features from Plan, Create, Verify, Package, Release, Configure, and Defend are moving. This is a lot ) of features. While we’ve outlined all of these features that are ready to be moved to Core / Free, we need your help to move them.
The work to move the actual code to the open source part of the codebase is defined in issues that are linked from this blog post. These issues will go into the backlog for each of the respective product development teams and will be prioritized against new feature development. If having this functionality in Core / Free is important to you, we invite you to contribute yourself to speed up the process. We’re not just giving you permission to help us move this code – we’re asking you to help us move it.
Synchronize collaboration with
Plan
Issues are the primary way people collaborate on ideas and plan work in GitLab. By open sourcing these new features, we’re making it easier than ever to plan your projects. We can’t wait to see what you come up with.
Related issues : Connect related issues together.
(Export issues : Export issues from GitLab as a CSV and receive the CSV as an attachment to your default notification email. Issue board focus mode : Use this tool to plan, organize, and visualize a workflow for a feature or product release. It can be used as a Kanban or a Scrum board.
Service desk
allows your team to connect directly with any external party through email right inside of GitLab – No external tools required. With that, the complexity and inefficiencies of multiple tools are eliminated, significantly shortening the cycle time from feedback to software updates. We would love to hear how you leverage service desk in your workflows now that it’s open source. Build better code and branch powerfully with Create
Features from Plan, Create, Verify, Package, Release, Configure, and Defend are moving. This is a lot ) of features. While we’ve outlined all of these features that are ready to be moved to Core / Free, we need your help to move them.
The work to move the actual code to the open source part of the codebase is defined in issues that are linked from this blog post. These issues will go into the backlog for each of the respective product development teams and will be prioritized against new feature development. If having this functionality in Core / Free is important to you, we invite you to contribute yourself to speed up the process. We’re not just giving you permission to help us move this code – we’re asking you to help us move it.
Synchronize collaboration with
Plan
The machine you’re using shouldn’t limit how easy it is to develop.
We’re excited to bring down two features for developing in web-first environments.
The
(design management allows you to upload design assets (wireframes, mockups, etc .) to GitLab issues and keep them stored in one single place, accessed by the Design management’s page within an issue, ensuring issues are the single source of truth for everything required to develop a feature.
All together, these changes to create should make it easier to go from wireframe to MVC in the blink of an eye – independent of what machine you’re on – improving project efficiency.
Bring code quality to new heights with (Verify )
Code quality reports on MRs will be open source. Keeping your project’s code simple, readable, and easy to contribute to is difficult. Code quality on MRs makes this easier to do and maintain.
We’re delivering a set of package managers so all your packages can stay in one place:
Conan (C / C ) repository
With four incredible (Release) moving to Core / Free, you can be so confident in your releases that you deploy on Fridays (YMMV).
Canary deployments roll out the new version of your application to a small portion of your fleet. Incremental rollout allows you to first check how the new version of your application is behaving before increasing the rollout to (%.) Feature flags allow you to ship a project in different flavors by dynamically toggling certain functionality.
(Support for multiple Kubernetes clusters in Configure
With support for
Multiple Kubernetes clusters
, you will be able to easily deploy different environments, like Staging and Production, to different Kubernetes clusters. This allows you to enforce strict data separation. Bolster application security with Defend
Defend your apps and infrastructure from security intrusions. Network policies for container network security will be available to all users. With that, you can install network policies into GitLab-managed Kubernetes clusters to limit communication between Kubernetes pods.
We hope that by open sourcing these features we will make it easier for all users to treat GitLab as a single application for the entire DevOps lifecycle. We are thrilled about the limitless possibilities ahead of us as a community and we’re looking forward to collaborating closely with each of you!
Cover image by Rodrigo Soares
GIPHY App Key not set. Please check settings