←back to thread

Sourcegraph went dark

(eric-fritz.com)
424 points kaycebasques | 2 comments | 20 Aug 24 03:30 UTC | HN request time: 0.426s | 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 #
mort96 ◴[20 Aug 24 14:00 UTC] No.41300159[source]▶
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.

replies(1): >>41300233 #
collingreen ◴[20 Aug 24 14:09 UTC] No.41300233[source]▶
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.

replies(2): >>41300561 #>>41300775 #
1. mort96 ◴[20 Aug 24 14:45 UTC] No.41300561[source]▶
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...
replies(1): >>41300849 #
2. jandrewrogers ◴[20 Aug 24 15:19 UTC] No.41300849[source]▶
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.