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.
Members of the GitLab for Open Source Program receive the following benefits at no cost:
While members of the GitLab for Open Source Program receive GitLab Ultimate at no cost, they do not receive support as part of their license.
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. Technical Account Managers (TAMs) 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.
The GitLab for Open Source team will then follow the community programs application workflow to process applications.
When verified, applicants receive a verification email containing specific instructions for obtaining their license.
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 email a renewal request to opensource@gitlab.com. If the request is urgent, please include [Urgent] in the email's subject line.
A renewal request should use the following template:
Subject: Renewal Request | Date of Expiration (MM/YYYY)
To help us find your account:
* Name of your organization or project:
* Email associated with this account:
To help us make sure you still qualify:
* Link to your publicly visible GitLab instance:
* Link to one of your OSI-compliant licenses:
* Written acceptance of this statement (Include this sentence in your request):
`I confirm that my organization does not seek to make a profit from this OSS project`
To help us plan for next year:
* Number of seats you are renewing:
* Please verify the license type to be renewed:
* Please attach a PDF version of last year's quote if available
* 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 renewal request is processed and accepted, applicants will be asked to sign a $0 renewal quote. After that:
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. Use the GitLab Community Programs support workflow to determine which is most useful in your case.
In general, we recommend the following:
opensource@gitlab.com.The following active SKUs are related to the GitLab for Open Source Program:
[OSS Program] SaaS - Ultimate (formerly Gold) - 1 Year[OSS Program] Self-Managed - Ultimate - 1 YearThe 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:
GitLab Open Source Partners, a public group and the default location for program activity. Program members receive access to the project and 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.
Open Source Partners Program, a private project accessible only to GitLab team members. This project is private because it contains sensitive personal data pertaining to open source partners and features a private service desk exclusively for GitLab Open Source Partners working on non-public issues. See the Community Relations Program Management handbook section to learn more.
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
Create an issue for each nomination so GitLab team members who are also interested in running can discuss, and so additional internal nominations can occur. Community Relations, Alliances, and Marketing leadership (CMO, Director of Corporate Marketing) teams will likely be involved. Prepare a nomination statement that explains your interest in joining the board. Post this as part of your issue so our internal teams can help you polish it.
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.
We are exploring ways to partner with the Linux Foundation to make it easier for Linux Foundation member projects to apply for and qualify for the GitLab for Open Source program. We are using the Linux Foundation to collaborate with their team on various initiatives.
The application process for LF members projects can be found here.FIXME
Note: In addition to having the Linux Foundation as an Open Source Partner, we are a paying member of the Linux Foundation through their consortium membership program.
Our team measures the success of our work in the following ways.
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:
We keep track of OSS impressions in the OSS Impressions Dashboard.
This dashboard takes into account:
The dashboard is generated by the content in:
We only use cumulative metrics in external presentations as per our communication guidelines (#8 of presentation section).
OSS cumulative metrics are kept in a spreadsheet: OSS Cumulative Metrics. They include the number of new projects and new seats per fiscal quarter.
To generate these cumulative graphs:
New projects enrolled per fiscal quarter and Number of new seats issued per fiscal quarter by clicking on the hamburger menu by each and clicking on Download Data.New Projects and New Seats. Paste the data from the relevant Sisene downloads there. This will generate new graphs that you can use to display cumulative metrics per fiscal quarter.We also track (and, when necessary, participate in) Hacker News discussions related to both our open source programs and partners. Examples include: