GitLab's open source program is part of the Community Relations team. It consists of three sub-programs:
| Program Name & Section in the Handbook | Description | Landing Page or Workboard |
|---|---|---|
| GitLab for Open Source Program | Qualifying open source projects receive GitLab Ultimate and 50,000 CI minutes for free. We process applications according to the Community Programs Application Workflow. | GitLab for Open Source Program Landing Page |
| Open Source Partners Program | A partnership program designed for large or prominent open source organizations | Open Source Partners Program Landing Page |
| Consortium Memberships | These memberships allow us to extend GitLab's leadership in key open source initiatives, enhance GitLab's brand, and/or improve engineering alignment | Consortium Membership Workboard |
We use epics, issue boards, and labels to track our work. We also maintain quarterly objectives and key results.
See the Community Relations project management page for more detail.
At GitLab, our mission is to change all creative work from read-only to read-write so that everyone can contribute.
The GitLab for Open Source program supports GitLab's mission by empowering and enabling open source projects with our most advanced features so that they can create greater impact and amplify the contribution mindset within their spheres of influence.
This program's vision is to make GitLab the best place for Open Source projects to thrive at scale.
Apart from actively maintaining and constantly adding value to the open source Community Edition, GitLab makes the Enterprise Edition's top Ultimate and Gold tiers available free-of-cost to qualifying open source projects.
More information about the program can be found on the GitLab for Open Source landing page.
Note: This program grants Ultimate features at the group level (these features are things like epics, roadmaps, merge requests, and other Ultimate features for groups).
Migration Services. For open source communities that need assistance with their migration, our team provides a variety of services to help. Check out our professional services page for more information.
Additional services. We sometimes hear requests for services we do not provide, such as providing hosting for Community Edition instances. We've partnered with others to help expand the options for our users. Check out our Technology Partners to learn more.
The following SKUs are related to the GitLab for Open Source program:
In order to qualify, projects must meet the program requirements listed on the GitLab for Open Source application page.
Here are some guidelines that help us make decisions about whether or not projects qualify:
Examples of OSS projects that usually qualify:
Examples that usually do not qualify:
For more questions, please see our GitLab for Open Source FAQ or contact us at opensource@gitlab.com
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.
From time to time, we make strategic exceptions to our program requirements, such as to the federal exception policy. These requests must be made by a GitLab Sales team member on behalf of a project.
Requests for qualification exceptions can be made by filing a new issue on the GitLab for Open Source program kanban board and selecting the oss-qualification-request template.
In order for this to be approved, both Account Executives and their Managers will need to sign off by checking the box next to their name in the submitted issue. If there is a relevant Technical Account Manager (TAM) associated with the account, they should be added to the issue in FYI so that they are notified of the exception request.
Qualifying open source projects can apply for self-managed Ultimate or SaaS Gold by submitting the GitLab for Open Source application form.
We follow then follow the community programs application workflow to process applications.
For more information on what applicants can expect, please see the Application Process section of the GitLab for Open Source application form.
There are a number of organizations that offer open source programs with discounts or free services just for open source projects. Here is a list of some of the programs we know that have been useful to pair with the GitLab for Open Source program:
GitLab Docs are a great resource for our program members since our docs are the single source of truth and answer a wide variety of questions program members may face.
If program members are unable to find what they're looking for in our docs, we ask that they post their question in the GitLab Forum. There, they can interact with other members of our community and many GitLab employees. We encourage program members to join the forum even if they don't have questions so that they can meet other members of our community.
In line with our Transparency value, GitLab has an open roadmap, so our community can always see what's ahead in the product priorities.
Feedback helps us to build the best product possible. Whether it's a bug report, a feature request, or feedback to our company, here's a guide for how to submit feedback.
Make sure to Thumbs Up issues.
Our team looks at the number of Thumbs Up votes as an indicator for priority, so make sure you're using that feature on issues as a quick way to give us feedback. Writing detailed comments of your use-case and thorough issue desciptions is another way you can help make it easier for our team to understand your needs and respond to your questions.
Just search for relevant issues on the GitLab product project, and start giving us your feedback!
When the GitLab for Open Source program began, we kept track and publicly displayed the members who joined the GitLab for Open Source Program at https://about.gitlab.com/solutions/open-source/projects/. This list is currently deprecated since it's quite out of date. However, we are retaining information about it for historic reference.
To do this, applicants submitted a Merge Request to the GitLab OSS project. Whenever the applicant was approved, and as part of the process, the project was added to a master list on the /gitlab-com/marketing/community-relations/gitlab-oss repository.
Unfortunately, the open source project list is now outdated because of the following reasons:
This section talks about how we used to update the open source project list so that we preserve this knowledge as we plan for future iterations of an open source project directory.
While the original Merge Request process was ideally meant to keep the list updated, there was also a manual step involved in transferring the file from the /gitlab-com/marketing/community-relations/gitlab-oss repository to the GitLab's website repository.
These additional steps were required to update the GitLab for Open Source members list on the website:
/gitlab-com/marketing/community-relations/gitlab-oss repositorydata/oss_projects.yml file At this time, the master list on the /gitlab-com/marketing/community-relations/gitlab-oss repository is only updated for applications, not for renewals. As such, it might contain data from projects who initially applied for the program but did not renew their yearly license.
Purpose: The GitLab Open Source Partners program seeks to build relationships with open source projects that have thousands of community members or users.
Through our partnership, we aim to gain insight to help us build a better product and navigate the challenges of being an open core, for-profit company. We also aim to create greater outreach through co-marketing and special initiatives.
About: Full program benefits and requirements can be found on the GitLab Open Source Partners landing page.
We have Open Source partners that use a variety of GitLab's products. In addition to Ultimate SaaS or Self-Managed, some of our Open Source Partners use the Community Edition instead of the Enterprise Edition because of their strong FOSS values.
We have a number of email templates to help us interact with prospective and current OSS Partners. These email templates are publicly visible to allow our community to learn from our onboarding process.
When an org has joined the OSS Partners program, we send them the OSS Partners Onboarding Packet.
We need to make sure that we have the right contact information for our Open Source Partners.
Suggested touchpoints for requesting contact information and updates:
Some OSS Partners will not have contacts for each function. If that's the case, the contact for that function should be left blank and the Primary contact should be contacted instead.
Multiple contacts can be added for each of these functions except the Primary contact.
Related Documents:
We use public issue trackers to help our OSS Partners through and beyond migration.
Public issue trackers help us understand the priority of various feature requests and bugs for our Open Source Partners (priority is denoted as: blockers, urgent, important, and nice-to-have). When OSS Partners set up a public issue tracker, it has the added benefit of helping them get used to our workflow so that they can start giving us more product feedback and helping us improve the product together.
We ask that a representative of the OSS Partner org opens the issue tracker so that they are able to edit the description section. If someone at GitLab opens the issue on the OSS Partner's behalf, the OSS Partner will not have edit access.
Follow these steps to create a public issue tracker:
gitlab.com/gitlab-org/gitlab projectOSS_Partner template where it prompts you to select a template, and click on Apply templateExamples of public issue trackers:
We use the GitLab Open Source Partners project to keep internal notes around collaboration with our OSS Partners. This project is accissible only by GitLab team members only as it contains sensitive information that should not be made publicly available. This board also contains a view of all Open Source Partners and has labels to help us identify if they align with any of our GTM messaging.
We use the GitLab Open Source Partners project to track the main issues for the partnership. Issues relating to strategic initiatives with our OSS Parrtner are added to the general OSS program board and are linked back to the relevant main OSS Partner issue.
More information about the project management for this program can be found on the main Community Relations project management page.
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 GitLab <> LF project 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. More information about this consortium membership can be found in the section below.
The Open Source Program Manager worked with the Content team on an editorial strategy to meet the needs of the Open Source Partners program. Posts about technical content and open source partner migrations tend to be very popular, so the Content team collaborates by brainstorming topics and doing reviews.
The plan is to publish posts on the GitLab Blog that are related to the Open Source Partner program and to feature these on the Open Source Partners page.
Marketing opportunities:
Resources:
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.
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
*.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.Note: 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.
Do this for 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.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. If it looks ok, have someone review and merge!
Unfortunately, the review app will not automatically show you the preview. Here's how to generate a link to preview the changes.
The View App lets you preview your changes. It 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 OSS 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.
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!
GitLab's open source program also oversees GitLab's representation and participation in select industry consortia.
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:
| Consortium | Level | Activities | Membership Details (internal only) |
|---|---|---|---|
| Linux Foundation | Silver | Eric Johnson is currently on the Board | Membership Details |
| Cloud Native Computing Foundation (CNCF) | Silver | Brendan O'Leary currently on the board | Membership Details |
| Fintech Open Source Foundation (FINOS) | Silver | Collaborating on Legend project | Membership Details |
Full details of our memberships with these organizations is available to GitLab team members only: Community Relations Consortium Memberships.
Some of the consortium memberhsip in which we participate allow members to run for their Board of Directors. Here is more information about how these elections run and how GitLab has run the internal nomination and campaigning process.
An issue was created for each nomination so that GitLab team members who were interested in running could discuss, as well as for internal nominations to occur. Teams involved: Community Relations, Alliances, Marketing leadership (CMO, Director of Corporate Marketing). Here are some nomination statement examples that can be shared with people hoping to write their own.
Once GitLab candidates were nominated, the Community Relations team helped run campaigns for the candidates. A spreadsheet was created with member companies, and a campaign message template was created. GitLab team members were made aware of the election and were given access to the spreadsheet and template in case they wanted to help campaign (announced on the #whats-happening-at-gitlab Slack channel).
The social media team is able to promote elections notification news. They need a page to point people to, preferably an updated page that lists the board of directors, or else a social media post from the organization that mentions the election results.
There are two Board Seats for Silver members and they are open for 2 year terms. This means that each year, only one seat is open for Silver member nominations.
The election process was not widely publicized for the 2021 election cycle and only the Primary/Voting contact was notified. Nominations had to be submitted via a form.
The entire election process lasted about two weeks: Jan 25th - Feb 11th. For more information, see this issue about the 2021 Linux Foundation Nominations (available to view by GitLab team members only).
Board of Directors - This election ran from December 9, 2020 to January 11, 2021 for the 2021 seat. Only one board seat was available and candidates sent self-nominations via a form.
Marketing Chair - This election ran from December 2nd - December 17th in 2020 for 2021 seats. The Marketing contact was sent an email with voting instructions and candidates sent their self-nomination emails to the CNCF marketing list.
We have a small budget to sponsor events that allow us to engage with and build relationships among our current open source partners' communities. All other event sponsorship requests, are handled by our field marketing team.
We use this adapted boilerplate copy to describe GitLab at open source conferences. If you are an event organizer we are working with, please feel free to use this to add GitLab to your site and materials.
Description:
[GitLab](https://about.gitlab.com/solutions/open-source/) is a complete DevOps platform, delivered as a single application, fundamentally changing the way Development, Security, and Ops teams collaborate. GitLab helps teams accelerate software delivery from weeks to minutes, reduce development costs, and reduce the risk of application vulnerabilities while increasing developer productivity.
Built on Open Source, GitLab works alongside its community of thousands of contributors to continuously deliver new DevOps innovations. From startups to global enterprises to leading open source projects, over 30 million users across the globe trust GitLab to deliver great software at new speeds.
Logo:
You can find png, jpg, svg, and eps files here: https://about.gitlab.com/press/press-kit/
We tend to use the Logo - gray and Stacked Logo - gray logos most, but any of these should work.
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. 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.The GitLab for Open Source program webpage and all of the child pages can be modified using Netlify CMS. Instructions for how to access and edit them can be found here. To add new OSS Partners, you'll still need to follow the process detailed below.