Episode 9 of The Craft of Open Source. Summary and transcript below. Listen at www.flagsmith.com/podcast, or wherever you get your podcasts.
Episode Overview
Sourcegraph’s first product was public code search that allowed developers to search across all public code bases and find useful pieces of code for their projects. After getting the hang of how to make search effective and being inspired by Google’s internal tooling for their own employees; they decided to focus their core product on code search within companies.
One of the core pillars of the company has been establishing trust with both the open source community and their customers to get them to allow search across their code bases. This is something that Quinn and the team have embraced in their culture (their employee handbook is published publicly) and how they build the product.
I really enjoyed learning about Sourcegraph’s approach to building their product and community based on transparency and trust. I hope you enjoy the episode.
-Ben
Episode Transcript
It’s great to have you with us, Quinn. Do you want to give us a bit of background about who you are and about your business?
My name is Quinn Slack. I’m the CEO and Cofounder of Sourcegraph. We make universal code search for companies that have code and anyone who works with code. I’m a coder myself. I love coding and have felt what it’s like to work on a big open source code basis. I’ve seen what it’s like to manage software projects inside JPMorgan, Bank of America and tech companies. My Cofounder and I ended up coming back with one thing, which is we love code search, and yet most devs, most companies never even heard of it, never had it, never knew why it’s awesome. We started Sourcegraph to get code search to every developer and every company.
Did you start the segment, do you think almost?
There are code search tools that existed before Sourcegraph and others have come up in the last ten years. We started Sourcegraph in 2013, but we have OpenGrok from Sun Microsystems, now Oracle OpenGrok. We have Etsy created Hound, and you have Livegrep. There are other code search tools, but there wasn’t a code search tool that was like the one that Google has internally. Google has this amazing internal code search tool, all of their devs love it. It’s got code intelligence and code insights. It lets you make campaigns its large-scale fixes and it’s called code search, no other name. If you’re a Google dev and you quit Google and you go to another company, a lot of times the thing that you miss most about Google is not the micro kitchens or the fresh salmon every day at lunch, it’s this code search tool. We wanted to bring a code search tool like that super high quality, that tool that people love. We wanted to bring that caliber code search tool to every other company out there so that it’s not just Google’s secret weapon internally.
We got into a private ex-Facebook group because they have a similar story with their feature flagging tool. There were people leaving Facebook and going like, “How do I do this now? I don’t have this amazing tool.” Did you have a stint at Google where you were exposed to that?
I personally was not at Google. My cofounder was at Google and we have other team members from Google. Facebook is another company. It’s Google and Facebook that have internal code search tools. Google’s has been around for a little bit longer. It’s a little bit more advanced, but Facebook has Big Grep also known as TBGS, The Big Grep Search and they have a pretty awesome developer platform internally. Ex-Facebookers also have the same sentiment.
It’s interesting that they don’t open source those things as well. That’s a big signal to me.
I don’t think that they’re refusing to open source it because they want to keep it internal. I think it’s because the codebases of Google and Facebook are special. They do things in their own way and it wouldn’t be that helpful if they were to open source it. They have open sourced some nice components. Google has open source libraries for doing engrams that make code search indexing easier. Google’s got a single massive monorepo. They’ve got so much tooling, same with Facebook.
It would be very hard for them to take what they use internally and throw it over the wall. It would be a ton of work. One thing we found is that code search for a company is a different product than code search across all public code. We didn’t realize that when we were getting started. You think, “It’s search.” The scope of what you’re searching across changes the implementation, what the search UI looks like. As a company, we decided, “Let’s make code search for a company amazing because then we’ll know that we’ve got a business model that we can then grow, and then we can then make good public code search.”
I cloned your repository and had a look at commit number one, which is always interesting. Do you know what commit number one was?
It would be from hello it’s Sourcegraph and making it open source in public.
Published Sourcegraph as open source rocket emoji. You had a fairly established codebase at that point by the looks of things, is that right?
It has come a long way since we made that commit. We had a basic code search then.
What was it? I did the same thing for Ansible and the first Ansible commit is amazing because it’s like 1 file that’s 300 lines long and it goes from there. You guys already had an existing product that you then open sourced. What was the history behind pre that commit?
In Sourcegraph, we did start out first by making public code search. You could go to Sourcegraph.com and search across open source code. You could do find references and go to definition. You could find use examples for this open source library you’re using, and that was great. One of the cool things about that is sometimes you’ll be working with the library. You’d be looking for use examples and you’d realize, “There’s this other library that’s an even higher level that does exactly what I want. I can use that instead.” That was good, but we are a business and we want to invest a lot in making amazing code search. You can’t make money directly on public code search, and we want Sourcegraph to be useful for companies.
We started by having a cloud service for Sourcegraph where you can go on Sourcegraph.com, you could sign in via GitHub and click that big scary green button that would OAuth all of your code up the Sourcegraph and then we would index it, and make it searchable. What we found out is that no one trusted us with all of their code. Why would they? We were a tiny little company. I think our team is and was trustworthy, but why would anyone believe us at that time? Certainly, the kind of companies with a lot of code that needed code search the most, they are not going to be trusting us. We decided, instead of trying to offer a cloud service, it didn’t work. We decided to go self-hosted and self-serve so you can take Sourcegraph, do a Docker run command and run it on your own network.
You get code search on your laptop or on your own EC2 instance. You don’t need to send any code off your network. That’s when our business began to take off. We decided to also go open source so that developer who’s thinking, “Should I or should I not try Sourcegraph?” It gives them a little bit more trust in us. We’re a little bit more transparent. We’ve also done some other things in our business. We’ve got a public employee handbook. That’s the thing that documents all of our processes, and that’s all public. We want to be transparent to the win that developers’ trust and to communicate to every single new person that joins our team that we want to do the good thing. We want to find strategies that force us to do the good thing.
That makes us always think about, “How are developers going to perceive this?” With that said, we are not 100% open source. We adopted a model that’s similar to Android or Google Chrome or VSCode or GitLab where we’ve got some open source code and non-open-source code. For us, those both live in the same repository. The non-open-source code is in the directories’ main enterprise. It’s clearly delineated in the licensed file when customers or anyone runs their Docker image that’s built from the enterprise sources contains a combination of open source and enterprise code, and that can access our online extension marketplace. You can get all these editor language extensions for code intelligence. That’s like how the underlying base of Android is open source, but if you want the Android Play Store, then you’ve got to work with Google.
With VSCode if you want to get the extension marketplace, you’ve got to use the official Microsoft build. With GitLab and with Chrome, similar situations. That’s the model that we ended up on. Some people ask like, “This Sourcegraph repo on GitHub, is that what you all work in?” Yes. You join Sourcegraph as an employee. On day one, all of your PRs, all of your issues, everything is going to be in that. We’re very transparent and public there.
At what point did you start talking about, “Maybe we should publish everything on GitHub?”
It was several years ago, and it felt like such a big decision. We were maybe 10 or 15 people at that time, and we had a few customers and it felt scary. It’s like, “Is this an irreversible step?” We think it makes sense for a lot of reasons, but maybe some massive company is going to come along, take all the code, repackage it and offer it. It felt scary but in hindsight, it was such a non-event, it made it easier for us to commit code and share links.
Open sourcing something, people don’t care unless they care about that product. We were very early as a company. Not that many people cared about Sourcegraph as a product back then. It was such a non-event. Even if it is a big event, even if it’s some big famous company that chooses to open source, that data they open source might get to the top of the Hacker News, but that’s a one-time thing. Open sourcing is not a big splash anymore. There are some people at Sourcegraph that thought that it was going to be a much bigger deal. In the end, it was business as usual the day after, and it doesn’t come up a lot.
It sounds a bit anticlimactic in a way.
We’re waiting for the massive spike and the hoards to come and that didn’t happen. We worked on that. We knew that we would get there through an amazing product that a ton of developers used and loved, not through the legal framework under which we released our code.
That then enabled developers to do Docker run or get put in and run something locally on their machine to kick the tires?
We did publish a Docker image before we had an open source release, but making the code public and open source showed developers a little bit more trust on the margin. Most people are still using our prebuilt Docker images. There’s a self-hosted, and that is a very important step for us as a company, which let us get bigger customers early. There’s open source. Self-hosted, that was a much more momentous decision for us. Open source, on the margin, makes that developer trust us a little bit more when they’re thinking, “Do I or do I not use Sourcegraph?”
“Open source is not really a big splash anymore. People don’t care about it unless they care about the product.”
It’s interesting because most of your back end looks like all of it is written and Go right. We’re in Python. If we were to distribute Docker images whilst having closed products, that would be weird because it would be trivial to steal all our stuff.
Obfuscating code feels weird. GitHub enterprise does that that I’m not sure why.
You must have spent a good few hours making sure there weren’t any API keys hidden in there before you published it.
You should be doing that anyway if you have a private repo and you can use Sourcegraph to help you do that.
How much time did you spend thinking about licensing and what license to choose?
That was a fairly easy decision. It was, “Do we go copyleft or not?” For our customers, every company with developers, we’d like them to be our customer in the future. We’d like to have a broad customer base. We’d like to have something that is unobjectionable. We chose Apache2. We didn’t feel like copyleft was the right choice for us. We also didn’t feel that we needed copyleft as a thing that might scare companies into needing to get a commercial license with us, because we had other elements. What we chose to keep on the enterprise side and not open source, that was enough of differentiation between the paid, free, and open source product. Apache 2 and in our rebuilt, it’s not half Apache 2 code and then half non-open-source code.
That code is still in the same repo. It’s still public and visible. The licenser doesn’t matter. It’s like, if you go on your blog and you publish some posts, that post is copyright, the default of creative expression, published is copywriting. Technically, if a GitHub repo is out there and it doesn’t have a license, that’s not open source, that’s copywriting. The other 50% is not open source, but that’s under an enterprise license that clearly states that. There’s no particular magic in that license.
In terms of the marketing of a company, did that change after you went open source? Were there unexpected benefits around that from a marketing perspective?
I wish. It had a surprisingly small impact. We need to market why code search is awesome, why you need to be using it, how it’s going to make you a better developer, what are all the other companies that use it. That’s what we need to be marketing and our code being open source or not, that doesn’t matter to people. There might be something here where we are an end-user product. We are Google for your code, code search. We’re not some library. We have an API, but we’re not some API that people integrate into their own code. End-user applications, people do treat them a little bit differently. You don’t go to GitHub to discover end-user applications.
You might go to GitHub to discover libraries, open source companies that offer something where the key entry point is the library. For example, a feature flagging company, that’s a library that you pull into your code. GitHub is probably a lot more effective for discovery there, and having an open source repo is a lot more effective for discovery, but not for us as an end-user application. Or maybe we’re being stupid about it and we could be getting a lot more out of it.
I’m still learning. We find that they have a benefit to each other. You can try and get traffic to your website and that can then take a look at your GitHub repository and then vice versa. It’s interesting because I haven’t spoken to many of the people for this series who’ve had that big close to open splash. For a lot of the people I’ve been speaking to, it’s always been how they’ve operated. There are also soft things around validators. You go into your website, see the GitHub logo, click on it, see that the whole thing is open especially as time goes on, it seems to becoming more common and has more weight within the hive mind.
I strongly prefer using code that I can view and it’s open source. I get that.
In terms of contributors, I see you’ve got 149 contributors. Was that like as soon as you opened it up, you were getting pull requests? What were your expectations around that?
We had no expectations whatsoever. Any contributions that we would get from the community would be a pure bonus. One benefit is we got a lot of customers, they report issues and we love it, and they love it. They go and file a GitHub issue where sometimes they’ll email us or in Slack channels, they’ll mention it. It was nice and we can always share a GitHub issue link with customers and show, “Here is the problem that’s been reported. We’re working on it.” That’s a nice way to keep us on the same page and to establish trust so that they know we’re not some black box, that we’re transparent with issues that they’ve reported. We weren’t expecting any contributions. I think this is another difference where we are an end-user application and those things get fewer contributions.
You could imagine a company who is thinking of, “Should we open source our code? The secret sauce.” Someone who said, “It’s going to be such a big splash. We’re going to get many contributions. People are going to be building our product for us.” That’s not going to happen. We were very conservative by estimating no external contributions. In the future, we will get some more, especially as we become not just code search for the company, but public code search. We’ve got around 80 people at Sourcegraph, multiply that by two, and that’s the total number of contributors we have. We’re going to be the key driving force behind contributions.
It’s rare for someone to send a PR that’s a significant feature implementation or something like that.
That’s been a common thread from everyone that I’ve spoken to. Maybe a little bit of a shame. I find that there’s a huge amount of value in someone raising an issue. Like if there’s a bug in your code that you weren’t aware of, you wouldn’t have been aware about it quite possibly unless they have gone on to GitHub and done that. There’s still a tremendous amount of value in that. The vast majority of your code basis has been written by members of the company.
One of the things that we’ve had a lot of trouble with, especially from a self-hosting point of view, how you strike that balance between, mainly from an infrastructure perspective on making the platform simple to self-host and balancing that with wanting to use some core piece of infrastructure that you wouldn’t necessarily want to have anything to do with if you were self-hosting. Is that something that you’ve come across frequently?
Our principle is we want to deliver Sourcegraph in the way that it would be delivered if it were an open source tool. That means trimming down the number of primitives for persistence and deployment that we might rely on. We have Sourcegraph rely on Postgres with a fairly wide version range, Redis, and block storage or object storage. We don’t need all the performance assumptions there. That’s easy to deploy. We’ve got a Docker image that will bundle up Postgres and Redis in the same Docker image. We have a lot of customers that will use Amazon, RDS or Google Cloud or SQL to Postgres in their respective cloud offerings of Redis. They don’t even have to have a Sourcegraph cluster.
You can deploy Sourcegraph on Docker and Docker deploys in Kubernetes. It means that we can’t use the hot new AWS API or service for some complex thing, but that’s okay. We keep it simple. That’s how some random person working on a random open source self-hosted single-tenant tool would need to build their tool. That feels natural. People massively overthink how to deliver a self-hosted software when their mindset is like, “This is our company’s product.” They think about wrapping it in all of these super complex deployment mechanisms, but no, keep it simple. Ship ML files, ship a Docker image and rely on a small number of primitives.
Was that a philosophy you had pre-opening the code up or did you have to start trimming off all these crazy whizzbang AWS services that most people wouldn’t know?
It was a philosophy that always appealed to me. We had one external dependency on a user authentication that we had to remove, but otherwise, you can go a long way with Postgres and Redis.
I know some of your larger customers or larger code bases, you must have some fairly stringent performance and underlying technology requirements.
We have customers with tons and tons of repositories. 500,000 repositories or instances with more than 1 million repositories. Another thing that we realized that a lot of people don’t think of with self- hosted is each company is going to be running their own instance. You might have 10,000 customers, but you don’t have to have a single instance scale up to 10,000 customer’s data. You have to make it work for the largest customer that you have.
If you’ve got a multi-tenant cloud service, you have to do so much scaling. There’s so much complexity. There’s also application complexity, deployment complexity. It has to be available 24/7 online. There’s a lot of other security considerations that are involved in a multi-tenant cloud service that is not involved in a single-tenant service that customers run. Self-hosted is massively simpler and you can get away with an order or two magnitude less scale with self-hosted. We’ve got massive customers, but multi-tenants would be 10 to 100 times bigger than any of our customers. It’s helped us move quickly and still offer a good performance to our customers.
Sharding as a business model.
That’s a good technical way to explain it, shard your customers.
We’re in the same boat. Although we don’t have as many large customers as you. They have different ways of approaching performance, tooling, and stuff, but we’re targeting the same thing. Are a lot of your larger on-premise installations running on top of Kubernetes and OpenShift?
We see a lot of running on Kubernetes on all the different cloud providers. We get to come up with the common denominator, and Docker Compose is fairly popular. We’ve got some customers that have their own container systems. One awesome thing about being in this business is we see how all kinds of companies deploy. The reason why a company might have their own container system is because they had a need for it before Kubernetes was out. They always bring an interesting angle and they’re not in Kubernetes model culture.
There are a lot of things to learn and I’m glad that there’s not a single model culture. We see it all and we try to make it so if you’ve got some custom container deployment scheduling, whatever system, that you can look at our Kubernetes or Docker Compose file and break apart the services and translate that to your own deployment. We don’t have many Docker containers that need to be run. There’s not that much inter container communication that needs to occur so that you can replicate it in your own system. Keep it simple.
“Code search is something you won’t be able to live without once you have it.”
In terms of deciding what to make proprietary and what to make public open, do those decisions tend to come naturally or are they big arguments for weeks on end?
It’s important to lay out a principle. For us, the principle is if a feature is way more important to bigger companies and is not as much of an individual developer feature, then that’s a good candidate for it being in enterprise. We’ll have plenty of discussions and you can see them in our issue tracker and our handbook, about particular issues and how do we classify them. Overall, people are understanding that this is a difficult decision for companies, and you’re always going to see some people hating a company for not making everything open source and free. The silent majority understands that there’s a difficult choice and you need a business around a product to be able to invest in making it better.
Did you put a lot of thought into that upfront or did that come out naturally? We’ve had exactly the same thing where we were trying to come up with a set of moral guidelines around some rules around this rather than what felt right.
We did have a draft of this principle and we put it in our CONTRIBUTING.md file. It’s a lot less contentious than we might’ve expected it to be, in the same way that going open source was much less of a splash than some people might expect it to be. Even for a company like GitLab where they had a lot of community interaction on this thing, the vast majority of the GitLab community understands and trusts GitLab on these kinds of decisions. Have you seen any kind of commentary or backlash and decisions you’ve made here?
We’re still starting out in fairly small. We are starting to build more proprietary code. We’ve taken a different path and it’s a separate branch effectively, but it’s in a private repository. We spent quite a lot of time trying to decide whether it was better to keep it in a public repository or not. We were a little bit worried about if someone forks our public repository, they’ve then fork some of our copyrighted stuff and what’s their responsibility for that.
One of the very first forks we had was the Financial Times, and it’s like, “Let’s find whoever it was that did that in the Financial Times.” We talk to them and they were using it internally. I’m still not sure what the right choice is. It’s maybe different for different people. We felt like, if someone’s forking a repository and they don’t own everything in that fork, then it felt like it added complexity, but then at the same time, we don’t get any oversight on top of the code that’s private.
For people in your situation, you have the problem of like, “How do I trust all that stuff?” We’re not asking for access to technology companies, ninety-eight percent of their IP upfront is the first thing you do when you installed it. For you, I can totally understand. That’s a huge win for being open. If some of your code was then still private, it wouldn’t make sense. There are many different ways of solving that problem.
The overhead of when you make a change to both public and private code at the same time to make it to two repos, isn’t that annoying?
It’s generally. All of the work happens on the open one and then we merge that into the private one. The features that are private tends to be fairly isolated. For example, we’d run on top of Oracle, when you’re doing those mergers, it’s not like your Git clients suddenly start. The red warning light starts going off and you’ve got 58 collisions or anything like that. That might come into a problem down the line, but it hasn’t yet.
Do you guys do any telemetry tracking of the people that are running the open source products?
If you’re running the open source version, no. If you’re running the enterprise version, it’s going to ping our servers for an update check, and you can check the handbook. It will send back also some information that it documents such as the quantity of users using it in a given day and so on. These scalar values help us understand high-level usage, but never sending anything like a file name or any code or anything like that, not even all the users and their email addresses. We wanted to pick something that was understandable and unobjectionable to 99.9% of the user base and something we can document.
You’ve not been curious to get any telemetry on the open self-hosted side of things. You don’t know how many people are running it, right?
We assume it’s a fairly low number because the Docker run using the images or getting the enterprise build. You can use it for free for under ten users. It’s like how many people use Chrome versus how many people build Chromium from source? The vast majority of people use Chrome. I do use Chromium, I don’t hold it to myself.
In terms of how do you dissuade or limit people from using those enterprise features if they haven’t paid for them or do you not?
You need a license key. You could make your own enterprise build that comments out the lines that would be violating the enterprise license. Because we’re an end-user product, companies are not going to be foolish to circumvent illegally a products licensing, and then have all of their developers use it. That would be a risky thing and we haven’t seen that happen.
Do you think that’s happened? Someone must’ve done it. It’s common in one line of code out, or maybe they haven’t had any?
I have no idea. I don’t care. We’d find out if it was being done at big companies because let’s say like ABC Corp was doing it. We’d get random bug reports or tweets from people at ABC Corp saying like, “I love Sourcegraph, but is this available.” I didn’t realize ABC Corp is using it. We don’t get many of those. There’s one very large company where we suspect something that might be going on. It’s weird. It’s like talking to random reporters and someone’s like, “My dad works at this company. He uses Sourcegraph and he loves it.” All these weird data points, we’re not hearing anything from the developers, but we’re hearing things second hand. It’s more like a curiosity. For our business model, if 99% of companies pay and 1% don’t, then that’s a cost of doing business. Not that it’s right, not that it’s ever right to do that, in my opinion, but that’s not a fatal flaw in the business model.
Every company has a breakage. I’ve not heard of a situation like that, but you’re never quite sure what goes on under the covers. What’s next for your project? Have you got major landmark plans or incremental gains?
It would be sad if I said, “The incremental gains.”
I like incremental gains.
Those are important. We’ve still got a ton of work to do, to get code search out to more devs, more companies. Our business is like we’ve got a ton of awesome customers where all their devs are using Sourcegraph for code search. What that means is Sourcegraph is the only place in those companies where all their code is accessible and all the devs use. From there, we get all kinds of awesome requests such as, “I want to be able to fix code, not to spine code. I want to be able to programmatically roll out this fix and make a thousand PRs and monitor the progress of that.” We’re working on that. We get requests like, “When I am looking at code, I want to see not just find references, go to definition, who wrote this, but also what does Datadog say or for this block of code, what feature flags are enabled or disabled and what proportion of users are getting that?”
That’s an interesting integration with feature flagging tools like yours, bringing all kinds of other requests like that. Also, people integrating internal tools around code ownership and code compliance like, “If this file changes, who do I need to get approval from?” There’s that. We’re coming out with public code search. We have Sourcegraph.com. You can search across all kinds of code, but there are a lot of product changes that we’re making to make that an even better experience. We want to make so if you want to to find awesome, automatically curated use examples for any open source project, and we’re going to show you, “Here’s the slow dash function.”
I feel like half of the GitHub searches must be around that use case and they’re always like the results. It’s like AltaVista for code.
Sometimes you’ll find a great Stack Overflow answer, but sometimes it’s out of date. The beauty of code is there’s so much of it. It’s all connected and you can treat it like data. We have some prototypes where you get an awesome rundown of, “Here’s how this library is used. Here are the best practices. Here’s the popular thing. This function is not used anymore. Maybe it’s not officially marked as deprecated, but no one’s using it like this anymore.” It’s a magical experience. We think 50 million developers a month are going to find it useful. We’ve got a lot of work to do. We are hiring, looking for great people, but that is something that we can do. We are totally excited over the moon about getting that out.
How did you figure out what to not do and what to say no to? I always find that defines products quite often so much more than what you do. You’ve got an interesting position where you’ve got tons of directions you could go in. How do you figure out which way to point?
We want to build things that will be useful to every single developer inside of the company, that they will use on a daily or almost daily basis. We want to do things that will apply to all companies and all developers out there. That helps us focus. It also helps us for the companies that we work with that are building integrations into Sourcegraph to show how this code is running into production, for example. It helps them know that we’re not going to go and build our own first-class feature flagging system. We’re not going to being able to build a logging and monitoring system because different companies need different kinds of feature flag systems. We don’t want to be the one specializing in that. We want to do the common denominator that reaches all of this. That has served us well so far.
Can you think of something that you’ve done that you weren’t expecting to be popular or get you three posts on to Hacker News or something unexpected that was successful for the project?
I can’t think of anything massive. It does go back to the incremental improvements. Once you have search, there’s a lot of incremental improvements and the big changes that we make, even though everything is anticlimactic and you should assume that every big release you make is going to be anticlimactic. Even if it is a big popular release and it gets a lot of attention, you want to keep growing and you want the release two months from now to be twice as big. In hindsight, it’s feeling anticlimactic.
I can’t think of anything like that. For me, the features that I love most are things around the color theme, adding higher contrast, making it faster, having better query auto-completion. It’s not like these massive mind-blowing things, but if you look at Google, and Google in 1998 had the same UI as Google now. It’s all this stuff under the hood. What are the results that it shows? How fast is it? How comprehensive is it? How personalized is it? That’s where Google has gotten better. That’s the nature of search. There are not these massive whizzbang changes. It’s an incremental improvement.
“People hate companies that don’t make everything open source, but the truth is you need a business around a product to make it better.”
A tough reality of search is you don’t get thanked for amazing results.
Search is a weird product. Search is not a system of record. You don’t need to use search. There’s no data that you can all link it to through search. Search is only useful if at that moment, for that particular need, it is a faster way or a better way of solving your problem. Every single time a developer uses Sourcegraph, their mind has to affirmatively think of Sourcegraph and affirmatively think that we are going to be a faster way, and same with Google.
We like to think of it like there’s this famous marketing tagline in the US about the rental car company, Avis. Hertz was the number one rental car agency and Avis is number two. They ran all these commercials saying, “Avis, we’re number two, so we try harder to win your business.” We like to think we’re search, we’re not a system of record. That makes us need to try harder to focus so much on speed, engagement, user experience because if tomorrow you don’t even think of Sourcegraph, then you’re not going to use us and you’re going to go away. We’ve got to win that every single day and every single time.
It’s almost a thankless task in a way. It’s difficult to describe. This search was 13% better than it would have been before.
We love our customers. We love what we do. Now is not the right time for any tech company to have any “woe is me” card.
Quinn, thank you so much for your time. That’s super interesting. I’m going to fire up my Docker runtime and kick some tires.
Code search is awesome. If anyone out there has not used code search, has no idea why it’s awesome, then I would love for you to experience how awesome code search is, and make you a better developer. You’re going to love it. It’s something in your toolkit that you won’t be able to live without once you have it. You are not alone. If you have not yet used code search, most devs haven’t and we’re on a mission to get code search to every dev. Hopefully, we can make an awesome code search that you love.
Thank you so much for your time and stay safe.
You too. Take care.
About Quinn Slack
Quinn Slack is CEO and co-founder of Sourcegraph. Prior to Sourcegraph, Quinn co-founded Blend Labs, an enterprise technology company with over 500 employees dedicated to improving home lending. At Palantir Technologies, he created a technology platform to help two of the top five U.S. banks recover from the housing crisis. He was the first employee and developer at Bleacher Report after graduating from high school. Quinn graduated with a BS in Computer Science from Stanford.
