Sourcegraph went dark

(eric-fritz.com)

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]▶

>>41298641 #

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]▶

>>41300159 #

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. yjftsjthsd-h ◴[20 Aug 24 15:09 UTC] No.41300775[source]▶

>>41300233 #

> 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.

replies(1): >>41304219 #

2. collingreen ◴[20 Aug 24 21:22 UTC] No.41304219[source]▶

>>41300775 (TP) #

I completely disagree - internal tools and high usage, open source, public tools used as marketing serve vastly different purposes and require vastly different workflows. Doing a great job for internal tools can leverage other internal processes, training, access control, implicit understanding, documentation, and aligned workflows. Many issues and bugs can be avoided or papered over and major changes can be forced onto users if necessary because of a shared understanding and a direct communication channels.

A great public codebase likely needs to be more understandable, more generic, more self guided, more error proof, more auditable, and more pluggable. Additionally, supporting popular open source at all comes with a deluge of requests, demands, audits, and obligations.

I expect these two converge as your "internal" consumer base grows big enough but for a small, cohesive team an internal-only codebase seems to me like a much much easier beast to tame.

replies(1): >>41308039 #

3. mort96 ◴[21 Aug 24 08:22 UTC] No.41308039[source]▶

>>41304219 #

> A great public codebase likely needs to be more understandable, more generic, more self guided, more error proof, more auditable, and more pluggable. Additionally, supporting popular open source at all comes with a deluge of requests, demands, audits, and obligations.

Literally none of that is necessary to publish a source code tarball. You keep moving goalposts. You don't need heavy community involvement and support self-hosting and all that just to publish your source code.

I mean feature requests will come, sure, but people working with closed source software receive those too.

replies(1): >>41311049 #

4. collingreen ◴[21 Aug 24 15:07 UTC] No.41311049{3}[source]▶

>>41308039 #

Maybe you're moving the goalposts - the OP took down their very popular, high use open source project that they use as a metering tool because the overhead was too high. My impression from the post and all the comments from the ceo and cto is that they are unwilling to just throw code over the fence without putting enough care into it to make sure it works well and reflects positively on them.

Yes, obviously, it is essentially no effort to just tar a folder and put it on the internet if you do literally nothing else and don't care at all what happens next.

replies(1): >>41314122 #

5. mort96 ◴[21 Aug 24 20:55 UTC] No.41314122{4}[source]▶

>>41311049 #

I'm literally only saying that they didn't need to closed-source it, it's not all or nothing. That's my entire point. I know that maintaining an open source project the way they were doing is a lot of work, but if they want to stop doing that work, they have other choices than "make it closed source".

replies(1): >>41316918 #

6. collingreen ◴[22 Aug 24 04:49 UTC] No.41316918{5}[source]▶

>>41314122 #

That's true!

↑