GitLab's open source program is part of the Community Relations team.
How to reach us:
@nuritzi on GitLabOn this page, you'll find information about the following sub-programs that are part of the open source program at GitLab. You'll find information about what they are and how they are run.
| Program Name | Description | Link to place in handbook |
|---|---|---|
| GitLab for Open Source Program | Qualifying open source projects get our top tiers and 50K CI minutes for free. Applications are processed according to the Community Programs Application Workflow. | Section 1 |
| Open Source Partners | A partnership program designed for large or prominent open source orgs | Section 2 |
| Consortium Memberships | These memberships allow us to show our technology thought leadership, help with our branding, and/or provide opportunities for engineering alignment | Section 3 |
Epics, issue boards, and labels are used to track our work. For more information on the specific ones we use, please visit the Community Relations project management page.
GitLab creates Objectives and Key Results (OKRs) per quarter. Here are the current OKRs for the GitLab for Open Source program.
We use the GitLab for Open Source KPI Dashboard on Sisene to track program metrics. This dashboard's visibility is internal to GitLab team members only and measures the following:
Current status stats: These stats give us an idea of how many active users we have as part of the GitLab for Open Source program.
Stats counted from program inception: Lifetime stats of how the program has performed since its creation.
Quarterly stats:
At GitLab, our mission is to change all creative work from read-only to read-write so that everyone can contribute.
The GitLab for Open Source program supports GitLab's mission by empowering and enabling open source projects with our most advanced features so that they can create greater impact and amplify the contribution mindset within their spheres of influence.
This program's vision is to make GitLab the best place for Open Source projects to thrive at scale.
Apart from actively maintaining and constantly adding value to the open source Community Edition, GitLab makes the Enterprise Edition's top Ultimate and Gold tiers available free-of-cost to qualifying open source projects.
More information about the program can be found on the GitLab for Open Source landing page.
Note: This program grants Gold features are the group level (these features are things like epics, roadmaps, merge requests, and other Gold features for groups). Any public project on GitLab.com automatically gets Gold features at the project level.
Priority Support. While our GitLab for Open Source program does not include paid support, members of the program receive a 95% discount on Priority Support. Support can be purchased for $4.95 per user per month by sending us an email to opensource@gitlab.com and requesting an add-on.
Migration Services. For open source communities that need assistance with their migration, our team provides a variety of services to help. Check out our professional services page for more information.
Additional services. We sometimes hear requests for services we do not provide, such as providing hosting for Community Edition instances. We've partnered with others to help expand the options for our users. Check out our Technology Partners to learn more.
The following SKUs are related to the GitLab for Open Source program:
In order to qualify, projects must meet the program requirements listed on the GitLab for Open Source application page.
Here are some guidelines that help us make decisions about whether or not projects qualify:
Examples of OSS projects that usually qualify:
Examples that usually do not qualify:
For more questions, please see our GitLab for Open Source FAQ or contact us at opensource@gitlab.com
Unfortunately, we are not able to accept all open source projects that are affiliated with the US Federal government. Projects that are affiliated must work with a Sales representative to see if they qualify.
From time to time, we make strategic exceptions to our program requirements, such as to the federal exception policy. These requests must be made by a GitLab Sales team member on behalf of a project.
Requests for qualification exceptions can be made by filing a new issue on the GitLab for Open Source program kanban board and selecting the oss-qualification-request template.
In order for this to be approved, both Account Executives and their Managers will need to sign off by checking the box next to their name in the submitted issue. If there is a relevant Technical Account Manager (TAM) associated with the account, they should be added to the issue in FYI so that they are notified of the exception request.
Qualifying open source projects can apply for self-hosted Ultimate or SaaS Gold by submitting the GitLab for Open Source application form.
We follow then follow the community programs application workflow to process applications.
For more information on what applicants can expect, please see the Application Process section of the GitLab for Open Source application form.
There are a number of organizations that offer open source programs with discounts or free services just for open source projects. Here is a list of some of the programs we know that have been useful to pair with the GitLab for Open Source program:
GitLab Docs are a great resource for our program members since our docs are the single source of truth and answer a wide variety of questions program members may face.
If program members are unable to find what they're looking for in our docs, we ask that they post their question in the GitLab Forum. There, they can interact with other members of our community and many GitLab employees. We encourage program members to join the forum even if they don't have questions so that they can meet other members of our community.
In line with our Transparency value, GitLab has an open roadmap, so our community can always see what's ahead in the product priorities.
Feedback helps us to build the best product possible. Whether it's a bug report, a feature request, or feedback to our company, here's a guide for how to submit feedback.
Make sure to Thumbs Up issues.
Our team looks at the number of Thumbs Up votes as an indicator for priority, so make sure you're using that feature on issues as a quick way to give us feedback. Writing detailed comments of your use-case and thorough issue desciptions is another way you can help make it easier for our team to understand your needs and respond to your questions.
Just search for relevant issues on the GitLab product project, and start giving us your feedback!
When the GitLab for Open Source program began, we kept track and publicly displayed the members who joined the GitLab for Open Source Program at https://about.gitlab.com/solutions/open-source/projects/.
To do this, applicants submitted a Merge Request to the GitLab OSS project. Whenever the applicant was approved, and as part of the process, the project was added to a master list on the /gitlab-com/marketing/community-relations/gitlab-oss repository.
Unfortunately, the open source project list is now outdated because of the following reasons:
This section talks about how we used to update the open source project list so that we preserve this knowledge as we plan for future iterations of an open source project directory.
While the original Merge Request process was ideally meant to keep the list updated, there was also a manual step involved in transferring the file from the /gitlab-com/marketing/community-relations/gitlab-oss repository to the GitLab's website repository.
These additional steps were required to update the GitLab for Open Source members list on the website:
/gitlab-com/marketing/community-relations/gitlab-oss repositorydata/oss_projects.yml file At this time, the master list on the /gitlab-com/marketing/community-relations/gitlab-oss repository is only updated for applications, not for renewals. As such, it might contain data from projects who initially applied for the program but did not renew their yearly license.
The GitLab Open Source Partners program seeks to build relationships with open source projects that have thousands of community members or users (or more).
Through our partnership, we aim to gain insight to help us build a better product and navigate the challenges of being an open core, for-profit company. We also aim to create greater outreach through co-marketing and special initiatives.
Full program benefits and requirements can be found on the GitLab Open Source Partners landing page.
We have Open Source partners that use a variety of GitLab's products. In addition to Gold and Ultimate, some of our Open Source Partners use the Community Edition instead of the Enterprise Edition because of their strong FOSS values.
Hi [Name],
We'd like to invite you to join our GitLab Open Source Partners program [1]. This program's aim is to feature your project in blogs, at GitLab events, and more, while also helping us engage with your community more regularly and learn more about your experience using GitLab. Since you're already part of our GitLab for Open Source program [2], and are a prominent open source project, we would love to have you as an open source partner. Just as an FYI, there are no membership dues for this program as it is completely free of cost.
Please let me know if you're interested in connecting to learn more about this partnership opportunity. Feel free to grab time on my calendar for a short call: [calendly link], or if you prefer to chat more via email, we can do that too.
Best, [Name]
We use public migration tracker issues to help our OSS Partners through and beyond migration.
Public migration tracking issues help us understand which issues are blockers, urgent, important, and nice-to-have for our OSS Partners. It also has the added benefit of helping them get used to our workflow so that they can start giving us product feedback and helping us improve the product together.
Follow these steps to create a public migration tracking issue:
gitlab.com/gitlab-org/gitlab projectMigrations template in the description section where it prompts you to select a template, and click on Apply templateExamples of public issue trackers:
Our Open Source Partners are shown on the Open Source Partners page and the main GitLab for Open Source program page. These are the steps to add a new logo to those sections.
You'll need to add an entry to the data/customers.yml file using GitLab's WebIDE.
Follow this format (you can copy and paste it at the bottom of the customers.yml file):
- name: ORG NAME
logo: /images/organizations/logo_ORG NAME.svg
logo_color: /images/organizations/logo_ORG NAME_color.svg
industry_type: 'open source software'
home_url:
landing: false
opensource_partner: true
Example:
- name: Inkscape
logo: /images/organizations/logo_inkscape.svg
logo_color: /images/organizations/logo_inkscape_color.svg
industry_type: 'open source software'
home_url: https://inkscape.org
landing: false
opensource_partner: true
*.svg) version of the logo in the official channels (e.g. the ARM trademarks page has SVG as one of the download options). If you can't find the SVG file on their channels, you may need to Google it and find one on Wikimedia Commons. Download the original file.logo_ORG Name.svg – Example: logo_inkscape.svg. This will be the greyscale image that will be shown on the customer reference page.logo_ORG Name_color.svg – Example: logo_inkscape_color.svg. This will be the color image that displays on the Open Source Partners page.#444444logo_ORG Name.svg as detailed above.Do this for both color and grey logos:
Prefer viewBox to width/height factor is toggled On. It should be near the bottom of the list of optimization factors.source/images/organizations and upload the two prepped logosOnce you've completed these steps, check to make sure that the pipleline works, and check out the preview. If it looks ok, have someone review and merge!
Unfortunately, the review app will not automatically show you the preview. Here's how to generate a link to preview the changes.
The View App lets you preview your changes. It detects which files have been changed, and then creates a URL, or a set of URLs, pointing to the built pages with the changes.
Since this type of merge request (adding a new logo to the OSS partners page), does not change any HTML files, the View App does not know where to point to. It defaults to the GitLab home page.
Since the View App points to the GitLab home page for this build as mentioned above, we need to add the path to the webpage you'd like to preview.
To do this, you need to be familiar with four parts of the View App URL:
https:// – it doesn't include "www".about.gitlab-review.app – this is what builds the previewExample:
https://nuritzi-master-patch-24835 (branch name).about.gitlab-review.app/solutions/open-source/partners (path to the webpage I want to preview)This formula creates: https://nuritzi-master-patch-24835.about.gitlab-review.app/solutions/open-source/partners. This link allows you to preview the MR changes for the nuritzi-master-patch-24835 branch on the GitLab Open Source Partners page.
For ease of use, here's the formula:
`https://` [your branch] `.about.gitlab-review.app` [rest of the path to the page you want to build]
You should now be able to create preview links when the View App doesn't work!
The Open Source Program Manager worked with the Content team on an editorial strategy to meet the needs of the Open Source Partners program. Posts about technical content and open source partner migrations tend to be very popular, so the Content team collaborates by brainstorming topics and doing reviews.
The plan is to publish posts on the GitLab Blog that are related to the Open Source Partner program and to feature these on the Open Source Partners page.
Marketing opportunities:
Resources:
| [Template | OSS Partner Use Case Blog Posts](https://docs.google.com/document/d/1oRwrwoo6PkuqafAsde11mqCnMvAI2KNZ9E7AfnGg9Fw/edit#) - includes template blog post questions to ask OSS Partners in order to publish posts about migrations, CI/CD, Security, and Project Management use cases. |
We define Consortiums as (often open source) groups that have come together to further a technology cause. The prototypical Consortium would be the Linux Foundation (LF), which is a non-profit technology consortium founded in 2000 as a merger between Open Source Development Labs and the Free Standards Group. The Linux Foundation's mission is to standardize Linux, support its growth, and promote its commercial adoption. It hosts and promotes the collaborative development of open source software projects.
Consortiums are marketing giants in the enterprise technology ecosystem. The success of the Cloud Native Computing Foundation today, the OpenStack foundation in the past, and many others, prove the value of technology thought leadership, branding, and engineering alignment. While these memberships sit within the budget of the Community Team's Open Source program, the Developer Evangelism team focuses on consortium marketing and integrating into the community to bring the GitLab technical perspective to the right conversations.
Here are some of the factors we keep in mind when considering to join a new consortium:
| Goals | Indicators | Examples of Indicators |
|---|---|---|
| Awareness Opportunities | Size of organization / contributor / member base: how many people are part of the organization’s community? | Monthly authenticated vs. non authenticated users visiting the sit. Annual users who perform a contribution activity of any kind. Annual users who perform a code-related contribution activity |
| Frequency and impact of marketing opportunities: what kind of communication channels do they have? Will we appear in official channels? How prominent is our placement? | Channels may include: Social, Newsletters, Blogs, Events (Size of each event) | |
| Ease of Collaboration | Dedicated marketing resources / point person: Does the organization have marketing capacity? | How mature is the organization's brand and marketing portions? Is marketing handled by volunteers, paid employees? |
| Relationship: how responsive is the person in charge of the relationship? | An alternative metric might be: Time-to-Execute for a few standard communication types. For example: from case study ideation to execution - 1 week? 1 month? 1 quarter? | |
| Understanding of community gates: Can the foundation approve directly - is there a community feedback process, is board approval required, etc | ||
| Contribution and hiring pool opportunities | Active community: How active is the community and do they know their own community’s health, engagement, etc? | Frequency of contribution? Rate of adoption? |
| Hiring opportunities: Are there opportunities to recruit from the community's talent pool? | What is the growth of the community or foundation itself? Are there job opportunities within that software ecosystem (are people hiring contributors from this community in general)? Are there job boards, or other professional development activities? | |
| What kind of informal and formal ways are there for us to contribute, and do they align with our interests? | Working groups? Advisory boards? Special initiatives? | |
| Can GitLab participate in the project's roadmap in ways that creates mutual value? | Example: Promoting adoption of GitLabCI to improve project testing and also expose contributors to GitLab's tools for their day-jobs/for-profit ventures. |
We are currently members of the following consortiums:
| Consortium | Level |
|---|---|
| Linux Foundation | Silver - board seat |
| Cloud Native Computing Foundation (CNCF) | Silver - board seat |
| Fintech Open Source Foundation (FINOS) | Silver |
| Continuous Delivery Foundation (CDF) | General |
Full details of our memberships with these organizations is available to GitLab team members only: Community Relations Consortium Memberships.
We have a small budget to sponsor events that allow us to engage with and build relationships among our current open source partners' communities. All other event sponsorship requests, are handled by our field marketing team.
