Authors Note: Hey, we messed up in this post by referring to BUSL-1.1 as Open Source. We’re sorry, we are leaving this post as-is to keep the record clear and we’ve followed up in a new post.
Since the beginning, the open source community has been a strong partner in Codecov’s growth and success. That’s why we always offered Codecov for free to use on any open source project. And if we’re being totally honest, Sentry being open source and seeing how they support the community with massive donations every year, played a big factor in our decision to join them.
Just like Sentry, we believe that every developer should have access to quality software. So … ahem … effective immediately, Codecov is publishing the core repositories that drive our product. These repositories are available under the same Business Source License (BUSL) license as Sentry’s core repos. The code is available now for you to run for yourself, study, modify, and redistribute in original and modified form. The BUSL means you can’t sell hosting, but after a period of time, the code reverts to the OSI-approved Apache 2.0 license.
As a part of this shift, we are offering a new self-hosted repo that makes it easy to run Codecov in a minimal docker-compose based setup for proof-of-concept and small volume deployments. We are end-of-lifing our commercial self-hosted offering but will continue to provide support to existing customers who are running Codecov on-prem.
Why is Codecov Open Sourcing?
When Jerrod and I started at Codecov, and throughout our careers, we depended a lot on open source projects and libraries. It was never a discussion of “if” we should open source Codecov, but rather “when.” Could we have started off as an open source code coverage project? Perhaps, but at the time there were only a few examples of how to run a successful open source SaaS business and our primary focus was to build a quality product developers would love.
As many of you reading can relate, building anything that doesn’t fall over when someone starts to use it is pretty hard. Building something that people love is exponentially harder. In reality, our journey to open sourcing Codecov started in 2018, when the Codecov codebase underwent a full rewrite of all parts of the product. This rewrite was completed in conjunction with the work of serving our users and building new features and, as you’d expect, took quite some time. At the conclusion of 2022, we had successfully completed the rewrite and no legacy code was active in our production systems. It was at this moment that we felt we could finally, seriously pursue open sourcing our codebase – which brings us to today.
Specifically, what Repositories will be open sourced?
All repositories that were open source ahead of this announcement will remain open source. The primary projects that will be converted from closed to open source are:
- codecov-api: Codecov’s API layer. This is a Django / Django Rest Framework application that services our front end and public REST API.
- worker: Codecov’s asynchronous task processing layer. This is a Python and Rust application that is primarily responsible for offline task execution, managing job queues, and so on.
- gazebo: Codecov’s React SPA front end. This is the front end application end users interact with on the app.codecov.io subdomain.
- shared: A collection of shared functions and classes that are used by both codecov-api and worker
- self-hosted: A repository that allows users to bootstrap Codecov proof of concept and small volume installations.
Can I make Pull Requests into these repositories?
Yes, please. If you want to contribute to any of these repos, please review our Contribution guide.
Can I open Issues and submit feedback?
Yup. Please use the feedback repository to submit Issues, as opposed to the individual repositories themselves.
Will Codecov’s planning and project management processes also be open?
Yup. With the move to open source our code, we will also open source how we work – you’ll be able to find us in public GitHub Projects very soon. Stay tuned.
Will you still use the Community Forum for Discussion?
We will be discontinuing posting on the Community Forum and instead, direct all users to the feedback repository to open Issues for discussion there.
What Happens to Codecov Self-Hosted?
Similar to Sentry, we will provide an open source repository containing a Docker Compose orchestration of our service for anyone to clone and use. This repository will be intended for low volume and proof-of-concept style deployments of Codecov. We will also offer support for organizations that opt to deploy self-hosted Codecov in this way.
If you need a more high volume / reliable deployment of Codecov we encourage you to use our cloud offering or our single/multi-tenant cloud solutions.
Will you offer more high availability releases of self-hosted using kubernetes, terraform, helm, etc?
In the past we offered more high availability (HA) versions of self-hosted, using Kubernetes and other such tools to provide an HA setup in the customer’s own infrastructure. Due to the complex nature of supporting these styles of deployments, and the fact that we’re open sourcing and providing a lower availability alternative, we will no longer be supporting these types of deployments.
Users of self-hosted Codecov are more than welcome to deploy Codecov in this fashion, we will not be providing support for these more complex, high-availability deployments.
How often will the self-hosted releases be updated?
Internally, Codecov uses a continuous deployment approach to update production. We will use this same approach to keep our self-hosted images up to date in a rolling release style. If the code is in production, it will be available via the latest tag for each self-hosted Docker image.
We may at times issue more stable versioned releases using calver. Unless otherwise noted, these releases will be tagged with 2023.x.x. The exact release cadence for these versioned releases (e.g., monthly, quarterly, milestone-based, etc) is yet to be determined.
Looking ahead
We believe that the operating model for any SaaS company has to be open source aligned. It’s a philosophy that companies will adopt more and more because their customers demand it. The open source model provides flexibility to tap into the benefits of the open source community.
While this doesn’t mean that every software company must necessarily be open source themselves, they are sure to use open source components in their products and they should support the open source community in every way possible, including supporting open source developers and funding open source projects.
All that said, what’s most important to us is building trust with you all. From transparency and security to collaboration, we want to make sure people of all expertise can share their opinions, contribute to new ideas, and be a part of a community of collaborators. With your help and more eyes on the code, we’re looking forward to shipping a well-tested, higher-quality product.
