Sourcegraph went dark

That's what ultimately lets us still do plenty of things for devs and the OSS community:

(1) Our super popular public code search is at https://sourcegraph.com/search, which is the same product customers use internally on their own codebases. We spend millions of dollars annually on this public instance with almost 1M OSS repositories to help out everyone using OSS (and we love when they like it so much they bring it into their company :-).

(2) We also have still have a ton of open-source code, like https://sourcegraph.com/github.com/sourcegraph/cody (our code AI tool).

BTW, if any founders out there are wondering whether they should make their own code open-source or public, happy to chat! Email in profile. I think it could make sense for a lot of companies, but more so for infrastructure products or client tools, not so much for full server-side end-user applications.

It's a bunch of reasons that add up. I'll give some more details for anyone curious.

(And I know that despite these reasons, lots of HNers probably wish it was not so. I agree! I too wish for a world where all companies could have their code be public and open source.)

- We have a lot of tech around large-scale code graph, indexing, etc., stuff that is very differentiated and hard to build. We were starting to put some of this in separate private repositories and link them in at build time, but that was complex. It added a lot of code complexity, risked bugs, and slowed us down, and if a lot of the awesome stuff was private anyway, what was the point?

- As we've been building Cody (https://cody.dev), our code AI tool, we've seen a LOT more abuse. That's what happens when you offer any free tier of a product with LLM inference. We had to move a lot more of our internal backend abuse logic to private repositories, and it added code complexity to incorporate that private stuff in at build time.

- It confused devs and customers to have 2 releases: an open-source release with less scaley/enterprisey features, and an enterprise release. It was a pain to migrate from one to the other (GitLab also felt this pain with their product) because the open-source build had a subset of the DB schema and other things. It was confusing to have a free tier on the enterprise release (lots of people got that mixed up with the open-source release), and it made our pricing and packaging complex so that lots of our time was spent helping customers understand what is paid and what isn't.

- There were actually very very few companies that were going to pay but then decided to use the open-source version and not pay us. A lot of people probably assume that's why we made this move, but it's not. I think this is because people like the product and see value in it, including all the large-scale code nav/search features that are in our enterprise version.

- Although very very few companies used our open-source version to avoid paying us, we did see it cause a lot of annoyance for devs who were asked by their management to try cloning our product or to research our codebase to give their procurement team ammunition to negotiate down our price. This honestly was just a waste of everyone's time.

- If we got a ton of contributions (we never really solicited any), then it might've changed the calculus. Sourcegraph is an end-user application that you use at work (and when fun-coding, but the primary revenue model is for us to charge companies). For various reason, end-user server-side applications just don't get nearly as many contributions. Maybe it's because you'd need to redeploy your build for a bunch of other users at your company, not just yourself. Maybe it's because they necessarily entail UX, frontend, and scaling stuff, in addition to just adding new features.

- We heard from people who left GitHub that people at GitHub were frequently monitoring our repository to get wind of our upcoming features and launches. Someone from GitHub told me his "job is to clone Sourcegraph". Since then, they obviously deprioritized their code search to re-found GitHub on AI, so we're not seeing this threat anymore. But I didn't love giving Microsoft an unfair advantage, especially since GitHub products are not open source either.

- Since we made our code non-open-source, we've been able to pursue a lot more big partnerships (e.g., with cloud providers and other distribution partners and resellers). This is a valuable revenue stream that helps us make a better product overall. Again, because Sourcegraph is an end-user application with a UI that devs constantly use and care about, we never really had the MongoDB/Redis/CockroachDB risk of AWS/GCP/Azure just deploying our stuff and cutting us out. We're not protecting from downside here, but we are enjoying the upside because now those kinds of distribution partnerships are viable for us. To give a specific example, within ~2 months of making our code non-open-source last year, we signed a $1M+ ARR deal through a distribution partner that would not have happened if our code was open source. This is not our biggest annual deal, but it's still really nice!

We are totally focused on building the best code search/intelligence and appreciate all our customers and all the feedback here. Hope this helps explain a bit more where we're coming from!

> There were actually very very few companies that were going to pay but then decided to use the open-source version and not pay us. A lot of people probably assume that's why we made this move, but it's not.

> To give a specific example, within ~2 months of making our code non-open-source last year, we signed a $1M+ ARR deal through a distribution partner that would not have happened if our code was open source.

So the reason these deals are now possible is mainly because time was freed up by not having the code base opensource?

No, it's that if all the code is free and open source for anyone, we would not be able to charge for it and there would be no deals. Even if, say, 60% of our product was open-source and 40% was closed source, we might still get a lot of direct customers but would struggle to do distribution partnerships because the distribution partners have outsized incentives and capacity to reimplement the subset of the 40% they think their market needs.

“Of… liability? Or… uh, what?”

“Oh—risk that we couldn’t sell the apples we gave away, obviously.”