Open Source Program

Learn about the GitLab for Open Source Program and other open source programs from GitLab’s Developer Relations team

GitLab’s open source program is part of the Developer Relations team. It consists of three sub-programs:

  • GitLab for Open Source Program, through which qualifying open source projects receive benefits like features of GitLab Ultimate with 50,000 compute minutes for free.
  • Consortium Memberships, which allow us to extend GitLab’s leadership in key open source initiatives, enhance GitLab’s brand, and/or improve engineering alignment

How to reach us

What we’re working on

We manage program support requests in a dedicated internal project with its own issue queue and tracking board.

We manage program editorial work with in the open source partner editorial queue. We track this work as part of the Developer Relations team roadmap. See the Developer Relations project management page for more detail.

GitLab for Open Source Program

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.

FAQs

What are the benefits of the GitLab for Open Source Program?

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 calculated at a program-specific cost factor. Product support is not included as part of this subscription.

Who qualifies for the GitLab for Open Source Program?

In order to be accepted into the GitLab for Open Source Program, applicants must:

  • Use OSI-approved licenses for their projects: Every project in the applying namespace must be published under an OSI-approved open source license.
  • Not seek profit: An organization can accept donations to sustain its work, but it can’t seek to make a profit by selling services, by charging for enhancements or add-ons, or by other means.
  • Be publicly visible: Both the applicant’s GitLab.com group or self-managed instance and source code must be publicly visible and publicly available.

Please note: Benefits of the GitLab for Open Source Program apply to a namespace. To qualify for the program, every project in an applicant’s namespace must carry an OSI-approved open source license.

We make the following exceptions to our eligibility criteria:

Federal Exception Policy 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.

Private Project Exceptions In some cases, we allow program members to host a small number of private projects if those projects contain sensitive data. Members should send an email to 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.

Strategic Qualification Exceptions We may make strategic exceptions to our program requirements. A GitLab Sales team member must make this request on behalf of an open source project. To request an execption, create an issue in the GitLab for Open Source Program project using the 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.

What are the terms of the GitLab for Open Source Program?

Upon acceptance to the GitLab for Open Source Program, all program members are subject to the GitLab for Open Source Program Agreement.

How does someone apply for the GitLab for Open Source Program?

Applicants should submit the form on the GitLab for Open Source Program page.

As part of the application process, applicants must provide screenshots of their GitLab projects to confirm eligibility. They should submit screenshots of:

  • The project’s license overview
  • The project’s license contents
  • The project’s public visibility settings

For more specific instructions on obtaining and submitting required screenshots, see GitLab Docs.

How are GitLab for Open Source Program applications processed?

The GitLab for Open Source team processes applications according to the Community Programs application workflow. For additional information on program-specific workflows, see the Open Source Program Workflows page.

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. Note that applications will not be processed during U.S. holidays; responses may be delayed during those periods. When verified, applicants receive a verification email containing specific instructions for activating their subscriptions.

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.

Must members of the GitLab for Open Source Program renew their memberships?

Yes. Program members must renew their memberships annually. If they don’t renew, their accounts will be downgraded.

Subscriptions granted under the GitLab for Open Source Program do not auto-renew.

We recommend that applicants begin the renewal process at least one month in advance of their renewal dates to ensure sufficient processing time.

How does someone renew their membership in the GitLab for Open Soure Program?

Subscriptions granted under the GitLab for Open Source Program do not auto-renew. 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 their subscriptions.

Where can members of the GitLab for Open Source Program find support?

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:

  • Send questions or issues requiring immediate attention or sensitive information to the GitLab for Open Source Program team at opensource@gitlab.com.
  • Review GitLab Docs for answers to general product-related questions.
  • Post questions in the GitLab for Open Source category of the GitLab Forum, where community members and GitLab team members can review and discuss them.
  • File bug reports and breaking behaviors as issues for product teams to review and address.

Program management resources

Updating the program application page

When seeking to edit the GitLab for Open Source application page, find the appropriate file at data/solution_children/join.yml.

Managing the program support queue

Members of the Community Programs 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.
  • When 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.

Consortium Memberships and Sponsorships

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.

FAQs

What is a consortium?

We define “consortium” as a group created to 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.

Why is consortium marketing important?

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.

How does GitLab participate in consortium activities?

While select consortium memberships fall within the purview (and budget) of GitLab’s open source program, the Developer Advocacy team focuses on consortium marketing, working to integrate GitLab’s overall community message and technical perspective into the most appropriate and effective industry conversations.

How can I recommend GitLab get involved in a consortium?

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:

  • Awareness opportunities
  • Ease of collaboration
  • Contribution and hiring pool
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 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?

In which consortia is GitLab involved?

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.

Program management resources

Elections for Board of Directors opportunities

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:

  • Expertise and experience with the technologies we hope to influence as part of the organization’s board
  • Pre-existing relationships with current board members and member organizations that could aid electability
  • Tenure at GitLab and seniority in role at GitLab

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.

Event sponsorships

GitLab’s Developer Relations team 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 participation 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.

Measuring our success

Our team measures the success of our work in the following ways.

Program enrollment

The GitLab for Open Source Program team monitors the health and vitality of the program by tracking overall program membership and members’ annual renewal rates. We do this via the follwing Tableau dashboard:

The dashboard reports the Number of Licenses the program is currently administering, the number of Unique Accounts associated with the program, and the Institution Rewnewed rate.

GitLab team members with SAFE access to Tableau can view this reports for additional details.

Program member GitLab utilization

The GitLab for Open Source Program furnishes insights about the ways open source projects and communities use GitLab’s various features and functions. We therefore track members’ overal utilization of GitLab where possible. We do this via Salesforce according to the following reports:

GitLab team members with access to Salesforce and Gainsight can view these reports for additional details.

Support ticket volume and response

The GitLab for Open Source Program team manages program support tickets in a dedicated private GitLab project with corresponding Service Desk. Because the team is dedicated to providing quick, helpful service to program members, we measure both the volume of tickets we receive quarterly and the average time required to respond to those tickets. We do this via the following Tableau dashboard:

GitLab team members with access to Tableau can view this reports for additional details.

Impact on Hacker News

We also track (and, when necessary, participate in) Hacker News discussions related to both our open source programs and partners. Examples include:

Last modified January 16, 2025: Removing OSS Partner Program from the Handbook (8b342c96)
View page source - Edit this page - please contribute. Creative Commons License