Why Mergify's Codebase Isn't Open Source Anymore: A Tale of Growth, Change, and Adaptation

In 2018, when Mergify first saw the light of day, the world of software development looked rather different. It was a time when Mehdi, Mergify's co-founder, and CTO, and I aimed to alleviate the constant pain of rebasing pull requests for our team of just four developers. With both of us being entrenched in open-source projects for nearly two decades, the decision to open-source Mergify's code on GitHub felt like a natural step.

No second-guessing, no overthinking, it was straightforward.

Fast forward to July 2022, and the scenario altered. We found ourselves transporting the code to a private repository. Why such a transition?

Let's journey through the reasons, the reflections, and the revelations that influenced this decision.

Transparency vs. Open-Source

To understand the backdrop, it's essential to delineate the distinction between transparency and open source. While open source means making your code publicly available, transparency embodies clear communication, involving users in decision-making, and being upfront about changes. Mergify might have retreated from the open-source front, but our commitment to transparency remains unwavering.

Revisiting the Reasons for Being Open Source

The primary allure of going open source was the idea that users could dive into Mergify's codebase. It's a charming proposition for any developer to peek behind the curtain of their favorite SaaS tool, especially a dev tool. They could discern the ‘why’ behind every feature and even chisel the product with their contributions.

Four years down the line, we took a retrospective look. How many external contributors had we gained? The answer was a mere half a dozen and zero regulars contributors. And it wasn't because of a lack of enthusiasm from our community.

The reality struck hard: first, our test suite was so intricately tied to specific GitHub setups that it was impossible for individual contributors to finalize a PR without a Mergify engineer stepping in. Writing code for Mergify includes writing functional tests that covers everything and interacts with a real GitHub service. This makes it very hard to contribute to Mergify.

Besides, most users interacted with Mergify as a service rather than a codebase. The pivotal realization was:

When you run a SaaS, your community orbits around the service, not the source code.

We always provided Mergify free of use to the open-source community — and we still do — and this is where they saw the value of the service. Mergify is not a library that you'd consume. In the same vein that most open-source projects are OK with GitHub being closed source, they actually did not see the value of having Mergify open-source either.

The Internal Dynamics: Discussions & Feedback

This transformation wasn't a unilateral decision. It was the culmination of rigorous internal discussions, feedback sessions, and countless hours of debate within the Mergify team. We often grappled with the dichotomy between being an open-source project and conducting internal deliberations. Much of our feedback is sourced from customers, and many strategy discussions remain internal. Balancing this with the expectations of an open-source project, where there's a presumption of all-encompassing transparency, became a challenge.

Many private companies are also struggling with this: take companies such as AWS, Elastic or Datadog building their SDK in public as an open-source project barely makes sense. While customer could in theory contribute in the code base, they have no vision on the internal agenda, roadmap, politics or discussion. This makes mostly useful to fix small annoying bugs, which are often possible because there is no advanced end-to-end tests which would require a complex test infrastructure.

Weighing the Pros and Cons

On the bright side, having Mergify open-source gave birth to the the idea of letting anyone utilize and run Mergify on their own, which sounded splendid.

In reality, deploying Mergify was anything but straightforward. Without comprehensive documentation and the intricacies involved, aspiring deployers would likely hit a wall. Like contributing to the service, running your own was close to impossible without the help and guidance of the Mergify engineering team.

Yet, the most formidable challenge arose from an unforeseen affair: our codebase being pilfered. As newer players emerged in our domain, they could gain an undue advantage by scrutinizing the plethora of challenges we'd overcome, laid bare in our source code. They would profit from our knowledge while potentially harming Mergify's venture.

This realization was jarring: were we unwittingly arming our competition?

Very likely.

Customer Perceptions and Feedback

An interesting facet of this transition was the customer feedback – or rather, the lack of it. We braced for potential backlash or concerns after our shift from open-source. To our surprise, there was no significant discontent or uproar. It appeared our users resonated with our quest for enhanced security and strategic growth. Keeping the Mergify adventure alive and funded seemed to be more important than accessing source code for an hypothetical need.

In Conclusion

Transitioning Mergify's codebase from open to private wasn't a decision made lightly. It was a step born out of evolving market dynamics, internal feedback, technical challenges, and a vision for sustainable growth. At the heart of this change lies our unwavering commitment to our users, our service, and our desire to offer unmatched value without compromising on security or strategy.

Amidst these changes, we've clung to one vestige of our open-source roots: our documentation remains open source. This move is our nod to the community, an acknowledgment of their significance in Mergify's journey. It's our way of saying, "While the code might be private, our commitment to community collaboration endures."

As Mergify continues to evolve, we remain grateful to our community for their understanding, support, and shared journey toward excellence. The chapters of our story might change, but the essence of our narrative — dedication to innovation and user-centricity — remains constant.