←back to thread

Sourcegraph went dark

(eric-fritz.com)
424 points kaycebasques | 2 comments | 20 Aug 24 03:30 UTC | HN request time: 0.423s | source
Show context
sqs ◴[20 Aug 24 10:28 UTC] No.41298641[source]▶
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, 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 (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.

replies(14): >>41298707 #>>41299099 #>>41299575 #>>41299592 #>>41299724 #>>41299784 #>>41299956 #>>41300159 #>>41300346 #>>41300771 #>>41301859 #>>41305881 #>>41311564 #>>41312895 #
1. adhamsalama ◴[20 Aug 24 13:37 UTC] No.41299956[source]▶
Why not go the SQLite way? Open source but don't accept external contributions. Literally just dump the code.
replies(1): >>41302757 #
2. cryptonector ◴[20 Aug 24 18:45 UTC] No.41302757[source]▶
> 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.