7 ms·

Sourcegraph CEO here. We made our main internal codebase (for our code search product) private. We did this to focus. It added a lot of extra work and risk to h

by sqs 2y ago

Sourcegraph CEO here. We made our main internal codebase (for our code search product) private. We did this to focus. It added a lot of extra work and risk to have stuff be open source and public. We gotta stay focused on building a great code search/intelligence product for our customers. That's what ultimately lets us still do plenty of things for devs and the OSS community: (1) Our super popular public code search is at https://sourcegraph.com/search https://sourcegraph.com/search, which is the same product customers use internally on their own codebases. We spend millions of dollars annually on this public instance with almost 1M OSS repositories to help out everyone using OSS (and we love when they like it so much they bring it into their company :-). (2) We also have still have a ton of open-source code, like https://sourcegraph.com/github.com/sourcegraph/cody https://sourcegraph.com/github.com/sourcegraph/cody (our code AI tool). BTW, if any founders out there are wondering whether they should make their own code open-source or public, happy to chat! Email in profile. I think it could make sense for a lot of companies, but more so for infrastructure products or client tools, not so much for full server-side end-user applications.

quantumwoke 2y ago
Been a fan of sourcegraph since 2016 or so, it's been exciting to watch the pivots along the way. That being said, the loss of transparency here is pretty sad, speaking as a large FOSS repo owner. What were the main factors apart from risk that went into the decision?
- sqs 2y ago
  Thanks for being a fan. And I understand it's a bummer to not have our code be public and open-source anymore. Sorry. It's a bunch of reasons that add up. I'll give some more details for anyone curious. (And I know that despite these reasons, lots of HNers probably wish it was not so. I agree! I too wish for a world where all companies could have their code be public and open source.) - We have a lot of tech around large-scale code graph, indexing, etc., stuff that is very differentiated and hard to build. We were starting to put some of this in separate private repositories and link them in at build time, but that was complex. It added a lot of code complexity, risked bugs, and slowed us down, and if a lot of the awesome stuff was private anyway, what was the point? - As we've been building Cody (https://cody.dev https://cody.dev), our code AI tool, we've seen a LOT more abuse. That's what happens when you offer any free tier of a product with LLM inference. We had to move a lot more of our internal backend abuse logic to private repositories, and it added code complexity to incorporate that private stuff in at build time. - It confused devs and customers to have 2 releases: an open-source release with less scaley/enterprisey features, and an enterprise release. It was a pain to migrate from one to the other (GitLab also felt this pain with their product) because the open-source build had a subset of the DB schema and other things. It was confusing to have a free tier on the enterprise release (lots of people got that mixed up with the open-source release), and it made our pricing and packaging complex so that lots of our time was spent helping customers understand what is paid and what isn't. - There were actually very very few companies that were going to pay but then decided to use the open-source version and not pay us. A lot of people probably assume that's why we made this move, but it's not. I think this is because people like the product and see value in it, including all the large-scale code nav/search features that are in our enterprise version. - Although very very few companies used our open-source version to avoid paying us, we did see it cause a lot of annoyance for devs who were asked by their management to try cloning our product or to research our codebase to give their procurement team ammunition to negotiate down our price. This honestly was just a waste of everyone's time. - If we got a ton of contributions (we never really solicited any), then it might've changed the calculus. Sourcegraph is an end-user application that you use at work (and when fun-coding, but the primary revenue model is for us to charge companies). For various reason, end-user server-side applications just don't get nearly as many contributions. Maybe it's because you'd need to redeploy your build for a bunch of other users at your company, not just yourself. Maybe it's because they necessarily entail UX, frontend, and scaling stuff, in addition to just adding new features. - We heard from people who left GitHub that people at GitHub were frequently monitoring our repository to get wind of our upcoming features and launches. Someone from GitHub told me his "job is to clone Sourcegraph". Since then, they obviously deprioritized their code search to re-found GitHub on AI, so we're not seeing this threat anymore. But I didn't love giving Microsoft an unfair advantage, especially since GitHub products are not open source either. - Since we made our code non-open-source, we've been able to pursue a lot more big partnerships (e.g., with cloud providers and other distribution partners and resellers). This is a valuable revenue stream that helps us make a better product overall. Again, because Sourcegraph is an end-user application with a UI that devs constantly use and care about, we never really had the MongoDB/Redis/CockroachDB risk of AWS/GCP/Azure just deploying our stuff and cutting us out. We're not protecting from downside here, but we are enjoying the upside because now those kinds of distribution partnerships are viable for us. To give a specific example, within ~2 months of making our code non-open-source last year, we signed a $1M+ ARR deal through a distribution partner that would not have happened if our code was open source. This is not our biggest annual deal, but it's still really nice! We are totally focused on building the best code search/intelligence and appreciate all our customers and all the feedback here. Hope this helps explain a bit more where we're coming from!
  - jsiepkes 2y ago
    > Sourcegraph CEO here. We made our main internal codebase (for our code search product) private. We did this to focus. > There were actually very very few companies that were going to pay but then decided to use the open-source version and not pay us. A lot of people probably assume that's why we made this move, but it's not. > To give a specific example, within ~2 months of making our code non-open-source last year, we signed a $1M+ ARR deal through a distribution partner that would not have happened if our code was open source. So the reason these deals are now possible is mainly because time was freed up by not having the code base opensource?
    - sqs 2y ago
      > So the reason these deals are now possible is mainly because time was freed up by not having the code base opensource? No, it's that if all the code is free and open source for anyone, we would not be able to charge for it and there would be no deals. Even if, say, 60% of our product was open-source and 40% was closed source, we might still get a lot of direct customers but would struggle to do distribution partnerships because the distribution partners have outsized incentives and capacity to reimplement the subset of the 40% they think their market needs.
      - vundercind 2y ago
        I believe the question came up because the original rationale given was “we did this to focus”, not “we couldn’t sell the code for as much if it was open source”.
        sqs 2y ago
        Both are factors, as I said in my original post (focus and risk).
        vundercind 2y ago
        “We stopped giving away some of our apples due to risk.” “Of… liability? Or… uh, what?” “Oh—risk that we couldn’t sell the apples we gave away, obviously.”
rapnie 2y ago
> (1) Our super popular public code search is at https://sourcegraph.com/search https://sourcegraph.com/search, Correction: Public code on Github. This looks to be restricted to searching Github only.. even though it had "context:global" on the querystring every hit came from Github, and none seen from Gitlab, Codeberg, Sourcehut and other self-hosted forges (e.g. Forgejo).
- cqqxo4zV46cp 2y ago
  I’m sure there are 50 other ways you could categorise all the code that it searches. Nobody said that it exhaustively searches all available open-source code. I’m sure you know that that’s an impossible claim. This isn’t a correction at all. It is, at best, an elaboration. Certainly not worthy of the snark you’re giving. The reality is that GitHub hosts >99% of all open-source source code that anyone really cares about. If you have some philosophical issue with it, that’s fine, but don’t shoot the messenger by attacking individuals.
  - Nullabillity 2y ago
    sqs isn't a random messenger, he's the person in charge of the decision.
breck 2y ago
I think the term the industry needs to embrace is "Early Source": https://breckyunits.com/earlySource.html https://breckyunits.com/earlySource.html Make everything public domain, fully open source, just delayed by N years.
- dudeinjapan 2y ago
  Will be lovely to have the source N years after AGI terminates humanity.
  - breck 2y ago
    Lol. You could write a sci-fi novel with a world of cyborgs where the age of all cyborgs is N (when they first got access to the source). And primitives are called "Pre-Ns"
    - dudeinjapan 2y ago
      Not too shabby an idea!!
- ezekg 2y ago
  There is a term for this, no? https://opensource.org/dosp https://opensource.org/dosp
  - breck 2y ago
    Interesting! I hadn't seen that term. Thanks! I don't like their implementation though. If one thinks from natural principles, one has to reject the idea of licenses on ideas. Early source is in harmony with nature. Also "Early Source" rolls off the tongue better than "Delayed Open Source Publication". ;)
    - yjftsjthsd-h 2y ago
      > Also "Early Source" rolls off the tongue better than "Delayed Open Source Publication". Yeah, but nobody will know what "Early Source" means until you explain it, whereas the latter makes perfect sense on first reading.
cxr 2y ago
Yet another person equivocating the concepts of publishing code under an open source license and managing a project in public.
- nearlyepic 2y ago
  It has to be disingenuous, right? These concepts aren't complicated. I wish they would just say "we want to make more money" and stop polluting open-source discourse.
a_t48 2y ago
The open/closed decision is a current weight on my mind right now. Our main competition is an open source product - it feels like it will be a tough sell to not also have the core of the product be free (Robotics framework). I might shoot you an email.
- sqs 2y ago
  Cool! I’d love to chat.
deleted 2y ago
[deleted]
adhamsalama 2y ago
Why not go the SQLite way? Open source but don't accept external contributions. Literally just dump the code.
- cryptonector 2y ago
  > Open source but don't accept external contributions. That's not the key to the SQLite model. The key to the SQLite model is that their 100% code coverage testsuite is proprietary. You can't credibly fork SQLite3 w/o a similar testsuite because everyone knows that SQLite3 has that testsuite and so it's simply better unless your fork has one too. This works very well for SQLite because it is the single most widely used piece of software ever. And that is because it solves such an important and universal problem (a local DB RDBMS) with such convenience (embedded, server-less). The reason that SQLite does not accept contributions is not so much that they don't want to, but that contributors can't contribute changes to the proprietary testsuite, and writing those is harder than writing the contribution, therefore contributions impose a big tax on the SQLite dev team that they prefer not to pay. Very few other pieces of software have similar universal usage/applicability/convenience stories. Therefore it's not easy to apply the SQLite model to all the things. Sourcegraph could have a business source-available option. If all you want is to be able to be able to debug problems and/or make contributions and you're a paying customer, then why would that not be enough? SQLite is essentially source-available given that you can neither contribute to nor credibly fork it.
mort96 2y ago
Huh in what way does publishing a source tarball alongside a release introduce a lot of work, risk and distraction? Your explanation makes literally no sense EDIT: I implore the downvoters to think about this for a second. You can, actually, publish source code for a project without also committing to providing support and documentation and testing across a variety of systems. Publishing a tarball takes very little time and effort.
- collingreen 2y ago
  Doing a great job on an open source codebase requires a higher level of polish, testing, design, ux, documentation, architecture, and general forethought than internal tools just like any internal vs self serve product. Only solving your own problems on your own hardware while being able to rely on your own well-informed team to bridge the gaps sounds much much faster and easier to me.
  - mort96 2y ago
    Sure but you can publish the source code while only solving your own problems on your own hardware, you're not required to provide support and documentation just to publish source code...
    - jandrewrogers 2y ago
      There is a significant intrinsic cost to making code "open source", through the simple act of making that source code available at all. This overhead exists without any regard for what you wish or promise. It invites myriad interactions that cost time and money for little or no offsetting benefit. Publishing source code, if anyone uses it at all, is not "free" in any sense. I know several people that stopped open sourcing their projects (not even businesses) because the cost of making their code available isn't worth it.
  - yjftsjthsd-h 2y ago
    > Doing a great job on an open source codebase requires a higher level of polish, testing, design, ux, documentation, architecture, and general forethought than internal tools just like any internal vs self serve product. Moving the goalposts to doing a great job internally also requires those things. Meanwhile, doing a perfectly fine job of FOSS requires none of them.
depr 2y ago
I hope code search will one day be offered at a lower price, so small/medium sized companies can use the product. I'll never be able to convince someone to buy it when it's 3 or more time as expensive source code hosting, and would in many cases be most expensive SaaS product per developer seat that the company uses. But it's a great product.
- prepend 2y ago
  I feel the same way. It’s really interesting and provides cool insights. But it seems hard to explain to myself to spend more on that than GitHub or IDEs. I’d like to hear more about the value customers get out of it as I wonder if it’s just groups with unlimited budget.
- 0x1ch 2y ago
  $9 to $20 per seat seems pretty average in the grand scheme of SaaS price modelling. I don't work in software development, but IT however.
  - hk__2 2y ago
    > $9 to $20 per seat seems pretty average in the grand scheme of SaaS price modelling. "SaaS" is not a feature; you can’t compare products just based on the fact thay they are "SaaS". Gitlab for example brings me far more value than a tool to search my codebase; I wouldn’t put the same amount of money in both.
  - morgante 2y ago
    Last time I got a quote it was >$5k minimum to use code search.
  - depr 2y ago
    That is Cody (AI coding assistant). Search is 49 per seat.
- beyang 2y ago
  This is in the cards and thank you for the feedback! (Sourcegraph CTO here)
BaculumMeumEst 2y ago
This thread reminded me to finally try Cody, I've been bouncing on and off Copilot for a few months. I wish I knew how good this was sooner, and I had no idea there was a generous free tier.
- jdorfman 2y ago
  If you (or anyone here) are an open source maintainer, please sign up for free Cody Pro credits https://sourcegraph.com/supporting-open-source https://sourcegraph.com/supporting-open-source
  - BaculumMeumEst 2y ago
    My most popular repo is just barely under the cutoff, but I can't advertise it because I'll doxx my shitpost account! Damn! I'll try to apply anyways ;)
    - jdorfman 2y ago
      Submit it anyway, I'll approve it.
      - BaculumMeumEst 2y ago
        Submission sent! Thanks!
- wesleyyue 2y ago
  If you're open to trying new AI coding assistants, would love if you can give https://double.bot https://double.bot a try! (note: I'm one of the creators) The main philosophical differences is that we are more expensive and are trying to build the best copilot with the technology possible at any given time. For example, we serve a larger, more accurate, and more modern autocomplete model, but it does cost more to serve. We also do a lot of somewhat novel work in getting the details right, like improving the autocomplete model to never screw up closing brackets, and always auto-close them as if you typed them.
cryptonector 2y ago
For business Open source is a business tool. Open source can be a goal, naturally, but for-profit entities have a duty to be profitable (or grow, plowing profits into building). I think there's no shame in saying this. You should not need to be elliptical in your public statements about this move. Everyone knows that this is about protecting your ability to monetize the product, and so it should be, and everyone knows this sort of move comes eventually.
benreesman 2y ago
Your product is really cool. Sometimes it makes sense to iterate in this or that repo. Obligatory: “Victory has defeated you.”
bpmooch 2y ago
> (1) Our super popular public code search is at https://sourcegraph.com/search https://sourcegraph.com/search, which is the same product customers use internally on their own codebases. We spend millions of dollars annually on this public instance with almost 1M OSS repositories to help out everyone using OSS (and we love when they like it so much they bring it into their company :-). If open source wasn't a current marketing fad, you would spend the same amount on other things. You're not doing it because you love open source.
hud_dev 2y ago
| Sourcegraph CEO here. Seems like you need to get back to your job of CEOing and leave the public outreach to the folks whose job it actually is? If you haven't fired them all? Any publicity person worth their salt will tell you: shut up. Don't talk. Leave it to the professionals. You're making everything worse.

by sqs 2y ago

quantumwoke 2y ago

Been a fan of sourcegraph since 2016 or so, it's been exciting to watch the pivots along the way. That being said, the loss of transparency here is pretty sad, speaking as a large FOSS repo owner. What were the main factors apart from risk that went into the decision?

sqs 2y ago
Thanks for being a fan. And I understand it's a bummer to not have our code be public and open-source anymore. Sorry. It's a bunch of reasons that add up. I'll give some more details for anyone curious. (And I know that despite these reasons, lots of HNers probably wish it was not so. I agree! I too wish for a world where all companies could have their code be public and open source.) - We have a lot of tech around large-scale code graph, indexing, etc., stuff that is very differentiated and hard to build. We were starting to put some of this in separate private repositories and link them in at build time, but that was complex. It added a lot of code complexity, risked bugs, and slowed us down, and if a lot of the awesome stuff was private anyway, what was the point? - As we've been building Cody (https://cody.dev https://cody.dev), our code AI tool, we've seen a LOT more abuse. That's what happens when you offer any free tier of a product with LLM inference. We had to move a lot more of our internal backend abuse logic to private repositories, and it added code complexity to incorporate that private stuff in at build time. - It confused devs and customers to have 2 releases: an open-source release with less scaley/enterprisey features, and an enterprise release. It was a pain to migrate from one to the other (GitLab also felt this pain with their product) because the open-source build had a subset of the DB schema and other things. It was confusing to have a free tier on the enterprise release (lots of people got that mixed up with the open-source release), and it made our pricing and packaging complex so that lots of our time was spent helping customers understand what is paid and what isn't. - There were actually very very few companies that were going to pay but then decided to use the open-source version and not pay us. A lot of people probably assume that's why we made this move, but it's not. I think this is because people like the product and see value in it, including all the large-scale code nav/search features that are in our enterprise version. - Although very very few companies used our open-source version to avoid paying us, we did see it cause a lot of annoyance for devs who were asked by their management to try cloning our product or to research our codebase to give their procurement team ammunition to negotiate down our price. This honestly was just a waste of everyone's time. - If we got a ton of contributions (we never really solicited any), then it might've changed the calculus. Sourcegraph is an end-user application that you use at work (and when fun-coding, but the primary revenue model is for us to charge companies). For various reason, end-user server-side applications just don't get nearly as many contributions. Maybe it's because you'd need to redeploy your build for a bunch of other users at your company, not just yourself. Maybe it's because they necessarily entail UX, frontend, and scaling stuff, in addition to just adding new features. - We heard from people who left GitHub that people at GitHub were frequently monitoring our repository to get wind of our upcoming features and launches. Someone from GitHub told me his "job is to clone Sourcegraph". Since then, they obviously deprioritized their code search to re-found GitHub on AI, so we're not seeing this threat anymore. But I didn't love giving Microsoft an unfair advantage, especially since GitHub products are not open source either. - Since we made our code non-open-source, we've been able to pursue a lot more big partnerships (e.g., with cloud providers and other distribution partners and resellers). This is a valuable revenue stream that helps us make a better product overall. Again, because Sourcegraph is an end-user application with a UI that devs constantly use and care about, we never really had the MongoDB/Redis/CockroachDB risk of AWS/GCP/Azure just deploying our stuff and cutting us out. We're not protecting from downside here, but we are enjoying the upside because now those kinds of distribution partnerships are viable for us. To give a specific example, within ~2 months of making our code non-open-source last year, we signed a $1M+ ARR deal through a distribution partner that would not have happened if our code was open source. This is not our biggest annual deal, but it's still really nice! We are totally focused on building the best code search/intelligence and appreciate all our customers and all the feedback here. Hope this helps explain a bit more where we're coming from!
- jsiepkes 2y ago
  > Sourcegraph CEO here. We made our main internal codebase (for our code search product) private. We did this to focus. > There were actually very very few companies that were going to pay but then decided to use the open-source version and not pay us. A lot of people probably assume that's why we made this move, but it's not. > To give a specific example, within ~2 months of making our code non-open-source last year, we signed a $1M+ ARR deal through a distribution partner that would not have happened if our code was open source. So the reason these deals are now possible is mainly because time was freed up by not having the code base opensource?
  - sqs 2y ago
    > So the reason these deals are now possible is mainly because time was freed up by not having the code base opensource? No, it's that if all the code is free and open source for anyone, we would not be able to charge for it and there would be no deals. Even if, say, 60% of our product was open-source and 40% was closed source, we might still get a lot of direct customers but would struggle to do distribution partnerships because the distribution partners have outsized incentives and capacity to reimplement the subset of the 40% they think their market needs.
    - vundercind 2y ago
      I believe the question came up because the original rationale given was “we did this to focus”, not “we couldn’t sell the code for as much if it was open source”.
      - sqs 2y ago
        Both are factors, as I said in my original post (focus and risk).
        vundercind 2y ago
        “We stopped giving away some of our apples due to risk.” “Of… liability? Or… uh, what?” “Oh—risk that we couldn’t sell the apples we gave away, obviously.”

rapnie 2y ago

> (1) Our super popular public code search is at https://sourcegraph.com/search https://sourcegraph.com/search, Correction: Public code on Github. This looks to be restricted to searching Github only.. even though it had "context:global" on the querystring every hit came from Github, and none seen from Gitlab, Codeberg, Sourcehut and other self-hosted forges (e.g. Forgejo).

cqqxo4zV46cp 2y ago
I’m sure there are 50 other ways you could categorise all the code that it searches. Nobody said that it exhaustively searches all available open-source code. I’m sure you know that that’s an impossible claim. This isn’t a correction at all. It is, at best, an elaboration. Certainly not worthy of the snark you’re giving. The reality is that GitHub hosts >99% of all open-source source code that anyone really cares about. If you have some philosophical issue with it, that’s fine, but don’t shoot the messenger by attacking individuals.
- Nullabillity 2y ago
  sqs isn't a random messenger, he's the person in charge of the decision.

breck 2y ago

I think the term the industry needs to embrace is "Early Source": https://breckyunits.com/earlySource.html https://breckyunits.com/earlySource.html Make everything public domain, fully open source, just delayed by N years.

dudeinjapan 2y ago
Will be lovely to have the source N years after AGI terminates humanity.
- breck 2y ago
  Lol. You could write a sci-fi novel with a world of cyborgs where the age of all cyborgs is N (when they first got access to the source). And primitives are called "Pre-Ns"
  - dudeinjapan 2y ago
    Not too shabby an idea!!
ezekg 2y ago
There is a term for this, no? https://opensource.org/dosp https://opensource.org/dosp
- breck 2y ago
  Interesting! I hadn't seen that term. Thanks! I don't like their implementation though. If one thinks from natural principles, one has to reject the idea of licenses on ideas. Early source is in harmony with nature. Also "Early Source" rolls off the tongue better than "Delayed Open Source Publication". ;)
  - yjftsjthsd-h 2y ago
    > Also "Early Source" rolls off the tongue better than "Delayed Open Source Publication". Yeah, but nobody will know what "Early Source" means until you explain it, whereas the latter makes perfect sense on first reading.

cxr 2y ago

Yet another person equivocating the concepts of publishing code under an open source license and managing a project in public.

nearlyepic 2y ago
It has to be disingenuous, right? These concepts aren't complicated. I wish they would just say "we want to make more money" and stop polluting open-source discourse.

a_t48 2y ago

The open/closed decision is a current weight on my mind right now. Our main competition is an open source product - it feels like it will be a tough sell to not also have the core of the product be free (Robotics framework). I might shoot you an email.

sqs 2y ago
Cool! I’d love to chat.

deleted 2y ago

[deleted]

adhamsalama 2y ago

Why not go the SQLite way? Open source but don't accept external contributions. Literally just dump the code.

cryptonector 2y ago
> Open source but don't accept external contributions. That's not the key to the SQLite model. The key to the SQLite model is that their 100% code coverage testsuite is proprietary. You can't credibly fork SQLite3 w/o a similar testsuite because everyone knows that SQLite3 has that testsuite and so it's simply better unless your fork has one too. This works very well for SQLite because it is the single most widely used piece of software ever. And that is because it solves such an important and universal problem (a local DB RDBMS) with such convenience (embedded, server-less). The reason that SQLite does not accept contributions is not so much that they don't want to, but that contributors can't contribute changes to the proprietary testsuite, and writing those is harder than writing the contribution, therefore contributions impose a big tax on the SQLite dev team that they prefer not to pay. Very few other pieces of software have similar universal usage/applicability/convenience stories. Therefore it's not easy to apply the SQLite model to all the things. Sourcegraph could have a business source-available option. If all you want is to be able to be able to debug problems and/or make contributions and you're a paying customer, then why would that not be enough? SQLite is essentially source-available given that you can neither contribute to nor credibly fork it.

mort96 2y ago

Huh in what way does publishing a source tarball alongside a release introduce a lot of work, risk and distraction? Your explanation makes literally no sense EDIT: I implore the downvoters to think about this for a second. You can, actually, publish source code for a project without also committing to providing support and documentation and testing across a variety of systems. Publishing a tarball takes very little time and effort.

collingreen 2y ago
Doing a great job on an open source codebase requires a higher level of polish, testing, design, ux, documentation, architecture, and general forethought than internal tools just like any internal vs self serve product. Only solving your own problems on your own hardware while being able to rely on your own well-informed team to bridge the gaps sounds much much faster and easier to me.
- mort96 2y ago
  Sure but you can publish the source code while only solving your own problems on your own hardware, you're not required to provide support and documentation just to publish source code...
  - jandrewrogers 2y ago
    There is a significant intrinsic cost to making code "open source", through the simple act of making that source code available at all. This overhead exists without any regard for what you wish or promise. It invites myriad interactions that cost time and money for little or no offsetting benefit. Publishing source code, if anyone uses it at all, is not "free" in any sense. I know several people that stopped open sourcing their projects (not even businesses) because the cost of making their code available isn't worth it.
- yjftsjthsd-h 2y ago
  > Doing a great job on an open source codebase requires a higher level of polish, testing, design, ux, documentation, architecture, and general forethought than internal tools just like any internal vs self serve product. Moving the goalposts to doing a great job internally also requires those things. Meanwhile, doing a perfectly fine job of FOSS requires none of them.

depr 2y ago

I hope code search will one day be offered at a lower price, so small/medium sized companies can use the product. I'll never be able to convince someone to buy it when it's 3 or more time as expensive source code hosting, and would in many cases be most expensive SaaS product per developer seat that the company uses. But it's a great product.

prepend 2y ago
I feel the same way. It’s really interesting and provides cool insights. But it seems hard to explain to myself to spend more on that than GitHub or IDEs. I’d like to hear more about the value customers get out of it as I wonder if it’s just groups with unlimited budget.
0x1ch 2y ago
$9 to $20 per seat seems pretty average in the grand scheme of SaaS price modelling. I don't work in software development, but IT however.
- hk__2 2y ago
  > $9 to $20 per seat seems pretty average in the grand scheme of SaaS price modelling. "SaaS" is not a feature; you can’t compare products just based on the fact thay they are "SaaS". Gitlab for example brings me far more value than a tool to search my codebase; I wouldn’t put the same amount of money in both.
- morgante 2y ago
  Last time I got a quote it was >$5k minimum to use code search.
- depr 2y ago
  That is Cody (AI coding assistant). Search is 49 per seat.
beyang 2y ago
This is in the cards and thank you for the feedback! (Sourcegraph CTO here)

BaculumMeumEst 2y ago

This thread reminded me to finally try Cody, I've been bouncing on and off Copilot for a few months. I wish I knew how good this was sooner, and I had no idea there was a generous free tier.

jdorfman 2y ago
If you (or anyone here) are an open source maintainer, please sign up for free Cody Pro credits https://sourcegraph.com/supporting-open-source https://sourcegraph.com/supporting-open-source
- BaculumMeumEst 2y ago
  My most popular repo is just barely under the cutoff, but I can't advertise it because I'll doxx my shitpost account! Damn! I'll try to apply anyways ;)
  - jdorfman 2y ago
    Submit it anyway, I'll approve it.
    - BaculumMeumEst 2y ago
      Submission sent! Thanks!
wesleyyue 2y ago
If you're open to trying new AI coding assistants, would love if you can give https://double.bot https://double.bot a try! (note: I'm one of the creators) The main philosophical differences is that we are more expensive and are trying to build the best copilot with the technology possible at any given time. For example, we serve a larger, more accurate, and more modern autocomplete model, but it does cost more to serve. We also do a lot of somewhat novel work in getting the details right, like improving the autocomplete model to never screw up closing brackets, and always auto-close them as if you typed them.

cryptonector 2y ago

For business Open source is a business tool. Open source can be a goal, naturally, but for-profit entities have a duty to be profitable (or grow, plowing profits into building). I think there's no shame in saying this. You should not need to be elliptical in your public statements about this move. Everyone knows that this is about protecting your ability to monetize the product, and so it should be, and everyone knows this sort of move comes eventually.

benreesman 2y ago

Your product is really cool. Sometimes it makes sense to iterate in this or that repo. Obligatory: “Victory has defeated you.”

bpmooch 2y ago

> (1) Our super popular public code search is at https://sourcegraph.com/search https://sourcegraph.com/search, which is the same product customers use internally on their own codebases. We spend millions of dollars annually on this public instance with almost 1M OSS repositories to help out everyone using OSS (and we love when they like it so much they bring it into their company :-). If open source wasn't a current marketing fad, you would spend the same amount on other things. You're not doing it because you love open source.

hud_dev 2y ago

| Sourcegraph CEO here. Seems like you need to get back to your job of CEOing and leave the public outreach to the folks whose job it actually is? If you haven't fired them all? Any publicity person worth their salt will tell you: shut up. Don't talk. Leave it to the professionals. You're making everything worse.