Compelling reasons to open-source internal service of a highly recognized brand by just dumping the sources?

Question

Assume you are considering open-sourcing a large service of your internal enterprise infrastructure. Let's say you have the resources required to ensure the minimal requirements are met: the licenses are sorted out, profanities removed, security audits conducted and all known security vulnerabilities fixed. Assume your company doing the open-sourcing has a very recognized and valued global brand.

Does it make sense to open-source such service by just dumping the files? I am assuming here it won't even be possible to run the service as-is, because it will have dependencies on other, not open-sourced systems.

If not, what would be the minimal effort required to make open-sourcing worthwhile?

Related questions:
Reasons NOT to open source not-for-profit code?
The reason to make some code open source
Is it OK to push my code to GitHub while it is still in early development?
Checklist for starting an open-source project

Answer 1

The "minimum requirements" for open sourcing some code depend primarily on why your company plans to publish it, and secondarily on what it is.

First, sometimes this kind of "code dump" actually makes sense. Specifically, if you are obligated to open source something to satisfy customers, partners, and/or a government, but you don't otherwise care about the code. This could include terms of an intercompany agreement, plans to abandon an otherwise-popular product, or regulatory compliance.

If that's not your motivation, then the situation you described falls below the threshold of minimum worthwhile results. Let's assume that the code is being open-sourced in order to create a userbase for it ("community", by some minimal definition). That would require, at a minimum, three of the six requirements below:

1. Existing popularity or marketing to create popularity
2. Adequate user documentation
3. Adequate code/developer documentation
4. Current code runnable as a "Minimum viable product"
5. Appropriate licensing
6. A present and responsive engineering team.

So, for example, a project with runnable code and a highly responsive engineering team that is liberally licensed is minimally viable even though it has no documentation. Alternately, a well-documented and highly-publicized project whose code doesn't currently run will also be minimally viable. In either case, there's a decent chance of attracting volunteers to fix the bugs/docs.

Your question suggests that you would have only (5) and maybe (1), and the project would fail on documentation, runnability, and involvement of existing staff. This is not minimally viable. The fact that it's for a well-known company makes it worse; the project would be visibly deficient and thus hurt the company's brand.