GitLab's open source program is part of the Community Relations team. It consists of three sub-programs:
Our work aligns with quarterly objectives and key results. See the Community Relations project management page for more detail.
By empowering open source projects with our most advanced features, the GitLab for Open Source Program supports GitLab's mission to make the world a place where anyone can contribute. We help make GitLab the best place for open source projects to grow and thrive.
Send questions about the GitLab for Open Source Program to opensource@gitlab.com.
At no cost, members of the GitLab for Open Source Program receive a GitLab Ultimate subscription (self-managed or SaaS), which includes 50,000 CI/CD minutes (users can purchase 1,000 additional CI minutes for a one-time, $8 fee). Product support is not included as part of this subscription.
While members of the GitLab for Open Source Program receive features of GitLab Ultimate at no cost, they do not receive support as part of their subscription.
In order to be accepted into the GitLab for Open Source Program, applicants must:
Benefits of the GitLab for Open Source Program apply to a namespace. To qualify, every project in an applicant’s namespace must carry an OSI-approved open source license.
opensource@gitlab.com in order to discuss this exemption. Program members must obtain written permission from the GitLab Open Source Program team in order to use their licenses outside of program requirements.program-qualification-exception-request template. when filing the issue. Account Executives and their managers must approve the exception request. Customer Success Managers (CSMs) associated with the account should also be notified of the exception request.Upon acceptance to the GitLab for Open Source Program, all program members are subject to the GitLab for Open Source Program Agreement.
Applicants should submit the form on the GitLab for Open Source Program page.
As part of the application process, applicants must provide screenshots to confirm their eligibility. They should submit screenshots of:
For more specific instructions on obtaining and submitting required screenshots, see GitLab Docs.
Gitlab uses SheerID, a trusted partner, to verify that applicants meet the GitLab for Open Source Program requirements. In most cases, applicants receive a decision on their application within three to five business days of submission. During periods of high submission volume, processing an application requires up to ten business days. When verified, applicants receive a verification email containing specific instructions for obtaining their license.
The GitLab for Open Source team processes applications according to the Community Programs application workflow.
Yes. Program members must renew their memberships annually. If they don’t renew, their accounts will be downgraded.
We recommend that applicants begin the renewal process at least one month in advance of their renewal dates to ensure sufficient processing time. Note that applications will not be processed during U.S. holidays and responses may be delayed during those periods.
To request a renewal, program members should complete the program application. The team will use this form to determine whether the entity applying for renewal still meets the program's eligibility criteria. Whether applying to the program for the first time or renewing a pre-existing membership, applicants complete the same form.
The person claiming the renewal for the subscription must be the same person who created the subscription for this open source project or organization in the GitLab Customer Portal. If a different person wishes to initiate the renewal, the existing owner needs to transfer ownership of the Customers Portal account. If the existing owner is no longer able to transfer ownership or renew, the project should open a support ticket to change the owner of the subscription before initiating renewal.
After completing application form, verified applicants receive a verification email with instructions to obtain their subscription licenses.
Members of the GitLab for Open Source Program may also be interested in:
While GitLab for Open Source Program benefits do not include product support, program members can receive help with GitLab in a number of ways. In general, we recommend the following:
opensource@gitlab.com.When seeking to edit the GitLab for Open Source application page, find the appropriate file at data/solution_children/join.yml.
The GitLab Open Source Partners program exists to build relationships with prominent open source projects using GitLab as a critical component of their infrastructure. By building these relationships, GitLab hopes to strengthen the open source ecosystem.
Open source partners receive specific benefits by joining the program. GitLab benefits from these partnerships when open source partners provide valuable feedback and data on their use of GitLab, even contribute to GitLab's open core. All parties jointly benefit when they're able to collaborate on community outreach, co-marketing, joint announcements, and special initiatives.
Program members receive:
Members of the GitLab Open Source Partners program agree to:
While most partners are also members of the GitLab for Open Source Program, not all are (as some partners are commercial open source entities and therefore ineligible for the program). Most partners use GitLab Ultimate (either SaaS or self-managed); however, some prefer using the fully open source Community Edition because of their strong commitment to using only open source tools.
Membership in GitLab Open Source Partners program is largely by invitation. Members of the open source program team extend invitations to longtime members of the GitLab for Open Source Program, projects using GitLab in interesting and innovative ways from which others can learn, or projects with large communities and brand recognition already using GitLab for everyday operations.
Additionally, GitLab team members can nominate open source projects or organizations to become partners. To do so, they can simply open an issue in the Open Source Partners Program project and use the open-source-partner-nomination issue template.
The GitLab Open Source Partners Program project contains sensitive data and personally identifying information about program members. It is therefore accessible only to GitLab team members.
Work on the GitLab Open Source Partners program occurs in two primary locations:
Developer-level persmission inside it. It's the place where program members, GitLab team memebers, and the wider open source community can interact, collaborate, share, and build.We maintain email templates to help us interact with prospective and current partners. When an organization has joined the GitLab Open Source Partners program, we send a comprehensive program guide.
We maintain a confidential, non-public register of our partners' contact details so we can remain connected to them.
When partners join the program, we instruct them to submit key community contact information to the private partner service desk at ospartners@gitlab.com. The Open Source Program Manager responds to these requests and updates internal documentation.
We periodically request updated contact information from partners to ensure we remain connected to the proper community representatives.
We try to maintain partner registries containing the following community contacts:
Members of the GitLab Open Source Partners program who are also members of the GitLab for Open Source Program may be eligible for an extended-period subscription. The current extended subscription renewal period is 36 months.
Partners seeking extended-period renewals should email their requests to opensource@gitlab.com. If the request is urgent, please include [Urgent] in the email's subject line. Partners should use this template to format their requests:
Subject: Open Source Partner (Application/Renewal)
Subscription Term: 36
Number of seats you are requesting:
The license type to be issued (Self-Managed or SaaS):
List any change of ownership to the account:
(If account ownership details change, please send the new account holder's name, email address, and contact's mailing address)
When a request is processed and accepted, applicants will be asked to sign a $0 quote with a 36-month term. After that:
Gitlab's open source partners requesting support track most of their issues publicly. They do this via issue trackers located in the GitLab Open Source Partners group—most commonly the Community Support project. Here, fellow open source partners partners and GitLab team members can collaborate on supporting GitLab's open source partners.
Often, partners wish to open issues related to their work migrating infrastructure from legacy infrastructure to GitLab (for instance, note examples from KDE, Drupal, and Freedesktop.org). To create migration-focused issues, partners can use the open-source-partner-migration issue template.
The GitLab Open Source Partners program is a commuinity-focused marketing effort designed to highlight ways high-profile open source communities are using—and succeeding with—GitLab. As such, we aim to share partner stories whenever possible.
We do this in many ways, including:
When we publish new partner-related stories, we link to them on the GitLab Open Source Partners program page and the GitLab for Open Source solutions page.
We often connect with partners when we feel we can help them share stories related to:
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.
Step 1: Add a new org to the Organizations list
You'll need to add an entry to the data/organizations.yml file using GitLab's WebIDE.
Follow this format (you can copy and paste it at the bottom of the organizations.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
Step 2: Prep the logos
First, create two SVGs: one color, one grey:
*.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.Filters -> Color -> Greyscale. Click on Live Preview so you can see what will happen. Save your changes.logo_ORG Name.svg as detailed above.If you are not using Inkscape, aim for getting a greyscale image with Hex Color Code: Dark Grey #444444 and then export the greyscale logo as an SVG with a transparent background.
Next, optimize the SVGs 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.Step. 3: Upload the logo via WebIDE
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.
Step 4: Review the changes
Unfortunately, the review app will not automatically allow you to preview the new page. The app typically 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 open source 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.
Here's how to generate a link to preview the changes:
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://c_hupy-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://c_hupy-master-patch-24835.about.gitlab-review.app/solutions/open-source/partners. This link allows you to preview the MR changes for the c_hupy-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!
If your pipeline is green, ask someone to review and merge!
GitLab's open source program team also oversees GitLab's representation and participation in select industry consortia, as well as GitLab's sponsorship of select open source community events.
We define "consortium" as a group createdto further some technological cause. In the context of open source software, a prototypical consortium would be the Linux Foundation (LF), a non-profit organization founded in 2000 as a merger between Open Source Development Labs and the Free Standards Group, which hosts and promotes collaborative development of open source software projects.
Consortia are influential leaders in their respective ecosystems, as they often host conferences and underwrite programs that influence global conversations about particular technological developments. Participating in consortia enhances GitLab's brand—and helps align GitLab's engineering efforts with global efforts and trends.
While select consortium memberships fall within the purview (and budget) of GitLab's open source program, the Developer Evangelism team focuses on consortium marketing, working to integrate GitLab's overall community message and technical perspective into the most appropriate and effective industry conversations.
You can open an issue in the Consortium Memberships project. When you do, please use the membership-evaluation template to structure your issue. Open source program team members will evaluate your application using the following criteria. When we review the application, we'll assess it with these considerations in mind:
| Considerations | What we're interested in | Questions we're asking |
|---|---|---|
| Awareness opportunities | Size of the organization Frequency and impact of marketing opportunities |
How many authenticated and non-authenticated users are visiting organization's website monthly? How many people are part of the organization’s community? What sorts of marketing and communication channels (social media platforms, newsletters, blogs, events) does the organization use? Will GitLab appear in those official channels? How prominent would our placement be? |
| Ease of collaboration | Access to a dedicated marketing resources/point person Time-to-execute for standard communication types |
Does the organization have marketing capacity? How mature is the organization's brand and marketing portions? How quickly can this organization produce a resource (e.g., a case study)? A week? A month? A quarter? How responsive is the person in charge of the relationship? Is marketing handled by volunteers or paid employees? |
| Contribution and hiring pool | Size of contributor/member base Overall community/member activity Frequency of community contribution Rate of adoption |
How active is the community the organization is attempting to foster? Does the organization have a sense of its community's health? Do we see hiring opportunities opportunities to recruit from the community's talent pool? What is the growth of the community or foundation itself? Do we see job opportunities within that software ecosystem (are people hiring contributors from this community in general)? How can GitLab contribute in ways that align with our interests? Can GitLab participate in the project's roadmap in ways that creates mutual value? |
We are currently members of the following consortia:
Complete details of GitLab's activities with these groups are available in the Consortium Memberships project. Note that because this project contains sensitive data and personally identifying information, it is only accessible to GitLab team members.
Some of the consortia in which we participate allow members to run for their respective Boards of Directors. Anyone interested in becoming more involved in any of the consortia GitLab supports should visit the Consortium Memberships project and open an issue.
Review the information below if you're thinking of seeking nomination for (or election to) consortium positions.
Internal nominations
The Community Relations team tracks consortium board elections closely. In the event that an election opportunity arises, the team will create a confidential issue in the Consortium Memberships project to discuss it. The team will determine which GitLab team member(s) could serve effectively in the elected position. Their considerations prioritize the following criteria:
The team will connect individually with the top candidate it feels would best suit the role given the above requirements, then ask that individual about their willingness and availability to serve. Candidates should consider the required time investment and their capacity for attending board meetings and representing GitLab at consortium events. Should the candidate wish to serve, the team will confirm the selection with the marketing organization leadership, then work with the nominee to prepare all requisite paperwork and craft a nomination statement. The team maintains a list of candidacy statements for reference and aid in this process. Should the candidate defer due to time or other constraints, the team will connect with the next person on the priority list given the above criteria.
Campaigning
Once GitLab candidates are nominated, the Community Relations team can help them campaign for their positions. We'll make other GitLab team members aware of the election and equip them to assist your campaign, too (e.g., by announcing the campaign on the #whats-happening-at-gitlab Slack channel).
Promoting
The social media team is able to promote elections notification news. They simply need a place to point people, preferably an updated webpage that lists the board of directors or a social media post from the organization that mentions the election results.
GitLab's open source program maintains a small budget for sponsorship of events that allow GitLab to engage with open source communities. We typically allocate this budget for local and regional community-driven events that GitLab's corporate events and field marketing teams have not already agreed to sponsor and staff. We prefer to sponsor events at which multiple open source projects and communities are present.
The open source program team tracks event partication in the Open Source Marketing project on GitLab. To suggest an open source event sponsorship, open an issue in this project and use the event issue template to file your request.
Event organizers and consortium leads working with GitLab will find GitLab's brand-related assets (such as logo files, press release boilerplate, and trademark information) in GitLab's press kit.
Our team measures the success of our work in the following ways.
The GitLab for Open Source Program can only succeed when it serves a growing and satisfied body of members. We therefore track program enrollment closely using the Open Source Program dashboard on Sisense. The dashboard reports the number of unique licenses we've issued as part of the program, the number of unique projects enrolled in the program, our annual renewal rate, and more.
This dashboard pulls data from Salesforce. GitLab team members with access to Salesforce can view a custom report for more detail on program accounts.
We also track (and, when necessary, participate in) Hacker News discussions related to both our open source programs and partners. Examples include: