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!