Reasons to Move Baserow Dev to Github (away from Gitlab)

[bfranklin]

First off, I love the Baserow team. You guys are very knowledgeable and building a great product I use daily.

I know you’re also interested in maximizing growth and building a strong community around Baserow is a big part of that. @olgatrykush is doing a tremendous job on this front and this discourse forum is valuable.

That said, I’m worried Baserow is not getting the recognition or support is deserves because primary development is happening on Gitlab vs. Github. I know that you have a mirrored repository there on Bram’s account with 1.3k stars but consider that Nocodb is, in my view, an inferior offering and it has 34k stars. All those devs working with Nocodb has to be a huge boost for bug fixing and feature dev. Then you have other options like Rowy that have 400% more stars than Baserow’s clone on Github or Baserow’s primary repo on Gitlab. I think a big reason for this is the location of the project.

What: Move Baserow primary dev to the same environment all of its competitors live in.

Bulleted reasons:

• GROWTH: Less friction for devs that want to participate = more participation and free help and growth of usage and product dev
• GROWTH, Discovery: Many devs, I think, use Github’s tagging system to discover options and then look at stars and commit or issue stats to determine usage and Baserow would be better positioned to attract folks with its numbers if primary dev were on Github.
• SIMPLICITY: Won’t have to maintain a mirror on Github that becomes outdated and then makes devs on Github confused and turned off, possibly thinking the project isn’t under active dev
  -SIMPLICITY #2: Most of the libraries and frameworks for Baserow are already on Github so the project would live closer to the code that it’s built on top of
• MANAGEMENT TOOLS: Github’s project management tools have improved dramatically over the past year with new Kanban projects layout
• ADDONS: Github’s marketplace offers some a large number of options of deployments and CI (if this Gitlab feature is some reason why people decide on Gitlab)

Reasons NOT to move

• VALUES: An idea that Microsoft can’t be trusted
• INTERTIA: Moving would take some work and is a nuisance and its better to focus this energy on the product instead of adopting some new workflow

I can see some merit to both of these reasons not to but given the momentum in this space and huge demand and need to help I think the risks of not having Github be the primary dev hub for the project outweigh the initial time it would take to switch and I think that so far Microsoft has been doing a great job to managing new features on Github and that, at some point, if the largest open source projects in the world are still trusting Github that it’s time for me to relax my paranoia and concerns about entrusting code to “bigtech” …

Important note: I don’t work for MSFT. Just thoughts from someone who cares.

[olgatrykush]

Hello @bfranklin, first of all — big thank you, words like this motivate us to keep building Baserow. And this type of community involvement is very valuable and special to us, so keep up the good work

We use GitLab because we try to use open source tools as much as we can, but your words make a lot of sense. I’ll rise up this question to the team next week.

And thank you for writing down the pros and cons, these details are very useful during discussions

[petrs]

Thanks for the nice words!

We all understand that Baserow deserves more stars The reasons why other projects have many more might be entirely different than what is the default repository vs a mirror of it. It is also not representative of adoption or anything tangible.

The decision that you propose is much more involved than just hosting the repository. I don’t think we would want to move our CI pipelines, nor issues and the whole system of work that we have. This is unproductive even if you don’t consider different feature sets, pricing, ability to self-host etc.

[bfranklin]

Okay, yeah … I am very far from the internal discussions and considerations so very likely I don’t have full view on this but here are some additional thoughts on your response.

Re: Alternative Reasons
Agreed. There could be a number of reasons. Examples: 1) People have also tested all the options regardless of where they are hosted and come to a different conclusion about the best offering; 2) People need something that works with MySQL ; 3) People have an easier time installing an alternative, etc … All that said: I think we have to consider that Github is where devs search for projects and this is the “top of the funnel” and I have to imagine that many projects languish and, again, don’t get the attention they deserve because they aren’t hosted in the place for most of the open source software in the world is hosted.

Re: Workflow Reason
I know workflows are annoying to have to rebuild so that’s why I mentioned that in the cons. It’s hard for me to predict whether benefits of the possibility of dramtically increased adoption or community involvement from being on Github outweigh the nuisance of migration but my hunch is that it would. It’s feels like something like the location of a restaurant: Hopefully people will travel a far distance to try the good food they are hearing about at a remote location but it’s much more likely people will come and the restaurant will win if they are serving great food and located right downtown where there is already lots of foot traffic and close to everyone’s homes so it’s an easy walk.

[Alex]

Really appreciate your ideas!

We have limited resources and ultimately when it comes to these types of decisions we are talking about a cost benefit analysis.

If we dedicate X hours of our employees to moving from Gitlab to Github we lose the same amount of hours that could have been invested in building new features (or any other productive work).

The gut feeling I have, is that the cost outweighs the benefit.

We are a fast moving company with goals in mind for this year, and a migration like that might set us back a significant amount of time.

Happy to hear what the other’s think

[bram]

Hey @bfranklin, thank you for your input on this topic. This has actually started a discussion about this topic internally. We’re currently figuring out on the pros and cons and setting a meeting about it.

[kissu]

Thanks for the feedback Franklin!
It’s actually perfect timing (I was going to propose the same this week).

[bfranklin]

Great, all.

@bram: Cool. I think I have outlined my key reasons. To simplify things, I think the formula for making a decision can be distilled down to something like:

Cost to Benefit Ratio Calculation

if (B > C) { move }

Where “C” (cost of moving) is the amount of time to make the switch and get used to the new workflow and “B” (benefit of moving) is the amount of additional free help you might gain from developers to work on new features and fix bug for your team if there are even more passionate enthusiasts using Baserow. It might be asked, if I even gained 2-3 really talented devs who contributed a fews hours a month of bug fixes for free, would this be worth the switch? I suspect you’d gain even more than this too.

Stars-to-meaningful-contribution Ratio

One interesting ratio to look at would be to manually count up the number of devs actually committing meaningful code fixes or additions to competitive nocode projects on Github (some I have already mentioned) and compare this to the number of stars for these projects. Then you could, perhaps, compare them to your internal data and be able to better predict what might happen in terms of actual code contributions from growing “star totals”

Just some more quick thoughts!