Hosting update for the druid-operator repository

[AdheipSingh]

We’re planning to move the druid-operator repository to the Deep.BI GitHub organization.

For background, the operator was originally part of the Apache Druid GitHub org and was later moved to datainfrahq/druid-operator. To clarify, DataInfraHQ is not a registered entity or foundation. It was simply a neutral namespace I used to host the project, including Helm charts and related materials.

Since that move, I’ve been handling the operator’s maintenance largely on my own. While the operator has seen wide adoption in production environments, updates and new features have been limited due to the lack of dedicated maintainer capacity and the fact that my other work over the past years was not Druid-focused.

Over the past year, several companies raised concerns about their ability to fork or contribute to the project because it was not hosted under a registered organization or foundation. More recently, with help from contributors at Salesforce and Disney, we initiated discussions with the Apache Druid PMC about moving the operator back under the Apache Druid project. The proposal was accepted in principle. However, there are still practical steps to complete, including repository setup, chart hosting, and PMC logistics, before the operator can be fully hosted and maintained under Apache.

---

Why Deep.BI

Sebastian and the team at Deep.BI have stepped forward to support the operator’s maintenance and active development. Hosting the repository under Deep.BI provides:

• A stable, registered organization for stewardship
• Clear ownership for day-to-day maintenance such as issues, reviews, CI, and releases
• Continuity while the remaining Apache-related formalities are worked through

This move does not change the nature of the project:

• The license remains Apache 2.0
• Contributions remain open and welcome
• Development and decisions will continue to happen in the open

Deep.BI has supported Apache Druid and other open-source data systems for many years and has committed to keeping the operator open, community-oriented, and aligned with Apache principles.

---

As of recently, after several years of sustained involvement with Apache Druid, I’ve also become an Apache Druid committer. This helps with alignment and coordination. However, operator maintenance still benefits from having a clearly scoped repository and ownership structure. The operator is implemented in Go and follows Kubernetes-native patterns, while Apache Druid itself is a Java-based system. Long-term sustainability benefits from reviewers and maintainers with hands-on experience in Go and Kubernetes, along with close collaboration with the broader Druid community.

I will continue working with the Apache Druid PMC and existing contributors to move the operator under Apache once the remaining steps are complete. Longer-term governance options, including a separate repository and review structure appropriate for a Go-based operator, can be discussed with the PMC as part of that process.

If you have questions or concerns about this transition, please start a discussion or open an issue so we can address them transparently.

Thank you for your continued support of the project.
Adheip Singh

[razinbouzar]

@AdheipSingh why not leave as-is while the remaining steps are completed? This would save a hop.

[AdheipSingh]

Hi @razinbouzar ,
With this project under an organization (which is focused on Druid OSS only), it will speed up a lot of pending issues, planned features and releases. Other engineers will be devoting time to this project, not just me. As of now, I'm maintaining this in an individual capacity on an ad hoc basis. Also, the ultimate goal is to move this to Apache, which we need to work on. The DataInfra domain is also expiring, so the charts will need to be moved.

[gianm]

It is concerning to hear that the plan is to move the Operator development to a third party repo rather than to do development at Apache. It has already been donated and the code has been imported to https://github.com/apache/druid/tree/master/druid-operator. This means that Apache is the proper place to do continued development.

What is the issue with doing development at Apache? If a separate repository is needed, we can move it to a new one like https://github.com/apache/druid-operator. This would be greatly preferred to moving the code to another third-party repository. It doesn't take long, just let us know that's what you want and it can happen quickly.

[abhishekrb19]

Agreed with @gianm. It’s surprising to see the change in plans to continue development in a different repo after it's been donated. I already see a contribution to the operator in the Apache Druid repo.

Long-term sustainability benefits from reviewers and maintainers with hands-on experience in Go and Kubernetes, along with close collaboration with the broader Druid community.

Anyone can review changes and contribute, so I don’t see why this should be a reason to move to a different repo. In fact, contributions like these are often encouraged and recognized as committers etc.

@AdheipSingh @razinbouzar, I’m happy to volunteer to help with any formalities needed to move this under the Apache organization. Please let us know what you need.

[pirvtech]

+1 to suggestion from @gianm. In the past I was a PMC for an apache project that had multiple repos.

[razinbouzar]

@abhishekrb19 and @AdheipSingh, transferring this repo to the Apache org may make sense in order to keep the PR and Issues history, along with not falling behind from commits that were added between the donation in September and today.

[AdheipSingh]

Thanks everyone for the feedback and offers to help.

When we discussed the move to Apache previously, there were still open steps around repository setup, charts hosting, and formal process. In the meantime, the goal was to ensure the operator has active maintenance capacity and doesn’t stall.

If there is now clear alignment and willingness to move this repository directly under the Apache org - preserving history and continuing development there - I, together with the team at Deep.BI, fully support that path. Our priority is sustainable maintenance and contributor clarity, not repository ownership.

Happy to coordinate on the concrete next steps and timeline so we can move forward efficiently.

[razinbouzar]

For starters, can we begin the migration to the Apache org? @AdheipSingh I think adding @abhishekrb19 as an owner would help. He can then transfer the repo to the Apache org and then add you and others in accordance with ASF policies to it once it's transferred.

[abhishekrb19]

Thanks @AdheipSingh and @razinbouzar. Based on the above, I went ahead and created a placeholder druid-operator repository under the Apache organization: https://github.com/apache/druid-operator

I would suggest the following next steps:

1. Update licenses headers to include Apache headers in all the files in this datainfrahq/druid-operator repo
2. Push datainfrahq/druid-operator repo's master branch containing updated license headers to apache/druid-operator - @AdheipSingh I think you should have push access, if not please let me know.

I see that step (1) was already done here when the donation was made to apache/druid, but it seems like using that imported tree won't preserve history. So I think it would be better for one of you to bulk update the license headers in all the files directly in this repository instead.

Once this is complete, I think we can fixup any pending CI items and remove the druid-operator tree from the apache/druid repo, etc. Please let me know if you have any concerns.

[razinbouzar]

@abhishekrb19 / @AdheipSingh submitted a PR to add license headers here.