sqs

Yes! Ollama models show up in the chat model dropdown in Cody, if Ollama is running on your machine.

Not that many people use Copilot Chat, anecdotally. We've focused on codebase chat when building Cody (https://cody.dev), since we can use a lot of the code search stuff we've built before. It's hard to build, esp. cross-repo where you can't just rely on what's accessible to your editor. You can try it on the web if you sign up and then go to any repository's sidebar on https://sourcegraph.com/search, or get it for VS Code/JetBrains/etc.

It's its own editor (albeit forked from VS Code), it's not a VS Code extension. They've built a great product.

Thanks for helping us make the product better! You can post any issues at https://community.sourcegraph.com. And you can also email support@sourcegraph.com (for customers or any private issues).

We will continue to have a free tier for personal use. Soon we will have a free tier of code search on Sourcegraph.com for private code.

Cool! I’d love to chat.

I was thinking business risk. Sorry it wasn’t clear.

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.

Both are factors, as I said in my original post (focus and risk).

> 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.

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!

Awesome to hear! What sucks about Sourcegraph for you, and how can we make it better?

Yes! We took a snapshot of the code and are keeping it at https://github.com/sourcegraph/sourcegraph-public-snapshot.

I see the point about keeping the old repo name so that links work. That's also mentioned in the blog post. That's a good idea. Let me chat with our team about that.

For your approach with syncing an encrypted form of the private code, why did you need/want to sync it back? Why not just keep a public snapshot as of the switchover date?

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.

Thanks! We appreciate you. It was really a focus thing. It added a lot of overhead, lost focus, and risk to have stuff be open source. Most customers weren't telling us it was valuable to them, and frankly we heard very little from people who were using our open-source build. (How could we have gotten your input earlier?)

We still have a lot of open-source code, but ultimately we need to focus on building a great product and making money on it. Which we are doing. :-) As Sourcegraph CEO, I obviously wish we could do all the things, but we gotta stay focused on building a great code search/intelligence product.

Glad you use Sourcegraph! I remember that blog post and thought it was awesome. I am the Sourcegraph CEO, and we haven't changed anything about our public code search at https://sourcegraph.com/search. That's the same product tons of customers use for their internal code, and our public code search is a really important way for us to dogfood, iterate fast, etc.

We just made our own internal codebase private.

We still have tons of repositories searchable at https://sourcegraph.com/search, almost a million. We did cull lots of non-GitHub repositories and repositories with less star. It was very complex to keep up with millions of repositories due to GitHub rate limits and scaling. We tried to keep as many as possible while still being able to focus on making a good product for customers (our biggest customer has ~600k repositories).

We're still spending millions of dollars annually to offer public code search, so our intent is certainly not to "destroy" it! If you have repositories you want us to add that are below the star threshold, please post at https://community.sourcegraph.com/t/most-public-repos-no-lon....

Impressively fast responses from Points.com!

1. Ah, this commit message feature isn't available in JetBrains yet, unfortunately. Most things carry over since they both use the same underlying code, but this is more editor-specific.

2. Your "reasonable near-term goal" is right in line with what we are thinking. Basically, "auto-edits" is f(edit that meets deterministic trigger criteria) --> multi-file diff. Here are some examples we have in mind; any others you had in mind?

update a type signature --> ripple that change across to all call sites/value literals (kinda like symbolic rename does today, but for more than just the name)

rename something --> update the docs

change code with a comment nearby --> update the comment if it's now invalid

update a func impl --> propose a new test case

Not for this fine-tuned model yet, but Cody supports local models: https://sourcegraph.com/docs/cody/clients/install-vscode#sup....

I just used Cody with Ollama for local inference on a flight where the wifi was broken, and it never fails to blow my mind: https://x.com/sqs/status/1803269013310759236.

Yeah, that is needed to make everything more accurate. We are working on 3 related things to make Cody better understand the structure of your code and take feedback from the compiler (and other tools).

All are experimental and not enabled by default, but you can peek at them if you're interested.

1. (experimental) LSP-based context — https://github.com/sourcegraph/cody/pull/3493

2. (experimental) TypeScript tsc context — https://github.com/sourcegraph/cody/pull/3843

3. (experimental) OpenCtx, which can pull in diagnostics from tools outside your editor — https://openctx.org/

And then of course the agent to actually iterate on the generated code based on this feedback.

We're really excited about this stuff, and it'll arrive in Cody when we can get it to a high quality bar and prove it helps.

For 1, set `"cody.experimental.commitMessage": true` in VS Code and then click the Cody icon above the commit message box in VS Code's source control sidebar. Let me know how that works for you (here or at https://community.sourcegraph.com).

For 2, we're working on it! And eventually we'll support cross-repository refactors in Cody using our batch changes (https://sourcegraph.com/docs/batch-changes). What kind of refactors do you want to make?

What would make it better than decent for you?

Awesome to see our Rust fine-tune here on HN. We (Sourcegraph team) are here if anyone has questions or ideas for us!

BTW, Cody is open source (Apache 2): https://github.com/sourcegraph/cody.

Teams (that don't need Cody Enterprise) should just buy Cody Pro for each dev individually for now. We will have shared billing soon.

Sourcegraph CEO here. We stopped making a standalone Electron app (which was an experiment) and instead remained focused on our web app and editor extensions. You can use Cody in your editor with no server needed. We didn’t fizzle out. :)

Haha, yeah, @jdorfman's sibling comment mentions the tools we use. Any mentions on HN, Reddit, Twitter, YouTube, etc., show up in our team chat. The gold standard, of course, is Sid at GitLab ("GitLab CEO here" :).

Sourcegraph CEO here. It’s not $99/user/month anymore. It’s great that a lot of companies were willing to pay that, but we and our customers prefer a lower per-user price and a higher % of devs at the company using it (ideally 100%). We reduced prices for our customers (current and future). You can see the posted pricing at https://sourcegraph.com/pricing.

For any other dev tools companies, I’d strongly recommend having lower prices so that every dev at your customer can use it (if that’s relevant for your product). If you start seeing customers be really picky with who gets a license, it’s probably priced too high.

Confirmed. Not affiliated in any way.

I am the Sourcegraph CEO. I don't know who this person is, and he is not affiliated with Sourcegraph, although I am grateful for his kind words! This is not an instance of what you're talking about.

I do agree with you that we'll all see see a lot more of this nefarious stuff going on and should be on guard.

You can try out GitHub Copilot Workspace now in read-only mode:

https://copilot-workspace.githubnext.com/AnandChowdhary/anan...