Future of Coding - Basic Developer Human Rights: Quinn Slack

Episode Date: October 24, 2018

Quinn Slack of Sourcegraph believes in low-hanging fruit. Before we improve programming in all the fancy ways, he has a list of all the little improvements and features we need to make available to all developers, such as jump-to-definition, autocomplete, and automatic formatting. In this conversation, we learn about the technical challenges to brining code intelligence to all editors, and Sourcegraph's chosen solutions, such as the Langauge Server Protocol and the Sourcegraph extension API. 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." Notes and transcript at futureofcoding.org/episodes/32Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Welcome to the Future of Coding. This is Steve Krause. Today we have Quinn Slack on the podcast. He is the co-founder of Sourcegraph, which is a company that has a code search product and allows you to search through your own code and all the versions of your code across all of your repositories and all of your dependencies. A really cool product that I hadn't heard of,

but now I'm pretty excited about, and I haven't got the chance to play with it too much on my own projects, but I'm considering giving it a go. I have played with their browser extension, which allows you to see various intelligence information, go to definition, the type of functions, the git blame information, and that was really, really impressive. So, we were connected actually through Aiden, who was also on this podcast

maybe about a year ago now, and yeah, I'm really glad we got a chance to have this conversation because Sourcegraph is one of those rare open source, they recently open sourced, it's a rare open source profitable developer tools company. So I'm excited to share this success story with all of you. He gives a lot of really cool tips for how to follow in his footsteps and he even offers to give advice personally if you email him or tweet at him. I forget which, but he mentions in the conversation. So now a brief message from our sponsor, Replit, which is spelled R-E-P-L dot I-T.

It is an online REPL for over 30 languages. It started out as a code playground, but now 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 are looking for hackers interested in the future of coding and making software tools more accessible and enjoyable. So email jobs at REPLIT if you are interested in learning more. And just a quick reminder that along with the sponsorship, Repl.it is sponsoring the transcripts of these episodes. So if you prefer to read them, listen. I guess you wouldn't be hearing these words anyways.

But in case you were trying to slog through the audio. Now you don't have to. You can find the audio for this episode at futureofcoding.org slash episodes slash 32 hashtag transcript. All righty, without any further ado, I bring you Quinn Slack. So I am here now with Quinn Slack. Welcome, Quinn. Thank you. Excited to be on. Yeah, really excited to have you. So if I'm not mistaken, you said you're now in Germany?

Yes, I'm in Germany in Berlin. And 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. Yeah, yeah, yeah. I am familiar with Prisma. That is awesome that they have a sound perfume. I do not. And I recently moved to London and there is construction nearby. So hopefully that won't interfere too much. Okay, so what can 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. Got it. That makes a lot of sense. So you mentioned you have a teammate there. So you

have a semi-remote team, it sounds like? Yeah, we're about one third remote. We want the best people, the best developers, no matter where they are in the world. And it turns out they're not all in San Francisco. So we have a teammate in Germany, teammate in Phoenix, teammate in South Africa, and looking to grow a lot more there. 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? Yeah, that's when we really started Sourcegraph as a project because we wanted it. We wanted a better code search.

And now it's grown into a business and company and we're really just getting started. 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? Yeah, let me start back early on. I'm a coder. I've always loved coding. And back when I was much younger, I would write code for other companies. And they'd send me checks through the mail, companies all around the world. And as someone who was, you know, this was middle school, it was just amazing that I

could write code anywhere in the world and help out these companies. And so I saw that, wow, writing code is this amazing opportunity. Then fast forward a little bit, met my co-founder, Byung. 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 can possibly be just constantly reinventing the wheel. At the same time, we also got to work inside of some big companies, Bank of America, JP Morgan, and 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, you know, who's already written this? Does this exist? How do I use this? So those two experiences, plus, you know,

Byung and I, we're hackers. We love coding and we love seeing how can we save time while coding? Who's using the same libraries that we're using? So these three things came together and we said, you know, wow, like this is, Sourcegraph is something that makes the world more like what we want it to be, where any developer can be extremely productive. 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. So 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 source graph. And it's where you say, how do I do this? How do I call this? How is this implemented? And so step one is build a better code search for developers. I think we're well on the 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. And 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. So obviously a grand vision, but we're totally focused right now on building

the best code search tool for devs. And code search is this interesting kind of tool. What we've seen is maybe 20% of developers, they just instantly click with code search. So Steve, do you use code search regularly? Like just on GitHub? Or any code search? Well, yeah, of course. You have to be constantly searching for things throughout your project. Is there another way to do it without that? Well, how often would you say you use code search like um so like in my developer i hit like control like just control f or control shift f to like search my whole project yeah um 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 yeah what about searching across projects other than the one that's currently in your editor?

Other projects that I've written? I'm not sure what you mean. 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 in 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? Oh yeah, all the time. Okay. And so, you know, it 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, who, you know, they might search inside their editor, but they're not benefiting from code search. So we see this just crazy opportunity where 20% of devs, they code search all the time. And, you know, they, most of them, they'll have a code search tool at their company. Some people will use GitHub, but you know, 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? And so 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. And 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. And then the next week they do a few code searches, and then it grows from there. And they brought this entirely new tool into their workflow that's on par with everyone remembers back before GitHub. And then you brought GitHub in your workflow, and that was such a big improvement. We're doing that with code search. And I mean, 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. And so we're bringing that to every other company in the world. So 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. And, you know, from our point of view,

it's awesome that we can be a new product in their toolkit, but, you know, it's not that great if you're a totally new thing. So 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. So, you know, usually what will happen is you start using that. You say, wow, I love that. It 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, you know, we'll have hundreds of users per day inside of a company by the time they, you know, reach out to us and ask any kind of question. So 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. Wow. Quite a story. So I just want to 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 nuanced. So on GitHub, there's a way you can search code.

You just type in a snippet of code, it searches all the projects. And I've used that before, and it's crappy, so I basically never use it. And so is that the sort of code searching that you guys have, just better? Well, I don't want to call it crappy. I would say the use cases you'd use that for very different from what you'd use source graph for. Um, and a lot of people, that's what they think of as code search. So, uh, you know, you might use GitHub's code search, which is totally global, like a couple of times a week, a few times a week, but source graph code

search, it searches over the code that you're actually working with, the code that's in your company's projects, you know, your dependencies. So 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. So, you know, if you have been using GitHub code search a few times a week, you'd probably be someone who uses source graph code search like 30 times a week or more. Got it. Got it. Got it.

And it searches every revision, every commit. Searches any commit. You can, you know, 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, uh, you see exceptions in your logs and 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 get diffs of commits that are related to access tokens? So, yeah, it does all these things, things that you might not have even thought of code search could do.

Fascinating. That's very cool and so that's the main product and then the um intelligent ide features is more of the like uh intro so uh the way you get people in the door yeah got it yeah and the way they're connected is as a developer you have these questions you need answered how do i do this thing in code you know Got it. Cool. this. Sometimes you need to see history or blame, and 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. Got it. That makes a lot of sense. And so people will add that sort of information into whatever editor they use, or they have Sourcegraph open in another window? They have Sourcegraph open in another window. 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.

And people have all kinds of different shortcuts set up to launch Sourcegraph. 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 one Bennett's master plan that I had access to. And I see that I think over email, you mentioned that you're, you also know him from school.

Yeah. I had the pleasure of getting to work with him in undergrad, worked in a lab together, and 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. So 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. 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, but I guess that's always how it happens. You always, if you're not embarrassed of your old self, then I need to work on version two. But I guess that's always how it happens. If you're not embarrassed of your old self, then you're not learning, I guess.

Exactly. It's a good way to track progress, too. Yeah. So just going through your master plan, I saw that you have phase one. And it reads to me almost like a declaration of developer rights or like developer human rights like like we believe like developers are entitled to these features in every editor that they use um and then you like list a bunch of things i don't have the list off the top of my head but it's it's like uh jump to definition and like i guess like seeing the type

of functions those sorts of things is is that how you see it? Like putting a stake in the ground and saying, this is the way, this is like the bare minimum. Yeah, absolutely. You know, 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've go to definition, find references, hover tool tips. Like, you know, 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. And yeah, we don't have it.

So any company like us, anyone building a product like this, first focus on the basics, the obvious things that every developer should have. And it turns out there's 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. So that's one of the things that we're focused on now. We'd love to talk more about how we're doing that. Yeah, yeah. Well, so one of the technical challenges that i thought you put uh interesting you put well on your master plan was how it seemed it it was an m 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 but you reframe the problem so now it's an M plus N problem. Yeah. I mean, walking through that and other technical, you know, challenges and solutions you're working through. 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, you know, Rust, TypeScript, JavaScript, Rust, Scala, if you want to get full language coverage for each of those combinations,

that's a lot of things to write. You got to write the Rust Vim plugin. You got to write the Atom Go plugin. And think of a matrix. You have M editors and N languages. It's a lot of cells to fill in. So it turns out developers have done a decent of cells to fill in. So, you know, it turns out developers have done a decent job of filling those in. But if, you know, there's a lot of wasted effort. Think of how much duplicative effort has gone into writing Rust support for Vim and then writing Rust support for Go. And 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. And so they've collapsed the problem into, you know, do a little bit of work for each editor and then the hard work for analyzing Rust code, that's all done. And so, you know, 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. But 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. And 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. So why shouldn't you get code intelligence when looking at code on GitHub, when reviewing

PRs on GitHub, you know, or GitLab or any other code host you might use. So it's all the more important that you have one thing that understands the language really well and that any tool can interface with. So Microsoft invented language server protocol, LSP, a couple of years ago, and 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. And those have shipped as part of Atom and VS Code. Some other companies have built some great language servers. And this is really the first effort of its type in static analysis. It's really gotten traction.

It's 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. And 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. So 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. And now it's finally within reach. And I think that we've made a pretty big impact in getting the world there. All that work is in open source too. And there are just hundreds or thousands of contributors to these language servers. It's a really cool effort. Wow. Yeah. You must be so proud. 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. Got it. So just a very, very specific implementation detail question. So when I install the source graph Chrome extension, and then I go to a public project and then I can open it in source graph, the language server is running on your servers and that's how it's happening. Yeah. The language server is running on your servers. And that's how it's happening. Yeah. But let's talk about the editor case. Language servers 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. And 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? And 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? But to actually say, well, what is this construct in a programming language? And you get into this difficult task of modeling concepts in C++ like const. And is the concept of const in C++ the same as, you know, something that's immutable in Scala? If so, you know, do you use the same concept in your kind of language independent modeling schema for that? Do you

have two different ones? And 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? It's this presentational orientation rather than a semantic orientation that's made LSP successful and easy to use and easy to implement language servers for?

Yeah, well, so from the perspective of implementing a language server, is it kind of, to me, it sounds intuitively kind of like it would be a plumbing, like repetitive, almost monotonous task for every language. It's kind of like, once you get good at it, you can, and you know the language,

you could just whip these servers out or is that kind of mis once you get good at it, and you know the language, you could just whip these servers out? Or is that kind of misguided? Is it like more of a tricky, nuanced task than it may seem? 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 the 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. And so 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?

And 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. So if the language does it, 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 it 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 do you give some kind of abstract go to definition paths such as, well, this definition is in this NPM package at this version tag. And so that's when, you know, you can get into really interesting, like naming challenges. You know, they say that there are a couple of hard problems in computer science. There's like caching naming and off by one errors. And this is really an interesting

naming problem when you want to resolve references and definitions across repositories. So 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 and 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. 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 someone's already, I would imagine someone already has?

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? No, no idea. So anyways, I see on your website, there is one and it has green checks all the way across. So maybe I'll have to spin it up and give it a shot sometime. Yeah, totally. When you code Haskell, do you get completion, hovers, go to definition in your editor? No, no, I don't. I get like, like basically syntax highlighting. That's, that's the extent of it. It's miserable. 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. So if I went to a Haskell project on GitHub right now and I have the source graph extension installed, it'll just work? It'll give me information? Yeah, that's it. We support 19 languages. And 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 at txt or package.json or something like that, then it's going to be really smooth.

Interesting. All right. I just want to look at a random Haskell project for one second and see if what it looks like. Because now I'm excited. That would be neat. 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. All right.

So I'm in a Haskell project, and I'll go to some complicated place. Can it tell me? I really like the inline git blame. Like this line was last changed by this person this many years ago with this commit message. That's really well done. Yeah. this commit message. That's really well done. Yeah, it doesn't seem like in JavaScript,

when I 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. 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. All right. Sounds good. Cool.

So let's get back on track. So 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. And particularly, I was wondering, you mentioned the distinction between like semantics and then just kind of like re XE tech search stuff. So I was wondering if in searching you, which side of it you take, or maybe both. Yeah. You know, you see this same idea of there's a really complex advanced, you know, maybe involving machine learning or probably not blockchain, but you know what I mean? There's that kind of way of solving a problem. And then there's the solve the problem in a really concrete way for developers. And that's what we do with search. So 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. And 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 of Sourcegraph with 27,000 repos internally. And so this is a huge benefit. 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. And in some ways those are more advanced than Sourcegraph, but Sourcegraph is this simple code search that just works really well. And, you know, it's directly targeted toward like what do developers need 20 times a day? So yes, there are a lot of people who are shocked to find that our search doesn't do, you know, machine learning under the hood, that it doesn't have super advanced ranking or anything like that. But 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. Yeah. Okay. And so it sounds like you use kind of a pretty basic algorithm to just look through every file and run the regex on that file

like on each line or on every file and then you know is it there's nothing clever going on it's pretty straightforward and then the clever stuff is in the performance of it so it's not in like you know building a model of the text or machine learning technique that's what i'm asking how do you get to the search solid yeah it's what I would classify as a bunch of systems techniques. It's looking at when you go and fetch the Git data to go search over, how do you do that most efficiently? So 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. So by combining those, you can search more quickly by doing some simple optimizations to the go regex package,

some of which we have upstreamed. You can just do a regex search faster for this specific use case. Different code paths for if 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 source graph slash source graph 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. Fascinating. Cool. Yeah, that makes sense. There's no, I like the way you put it. There's no black blockchain virtual reality magic. It's just straight up, you know, like optimization techniques to make something simple and good.

Yeah. You know, at our last board meeting, one of our investors who's, you know, former developer himself pointed out this tweet chain where someone had asked, you know, do we do these techniques? And I said, no, we don't use machine learning. And he said, do we really want to be admitting we're not using machine learning? And 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 the ideal.

And maybe well into the future, we'll see benefits from even more advanced search. But I'm not sure if they're live yet. One was the code review impact analysis. Is that working? So, I mean, that's in the master plan is something that we will do in the future. But let me talk about how we plan to do these things. So there are all kinds of other pieces of information you want to see when reviewing code. For example, you want to see, well, you know, this function that was changed, who are the callers

by name, you know, 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. There's so many things like this that, you know, you see instances of and some tools and some other tools don't do it. And there's so many things that we couldn't even think of them all. So we want to make it so that if you have some great idea for something that should show up when reviewing code, that you can make it so that shows up everywhere you're reviewing code. So 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 review tool, and in your editor. So it's like editor extensions, but everywhere you look at code. It's going to show up in your code host, in your review tool, and in your editor. So it's like editor extensions, but everywhere you look at code. So 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. And 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. And this is actually open to anyone else who wants to write these. You can publish them to sourcegraph.com and then anyone else using our browser extension can go and enable them and suddenly see all that info right on GitHub. Got it. Okay, so it's turning the browser, it's a browser extension extension. The terminology, yes.

You can write extensions for a browser extension. Very, very funny. That's cool. And these extensions work in browser extensions. That's the only place they work. They don't also work in editors. We have a prototype of it working in editors. And the source graph extensions are in alpha. By the time they're in beta, then they will work in editors. So that's coming soon. So source graph extensions run on a source graph, like non-language server. Yeah. Where do the extensions run in an editor setting? They are, well, source graph extensions are JavaScript bundles. You know, they look a lot like VS code extensions that people are familiar with that. And so 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, you know, in some separate node process or however your editor runs extensions. So it's all client side. It doesn't need to hit some server or anything like that. So, 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. Yeah. And, you know, by like going into these details, it makes it sound more complex than it actually is. From the user's point of view, they install Sourcegraph for Chrome.

And then, you know, if they're in a team that's already enabled CodeCub, then it just works. Otherwise they just go to Sourcegraph.com and they click, you know, enable next to CodeCub and then that works. 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 a Atom extension? It almost comes the opposite like why would i ever write an atom extension if i instead write a source graph extension then it's the same thing with the language server 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 were 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. And same thing for these source graph 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. And by the way, if your team uses three different editors, then you want everyone on your team to be able to use that same thing so they all get the same info. It's all consistent.

Yeah, it feels kind of like, so what was the thing Microsoft came up with? Language server protocol. It sounds like you're coming up with a editor extension protocol. Exactly. Are you going to call it something like that and make it a thing? If I decide for some dumb reason that I'm going to make my own brand new text editor to compete with all the others, I could just implement its extension API to be your API, and then you don't need to install Sourcegraph to then install the extensions. It 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. It could just go, it could skip that step. Yeah, that's exactly it. So, you know, on the code host side, one thing we're working on is getting code hosts to support Sourcegraph extensions natively. So GitLab, you know, Bitbucket, maybe even GitHub eventually,

then you can have a source code extension and 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. And you have this

way richer API to customize GitHub, because the Sourcegraph browser extension can arbitrarily change the GitHub DOM. Fascinating. Cool. Yeah, well, I think I saw somewhere that GitLab, I didn't see Bitbucket, but I saw GitLab is working on directly integrating in the way you just mentioned. So how's that going?

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. It's one thing that we can do now that we've open sourced Sourcegraph, which we did just about a week ago. And 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. So will you make any money from this GitLab integration? Because if they implement your protocol, are they cutting you out? Well, first, we are doing just fine as a company. And to a first approximation, what we focus on is what is going to make developers really happy. And everything else follows from that. But 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. You know, for GitLab, there's a variety of reasons.

For Sourcegraph, there's a variety of reasons. So, you know, we'll ship the core version along with GitLab. And then if you want the enterprise features, then, you know, 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 used that application because of GitLab, and then they upgraded to Mattermost Enterprise. So good pattern there. And 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, and then they need Sourcegraph Enterprise. But that's something that, you answered, is will developers even know they're using

Sourcegraph or will it be such a tight, like almost white-labeled integration that they won't see it? Well, you know, 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, you know, that are Sourcegraph specific where it's probably going to be most helpful to developers to know that, you know, hey, now I'm in the Sourcegraph extensions page on GitLab. You know, it'd be weird to not use the name Sourcegraph at all. So 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, you know,

taking developers out of the tools that they use. So we'll find the right mix, but, you know, that's on us. That's something we'll be working on over the coming weeks. 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.

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. And 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. And 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. So 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? And 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 auto-complete the next three lines of code, not just the next token. Or it knows that, you know, the 37 other times it saw this pattern, there was a failure in CI.

So this is about taking advantage of data at larger scale within code, not just, you know, the really basic go-to-definition, find references and hovers. So, you know, there's a lot more work we need to do here, but there's, I think, hopefully people get excited about some of those examples I laid out. Yeah. Well, it sounds like now you're going to need to take off the gloves and actually do the machine learning, blockchain, virtual reality, you know, to get it, you know, to do all those sorts of things. Yeah. First blockchain. No, just kidding. You know, 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, you know,

a thousand repos in my company of this thing and sort them by something really simple. Like, you know, when were they most recently changed? And you can get some really valuable insights from that without getting into complex machine learning. And, you know, 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, you know, what are the breaking changes for a given diff. Yeah, that makes a lot of sense. Do you have examples of that so far? Are there people who have made some really cool extensions that you could talk about?

Well, we released it like two and a half weeks ago, so not yet. Okay. So source graph extensions were part of the open source? They came right before the open sourcing. Got it. Got it. Got it. So maybe could you walk us through the decision? So 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? Yeah. So we open sourced Sourcegraph about a week ago, and we had 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. But 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. And in hindsight, I wish we had done it a lot sooner. So 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. That means that you are 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. Did they do it? Did they choose not to because it was closed source or because it was a bad product? Did they do it? Do they choose not to because it was closed source or because it was a bad product? The questions or the things that you experience, they're going to become a lot more clear when you're open source because you take a lot of objections off the table. So 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. 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 they're thinking about starting a company for developers, it seems to me almost like what you did was keep optionality, because once you have something, 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. So it almost seems like you kept your options open. You established, OK, I know pretty much how this can go if we open source it.

And then you made a more informed decision later on. So is that accurate? Or you'd still encourage new entrepreneurs and developer tools to be like, no, no, no, no. You don't need to keep options open in that way. You can just start from open source from day one. I think you should start from open sourcing day one. Yes, it kept some options open for us, but we just would have learned, you know, 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. And 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. So 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.

That's quite a claim because I can point to many, many billion dollar companies that I think I'm not sure that would be true of. Well, I mean... So I worked for a company and it was closed

source and they are doing very well in their sales, etc. And they're sitting, you know, sales, et cetera, et cetera. And they're like a developer tool, the kind of business. And but they were they were always worried about fast followers because, you know, it's not like someone could compete. You know, it's not like they're impervious to competition. So, yeah. Yeah.

You know, so I don't know the details of that, but I suspect that even if they had open open source their code or a core of their code, if they pick the right things to open source, then they would still have a great business. If a company is, you know, a multibillion dollar business at this point, there are probably some things that they do extremely well that are not entirely encoded in, you know, the core open source release they might make. Yeah. Yeah. All right. It's good points. And I like being another, like an open source generational person like you, I, I want to believe that I think my dad and a lot of like enterprise software people would just laugh at us as idealists. So. Yeah. Well, you know, I mean, it's, it's that kind of thinking, which was a big reason why we took so long to open source. It's risky and you can always make the point, you know, GitLab or GitHub is closed source. And so clearly you can be closed source and have a great business, but 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 and it's on the founders and creators of these tools to make these really difficult calls to say, well, you know, 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. And 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. Wow. All right. You're sold. And so another thing you

mentioned, it seems to me like in conjunction with open source is this open company idea. Is that a term you came up with or that you're taking it from somewhere? As far as we know, we came up with it and also open product. And 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? And 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, you know, we're going to IPO on this date. And 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. And 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. So 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. Yeah, wow, very admirable. It reminds me a bit of Buffer, if you're familiar. They release a lot of things quite transparently. Yeah. 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 that are, you know, 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. So I would say it is different from Buffer in that way. That 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 Principle from Bridgewater. Yeah, absolutely. So I had a few questions. We had one 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. Yeah, you should. So I feel like it's almost like it would feel like it'd be lazy coming from me,

like, hi, I'm interviewing this person, tell me what I should ask. So Daniel Schlitt, S-C-H-I-L-D-T. He's at A-U-T-I-O-M-A-A on Twitter. He asks, how do we get a zoomed out view of a code base, 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? 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, you know, 90% of devs. And so 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. And 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. But 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. And 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. And I would love to have Daniel or other people out there that want to build these visualizations, go build a source graph 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 are the projects going on, here's the status of them. That's one little source graph 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. Very cool. And these would be, people can make these sorts of things in source graph extensions. Yeah. Cool. I wanted, I think we were connected originally by Aiden

Kanief, who I had on the podcast almost a year ago, I think. Did you guys meet at YC? I met when someone said what Aiden is building is really cool. I emailed him and we met up. Cool. Got it. Did you do YC at all? No. Yeah. Okay. So I think there is obviously very, very different between what you and Aiden are building from the like product perspective, you solve very different problems. Um, but it seems like there are some similarities. Do you, do you see any similarities or places for collaboration? I think the 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 Aiden is building at 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 or 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 Aiden with this 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. And right now, they have to build these things per editor. And when they get on a code host, they're going to have to build, you know, 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 that on.

So people like Aiden, people like CodeStream, we want to make it way easier for them to do that. And we don't want to go, you know, 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 on. We're not going to go and compete with them.

That's something that platforms need to do well. And we will do that. Yeah, yeah. It took me a little while, but now I'm really starting to get the way you've nipped this M times N problem by inserting yourself as a platform. I guess you guys worry about the integrations to every editor and online code hosting platform in existence. And then it's just anyone else can write a single extension and have it just scale to all of those things seamlessly. Very, very cool. Got it.

That makes a lot of sense. So 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 how the company itself is going so far, number of customers or size or anything you wanted to share to give us a sense of what's going on with the company. I'd be curious to hear. Yeah. We have a 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. And that's a pretty lofty target to get to. So we have a little report card where we say, you know, for these customers that are using Sourcegraph, what percentage of developers used us on any given day? These are customers that, you know, 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, you know, 500 developers or 2000 developers or whatever, using our product on any given day. Uh, so, um,

those are the kinds of numbers that we see and you can extrapolate from there. You know, if we have that many users inside of a company, then we're doing pretty well. So yeah, we're, we're good. And, uh, 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. So 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 love to be one of those other companies that these DevTools founders look to and say, you know, Sourcegraph did it. These other companies did it, so I can do it too. Wow. Very inspiring. So do you see your future as being, you know, acquired by GitHub, Microsoft, one of those, or IPO one day, or you're, you know, it's too early to tell or whatever. Well, Sourcegraph is the most used tool in a lot of our customers. And that's a really powerful position to be in that, you know, we're a product that developers use more than the other tools, the code host, you know, these other paid commercial dev

tools they use. So we're not looking to be acquired by tools that are used less frequently than search. Yep. Yep. Got it. That's well said. Um, so, uh, so have you got, it sounds like you guys have raised money. You have a board. It's like a series A series B, where are you at in that stage of things yeah we're series a we announced uh some stuff a little over a year ago we have an awesome board and uh it's you know 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 you know before i was ce CEO of a DevTools company, I obviously had reason to be cynical. Just how much do these startups care about actually making a great product and how much

they care about monetizing or being acquired? And from my limited data point as obviously CEO and co-founder of Sourcegraph and investor in a few other DevTools 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. So 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. 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?

Yeah, absolutely. So ones we work with, Scott Rainey at Redpoint. He's fantastic. He was, you know, early on the board at Heroku, Stripe, Twilio, a bunch of other great companies. And then Goldcrest, Adam Ross, Dan Friedland. They were early in, you know, a bunch of the SpaceX, Tesla, Facebook-type companies.

And they understand their thesis is founder market fit. They saw that beyond 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. And so if, so I guess 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? Do you have advice on that?

Well, I think two ways, you know, people always say get the warm intro. And if you can impress anyone else who's at a reasonably successful startup with your product, then you can probably get a warm intro to that company's investors. But 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. And 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. And you don't necessarily need a warm intro. You just need a lot of users that love your product. So don't feel like you need to do all these things in order to get into the email inbox of these investors. And the ones that ignore you when you have a great product, well, they're literally failing at their job. 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 to bite them eventually. 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 have 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, you know, like work on your product first.

Yeah, we'll certainly work on the product first until you can get people excited about it. And hopefully those people are not, you know, just total randos on the internet, but they're people that, you know, 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've solved a problem way harder than getting investors excited about your product. And 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, you know, someone at a DevTools 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, you know, that's, that's enough for me to want to help you out and for me to want to invest. And then these things build on it, you know, then I can put you in touch with these other people you email can put you in touch with investors. So it just focused on getting a few of these data points of people that can,

you know, eventually pay for your product and getting them excited. And that's all that matters. And then at that point, once you have that, it's literally investors' jobs to know that what you have built is on the track to be successful. Yeah, you make it sound quite simple. Well, the hard part, as I said, is getting potential customers excited about that. You know, once you've done that, then the rest is relatively simple, but I can understand how it seems daunting to people that are not, you know, that have not done this before that are not in Silicon Valley or things like that. But 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. Cool. Yeah, that's a good message. So you mentioned that you are an investor in other DevTools companies. So I'd be curious to hear the names and stories or whatever of other companies you're invested in or that you just know about and are excited about. Yeah, well, let me talk about the ones that I'm just excited about in general, because the ones that 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 in the 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 and 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. Some of the interesting ones that I've seen are there's obviously Coder.com. There's Gitpod.io. There's Glitch, REPLIT.

And 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. So that's one area that I'm definitely interested in. Do you use any cloud IDEs, Steve? Yeah, well, now I feel like I have to thank you,

because I use a cloud nine, which has been bought and kind of it feels like left, you know, to languish a bit, but I love it. And you know, I have a Chromebook, so I need to use a cloud IDE. So and I like it a lot, you know, the whole Cloud IDE Chromebook lifestyle. So I'm excited to try out this Coder.com that I've never heard of. And what was the other one, CodePod? Gitpod.io from TypeFox. It's a cool URL. Let's see.

I'm curious what this is like. Oh, interesting. Okay, so got it. Cool. So Gitpod is more like a code review. They have really good code review integration. Yeah. And they're not actually built on VS Code proper.

They built a kind of subset of VS Code called Theia, T-H-E-I-A, 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. Got it. Yeah, that looks cool too. I'm excited to give those both a try. I totally agree with everything you said. It's the sentiment of you want to review a pull request, you want to make a small change. And also, you know, we both are Chromebook people. So we're all about, you know, doing things in the browser. Yeah. It's related to your M times N problem. Like, let's just stop it with these native platforms. Let's like just pick a platform and then we'll, that works on every device. And then we just all compile to that platform yeah well you know that's the holy grail i don't know how long it's going to take for us to

get there but uh i think we're moving in that direction yeah well i i really appreciate all the work you're doing to um kind of like fill fill in all the the groundwork to like kind of virtualize this platform for ides 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, you know, all these language communities. It's hard to get language communities

to agree on, you know, basically anything. That's one of the religious wars in programming, but they agree that LSP is the way forward. Cool. Yeah, that makes sense. So 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 place on the web that people should know about you from if you have those? Yeah. I'm SQS on Twitter, SQS at 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. So 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. And 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. And I personally certainly will too. Great. Thanks so much. That's a very generous offer. Are the things that you're looking for that you want to ask the community for? Are you hiring? Are you looking, I don't know, any sort of thing that you want collaboration on? I guess you mentioned some things already. 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. Oh, wow. So it sounds like you're saying in the

sense that you'd hire them or different? This is like a sponsorship model. Hire them. Or if someone wants to do this on the side, then happy to do some kind of contracting arrangement. Oh, fascinating. So that sounds like a very cool open offer that if anyone wants to make a language server for any language and they do a good job, you'd pay them almost hourly to do this work that without you would be just free open source work. Yeah, absolutely. And all that work would be open source. So it would go back and benefit the whole community. Wow, that's crazy. Do you have that up on the internet in various places? I didn't catch that. We do. We put it on Twitter, put it on Hacker News. We probably should put it on our main website. Yeah, that's such a neat offer. I don't know of, I can't think of any offer similar, like comparable to that. Like, you know, if you want to do open source work on this thing, we'll just like pay you

for it. You know, like that's, that's so cool. 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 gonna be up on our site. Cool. Yeah. I, yeah.

Anyways, at least that's my reaction. So I guess you'll, you'll see if other people have a similar like shocks like is this like i'm pinching myself is this a dream cool well anyways thanks so much for your time this was wonderful yeah thank you all right take care okay bye