32 - Basic Developer Human Rights: Quinn Slack
10/24/18
Five years ago, Quinn Slack and Beyang Liu had a very simple idea to make programming more efficient: code search. They imagined a powerful query langauge with the ability to search through all commits of a project, all of a project’s dependencies, and across all repos of a large team. It would be fast and reliable, a tool that developers could depend on to use dozens of times per day. They wanted to bring the powerful search tools that large companies like Facebook and Google have to all developers. Sourcegraph was born.
Over time their vision to improve programming codified into the Sourcegraph master plan. In parts it reads as a list of “Basic Developer Human Rights.” They declare:
Every developer deserves to have all these features work 100% of the time:
Jump to definition
Hover tooltips (with type info and docs)
Advanced textual code search
Symbol search
Find references (local and cross-repository)
Autocomplete
Automatic formatting
Inline errors, linting, and diagnosticsThe above features should be available:
For every language
In every IDE and editor
Everywhere you read code (on GitHub, Bitbucket, GitLab, Visual Studio Team Services, > Stack Overflow, Phabricator, Sourcegraph, etc.)
Everywhere you review code (in pull requests on GitHub, etc.)
For both your own code and the code of all of your dependencies
And in just a few short years, they’ve made a shocking amount of progress towards achieving this goal. They’ve whole-heartedly adopted Microsoft’s Language Server Protocol and are organizing the community around building LSP implementations for all popular langauges. Chances are that this will work with whatever text editor or IDE you use, and you can install the Sourcegraph Chrome Extension to get it working on your code hosting platform. If it doesn’t work with your programming language of choice, you can build it yourself and get paid for it – Sourcegraph has offered to sponsor anyone looking to build an LSP implementation.
It doesn’t stop there. Sourcegraph recently released the Sourcegraph extension API, which allows developers to write editor extensions that will work anywhere that Sourcegraph works, which is now virtually anywhere you look at code.
In this conversation, we learn about the technical challenges to brining code intelligence to all editors, and Sourcegraph’s chosen solutions. Quinn explains how Sourcegraph code search is so effective without resorting to any fancy machine learning. We also discuss the trade-offs of open-sourcing a devtools company from Day 1, how to find like-minded investors, and how to “win the hearts and minds of developers.”
Transcript
Transcript sponsored by Repl.it
Oops! I sent this episode off for transcription before adding the introduction. I pasted the message from our sponsor below at a negative timestamp.
-00:30:00
SK:
Repl.it is an online repl for over 30 languages. It started out as a code playground, but now is goes up to a full development environment, where you can do everything from deploying web servers to training ML models, all driven by the repl. They are a small startup in San Francisco, but they reach millions of programmers, students and teachers. They're looking for hackers interested in the future of coding and making software tools more accessible and enjoyable. So, email jobs@repl.it if you're interested in learning more.
00:00:00
SK:
I am here now with Quinn Slack. Welcome Quinn.
00:00:03
QS:
Thank you, excited to be on.
00:00:05
SK:
Yeah, really excited to have you. If I'm not mistaken, you said you're now in Germany?
00:00:11
QS:
Yes, I'm in Germany, in Berlin. PRISMA is very nice to host me here while we're in Berlin. They have this amazing soundproof room that I'm speaking from, so props to them. They got a great product too.
00:00:24
SK:
Yeah, yeah, I am familiar with PRISMA. That is awesome that they have a soundproof room. I do not and I recently moved to London. There was construction nearby, so hopefully that won't interfere too much. Okay, so can I just ask what are you doing in Berlin?
00:00:43
QS:
Yeah, visiting people we know. We have a teammate here, Felix, who's based in Berlin, some customers and going to the Go Meetup tonight, just a quick trip through Berlin, had been in Singapore before. We have users, customers all around the world and it's good to go visit them. Also, I had an Indian wedding that brought me outside of San Francisco, so might as well hit up some other cool places on the way.
00:01:08
SK:
Got it. That makes a lot of sense. You mention you have a teammate there, so you have a semi-remote team, it sounds like.
00:01:15
QS:
Yeah, we're about one-third remote. We want the best people, the best developers no matter where they are in the world and turns out, they're not all in San Francisco. We have teammate in Germany, teammate in Phoenix, teammate in South Africa and looking to grow a lot more there.
00:01:33
SK:
Oh cool, so I was poking through the interwebs and I saw that you had started this company five years ago. Is that about right?
00:01:42
QS:
Yeah, that's when we really started Sourcegraph as a project because we wanted it. We wanted better code search and now, it's grown into a business and company. We're really just getting started.
00:01:55
SK:
Cool, so was this your first foray into the world of developer tools? I'm curious to kind of get your origin story from that perspective, who or what were your first major influences?
00:02:07
QS:
Yeah, let me start back early on, I'm a coder. I've always love coding and back when I was much younger, I would write code for other companies and they send me checks through the mail, companies all around the world. This was middle school, it was just amazing that I could write code anywhere in the world and help out these companies. I saw that, “Wow, writing code is this amazing opportunity.” Then, fast forward a little bit, met my co-founder Beyang. He had been at Google. He had seen inside Google and what we had heard from Facebook, they have these amazing tools for developers that let them search all their code and be way more productive than you could possibly be, just constantly reinventing the wheel. At the same time, we also got to work inside of some big companies, Bank of America, JPMorgan. We saw that they have amazing people, amazing technology, but they don't have a way to look across all of their code and see "Who's already written this?" "Does this exist?" "How do I use this?"
00:03:11
QS:
Those two experiences, plus Beyang and I were hackers. We loved coding and we loved seeing how can we save time while coding, who's using the same libraries that we're using. These three things came together and we said, “Wow, Sourcegraph is something that makes the world more like what we want it to be, where any developer can be extremely productive.” It's also something that every company needs that these big companies need, that small companies need and it's something that we ourselves really want as developers. We built Sourcegraph and it's better code search for developers. It's something that you use while coding. You got your monitor up on one screen, you're writing code in your editor and on the other screen, you got a Sourcegraph. It's where you say, “How do I do this, how do I call this, how is this implemented?”
00:03:59
QS:
Step one is build a better code search for developers. I think we're well on our way there. What it's turning into of course is more than just search because the result of search is not a result, but an answer, so a way to answer the questions that come up while coding. I'll talk more about the third step, but we eventually want to make Sourcegraph into something that doesn't just help developers be way more productive, but that also gives them an opportunity to make a living, writing code, so that anyone anywhere in the world who needs the code they're writing will be able to pay them or have their company pay them. Obviously, a grand vision, but we're totally focused right now on building the best code search tool for devs. Code search is this interesting kind of tool. What we've seen is maybe 20% of developers, they just instantly click with code search. Steve, do you use code search regularly?
00:04:52
SK:
Like just on GitHub or you mean-
00:04:56
QS:
[inaudible] search.
00:04:57
SK:
Well, yeah of course, like you have to be constantly searching for things throughout your project. Is there another way to do it without that?
00:05:04
QS:
Well, how often would you say you use code search?
00:05:09
SK:
Like in my developer, I hit like just Control F or Control Shift F to like to search my whole project?
00:05:15
QS:
Yeah.
00:05:17
SK:
Like constantly, like I don't even keep track of all. It's like how often do I use Google, like I don’t know, every few minutes.
00:05:23
QS:
Yeah, what about searching across projects other than the one that's like currently in your editor?
00:05:30
SK:
Other projects that I've written? I'm not sure what you mean.
00:05:34
QS:
Like you're writing code, you're using some open source library and you want to see, “Well, how am I supposed to call this function?” You might be able to pull up the docs. You might want to see the projects on repo, how is it called. You might want to see how other people from other repos are calling it. Do you ever do things like that?
00:05:52
SK:
Oh yeah, all the time.
00:05:56
QS:
Okay and so, turns out not everyone does that all the time. There are a lot of developers who've never seen what a good code search tool can do for you. They might search inside their editor, but they're not benefiting from code search. We see this just crazy opportunity, where 20% of devs, they code search all the time. Most of them, they'll have a code search tool at their company. Some people will use GitHub, but when you have a tool like Sourcegraph that's meant to do code search and that does it really well, then it turns out you code search a lot, but 80% of devs out there, they're not really sure, “ Well, what do I use code search for?” It's been really magical for us, where we get pulled inside of a company, our product does and the 20% of devs it immediately clicks with them. Then, the other 80% of devs, we turn them on to code search and you see these people the first time they do zero code searches in a week. Then, the next week, they do a few code searches. Then, it grows from there. They brought this entirely new tool into their workflow that's on par with like everyone remembers back when before GitHub. Then, you brought GitHub in your workflow and that was such a big improvement.
00:07:04
QS:
We're doing that with code search. The pattern, the reason why we don't think we're totally crazy here is if you look at what devs inside of Facebook and Google use, they use their code search tools all the time. We're bringing that to every other company in the world. We're really building a brand new product that most developers do not have a ton of experience with, but that really clicks for them quickly. From our point of view, it's awesome that we can be a new product in their tool kit, but it's not that great if you're a totally new thing. The no-brainer thing that every developer can use immediately is our browser extension. You install that and then, any code you look at on GitHub or your other code hosts, you get all the code intelligence. You get go to definition, hover tooltips and so on.
00:07:52
QS:
Usually, what'll happen is you start using that, you say, “Wow, I love that, makes it way easier to browse code, I can click through, go to definition, makes it easier to review code.” You start using code search. You bring it inside your company and then, it spreads inside your company and will have hundreds of users per day inside of a company by the time they reach out to us and ask any kind of question. That's our business and we will not stop until we have every developer using way better tools that means code search to make them way more productive and code intelligence whenever they look at code. That's what we're all about.
00:08:31
SK:
Wow, quite a story. I just want to like backtrack a bit because I'm not sure if I answered accurately when you asked the question of whether or not I personally code search because I think it's like nuanced. On GitHub, there's a way you can search code. You just like type in a snippet of code, it searches all the project and I've used that before. It's crappy, so I basically never used it. Is that the sort of code searching that you guys have just better?
00:09:03
QS:
Well, I don't want to call it crappy. I would say the use cases you'd use that for are very different from what you'd use Sourcegraph for. A lot of people that's what they think of as code search. You might use GitHub’s code search, which is totally global, like a couple times a week, a few times a week, but Sourcegraph code search, it searches over the code that you're actually working with, the code that's in your company's projects, your dependencies. It's like similar in some ways, but it searches over the code you care about, it's a lot more scoped and then, it supports regexes. It's like really fast, supports any revision and so on. If you have been using GitHub code search a few times a week, you'd probably be someone who uses Sourcegraph code search like 30 times a week or more.
00:09:55
SK:
Got it and it searches every revision, every commit?
00:09:58
QS:
Searches any commit. You can do a search over all revisions. You can search for diffs. Like one great use case is if something related to access token starts failing, you see exceptions in your logs. You just do a diff search over access token. You see like what are all the changes related to access tokens? What are all the git diffs of commits that are related to access tokens?Yeah, it does all these things, things that you might not have even thought of code search could do.
00:10:27
SK:
Fascinating. That's very cool. That's the main product and then, the intelligent IDE features is more of the, like intro, the way you get people in door...?
00:10:42
QS:
Yeah.
00:10:44
SK:
Got it, cool.
00:10:44
QS:
In the way, they're connected. As a developer, you have these questions you need answered: How do I do this thing in the code? Why is it built this way? Why did this thing break? Sometimes, you get that answer just by doing a search and seeing the result. Sometimes, you need to pivot from there and say, “Well, what are the callers of this function?" or "What's the definition of this?” Sometimes, you need to see history or blame. We want to be that place you go to answer these questions that come up while you're coding, so you can get back to coding and build a lot more awesome stuff.
00:11:15
SK:
Got it. That makes a lot of sense. People will add that sort of information into whatever editor they use or they have Sourcegraph open in another window?
00:11:27
QS:
They have Sourcegraph open in another window and you can install an editor extension, so it's like a single hotkey to jump to Sourcegraph. A lot of people though, they just set up like a Chrome or Firefox shortcut, so they do alt tab, they hit S tab and then, type in a search. As you know with developers, there's not one way that everyone does it. People have all kinds of different shortcuts set up to launch Sourcegraph.
00:11:51
SK:
Got it. Cool, so I wanted to talk about your master plan. That's a phrase that I am familiar with. I constructed my own a few years ago and I based it off of Juan Benet's master plan that I had access to. I see that I think over email you mentioned that you also know him from school.
00:12:14
QS:
Yeah, I had the pleasure of getting to work with him in undergrad, worked in a lab together. He's done just amazing things. I also think your master plan is awesome. That was one of the things that I picked up on when I was doing research in advance of this. To anyone listening out there, if you want to know where the genius for this podcast comes from, then check out the master plan and I think you'll get a great sense.
00:12:37
SK:
Thank you. Yeah, anyways, I'm a little embarrassed of it at this point because things have changed a lot, so I need to work on version two. I guess that's always how it happens. If you're not embarrassed of your old self, then you're not learning I guess.
00:12:53
QS:
Exactly, it's a good way to track progress too.
00:12:57
SK:
Yeah, just going through your master plan, I saw that you have like phase one and it reads to me almost like a declaration of developer rights or like developer human rights, like, “We believe like developers are entitled to these features in every editor that they use.” Then, you like list a bunch of things. I don't have the list off the top of my head, but it's like jump to definition, I guess like seeing the type of functions, those sorts of things. Is that how you seen it like you're putting a stick in the ground and saying, “This is like the bare minimum.”
00:13:34
QS:
Yeah, absolutely. There are so many neat advanced developer tools and advanced kind of static analysis, but until we make it, so that every developer when they're writing code in their editor and when they're reviewing code, they have code intelligence. They have go to definition, find references, hover tooltips, like we don't need to worry about the more advanced stuff, let's get that evenly distributed to every developer. That's such an obvious win. Yeah, we don't have it. Any company like us, anyone building a product like this, first focus on the basics, the obvious things that every developer should have. It turns out there are some pretty significant technical barriers to getting those things available in every editor in a consistent way in every code host, in every code review tool. That's one of the things that we're focused on now. We'd love to talk more about how we're doing that.
00:14:25
SK:
Yeah, well, so one of the technical challenges that I thought interesting, you put well on your master plan was how it was an M times N problem, where you had like M different editors and N different languages and so, it was just like you needed to build a customized thing for every combination of the two. You reframe the problem, so now it's an M plus N problem. Can you walk us through that and other technical challenges and solutions you're working through?
00:14:56
QS:
Yeah, so this is the idea that for every editor out there, Vim, Emacs, Atom, VS Code, Sublime, Visual Studio, all these things and then, for every language, Python, Go, TypeScript, JavaScript, Rust, Scala, if you want to get full language coverage for each of those combinations, there's a lot of things to write. You got to write the Rust Vim plugin, you got to write the Atom Go plug-in and that's think of a matrix. You have M editors and N languages. It's a lot of cells to fill in, so turns out, developers have done a decent job of filling those in, but there's a lot of wasted effort, think of how much duplicated effort has gone into writing Rust support for Vim and then, writing Rust support for Go.
00:15:42
QS:
What if the effort could be better shared? Turns out for Rust that's a new language. It's done a great job. They've written one Rust language server that all the editors use. They've collapsed the problem into do a little bit of work for each editor and then, the hard work for analyzing Rust code that's all done. It's really cheap to add in new editors. Other languages haven't done quite as good of a job because the concepts like language server protocol, which is the standard way of how does an editor talk to the language support module that didn't exist. Now that that exists that helps us collapse this problem into M plus N and make it a lot easier, so that no matter what editor you use, you're going to get the same great language support.
00:16:28
QS:
It turns out that this is even more important than you might think because it's not just editors that you want to have language support in. It's also really wherever you look at code, it's also your code host, your code review tool and then, other kinds of tools you might write to automate coding. Why shouldn't you get code intelligence when looking at code on GitHub, when reviewing PRs on GitHub or GitLab or any other code host you might use. It's all the more important that you have one thing that understands the language really well and that any tool can interface with. Microsoft invented language server protocol, LSP, a couple years ago. They have released a few implementations. We've released some implementations for Go, for TypeScript, JavaScript. Some of our teammates also did PHP and other languages. Those have shipped as part of Atom and VS Code.
00:17:23
QS:
Some other companies have built some great language servers. This is really the first effort of its type in static analysis. It's really gotten traction. Basically for any language out there, there's a language server. Not all of them are production quality or perfect, but there's a lot of work going on to make them better. You can see a table that we've compiled of the language server status for each language at langserver.org. You can begin to see how every language pretty soon is going to have a really high-quality language server, which makes it so that in any tool you use, you're going to get great code intelligence. This is the way that we are addressing this basic developer human right, which is that developers should get these things no matter what language they use, no matter what tool they use. That was something that just seemed so far away when we started Sourcegraph. Now, it's finally within reach.
00:18:17
QS:
I think that we've made a pretty big impact on getting the world there. All that work is an open source too and there are just hundreds or thousands of contributors to these language servers. It's a really cool effort.
00:18:30
SK:
Wow, yeah, you must be so proud.
00:18:33
QS:
Yeah, well, I'm also a very happy user because I use these. I'm an Emacs and VS Code user and I cannot wait for the world, where in Emacs or in VS Code, I can get the best of both worlds and I never have to be jealous when in Emacs of the things I get in VS Code and vice versa.
00:18:53
SK:
Got it. Just very, very specific implementation detail question, so when I install the Sourcegraph Chrome extension and then, I go to a public project and then, I can open it in Sourcegraph. The language server is running on your servers and that’s how it's happening?
00:19:10
QS:
Yeah, but let's talk about the editor case. Language service can also be used in editors of course and what the editor will literally do is run the language server process on your own machine. It's totally local. It's a server, but there's no need for it to be on a different machine. When you put your mouse over a token in your editor, it will ask the language server for, “What should I show in the hover tooltip on line 37, character 22?” The language server gives it some text string back and it shows that in the tooltip and that's it. Same idea for definition, the editor will ask the language server, “Okay, the user asked to go to definition on line 85, character 102, what is the file and line and character that I should take the user to?” It's this really simple protocol. It explicitly doesn't try to model concepts in programming languages. One of the difficult things that other schemes like LSP have tried is to try to model these concepts, to try to not just say, “Oh, where should I take the user, what should I show the user?” To actually say, “Well, what is this construct in a programming language?”
00:20:21
QS:
You get into this difficult task of modeling concepts in C++ like const and is the concept of const in C++ the same as something that's immutable in Scala? If so, do you use the same concept in your kind of language independent modeling schema for that? Do you have two different ones? They've gotten mired in some of the details there. There have been some great efforts here, but it is so much easier, the route that LSP took, which is don't worry about modeling the languages, just worry about what does the user care about, what should I show the user?
00:20:58
QS:
It's this presentational orientation rather than a semantic orientation. That's made LSP successful and easy to use and easy to implement language service for.
00:21:09
SK:
Yeah, well, so from the perspective of implementing a language server, to me, it sounds intuitively kind of like would be a plumbing, like repetitive, almost monotonous tasks for every language is kind of like, the point you get good at and you know the language, you could just whip these servers out or is that kind of misguided and is it like more of a tricky nuanced task than it may seem?
00:21:35
QS:
Well, it totally depends on how well does the language introspect its own source code. Some languages have awesome compiler and type-checking APIs for their own source code. Go is really good for example. Typescript is good. Rust is great. Java has gotten a lot better with a Java C API, but other languages, they don't have any standard library type checking package. Ruby, for example, great language, but you don't even have a notion of type checking in Ruby. There's no official or blessed way of analyzing Ruby code. It's a lot harder in those languages. The way to build a language server is first you start out with being able to answer those questions of what should I show in the hover tooltip, what's the definition? Once you have that, then yes, it's easy to build a language server around that because it's just serving up those answers over some simple JSON RPC protocol.
00:22:35
QS:
If the language offers support for that then it's going to be pretty easy, but even so, it might be easy to do the basics, but then you get into these really interesting challenges around, “Well, what if you have a massive repo?” You have a 40 gigabyte repo and you want to answer a hover, do you want to wait for that entire repo to clone and to build? How do you do this incrementally? How do you do incrementally if you don't have a warm language server process running? When you have things like dependency fetching, then how do you do that? If there's a reference to something that's outside of the repository, then how do you do that? Do you give the file path to user/local/site_modules or you give some kind of abstract, go to definition path, such as, “Well, this definition is in this NPM package at this version tag”?
00:23:25
QS:
That's when you can get into really interesting like naming challenges. They say that there are a couple hard problems in computer science. There's like caching, naming and off-by-one errors. This is really an interesting naming problem when you want to resolve references and definitions across repositories. You can get arbitrarily complex and I would highly recommend if there's someone out there, who just loves a language, to go and build a language server for that. Make it work really well in their editor. You'll learn so much more about the language, about the build system in doing so. I did that for Go, got that kicked off, and some of our other teammates at Sourcegraph, we've done that for some other languages and it's a really rich experience, very fun thing to hack on.
00:24:13
SK:
For my own interest, like Haskell is a language that I like, but I find the development experience to be quite lacking. Is that a language that... I would imagine someone already has...
00:24:26
QS:
Yeah, there's a Haskell language server. I don't know how good it is. I don't know what the state of Haskell's own libraries for analyzing its own code are. Are you familiar?
00:24:39
SK:
No, no idea. Anyways, I see on your website there is one and it has green checks all the way across, so maybe I’ll just spin it up and give it a shot sometime.
00:24:46
QS:
Yeah, totally. When you code Haskell, do you get completion, hovers, go to definition in your editor?
00:24:54
SK:
No, no, I don't. I get like basically syntax highlighting. That's the extent to it. It's miserable.
00:25:01
QS:
Yeah. Well, yeah, we think that should be improved. We think that you getting those things is such a no-brainer and would make you more productive, so let's hope that the Haskell language server does that well and that we can play a part in making that even better.
00:25:17
SK:
If I went to a Haskell project on GitHub right now and I have the Sourcegraph extension installed, it will just work? It'll like give me information?
00:25:27
QS:
Yeah that's it. We support 19 languages. Again, it's based on the quality of the language server, so some of those are going to be really good, some of them not and then, it can also be dependent on the project. If a project has a make file to install dependencies, then the language server probably is not going to be able to figure out how to do that but if it's got nicely formatted requirements.txt or package.json or something like that then it's going to be really smooth.
00:25:54
SK:
Interesting, all right. I'm just going to look at a random Haskell project for one second and see what it looks like on-
00:26:04
QS:
Yeah.
00:26:06
SK:
One sec because now I'm excited. That would be neat.
00:26:12
QS:
Yeah, we got some Haskellers on the team, so they will be excited to listen to this podcast and know that Haskell support was featured.
00:26:23
SK:
All right, so I'm in a Haskell project and I'll go to some complicated place. Ok, can it tell me … I really like the in line git blame, like this line was last changed by this person this many years ago with this commit message. That's really well done. It doesn't seem like in JavaScript, when I like double click on a word and hover it, it'll give me information, but it's not doing that here. Even though in JavaScript I had no types, but here I explicitly list the types, so I guess this language server isn't great probably.
00:27:07
QS:
Yeah, well send the repo... Go post that as an issue and we'll look into that. We'll fix the underlying problem or see what's going on.
00:27:17
SK:
All right, sounds good. Cool, so let's get back on track. That's the in-editor stuff, so as far as the searching goes, I'd be curious to know what sorts of techniques you've used to make that so much better than other solutions? Particularly, I was wondering, you mentioned the distinction between like semantics and then just kind of like regex-y text search stuff, so I was wondering if in searching, which side you take or maybe both?
00:27:51
QS:
Yeah, you see this same idea of there's a really complex, advanced, maybe involving machine learning or probably not blockchain, but you know what I mean. There's that kind of way of solving the problem and then, there's the solve the problem in a really concrete way for developers and that's what we do is search. Our search, it's hybrid search, it'll index some branches and then, otherwise, it'll just go and after you type in a query, literally live, go search over every file and find the matches. That means that you never need to wait for indexing. That means that the query syntax can be really advanced. If we make it even more advanced, then it just works and you don't need to wait for all your code to be re-indexed. We have users in Sourcegraph with 27,000 repos internally. This is a huge benefit.
00:28:39
QS:
Specifically, some of the other search things for code that we've seen, they target use cases that you don't actually do all that often. The global search use case, usually you want to search over your own code. We've seen some other code search applications that do natural language search across code, code searches that ignore punctuation that don't support regexes. In some ways, those are more advanced than Sourcegraph, but Sourcegraph is this simple code search that just works really well. It's directly targeted toward like what do developers need 20 times a day. Yes, there are a lot of people, who are shocked to find that our search doesn't do machine learning under the hood that it doesn't have super advanced ranking or anything like that. It turns out, if you show developers results really quickly and you give them advanced query syntax, then that's what developers want out of search.
00:29:39
SK:
Yeah, okay. It sounds like you use kind of a pretty basic algorithm to just look for every file and run the regex on that file, like on each line or on every file and then, there's nothing clever going on, it's pretty straightforward?
00:29:54
QS:
Then, the clever stuff is in the performance of it. It's not in like building a model of the text or machine learning techniques.
00:30:03
SK:
That's what I'm asking you, how do you make the performance of the search solid?
00:30:07
QS:
Yeah, it's what I would classify as a bunch of systems techniques, it's looking at when you go and fetch the data to go search over, how do you do that most efficiently? You run git archive. You get this archive file back. Well, it turns out if you use a combination of getting a zip file and a tar file, you get best of both worlds. The zip file, of course, given that it has a header, it gives you the index and offset for each file. That gives you random access. The tar file is able to be delivered sooner. You get the first byte of the tar file sooner. By combining those, you can search more quickly by doing some simple optimizations to the go regex package, some of which we have up-streamed. You can just do a regex search faster for this specific use case. Different code paths, we've ever seen a non-ASCII character in the file versus it's all ASCII. Those techniques, which are all in our open source code, you can see that the Sourcegraph/Sourcegraph repo, those things make live search really fast. I would guess that most people who use Sourcegraph code search don't even know that it's searching live and we love to hear that.
00:31:19
SK:
Fascinating, cool. Yeah that makes sense. I like the way you put it, there's no blockchain, virtual reality magic. It's just straight up like optimization techniques to make something simple and good.
00:31:32
QS:
Yeah, at our last board meeting, one of our investors who's former developer himself, pointed out this tweet chain, where someone had asked, “Do we do these techniques?” I said, “No, we don't use machine learning.” He said, “Do we really want to be admitting we're not using machine learning?” Of course, I said, “Well, yes, developers want things that work for them, they don't want these complex techniques.” Of course, he's a great board member. He was just testing me, but we're serious about this. We think that the search that we have now that's like the ideal and maybe, well into the future, we'll see benefits from even more advanced search, but I think for right now, what we have solves the developer problems around code search.
00:32:22
SK:
Yeah, totally. There are a few other features that I saw in their master plan, so I'm not sure if they're live yet. One was the code review impact analysis. Is that working?
00:32:37
QS:
I mean that's in the master plan, it's something that we will do in the future, but let me talk about how we plan to do these things. There are all kinds of other pieces of information you want to see when reviewing code. For example, you want to see, well, this function that was changed, who were the callers, by name, what authors are calling it, who's depending on it, what other projects depend on it, how many other call sites depend on this? You want to see things like that. You might also want to see things like code churn. This line of code has changed a lot recently, so you probably want to give it careful attention when reviewing.
00:33:12
QS:
There are so many things like this that you see instances of in some tools and some other tools don't do it. There's so many things that we couldn't even think of them all. We want to make it, so that if you have some great idea for something that should show up when you're viewing code, you can make it so that shows up everywhere you're viewing code. What we've done is made a Sourcegraph extension API. You can write an extension against the Sourcegraph extension API. It looks a lot like an editor extension and that is going to show up anywhere you look at code. It's going to show up in your code host, in your view tool and in your editor. It's like editor extensions, but everywhere you look at code.
00:33:53
QS:
We have some examples of that. We have one that does code coverage, working with Codecov. That's codecov.io, a great code coverage tool and that shows you when you're looking at code on GitHub, what are all the lines that are tested and what are the lines that aren't tested. Of course that's really useful to know when reviewing code. Other things like that, the way that we're going to get them into the review process is build them as Sourcegraph extensions. It's on this open API. We'll do some more of those, the code review impact one that you saw is an example of one that we will do. This is actually open to anyone else, who wants to write these. You can publish them to sourcegraph.com. Then, anyone else using our browser extension can go and enable them and suddenly, see all that info right on GitHub.
00:34:37
SK:
Got it, okay. It's a browser extension extension.
00:34:45
QS:
The terminology, yes, it's you can write extensions for a browser extension.
00:34:51
SK:
Very, very funny. That's cool. These extensions work in browser extensions that's the only place they work? They don't also work in editors?
00:35:02
QS:
We have a prototype of working editors and, you know, extensions are in alpha. By the time they're in beta, they will work in editors, so that's coming soon.
00:35:11
SK:
Sourcegraph extensions run on a Sourcegraph like non-language server, yeah, where do the extensions run in an editor setting?
00:35:20
QS:
While Sourcegraph extensions are JavaScript bundles. They look a lot like VS Code extensions if you are familiar with that. If you are in your browser, then they're going to run in a web worker, in your browser. If they're in your editor, then they're going to run in some separate node process or however your editor runs extensions. It's all client-side. It doesn't need to hit some server or anything like that.
00:35:46
SK:
Yeah, so in your editor, it would run, like you would spin up a Sourcegraph thing and then the Sourcegraph thing would spin up the Sourcegraph extension?
00:35:54
QS:
Yeah and by like going into these details, it makes it sound more complex than it actually is. From the users’ point of view, they install Sourcegraph for Chrome and then, if they're in a team that's already enabled Codecov, then it just works. Otherwise, they just go to sourcegraph.com and they click "Enable" next to Codecov and then that works.
00:36:12
SK:
Yeah, yeah, I'm with you. The reason I want to get into the details is because I think the question of why would I ever write a Sourcegraph extension instead of like an Atom extension? It almost becomes the opposite, like why would I ever write an Atom extension, if I instead write the Sourcegraph extension, then it's the same thing with the language server.
00:36:34
QS:
Exactly, it's this M times N problem again, where what you want to do is you've got some great idea for something you want to see in your code. You want to just write that in one thing and get that everywhere you look at code. Just the same as we're talking about language servers, you don't want to write like 10 different things to get Rust in every editor. You want to just write one thing and then, tiny little adapter for each editor. Same thing for these Sourcegraph extensions. When you want to see code churn metrics, when you want to see change impact of a PR, you just want to write that once and get that for the editor you use, for the code host you use. By the way, if your team uses three different editors, then you want everyone in your team to be able to use that same thing, so they all get the same info, it's all consistent.
00:37:22
SK:
Interesting. Yeah, it feels kind of like … What was the thing Microsoft came up with, the-
00:37:28
QS:
Language server protocol.
00:37:30
SK:
It sounds like you're coming up with an editor extension protocol.
00:37:33
QS:
Exactly.
00:37:36
SK:
Are you going to call it something like that and make it a thing, like if I decide for some dumb reason, I'm going to make my own brand new text editor to compete with all the others, I could just like implement its extension API to be your API and then, you don't need to install Sourcegraph to then install the extensions. You could just go, you could skip that step?
00:37:53
QS:
Yeah that's exactly it. On the code host side, one thing we're working on is getting code hosts to support Sourcegraph extensions natively, so GitLab, Bitbucket, maybe even GitHub eventually, then you can have a Sourcegraph extension, just use them natively in those. It's kind of like the extension API that you wish your code host had in that way. With editors, it's a lot easier to imagine how we can go and someone can go and submit a PR and get editors to support it natively. With these hosted code host services like GitHub, it obviously takes some more intervention on their side to support this, but in the meantime, to avoid that that's why we have the browser extension, so that you effectively have full Sourcegraph extension support on GitHub. You have this like way richer API to customize GitHub because the sort of your browser extension can arbitrarily change. The GitHub DOM.
00:38:49
SK:
Fascinating, cool. Yeah, well, I think I saw somewhere that about GitLab. I didn't see Bitbucket, but I saw GitLab is working on directly, like integrating in the way you just mentioned. How is that going?
00:39:02
QS:
Yeah, we are talking with GitLab very soon. We're going to submit a merge request to get Sourcegraph distributed as part of GitLab, so that you can get code search from Sourcegraph code intelligence and any of these other Sourcegraph extensions totally natively in GitLab. That's going to be really, really cool for us. One thing that we can do now that we've opened sourced Sourcegraph, which we did just about a week ago. The response has been tremendous. It means a lot more people have found out about Sourcegraph, but it also means we can go and integrate deeply with GitLab. We're really excited about that.
00:39:39
SK:
Will you make any money from this GitLab integration because like if they like implement your protocol, are they cutting you out?
00:39:49
QS:
Well, first, we are doing just fine as a company and to a first approximation.... What we focus on is like what is going to make developers really happy and everything else follows from that. In this case, yes, just as GitLab does, they have the open source and free versions of their product and then, there are reasons why you'd upgrade. For GitLab, there's a variety of reasons. For Sourcegraph, there's a variety of reasons, so we'll ship the core version along with GitLab. Then, if you want the enterprise features, then you'll upgrade to Sourcegraph Enterprise. The other great example of this is with Mattermost, which is a team chat application, a lot like Slack. It's shipped as part of GitLab and a lot of companies first use that application because of GitLab and then, they upgraded to Mattermost Enterprise, so good pattern there. If nothing else, we just want to get more developers inside of companies using Sourcegraph and we know that a lot of those people, it ends up getting to hundreds or thousands of users a day. Then, they need Sourcegraph Enterprise. That's something that it's kind of out of developers’ hands. They don't really have to care about. They just know that they have a product they love.
00:41:02
SK:
Got it. Yeah, well, so part of what I was asking, I think you answered, is will developers even know they're using Sourcegraph or will it be such a tight, like almost white label integration that they won't see it?
00:41:16
QS:
Well, we got to figure out the details, but we want to make it so that it feels native as much as possible, but there are certain concepts that are Sourcegraph specific, where it's probably be most helpful to developers to know that, “Hey, now I'm in the Sourcegraph extensions page on GitLab,” it’d be weird to not use the name Sourcegraph at all. If you look at the browser extension, it actually uses the UI of whatever code host you're using. That's a really important thing. We don't want to be taking developers out of the tools that they use, so we'll find the right mix, but that's on us. That's something we'll be working on over the coming weeks.
00:41:57
SK:
Cool, very exciting. One other thing I saw from the master plan was this global code graph, so maybe you could talk a bit about that.
00:42:08
QS:
Yeah that's something I alluded to where you can build a great language server that works in an editor, but then there are all these other really interesting challenges around cross repository references, so understanding the dependency graph, but also more granular than that. Not just this repo or project depends on this other repo or project, but this function at this version calls into this package and into this specific function. When you have a code graph like that, it unlocks a lot more kinds of questions that you can ask about your code. This PR impact one that we were just talking about is a great example. When you have a change and you change a function, what are all of the other call sites that are affected by this? You need a global code graph to do that because a lot of times, you're going to be changing things that other repos depend on. If you are just doing a naive in editor find references, you're not going to see the 75 other packages inside of your company that are relying on this.
00:43:06
QS:
The global code graph is about taking code analysis, doing it across repositories and there's some pretty powerful stuff that can come there. There's also a lot of statistics that you can show, so helping with the question of what library should I use, is this a healthy library, is this trending well or not? Eventually, we think that this global code graph is going to have enough data, so that it can actually give you advice while coding on how to do certain things. It's seen this pattern of code that you're writing enough times to know that we can autocomplete the next three lines of code, not just the next token or it knows that the 37 other times it saw this pattern, there's a failure in CI. This is about taking advantage of data at larger scale within code, not just the really basic go to definition, find references and hovers. There's a lot more work we need to do here. Hopefully, people get excited about some of those examples I laid out.
00:44:15
SK:
Yeah, well, it sounds like now you're going to take off the gloves and actually do the machine learning, blockchain, virtual reality, you know, to get it to do all those sorts of things.
00:44:25
QS:
Yeah, first blockchain. No, just kidding. A lot of those things, you can imagine how they get better with machine learning, but there's a basic version, which is just show me all the call sites across all thousand repos of my company of this thing and sort them by something really simple, like when were they most recently changed. You can get some really valuable insights from that without getting into complex machine learning. In that case, one reason why it's important to do that without complex machine learning is developers need to know how this list was constructed. They need to know that it's comprehensive. It can't be some best-effort approach if you're using it to do critical things like understand what are the breaking changes for a given diff.
00:45:07
SK:
Yeah that makes a lot of sense. Do you have examples of that so far? Are there other people who have made some really cool extensions that you could talk about?
00:45:17
QS:
Well, we released it like two and a half weeks ago, so not yet.
00:45:21
SK:
Got it. Okay, so Sourcegraph extensions were part of the open source?
00:45:25
QS:
They came right before the open sourcing.
00:45:28
SK:
Got it, so what maybe could you walk us through the … Open sourcing, I imagine, has been on your mind since before you started the company? It's been five years, you just open sourced. Can you walk me through your thinking, how it changed over time and eventually, why you made the decision?
00:45:45
QS:
Yeah, so we open sourced Sourcegraph about a week ago and we have a lot of open source code before that. Our language servers are all open source. We released GraphQL libraries, a lot of other things in open source. The core of Sourcegraph wasn't yet open source and the reason why we ended up open sourcing it was really first principles, we felt that we would be way more likely to use and love Sourcegraph if it were open source. In hindsight, I wish we had done it a lot sooner. What I would recommend to other people, who are building tools for developers, no matter if you think you're going to be selling this tool, go and open-source it and get it in the hands of as many developers as possible.
00:46:29
QS:
That means that you're going to learn more quickly. Everything you do is going to go more quickly. You're going to have more eyeballs, more people looking at your code, more people looking at your product. You never have to worry if someone chooses not to use your product. Do they choose not to because it was closed source or because it was a product? The things that you experience, they're going to become a lot more clearer when you're open source because you take a lot of objections off the table. I wish we had done this a lot sooner. Why didn't we? It never seemed like the top priority at the time, but in hindsight, I know that it would have just made everything a lot better and in the end, it's something that felt right to us as developers. We want Sourcegraph to be used by a lot of developers out there and I don't see a world in which it's used by 50% of all developers unless it's an open source tool.
00:47:23
SK:
Got it. Yeah that makes a lot of sense. From my own thinking on this topic... Because I think everyone who's in this world thinks about it a bit. If you're thinking about starting a company for developers. It seems to me almost like what you did was keep optionality because once you open source something, it's hard to go backwards, but when it's closed source, you can do what you did and open source it once you've figured out the business model a bit more. It almost seems like you kept your options open. You established, “Okay, I know pretty much how this can go if we open source it.” Then, you made a more informed decision later on, so is that accurate or you still encourage new entrepreneurs in developer tools to, “No, no, you don't need to keep options open,” and that way you can just start open source from day one.
00:48:14
QS:
I think you should start from open sourcing day one. Yes, it kept some options open for us, but we just would have learned stuff a little more quickly, would have been able to iterate a little more quickly if it had been an open source. Another concern why people don't open source immediately is because they think that it might affect their ability to have a viable business, to make money. What I would say there is if your ability to make money is entirely dependent on the entirety of your code being closed, then you probably haven't found the right business model anyway. Your business model is not going to be robust enough. It should be robust, so that you can open up a core piece of the code and still have a great business there. Open sourcing forces you to build this robust business instead of something that's relatively flimsy that just hangs on the closed source nature of your code.
00:49:06
SK:
That's quite a claim because I can point to like many, many billion dollar companies that I think, I'm not sure that would be true of, you know?
00:49:18
QS:
Well, you mean-
00:49:20
SK:
So I worked for a company and it was closed source. They are doing very well and they're sales etc., etc. They're like a developer tool-y kind of business. They were always worried about fast followers because it's not like they're impervious to competition, so yeah.
00:49:46
QS:
I don't know the details of that but I suspect that even if they had to open-sourced their code or a core of their code, if they picked the right things to open-source, then they would still have a great business. If a company is a multi-billion dollar business at this point, they're probably some things that they do extremely well that are not entirely encoded in the core open source release they might make.
00:50:09
SK:
Yeah, it's good points. I, being an open source generational person like you, I want to believe that. I think my dad and a lot of like enterprise software people, would just laugh at us as idealists.
00:50:24
QS:
Well, I mean it's that kind of thinking, which was a big reason why we took so long to open source, it's risky. You can always make the point, GitHub is closed source. Clearly, you can be closed source and have a great business. I and the rest of our team, we just fundamentally felt that if something like GitHub were starting now, it would need to be open source, so times change. It's on the founders and creators of these tools to make these really difficult calls to say, “Well, my dad would think I'm crazy, but I'm going to do this anyway because I have a sense of what developers want today and I think it's this way.” That's in the end the call that we had to make. I would love to talk to any other founders, considering this, I'd love to lay out our experience here and I really do believe that you're not going to see developer tools be really successful, either in users or financially, if they're not open source, if they don't have a serious component that's open source.
00:51:27
SK:
Wow, all right, you're sold. I think you mentioned, kind of it seems to me like in conjunction with open source, is this "open company" idea. Is that is a term you came up with or is that you're taking it from somewhere?
00:51:41
QS:
As far as we know, we came up with it, and also "open product". What these terms mean is being open about not just the code, but about what is the product roadmap, how do you decide what gets on the product roadmap? With open company, taking other functions of the company, how you do HR things, sales, marketing, these other things, how you do those? Not any sensitive data, no customer data, no personnel data, but the processes and the principles behind them. GitLab has done a fantastic job of laying this out. They are very public with all these things. They even in their public documents, they state that, “We're going to IPO on this date.”
00:52:22
SK:
Wow.
00:52:24
QS:
When you read that as a developer, you think, “Wow that is a company that I can get excited about, not just because their product is great, but because I really believe in what they're doing.” That's what we want to be doing more of. We've always had our master plan public. That's gotten a lot of developers excited, but we'll be sharing more about our product roadmap, which is now in a public repository on GitHub as markdown files. People can go, comment on it. They can go, look at it. Another side benefit of that is if you are someone thinking of using Sourcegraph, then you know exactly what's going to be coming in the next three to six months. You can also influence it a lot better than if it was an opaque process. I don't know of many other companies that do open product. GitLab does do a great job of open company and we want to be right there with them on that.
00:53:14
SK:
Yeah, wow, very admirable. It reminds me a bit of Buffer. If you're familiar-
00:53:20
QS:
Yeah.
00:53:20
SK:
They release some of their things quite transparently.
00:53:23
QS:
Yeah. Well, Buffer does really interesting things. They're very transparent. They publish salary data and statistics that I think actually might make it difficult to run a business. That might cause some people to decide, “Hey, this company is not for me.” Some people might love working there, but we're not trying to publish that kind of data. We're trying to publish data, information about principles and processes, stuff that is not going to make people worry necessarily, but that just gives more information about like what we value. I would say it is different from Buffer in that way.
00:54:05
SK:
It makes a lot of sense. It feels almost in a way like Ray Dalio recently has been trying to share a lot of the values and principles -- his book is called Principles" -- from Bridgewater.
00:54:16
QS:
Yeah, absolutely.
00:54:22
SK:
We had one a good question from Twitter. You went and asked for questions on Twitter, which was fun. I haven't done that before, but maybe I should. I don't give anyone a heads up on who I'm interviewing next.
00:54:34
QS:
Yeah, you should.
00:54:38
SK:
I feel like it's almost like it would feel like it would be lazy, coming from me, like, “I'm interviewing this person, like tell me what I should ask?” Daniel Shildt, he is @autiomaa on Twitter. He asks, “How do we get a zoomed out view of a codebase, visualizing the structure of like a larger macro system and yet tie that down to the implementation details of lines of code? Do you see any value in 3D visualizations for this?”
00:55:14
QS:
Yeah, visualizing code is a really interesting idea. The way that we see it is people's minds work in different ways. People want different kinds of visualizations. There's no one visualization that would jive with the minds of 90% of devs. We need to make it easy for developers to build their own kinds of visualizations. Some people might like a visualization that shows them all the functions and shows them edges between the functions, based on the call graph. Some people would like to see, “Well, I'd like the nodes to be the modules.” There's no one size fits all. So what we want to do is we want to make it, so that these 20 different types of visualizations, you can build all of them. You can pick and choose and whichever one you want, you can see it in your editor and in your reviews and on your code host. We don't think that we can build the one visualization to rule them all. We are focused on what are the things that every developer does, code search, go to definition, these basic human rights for developers and then, building a platform for other people with these more specific ideas to roll them out to a lot of other developers. That in the end is going to make better visualizations than we could possibly come up with on our own, so that's our answer there.
00:56:34
QS:
I would love to have Daniel or other people out there that want to build these visualizations, go, build a Sourcegraph extension. I've actually been working on one in keeping with our open product idea that it's not so much a code visualization, but it takes all these markdown files that describe our product roadmap and shows them in a little chart that shows a Gantt chart of, “Here the project’s going on, here's the status of them.” That's one little Sourcegraph extension that visualizes essentially markdown files. As we see more of those, we'll post those. They make for awesome screenshots, so look out for those.
00:57:11
SK:
Very cool and these would be, people can make these sorts of things in Sourcegraph extensions?
00:57:16
QS:
Yeah.
00:57:18
SK:
Cool. I think we were connected originally by Aidan Cunniffe, who I had in the podcast almost a year ago I think. Did you guys meet at YC?
00:57:32
QS:
I met when someone said, “What Aidan is building is really cool.” I emailed him and we met up.
00:57:39
SK:
Cool, go it. Did you do YC at all?
00:57:41
QS:
No.
00:57:43
SK:
Okay, there is obviously very, very big differences between what you and Aidan are building from like a product perspective, you solve very different problems, but it seems like there are some similarities. Do you see any similarities or places for collaboration?
00:58:02
QS:
I think that similarities are awesome. They are when a developer's coding, show them information or actions that help them do things more quickly and kind of like I was talking about with code visualizations, we don't think that Sourcegraph is going to be the ones with the best ideas around visualizations. With what Aidan is building an Optic, we don't think that Sourcegraph should ever be the one to understand the structure of your express app and the API that it exposes and gives you actions to do changes, refactors based on that. That's a little too specific for what we're doing. It's extremely valuable, but we don't want to be doing that. We want to make the platform for people to do that, so that someone like Aidan with his awesome idea can just focus on implementing that awesome idea to understand the structure of your app and offer refactorings and make it, so that then that works in every editor and in every code host. Another great example is a company like CodeStream that does code discussions. Right now, they have to build these things per editor. When they get on a code host, they're going to have to build the CodeStream support for each code host, but with Sourcegraph extensions, with us being integrated in all these code hosts, we'll give them a really nice platform to build out on.
00:59:18
QS:
People like Aidan, people like CodeStream, we want to make it way easier for them to do that and we don't want to go build what they're building. That's another reason why this open product idea is important. We want to build a platform for developers and so, we got to be super transparent about what are we doing and what can other companies do and know that we're going to be an awesome platform for them to reach people. We're not going to go and compete with them. That's something that platforms need to do well and we will do that.
00:59:48
SK:
Yeah, it took me a little while, but now I'm really starting to get the way you nip this like M times N problem by like inserting yourself as a platform. I guess you guys worry about the integrations to every editor and online code hosting platform in existence. Then, just anyone else can write a single extension and have it just scale to all those things seamlessly.
01:00:13
QS:
Yeah.
01:00:15
SK:
Very, very cool, got it. That makes a lot of sense. I was curious, I know you mentioned that you're not as open as Buffer is, but I'd be curious if there's any metrics or qualitative data you wanted to share about like how the company itself is going so far, like number of customers or size or anything you want to share to give us a sense of what's going on with the company, I'd be curious to hear.
01:00:40
QS:
Yeah, we have bunch of awesome logos on our homepage and just so that they don't get stale because we'll probably get some great new ones on, go check out our homepage. I'll talk though about how we measure metrics internally with our customers. We think Sourcegraph should be used by 90% of developers at their company every single day. That's a pretty lofty target to get to, so we have a little report card, where we say, “For these customers that are using Sourcegraph, what percentage of developers used us on any given day?” These are customers that have opted into sharing this information with us and it's pretty cool to see there are companies whose products I use every day, who have 500 developers or 2,000 developers or whatever using our product on any given day. Those are the kind of numbers that we see and you can extrapolate from there. If we have that many users inside of a company, then we're doing pretty well. Yeah, we're good and I think it's cool because we are an open source company. We are a company for developers and we have shown, I think, we've disproven in a lot of ways that you can't sell to developers. There are some other companies that recently have shown that really well. Obviously, GitHub’s very high valued acquisition by Microsoft, GitLab, JFrog, HashiCorp, and we'd love to be one of those other companies that these dev tools founders look to and say, “Sourcegraph did it, these other companies did it, so I can do it too.”
01:02:15
SK:
Wow, very inspiring. Do you see your future as being acquired by GitHub, Microsoft, one those or IPO one day or it's too early to tell or whatever?
01:02:26
QS:
Well, Sourcegraph is the most used tool and a lot of our customers and that's a really powerful position to be in that we're a product that developers use more than the other tools, the code hosts, these other paid commercial dev tools they use. We're not looking to be acquired by tools that are used less frequently than Sourcegraph...
01:02:52
SK:
Yup, got it. That’s well said. It sounds like you guys have raised money. You have a board. It's like Series A, Series B, where are you at in that stage of things?
01:03:06
QS:
Yeah, we're Series A. We announced some stuff a little over a year ago. We have an awesome board. I sometimes don't know if people believe this, but when we have board meetings, it's about winning the hearts and minds of developers and it's really cool to see that because before I was CEO of a dev tools company, I obviously had reason to be cynical, like just how much do these startups care about actually making a great product and how much they care about monetizing or being acquired? From my limited data point, as obviously CEO and co-founder of Sourcegraph and investor in a few other dev tools companies, I will say that the venture capitalists in San Francisco, at least the ones that I'm familiar with, they understand that it's about building a great product for developers and it's about winning the hearts and minds. If there are any listeners out there that are cynical about those things, then I would just strongly recommend, be charitable and go and understand that these investors know that the best way to get to a really big company is to make a lot of developers happy.
01:04:19
SK:
Let's do one better, can you give us the names of your investors that you'd want to share as being good for developer tools founders?
01:04:27
QS:
Yeah, absolutely, so ones we work with Scott Raney at Redpoint. He's fantastic. He was early on the board at Heroku, Stripe, Twilio, bunch of other great companies. Then, Goldcrest, Adam Ross, Dan Friedland, they were early in a bunch of the SpaceX, Tesla, Facebook type companies. Their thesis is founder market fit. They saw that Beyang, my co-founder and I were crazy about developers and that we understood them. They're fantastic and then, just a bunch of other great advisors, people who are engineering managers at startups at Google, YouTube, companies like that. Those are the kinds of people that we really get a lot of great advice from.
01:05:14
SK:
Now talking directly to someone who is trying to start a company in this space and raise money, how would someone get ahold of those sorts of people, wouldy you have advice on that?
01:05:24
QS:
Well, I think two ways, people always say, “Get the warm intro,” and if you can impress anyone else, who's had a reasonably successful startup with your product, then you can probably get a warm intro to that company's investors. The second thing I'd say is think of the investor’s job, their job is literally to find the crazy good ideas before anyone else can. If you can show a crazy, awesome product that's got people saying great things about it on Twitter or elsewhere, then it's kind of the investor’s job to see those signs, to pattern match. You don't necessarily need a warm intro. You just need a lot of users that love your product. Don't feel like you need to do all these things in order to get into the email inbox of these investors. The ones that ignore you when you have a great product, well, they're literally failing at their jobs, so you should feel pretty secure in the knowledge that if you have a great product and they're not responding to you, then you're the one who's winning, they're not, and it will come back and bite them eventually.
01:06:26
SK:
Well that I imagine is a reasonably easy thing to do mentally, but when you're in that position, you have a good product, the metrics are looking good. What about the more, I would say common case or mentally, it seems common to me, of like you kind of a basically nothing, a prototype or an idea or a slide deck, you're just getting started, how would you get ahold of investors or maybe you would say, “Don't yet, like work on your product first.”
01:06:57
QS:
Yeah, well, certainly work on the product first until you can get people excited about it. Hopefully, those people are not just total randos on the internet, but they're people that have built a dev tool or who can bring that inside of a company, who can be future customers. If you can get potential customers excited about your product, then you solve the problem way harder than getting investors excited about your product. You can take a handful of customers that are excited about your product, even before they've paid a lot of money and you can get on the radar screens of investors. If there's anyone who is even worried about getting there, then go find some founder or someone at a dev tool startup that you respect and email them, asking for advice. The community is just amazing. I guarantee you they'll reply. I will reply if you email me and if you have some of the data points that's enough for me to want to help you out and for me to want to invest. Then, these things build on it. Then, I can put you in touch with these other people. You email, I can put you in touch with investors, so just focus on getting a few of these data points of people that can eventually pay for your product and getting them excited. That's all that matters.
01:08:13
QS:
At that point, once you have that it's literally investor’s jobs to know that what you have built is on the track to be successful.
01:08:23
SK:
Yeah, you make it sound quite simple.
01:08:25
QS:
Well, the hard part as I said is getting potential customers excited about that. Once you've done that then the rest is relatively simple, but I can understand how it seems daunting to people that have not done this before, that are not in Silicon Valley or things like that. I really just want to reiterate that if you can get potential customers excited about your product, then you've done the way harder thing than anything else.
01:08:51
SK:
Cool, yeah. That's a good message. You mentioned that you are an investor in other dev tools companies, so I'd be curious to hear the names and stories or whatever of other companies you invested in or that you just know about it or excited about?
01:09:05
QS:
Yeah, well, let me talk about the ones that I'm just excited about in general because the ones I've invested in for the most part haven't announced these things publicly and I don't want to leave some out. One thing I'm really interested in is these online editors and cloud IDEs. Is every developer going to switch to using cloud IDE tomorrow? Probably not, but there's a certain subset of the operations that developers do that I think could be done on a cloud. When you're doing a PR and you want to make a quick change, well you'd like a cloud IDE and you'd like that to have all the code intelligence you'd get in your normal editor because it sucks if you see a change you want to make. You go do it in the GitHub editor and you don't know if it compiles, if you have the right tab indentation, so cloud IDEs, I think, will start to chip away at some of these use cases.
01:09:57
QS:
Some of the interesting ones that I've seen are, there's obviously coder.com, there's gitpod.io, there's Glitch, repl.it. These all are targeting different use cases. Some are the professional developers, some are product managers, some are QA people, some are students. I don't know what is going to be the most successful approach there, but I'm really excited to follow it. Of all of those, Glitch is the one that's the most out there, totally new workflow. Coder. com is the one that I think has done the best job of taking VS code and putting it on the web and making it so, you can even use a lot of the extensions that VS code has right on the web. They've done some pretty amazing things in the backend to make that work. That's one area that I'm definitely interested in. Do you use any cloud IDE Steve?
01:10:52
SK:
Yeah, well, now, I feel like I have to thank you because I use Cloud9, which has been bought and kind of, it feels like, left to languish a bit. I love it and I have a Chromebook, so I need to use cloud IDE. I like it a lot that, the whole cloud IDE, Chromebook lifestyle, so I'm excited to try out this coder.com that I've never heard of. What was the other one, codepod?
01:11:17
QS:
Gitpod.io from TypeFox.
01:11:19
SK:
It's a cool URL, let's see. I'm curious what this is like. Oh interesting, okay, so got it, cool. Gitpod is more like a code review.
01:11:38
QS:
They have a really good code review integration, yeah. They're not actually built on VS Code proper. They built a kind of subset of VS Code, called Theia that they're built on. It looks a lot like VS code, but it's stripped down to run a little more quickly in the browser.
01:11:57
SK:
Got it. That looks cool too. I'm excited to give both a try. I totally agree with everything you said. The sentiment of you want to review a pull request or make a small change and also, we both are Chromebook people, so we're all about doing things in the browser. It's related to your M times N problem, let's just stop it with these native platforms. Let's just pick a platform that works on every device and then we'll just all compile to that platform.
01:12:29
QS:
Yeah. Well that's the Holy Grail. I don't know how long it's going to take for us to get there, but I think we're moving in that direction.
01:12:37
SK:
Yeah. Well, I really appreciate all the work you're doing to kind of like fill in all the groundwork to, like kind of virtualize this platform for IDEs.
01:12:47
QS:
Yeah, well, we've done a little bit of the work and you can look at langserver.org to see all the work being done per language. It's really cool to see all these language communities. It's hard to get language communities to agree on basically anything. That's one of the religious wars in programming, but they agree that LSP is the way forward.
01:13:09
SK:
Cool. Yeah that makes sense. Just in a wrap up, I want to get some places on the web that you want people to reach out to you, like your website, your email address, Twitter, the places on the web that people should know about you from, if you have those.
01:13:28
QS:
Yeah, I'm @sqs on Twitter, sqs@sourcegraph.com, those are my initials. Some people think that it's actually Amazon Simple Queue Service, but that's a lot younger than I am. I was sqs before that. Sourcegraph.com is where Sourcegraph is. You can try it out on any public repo, spin it up inside your company to get it to work on private code, it's nice and secure that way. If you're a user, if you got a great idea for a dev tool, if you have a feature request, if you want to start a company that's building things for developers, I'd love to hear from you. Reach out and we'll help in any way that we can. I personally certainly will too.
01:14:10
SK:
Great, thanks so much. That's a very generous offer. Are there things that you're looking for that you want to ask the community for? Are you hiring? I don't know, any sort of thing that you want collaboration on...
01:14:27
QS:
Yeah, if you want to build a language server or one of these source code extensions, we'd love to help. If you'd love to quit your job or on the side, write one of these, then we'd love to sponsor you. Let us know, if you're crazy about a certain language and you want to improve tooling for that language, we would love to help make that possible for you.
01:14:47
SK:
Oh wow, so it sounds like you're saying in the sense that you'd hire them or different, this is like a sponsorship now?
01:14:54
QS:
Hire them or if someone wants to do this on the side, then happy to do some kind of contracting arrangement.
01:15:03
SK:
Oh fascinating, so that sounds like a very cool open offer that like if anyone wants to make a language server for any language and they do a good job, you’d pay them like almost hourly to do this work that without you would be just free open-source work?
01:15:20
QS:
Yeah, absolutely. All that work would be open source, so it would go back and benefit the whole community.
01:15:28
SK:
Wow that's crazy. Do you have that up on the internet in various places? I didn't catch that.
01:15:32
QS:
We do, we put it on Twitter, put it on Hacker News. We probably should put it on our main website.
01:15:41
SK:
Yeah that's such a neat offer. I can’t think of any offer similar, like comparable to that, like if you want to do open-source work on this thing, we'll just like pay for it, like that's so cool.
01:15:55
QS:
Yeah. Well, I mean hearing this reaction, we probably should make it more prominent, so by the time this podcast goes live, it's probably going to be up on our site.
01:16:04
SK:
Cool. Yeah, yeah anyways, at least that's my reaction, so I guess you'll see if other people have a similar like shocks, like I'm pinching myself, this is a dream? Oh cool, well, anyways, thanks so much for your time. This was wonderful.
01:16:18
QS:
Yeah, thank you, all right, take care.
01:16:21
SK:
Bye.