Most likely support. GH probably doesn’t want to support an open source version (triaging issues, reviewing 3rd party pull requests, having an open roadmap). Likewise it would probably be bad PR if they just dumped the code base and were really slow (or didn’t) respond to bug reports.
Being open source requires a lot more than just the source code being available.
I'm not trying to be mean or sarcastic or anything. Just look at how maintainers are treated for a week and you'll see exactly what I mean.
Just because something is open source, does not mean you have to engage with the "community". Slapping GPL on some code on a git repo somewhere, with a big sign saying if you don't like it you have the right to fork, so please fork off, is also open source, and a totally ok thing to do if you don't want to develop a community [Open source maintainers don't owe the world anything beyond what they freely want to give it]
The GitHub way of working has only been around since GitHub launched. Accordingly, the free software and open source communities that predate GitHub had their own ways of working before GitHub came along. Despite the widespread perception that GitHub makes doing open source easy, it comprises a set of practices that can be and are frequently more taxing than the alternatives. If GitHub is all you know, though, or you've forgotten, or you've just not noticed and never measured it, then it's easy to think that the GutHub way embodies the essentials of development in the open, even though its workflows are pretty bloated.
Well, you don't necessarily have to do those things. See for instance Apple's XNU Kernel. :)
Well, "maximum engineering secrecy" would be not releasing the source code to XNU. Apple is very secretive overall, to be sure, but not in this one respect.
I'm glad that XNU's source code is available—it lets you do a number of neat things. I wish more was available, but I'll take what we can get.
By extension, I don't support the idea that there's no point in releasing source code if you can't also release documentation and review outside pull requests. Making a tool available to the public is always better than hoarding information. All the other stuff is even better, but code is code.
---
All of that said, I recognize that for Github specifically, releasing code and not engaging with it might be a bad look, because their product is a code sharing platform. I don't think that applies to most companies, though.
