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.
  • GitLab Open Source Partners, a partnership program designed for large or prominent open source projects and organizations.
  • 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.

GitLab Open Source Partners

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.

FAQs

What are the benefits of being a member of the GitLab Open Source Partners program?

Program members receive:

  • Public recognition as a GitLab Open Source Partner
  • Direct line of communication to GitLab
  • Assistance migrating additional infrastructure to GitLab
  • Exclusive invitations to participate in GitLab events
  • Opportunities to meet with and learn from other open source partners
  • Visibility and promotion through GitLab marketing channels

What are the requirements for being a member of the GitLab Open Source Partners program?

Members of the GitLab Open Source Partners program agree to:

  • Engage in co-marketing efforts with GitLab
  • Complete a public case study about their innovative use of GitLab
  • Plan and participate in joint initiatives and events

Who qualifies for the GitLab Open Source Partners program?

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. GitLab team members can nominate projects as partners by opening an issue in the Open Source Partners Program project and applying the appropriate issue template 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.

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.

Program management resources

Managing projects

Work on the GitLab Open Source Partners program occurs in two primary locations:

Welcoming new partners

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.

Collecting and managing partner contact details

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:

  • Primary: The person representing the project and/or community at meetings and serving as our principal connection to the project.
  • Alternate: The person we can contact if we’re unable to reach the primary contact.
  • Marketing: The person we contact when partner event and marketing opportunities arise.
  • Technical: The person we contact regarding participation in surveys or focus studies that require technical expertise, or when something at GitLab may require input from technical contacts at open source partner organizations.
  • Legal: (optional) The person we contact to weigh in on legal matters, such as updates to terms of service agreements, partnership activities, or permission to use a project’s logo.

Renewing and extending partner subscriptions

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. 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:

  • For Saas: No further action is necessary.
  • For Self-managed: Applicants need to download licenses from the GitLab Customer Portal and upload them to their instances.

Tracking partner issues

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 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 osspartners@gitlab.com. We then track these issues on the (private) GitLab Open Source Partners Support board.

Sharing partner stories

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:

  • posts on the GitLab blog
  • case studies for GitLab.com
  • webcasts and webinars for GitLab’s video channels
  • event showcases and presentations

We tag partner-related stories with the open-source tag on the GitLab Blog.

We often connect with partners when we feel we can help them share stories related to:

  • Their plans to migrate infrastructure to GitLab
  • Their success at migrating infrastructure to GitLab
  • Their innovative use of GitLab to build something notable or solve a technical/social challenge for their project and community
  • Their resolution of critical technical challenges that align with themes central to other GitLab marketing campaigns (e.g., CI/CD, security, or project management)

We track the status of this work with the GitLab Open Source Partners Editorial Queue.

Adding a new logo to the Open Source Partners program page

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.

  1. Retrieve the partner logo in the highest resolution available.
  2. Resize the logo so it conforms to something roughly the size of a 72px cube, then save it in PNG format. Use a file naming convention that looks like partner-logo.file-name.png.
  3. Load the partners.yml file and open it in an editor.
  4. Add the logo URL, image alt text, and partner landing page in accordance with the yaml convention in the file.
  5. Locate the /static/nuxt-images/open-source folder in the GitLab codebase.
  6. Add the resized version of the partner logo to that folder.
  7. Create a merge request to merge the updated partner roster and logo

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 October 17, 2024: Community Handbook Page (f9d50bbb)
View page source - Edit this page - please contribute. Creative Commons License