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.

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

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.

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

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.

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

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.

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

That's true!