At Watermelon, we’re making our passive documentation search engine source-available.
When we started this company 18 months ago, we immediately adopted openness as a value. We started with an open-source repository for our VS Code extension for individuals as well as an open product roadmap, and occasionally writing about our progress publicly. We also very recently, wrote a rough draft for a public company handbook that shares our strategy.
We’ve kept expanding and we’re now serving early adopters with our team-oriented product, a passive documentation search engine that serves teams via a GitHub Application. We’ve spoken to engineering executives at companies of all sizes and we’ve understood that it’s very important to scrutinize an application that will deal with such sensitive infrastructure that a codebase is for a company. It’s important to show both engineering executives and individual contributors the easiest way possible, that we’re not storing a company’s code.
As developers ourselves we understand this perfectly. We simply prefer to install products that are open instead of those that are closed.
As part of our strategy, we’re adopting an open-core business model. What this means in practical terms is:
Our IDE extension repo has an Apache 2.0 license, and our passive documentation search engine repo also has an Apache 2.0 license with a commons clause. We understand that this doesn’t fully fit the definition of open-source provided by the OSI and that’s why we’re being very clear and upfront with the terminology.
Despite that, a product becoming source-available is a win for its users.
We strongly believe that a dev-oriented company working on its codebase in public is a win for the ecosystem. GitLab is the quintessential example of a company that has used the open-core business model to build something that developers love that makes revenue at scale, and it’s one that we want to follow.