Our product, Sourcegraph, lets software teams search and explore their code, so naturally we think a lot about how to help software teams ship better software faster. As we've grown, we've learned a lot from GitHub, Visual Studio Code, GitLab, and other teams who have shared their internal processes, and we're going to start doing the same.
We'll be publishing a series of posts here about how we build Sourcegraph. A few things make Sourcegraph and our development process different from many other companies:
Our product is for developers, so our developers naturally have a larger role in product planning and user/customer interaction (compared to companies building products for salespeople, photographers, etc.).
Our product needs to be super easy for a single developer to set up, get code search and intelligence on their organization's codebase, and share with their entire team.
Sourcegraph is self-hosted; organizations run the Docker image or Kubernetes cluster for Sourcegraph on their own servers. We can't roll back or push out an automatic update. (Sourcegraph.com is a public instance with only public code from GitHub.com and other sites; customers' code never touches our servers.)
Unlike many other developer-facing products, developers directly interact with our product and its UI. It's not just running behind the scenes.
All this means we need to communicate well internally and externally, and we need to ship a robust, high-quality product to customers on a consistent schedule.
Subscribe to email updates to get notified when the next posts in the series are published. Tell us @srcgraph if there are other topics you'd like to hear about. We're looking forward to sharing our team's culture and processes!