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 :)
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.
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 :)
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.
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).
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.
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.
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).
[1] https://platform.openai.com/docs/api-reference/chat