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 open source.

The motivation

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 permissions, so we decided to make a public repository dedicated only to DoltHub issues.

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:

1. Create a private dolthub-issues repository.
2. 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.
3. Create new labels (issues don't transfer with labels) and apply to transferred issues.
4. Make dolthub-issues public.

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 IPO. Our long term goal is to support both models of Git-style collaborative development:

1. The GitHub way: Closed source. Centralized remote storage and public website with permissions.
2. 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 DoltLab.

Conclusion

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.