GitLab's open source program is part of the Developer Relations team. It consists of three sub-programs:
We track our work as part of the Developer Relations team roadmap. Our work aligns with quarterly objectives and key results. See the Developer 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 [email protected].
At no cost, members of the GitLab for Open Source Program receive a GitLab Ultimate subscription (self-managed or SaaS), which includes 50,000 compute minutes (users can purchase 1,000 additional compute 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.
[email protected] 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. 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 activating their subscription.
The GitLab for Open Source team processes applications according to the Community Programs application workflow.
Some users may need to input a VAT number when completing their program applications. GitLab for Open Source Program members can simply input N/A into the VAT field during registration.
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 for activating subscription.
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:
[email protected].When seeking to edit the GitLab for Open Source application page, find the appropriate file at data/solution_children/join.yml.
Members of the Developer Relations team use GitLab Service Desk to manage program members' support requests. Because these requests often contain sensitive data and personally identifying information, we file them as issues in a private project. When a new request arrives, Service Desk will label the issue as OS Program Support::Intake. When the ticket is under active review and remediation with a team member, that team member should assign it to themselves and add the OS Program Support::Open label. When a support issue is pending program member review and/or additional details, it should receive the OS Program Supprt::Pending label. And when a a support issue has been resolved, it should receive the OS Program Support::Closed label. View the current status of all open program support issues on a private project board.
Community Programs team members can access data regarding GitLab for Open Source Program applications via SheerID. These data are useful for understanding application trends, changes in application volume, and more.
To access a report:
https://my.sheerid.com/ReportingTimeline selectorMember OSS from the Program Name pulldown selectorUpdate buttonView a video tutorial of this process.
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 and complete a partner onboarding issue.
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 [email protected]. 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 [email protected]. 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.
Partners may 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.
Occasionally, partners must open support issues that contain sensitive details about their projects. To do this, they email the partner service desk at [email protected]. We then track these issues on the (private) GitLab Open Source Partners Support board.
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:
We track the status of this work with the GitLab Open Source Partners Editorial Queue.
Members of the GitLab Open Source Partners program are listed on the partner program landing page. Follow these instructions to add a new logo to the roster.
PNG format. Use a file naming convention that looks like partner-logo.file-name.png.partners.yml file and open it in an editor./static/nuxt-images/open-source folder in the GitLab codebase.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 Developer 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 Developer 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: