Sourcegraph CEO here. We're back to work on testing release candidates for Sourcegraph 2.12, coming out this week. I'm especially excited about a few big new features that fit really nicely into the code search and browsing workflows people use Sourcegraph for:
along with a whole host of improvements to code search, code intelligence, self-hosted deployment on a single node and k8s, etc.
Happy to answer any questions folks have about our open sourcing. I summarized the business case at https://twitter.com/sqs/status/1046913901688807424. And we went with the Apache License (2.0) and an open core model because that's about as standard and as open as possible for this kind of thing.
Every single developer that used Sourcegraph and talked to me about it loved the product. I think that every code product must have intelligent navigation.
I saw you already responded to my tweet in https://twitter.com/sqs/status/1046986755919024129 We're looking forward to add Sourcegraph to GitLab by default and it is awesome that you offer to do the work.
Thanks for choosing the Apache license which will make this much more acceptable to some companies then for example AGPL.
Sourcegraph CEO here. :) Thanks for creating GitLab and for the kind words. We're indeed looking forward to adding Sourcegraph to GitLab by default. Look out for a prototype/proposal MR from us in a bit. That's one of the super valuable kinds of features/integrations that we can do now that Sourcegraph is open source!
It's too bad that a browser extension is required to make this work. I've asked previously for GitLab to provide the necessary hooks so that any plugin could offer this type of functionality in a first class way, and was told that the proposal lacked a "concrete first need". I suppose SourceGraph has now demonstrated the usefulness of such a thing, which is great!
Yes, we would love to integrate Sourcegraph into all code hosts directly and not require users to install a browser extension. Please provide the same feedback to other code hosts you use (GitHub, Bitbucket, Phabricator, etc.) as well and link to this thread. :)
Hey! Sourcegrapher who works on the browser extension and other integrations here.
The road to complete integration in a product is a bit longer as it takes collaboration if the product isn't open source. This is what we'd like in every product we integrate with.
However, I just did quite a bit of refactoring to make it easier and more straight forward to add support for new code hosts to the browser extension.
If you want to add support, we'd gladly accept a PR!
Hello Mike! Can you please reference the Sourcegraph example in the issue? Maybe this will initiate further discussion and convince someone to reconsider your proposal. Thank you!
Sourcegraph engineer here - that's the goal of the Sourcegraph extension API, being generic and code-host agnostic. One Sourcegraph extension can provide the same features on any code host (Gitlab, GitHub, Bitbucket, ...)
- We are a pretty small shop, only 3 developers, and looking at Sourcegraph for the first time. We have a full Kubernetes cluster for running some of our production applications and would be happy to run this there. The Sourcegraph site lists a Quickstart instructions and instructions for Data Center. I am unsure what exactly the difference between them is.
- The Docker image for sourcegraph/server (used in your Quickstart instructions) doesn't have a Dockerfile listed anywhere. Is that available somewhere?
- The Quickstart instructions also seem to instruct mounting the Docker socket into the container. I haven't seen anything that explains why that is required.
Basically wondering which version I should be looking to deploy for our small team.
You should definitely use our Quickstart instructions :) You can deploy it to your existing Kubernetes cluster (or any other Docker environment).
- The Quickstart instructions[1] describe how to set up a single-machine single-container Sourcegraph instance, which is recommended for small teams. Our Data Center[2] offering is for large teams and runs Sourcegraph across multiple machines in multiple containers for high availability, scalability, etc.
- The Docker Hub image sourcegraph/server is the official, free Sourcegraph build is called Sourcegraph Core and it includes various paid enterprise features built in so that upgrading to Sourcegraph Enterprise is easy (you only need to supply a license key, rather than migrating to a new Docker image). So, the exact recipe for building it is not open-source. However, we use the same exact Dockerfile in Sourcegraph OSS[4] which you can take a look at.
- Each language server providing code intelligence will run as separate Docker container. By mounting the Docker socket into the container, Sourcegraph can automatically start/stop/manage these containers for you. However, this is not required, and in the case of Kubernetes deployment we do not recommend it, please see the "Manual Installation" section of our Code Intelligence docs[5] for more information.
- Write the server part https://github.com/chrismwendt/graphql-ws-langserver (once a browser-based GraphQL analysis library exists, this would be unnecessary because the analysis could be done entirely in the browser)
What features (other features, if any) are you specifically interested in? It would be awesome if you posted feature request issues on the open-source repos for sourcegraph/sourcegraph or for the editor plugins!
- https://github.com/sourcegraph/about/blob/master/projects/ex...
- https://github.com/sourcegraph/about/blob/master/projects/so...
- https://about.sourcegraph.com/blog/discuss-code-and-docs-in-...
along with a whole host of improvements to code search, code intelligence, self-hosted deployment on a single node and k8s, etc.
Happy to answer any questions folks have about our open sourcing. I summarized the business case at https://twitter.com/sqs/status/1046913901688807424. And we went with the Apache License (2.0) and an open core model because that's about as standard and as open as possible for this kind of thing.