bshzzle

Hey just following up on this - we just shipped support for any model that supports the OpenAI Chat Completions API (1), including Ollama and Llama.cpp. You can checkout the docs here: https://docs.sourcebot.dev/docs/configuration/language-model...

[1] https://platform.openai.com/docs/api-reference/chat

Yea it's a similar idea - DeepWiki has the generated "wiki" part which we think is really cool (and maybe we'll add something similar in the future). The core chat experience is the same idea - we had some UX inspiration since we think they nailed the experience.

Deepwiki's context retrieval seems to be more sophisticated. I'm speculating, but I imagine they are using the generated wiki + embeddings which probably gives them higher recall over the codebase, vs. how we are using precision search.

Sourcebot has more "IDE" features built into the product like a file explorer and code navigation, which makes it easier to use the AI-generated answer as a jumping off point for further code exploration.

We went with Zoekt because it is full-featured (it's fast, supports regex, search filters, streamed search, etc.), and is a mature project. Sourcegraph, GitLab, and other large companies use it, so it felt like a safe choice. Overall our experience has been positive - maybe I'll write a blog post about it :)

awesome glad to hear! We are monetizing enterprise features like audit logging and SSO. The core product will remain free and under a FSL license.

Yea they are currently separate - the MCP server exposes out the same tools that Ask Sourcebot uses, but the actual LLMs call is on the MCP client. It would be interesting to merge them though - maybe have a Exa style MCP tool that lets MCP clients ask questions similar to how we are doing it with Ask Sourcebot.

Would be great to hear more about your use case though.

Ah I was just replying to your previous comment - I'm guessing you found this? ;) https://docs.sourcebot.dev/docs/connections/local-repos

Thanks for the support!

You certainly could create an embedding of your code and then hooking it up to OpenWeb UI or equivalent as a chat interface - we've actually spoked to some teams that have rolled their own custom solution like that!

From a product POV: our main focus with Sourcebot is providing a world-class DX and UX so that it is really easy to use. Practically speaking, for DX: a sys-admin should be able to throw Sourcebot up into their cluster in minutes with minimal maintenance overhead. For UX: provide a snappy interface that is minimal and gets out of your way.

From a technology POV: vector embeddings (and techniques like graph-RAG) are definitely something we are going to investigate as a means of improving the agent's ability to find relevant context fast. Bringing in additional context sources (like git history, logs, GitHub issues, etc.) is also something we plan to investigate. It's a really fascinating problem :)

Running Sourcebot with a self-hosted LLM is something we plan to support and have documented in the golden path very soon, so stay tuned.

We are using the Vercel AI SDK which supports Ollama via a community provider, but doesn't V5 yet (which Sourcebot is on): https://v5.ai-sdk.dev/providers/community-providers/ollama

We used Perplexity as a mental mapping since there is some overlap, e.g., LLMs using search and citing its sources, it's a webapp, etc.

I like this idea! Will fix this in a sec.

Yes - there is a file watcher that should pickup modifications to the configuration file.

And you can persist indexes across restarts by mounting a volume to the `/data` directory (e.g., `-v $(pwd):/data`). Indexes are stored in a `.sourcebot` cache directory.

Thanks for the interest!

Hey!

Yea that is correct - in its current state, it's functionally a UI wrapper on top of the zoekt-webserver api. One of the reasons why we decided to go with a separate app is that we have much more experience with Typescript, React, and NextJS (the web framework we are using), so it felt like we could move allot quicker using what we know.

In terms of semantic search, that is still very early days - my intuition is that having a separate "semantic code indexer" server written in Python would again allow us to move quickly (since all of the ML libraries are written in Python).

Thanks for the thoughtful question.

This is still day 1, so we honestly don't have an answer if we will get to a point where we can monetize - it's too early to tell. However if we do end up going down that road, I don't think generating revenue and being a good steward of open source is mutually exclusive.

My view is that there is a balance that can exist between open source and building a profitable business that doesn't negatively impact the open source community. Companies that come to mind that I think are striking this balance are PostHog & GitLab.

No just GitLab and GitHub atm - but please feel free to file an issue for Perforce support.

Yea exactly - on ingest it clones the repos and will periodically fetch new revisions.

Currently we don't support in-place repos, but feel free to file a issue and we'd be happy to take a look.

Currently, we don't have any plans of monetizing - the main focus for us right now is building something that people want to use :)

yes definitely - mind opening a issue so we can track it?

Thanks! Yea we would definitely like to support more code-hosts. If you have a sec, could you open a issue so we can track it?

I think in the immediate term, we would like to talk to as many people as we can that have this "search across many repos" problem such that we can dial in the core search experience.

Looking beyond the immediate, I think there is allot of fertile ground with respect to making engineering teams more efficient beyond just regular code search. Semantic code search for example is one of those features that I really wish I had when I was at my last job - would have made onboarding onto new codebases much easier.

Would love to hear more about your use cases: brendan@sourcebot.dev

yea it's a fair question - an IDE is often more convenient when you have the code checked-out locally. This becomes a pain when you work in a organization with potentially hundreds of repositories that you need to search across (e.g., a org stores their 100+ microservices in separate repos, and you need to find all places where they make a request to your service).