DoltHub is a place on the internet to share, discover, and
collaborate on Dolt databases. The source code for DoltHub is
private, and we recently decided to make a public repository for DoltHub
issues while we work on making DoltHub
Dolt is open source. Not only does this help us engage
with our community by discussing bugs and desired features, but people can make
contributions to our code base and fork our code for their own projects. Issues from our
customers and community are especially important because they help drive our feature
roadmap and keep people up to date with bug fixes.
Our DoltHub source code is private. We hope one day to make it open source as well, but in
the meantime we needed a better solution for tracking DoltHub bugs and feature requests.
Before our public issues repository, people reported DoltHub issues using a combination of
the contact us page on our website, our
Discord, and Dolt issues. If it wasn't something we
could immediately address, we'd make an issue in our private DoltHub repository and if possible follow up with the person when we had status updates.
Not only was this process time consuming for our team, but it kind of left people in the
dark once they told us their request. They couldn't look at upcoming DoltHub features,
known bugs, or get live updates when something was fixed. While we always tried to respond
promptly via email or Discord, people couldn't have the peace of mind that their ideas
made it into our private queue. We wanted there to be more transparency and engagement
with our community through GitHub.
How we did it
GitHub does not allow issues-only access
so we decided to make a public
repository dedicated only to DoltHub
It took a few steps to migrate our issues from our private repository to our public one.
GitHub doesn't let you bulk transfer issues or transfer them from a private to public
repository. These were our steps:
- Create a private
- Go through every issue and if we wanted it to be public-facing, transfer it to the new
repository. We kept some internal issues in our private repository.
- Create new labels (issues don't transfer with labels) and apply to transferred issues.
Now anyone can create and subscribe to DoltHub issues. This is especially useful for our
bounty participants who use DoltHub on a daily basis
and are great at tracking down bugs.
Why not make DoltHub open source?
Guest starring Tim Sehn with a DoltLab teaser
Good question, especially in light of the recent GitLab
Our long term goal is to support both models of Git-style collaborative development:
- The GitHub way: Closed source. Centralized remote storage and public website with
- The GitLab way: Open source. Federated self-hosted remote storage and websites.
When we started building Dolt in 2018, GitHub was the dominant model of Git collaborative
development. We had used GitHub for previous projects and we were unfamiliar with GitLab.
It was also unclear how GitLab would make money so that scared us a little. The GitHub
model was the obvious choice.
Fast forward to 2021. GitLab has had a lot of success. The choice is not as obvious. Our
customers are asking to self host a DoltHub, wanting a "DoltLab". Some people are
uncomfortable putting their data on the internet, regardless of permissions model, just
like source code. In some companies, it's easier to adopt a public tool like DoltHub.
In other companies, it's easier to download and experiment with an open source tool
like DoltLab. We think having a DoltLab will make it easier to adopt Dolt
regardless of the type of company you work in. Our primary goal right now is Dolt adoption.
There are a few steps to making a DoltLab out of our current DoltHub codebase, assuming we
intend to share code between both. The first is to rip out the features that don't make
sense in a self-hosted offering: payments, bounties, etc. The second is to separate out
all the infrastructure and deployment code, potentially releasing what's left as a closed
source piece of software you could download and run i.e. a closed source DoltLab. Lastly,
we need to open source what is left, actually restructuring the above as different Git
repositories, creating appropriate dependencies. As you can see, building a DoltLab is a
relatively heavy lift and we're torn between adding more DoltHub features or building
Until then, make an issue if you find a
problem with DoltHub or have a feature request.
If you're inspired to help us build DoltLab, we need more front end/full stack engineers
to make it happen and are actively hiring. Send us your resume on
LinkedIn if you're interested or come talk
to us in our Discord.