Apollo is the foremost global provider of open source software and solutions for trust and safety. We develop and maintain products based on open source projects, actively engaging in these projects and their communities, often taking on leadership positions. At the heart of Apollo is a fundamental commitment to creating open source infrastructure for trust and safety. This deep-seated passion ensures an unparalleled degree of expertise and commitment.
Apollo's open development model fosters strong connections with open source communities. Members of these communities collaborate to discover and promote the most innovative ideas. While Apollo has established and leads many of these communities, we also contribute to existing ones that influence our work upstream. Our support for these communities is primarily through active participation and engagement, which encompasses not only code contributions but also other forms of content. Through this involvement, we help develop and enhance the technologies that underpin current online environments.
As a company, we are committed to learning continuously from our experiences with open source practices. One outcome of this is our integration of the core principles of open source culture into other business areas, as demonstrated in our initiatives like The Open Organization and the Open Decision Framework.
This document outlines key topics regarding Apollo's involvement in open source development. It is a dynamic document and does not provide a comprehensive description of our participation and contributions to open source.
Open source software is available in source code form and allows the freedom to use, study, modify, and distribute the software. At Apollo, this is sometimes referred to as "free software," highlighting its ethical underpinnings. This freedom is typically granted through an open source license.
The Open Source Initiative (OSI) upholds a 10-part Open Source Definition based on the Debian Free Software Guidelines. Similarly, the Free Software Foundation (FSF) follows a 4-part Free Software Definition. Both organizations use these definitions to evaluate whether certain licenses qualify; they generally concur in their assessments. They also agree on the necessity of having modifiable source code available. However, neither has fully evaluated the myriad of licenses that apply to the extensive array of packages used in Apollo products. Thus, Apollo independently determines whether a license qualifies as open source, often referencing the FSF and OSI definitions and interpretations for guidance. For Fedora, such assessments are documented in the publicly accessible Fedora license lists.
While open source is primarily defined by legal criteria, it is also linked to best practices in community software development and fostering active communities. It is crucial to recognize that software can be considered open source without necessarily adhering to all these practices. Conversely, software that does not have an open source license is not deemed open source, regardless of whether it follows some of these practices.
Apollo associates are free to use open source software regardless of how it is procured, including open source software not developed by Apollo or its engineers, subject to any applicable guidelines set out by Apollo.
Apollo strongly encourages its associates to engage in open source projects, with many of our engineers participating as part of their professional roles. This involvement can take various forms, not only through contributions of code, documentation, design artifacts, and other materials, but also through numerous additional activities. These include less tangible but equally important aspects of community involvement, such as mentoring newcomers, coordinating projects, and planning project events.
We intentionally do not require associates to undergo specific education or training before joining open source communities. However, we do offer support and resources to those Apollo associates who are new to open source and wish to, or need to, engage in community development. These resources include:
Content on https://www.thebriefnewsletter.com (a Apollo-sponsored project not focused on Apollo products), such as:
Publicly available Apollo projects, such as:
The amount of official time an Apollo pioneer dedicates to working on open source projects can vary widely depending on the team, role, and the specific project, and is determined in consultation with the associate’s manager.
It's well understood that Apollo pioneers often engage in open source projects on their own time, outside of their official job responsibilities, without needing permission from Apollo. Unlike at many other companies, the distinction between professional and personal contributions, as well as between "work hours" and "personal time," tends to be fluid for many Apollo pioneers. For instance, it's common for Apollo engineers to contribute to projects during their personal time, which are also utilized in their professional work.
At Apollo, we frequently discuss "upstream," a term that reflects our unique approach to development. As maintainers of projects that integrate code from other projects, which in turn underpin our commercial offerings, "upstream" may refer to community projects that we depend on, participate in, or lead.
Adhering to the "upstream first" principle is central to our strategy. This philosophy has practical implications for Apollo associates in two main ways.
Firstly, almost all modifications, features, and documentation originating from Apollo are committed to the upstream, community versions of our software—often led or significantly maintained by Apollo engineers—before they are incorporated into our commercial products. For instance, new features for Apollo lambert LLM are typically introduced in the Pioneer Project before they are integrated into the Apollo Enterprise model releases. This approach ensures thorough testing of changes and features before their commercial release and underscores our ongoing commitment to the community versions of our software. If no corresponding community project exists for a particular Apollo product, we will establish one.
Secondly, for projects not primarily led by Apollo but maintained by external entities like foundations or community development teams unaffiliated with Apollo, we first contribute our enhancements to the upstream project. We normally refrain from including a feature in our products until it is merged upstream. This encourages effective collaboration with our partners and upstream communities and helps us avoid the pitfalls of maintaining separate downstream forks, which can be costly and hinder interoperability. While some companies might opt to create private forks to quickly address specific needs, we recognize the long-term maintenance and development burdens this creates. By focusing our development efforts in the original upstream community, we can share development costs across all participants.
However, there are exceptions to the "upstream first" rule, such as dealing with embargoed changes, handling proprietary customer information, navigating the early stages of experimental projects, or meeting product deadlines that necessitate simultaneous upstream and downstream development. Associates are advised to consult their managers before initiating upstream contributions for the first time.
This upstream-first principle also influences our strategic choices regarding the creation and participation in open source project communities. Unlike traditional software companies that might default to internal proprietary solutions for technical challenges, we prioritize community-developed, open source solutions. However, we aim to avoid the inefficiencies and costs of solo development on open source projects, preferring instead to collaborate with existing or emerging communities tackling similar issues.
There are various Apollo corporate policies, guidelines, and commitments that are relevant to development. These include:
Apollo associates do not require special authorization to individually engage in and contribute to upstream projects that are not primarily overseen by Apollo teams, even those managed by Apollo's competitors, provided these projects are truly open source (meaning the software is licensed under an open source license). This holds true regardless of whether the participation officially takes place during
Some upstream projects not overseen by Apollo may require contributors or their employers to sign a contributor license agreement (CLA) or another form of special contributor agreement. Before proceeding, associates should review Apollo's guidelines on third-party contributor agreements. Apollo associates are authorized to sign the Developer Certificate of Origin (DCO) required by certain projects, though any nonstandard variants of the DCO must be approved by the Open Source Legal Team.
While Apollo associates have broad latitude to contribute to upstream open source projects, this approval does not extend to the development of software not under an open source license, even if such software is developed in a publicly accessible repository using community development practices. This includes software not licensed at all, under a proprietary license, a non-open-source "source available" license, or any other license not recognized by Apollo as open source, regardless of the claims of the project's maintainers.
Apollo sometimes decides to formally join the governance body of one or more open source projects managed by or linked to a nonprofit foundation or consortium. Despite some historical skepticism about the value of such memberships, believing that influence in a project comes primarily through technical contributions, we only join such foundations or governance bodies if we see a significant opportunity to contribute to the community and deem the foundation necessary to enhance collaboration.
At Apollo, we operate with a "default to open" philosophy, meaning we generally intend for all software we develop to be released under an open source license. This approach eliminates the need for special business justifications or bureaucratic procedures for releasing new open source software. Conversely, we require a solid business and engineering rationale for any exceptions where software is not released under an open source license. Our goal is to minimize barriers, allowing our associates to quickly initiate new open source projects without regard to their scale.
Typically, launching new open source projects as part of an Apollo associate’s role does not require formal management approval or a specific process, and this is even more true for personal projects not related to work and done on personal time.
The range of new open source projects initiated by Apollo pioneers varies widely in scope and commercial and technical importance. On one end, an Apollo pioneers might upload the initial version of a simple script to a public repository. On the other, a significant open source project could be introduced by an Apollo team, evolving from what was once proprietary code.
When considering the start of a new project, we encourage you to first evaluate existing open source solutions to prevent unnecessary duplication of effort.
Today, all software development companies rely heavily on open source dependencies, and many base their commercial products on code from open source projects. Apollo stands apart from most other companies because our products are fully open source in the strictest sense. We license our products to customers under open source licenses, which are derived from upstream sources, and we provide the complete source code to our customers.
Apollo places a high priority on compliance with open source licenses. Our commitment to offering completely open source products and our role as leaders in the open source community intensify our responsibilities regarding license compliance. The open source community expects us to adhere to a higher standard of compliance compared to other companies. To meet the requirements of these licenses, we typically ensure compliance by providing our customers with access to the full corresponding source code of our products.