Most active commenters
  • sqs(3)

←back to thread

Sourcegraph went dark

(eric-fritz.com)
424 points kaycebasques | 19 comments | 20 Aug 24 03:30 UTC | HN request time: 1.236s | source | bottom
Show context
sqs ◴[20 Aug 24 10:28 UTC] No.41298641[source]▶
Sourcegraph CEO here. We made our main internal codebase (for our code search product) private. We did this to focus. It added a lot of extra work and risk to have stuff be open source and public. We gotta stay focused on building a great code search/intelligence product for our customers.

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.

replies(14): >>41298707 #>>41299099 #>>41299575 #>>41299592 #>>41299724 #>>41299784 #>>41299956 #>>41300159 #>>41300346 #>>41300771 #>>41301859 #>>41305881 #>>41311564 #>>41312895 #
quantumwoke ◴[20 Aug 24 10:39 UTC] No.41298707[source]▶
Been a fan of sourcegraph since 2016 or so, it's been exciting to watch the pivots along the way. That being said, the loss of transparency here is pretty sad, speaking as a large FOSS repo owner. What were the main factors apart from risk that went into the decision?
replies(1): >>41298885 #
sqs ◴[20 Aug 24 11:14 UTC] No.41298885[source]▶
Thanks for being a fan. And I understand it's a bummer to not have our code be public and open-source anymore. Sorry.

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!

replies(6): >>41298979 #>>41299240 #>>41301021 #>>41303956 #>>41305711 #>>41308575 #
1. cdchn ◴[20 Aug 24 12:06 UTC] No.41299240[source]▶
>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.

Trying to spin that it was "for the devs" is really stretching the bounds of incredulity. We get it, its fine, you have investors to answer to, but come on don't pee on our shoes and tell us its raining.

replies(3): >>41299289 #>>41299499 #>>41299604 #
2. sqs ◴[20 Aug 24 12:10 UTC] No.41299289[source]▶
Fair, I probably didn’t hear from the devs who weren’t annoyed by that. I heard from plenty of devs who were annoyed by it.
replies(1): >>41299474 #
3. orochimaaru ◴[20 Aug 24 12:36 UTC] No.41299499[source]▶
Actually this one I get completely. There’s plenty of places or managers with dev orgs that will check if they can install something complex in house with open source. Nothing wrong with it. But it’s usually a huge waste of time.
replies(2): >>41299761 #>>41299916 #
4. Cthulhu_ ◴[20 Aug 24 12:51 UTC] No.41299604[source]▶
Yeah while I'm sure the developers that were asked to just grab the code and make it work wasn't their favorite job, I think the bigger one is further down - Github developers being tasked with reverse-engineering an open source product to create a closed source clone.

I would've respected GH more if they just used Sourcegraph and instead spent those developers on improving the open source product itself. But, I suspect that Github / Microsoft would then need a locked down license that e.g. Sourcegraph would forever remain open source, or that GH gets free licenses if they ever went closed source, or whatever.

replies(1): >>41299677 #
5. cdchn ◴[20 Aug 24 13:00 UTC] No.41299677[source]▶
>Yeah while I'm sure the developers that were asked to just grab the code and make it work wasn't their favorite job, I think the bigger one is further down - Github developers being tasked with reverse-engineering an open source product to create a closed source clone.

They don't want Github to clone their product. They weren't doing it for the Github devs.

6. pas ◴[20 Aug 24 13:12 UTC] No.41299761[source]▶
Why? Getting operational experience with the product that you might then pay a lot for seems very important. Especially if you end up liking the product/service but not the pricing changes that might then happen, so doing some exploratory fact finding for a backup plan doesn't seem to be waste of time.

For example when we used Jira on-prem and it was snappy and we were happy ... and it was a rather important point of difference compared to the slow shitocumulus version.

Also, when people are using GitHub issues to ask questions the problem is usually a lack of clear documentation. (And if spending time to link FAQ answers to potential customers is a waste of time ... then maybe it's not surprising that Sourcegraph CEO is doing damage control on HN instead of focusing on focusing or whatever.)

7. Aeolun ◴[20 Aug 24 13:31 UTC] No.41299916[source]▶
> But it’s usually a huge waste of time.

Is it? I think at this point my company has probably saved millions of dollars by not paying for subscriptions, but hosting everything in-house. The price point of a lot of these services makes perfect sense when you are small, but paying 1M/year in subscription fees when you can host the same thing for 10k/year is just bonkers. I appreciate that someone has to pay for it for them to continue making the product, but there’s a point where it makes more sense for me to spend a year setting it up (and really only costs two weeks).

replies(3): >>41300441 #>>41302179 #>>41302269 #
8. orochimaaru ◴[20 Aug 24 14:32 UTC] No.41300441{3}[source]▶
My experience was with things like openstack and kubernetes. The org decided to do “cloud” in house first with openstack and then kubernetes - and run critical services on them that had very strict performance SLA.

The amount of time needed to do the whole thing wasn’t worth it. Sure I enjoyed tinkering with the kernel and drivers and k8s. Also diving into known cgroups and namespaces worked etc. However, from a time to market/stability perspective the solution was nowhere comparable to what public cloud providers offer.

Yeah - the subscription costs more. My experience has been that when things get big and hiring gets tense in house solutions just add stress on the devs maintaining it. At least with public cloud services - it’s clearer - if the budget doesn’t exist don’t run it.

I will add that I don’t use sourcegraph nor am I connected with them in anyway. So I’m not batting for their go private strategy. Just commenting on this one point.

9. OliverGilan ◴[20 Aug 24 15:39 UTC] No.41301032{3}[source]▶
This seems weirdly hostile. He laid out a bunch of points but you’re grabbing on to this one to make it seem like he’s using classic corporate-speak. Do you find it so unrealistic that the CEO of Sourcegraph has heard from devs that their managers asked them to try to clone or investigate the product before buying? That seems pretty likely
replies(2): >>41301297 #>>41301632 #
10. HelloNurse ◴[20 Aug 24 16:08 UTC] No.41301297{4}[source]▶
Investigating Sourcegraph's source code as part of procurement is not only plausible, but useful work that a software engineer should be happy to do.

Stating that making such evaluations impossible is a good thing is therefore more bullshit than other reasons to go closed source.

11. int3 ◴[20 Aug 24 17:28 UTC] No.41302042{5}[source]▶
people can do things for more than one reason
12. everforward ◴[20 Aug 24 17:45 UTC] No.41302179{3}[source]▶
That math only works out nearly that cleanly if you avoid pricing out the engineer time for it.

If you’re paying $1M/year in fees, I would be shocked if you don’t have a whole team to support the open source version. Oncall, system upgrades, the usual stream of tickets about things not working right and people wanting to integrate, etc.

I do believe it can be cheaper to self-host, but I really doubt the difference in cost is 2 orders of magnitude. I’d be surprised if it was a single order of magnitude. I would wager it’s less than the sellers profit margins because of economies of scale; I would guess in the range of 10%-20%.

replies(1): >>41303944 #
13. avianlyric ◴[20 Aug 24 17:53 UTC] No.41302269{3}[source]▶
Well that obviously doesn’t apply to Sourcegraph because their self-host offering requires paying a subscription. You can’t use any form of Sourcegraph on private code, (at least not without all the important features being nobbled) without paying a subscription. So there’s no saving to be made from self-hosting sourcegraph
replies(1): >>41302922 #
14. avianlyric ◴[20 Aug 24 17:57 UTC] No.41302311{5}[source]▶
If we ignore the final sentence of his reason, then you might have a point. But given his reason ends with:

> This honestly was just a waste of everyone's time.

Makes it pretty clear that the benefits to Sourcegraph (I.e. not wasting time negotiating with companies acting in bad faith), was a large part of this rationale.

Besides, if you had ever tried using the OSS version of Sourcegraph, you would realise that OSS Sourcegraph is a shadow of its enterprise version. Trust me, Sourcegraph didn’t loose any sales to people running OSS Sourcegraph, and anyone who’s willing to rip out the licensing system, so they can use the enterprise features without paying, obviously isn’t going to become a paying customer either.

15. tptacek ◴[20 Aug 24 18:20 UTC] No.41302534{5}[source]▶
It's both hostile and, worse, boring. I know it sucks to be intrinsically less interesting than someone you disagree with passionately, but it is the case here that the CEO of the company explaining their policy shift is much more interesting than your rebuttals, which seem superficial and rote by comparison.

Someday somebody is going to be intrinsically more interesting about, like, supporting DNSSEC than me (maybe Geoff Huston will sign on and start commenting), and I'm going to want to claw my eyes out. I have empathy for where you're coming from. But can you please stop trying to shout this person down?

16. JamesBarney ◴[20 Aug 24 18:57 UTC] No.41302868{3}[source]▶
He took the time to write out a detailed explanation of why they made a decision they did. Giving us more transparency than 99% of CEOs or companies. There is a whiff of spin there, but come on compare it to every other product decision ever made and we're getting so much more transparency.

Behavior like this means the next time a CEO will be marginally less motivated to do this. You're shitting in the commons.

17. mdaniel ◴[20 Aug 24 19:02 UTC] No.41302922{4}[source]▶
> So there’s no saving to be made from self-hosting sourcegraph

That may have been true in the time before LLMs, but I'd argue that any sourcecode exfiltration nowadays runs the very real risk of "oh, sure, we won't use your code for training our model ... wink, wink"

replies(1): >>41303622 #
18. lallysingh ◴[20 Aug 24 20:16 UTC] No.41303622{5}[source]▶
There's enough open source code available that the hassle of other code probably isn't worth it. LLMs aren't insightful enough to benefit from any differences you'd see between open and closed source code corpii.
19. renewiltord ◴[20 Aug 24 20:53 UTC] No.41303944{4}[source]▶
Many organizations will accept defacto 90% SLA if internal vs 99.99% If external