The worst engineering behavior I've found is when development teams are not accountable for their code quality. Just a group of people developing in isolation, with code that will be never seen by anyone else. Then the code base becomes a ponzi scheme of technical debt, where a hierarchy of power is built by forcing other people to refactor lousy code.
I think auditing code for bad practices, beyond code review, is something done regularly for open source projects but very rarely on proprietary software.
Auditing, beyond code review, is key to code quality. Also, making people KNOW their code will be read at any moment by any person gives lousy developers a sense of vulnerability and a call to action to act as real engineers.
I think a lot of people could save time and money by everyone pooling efforts to build business tools that we all need.
It also takes us back to the roots of software development. Buy programmers, not software.
I certainly didn't get the impression that what they're producing is actually OSS.
Its quite possible to share your source code with your client, who runs it, completely openly. In fact, this is a successful model for countless decades in certain software markets, as well as a standard model of behavior, in general, in software industry.
The way it worked is, you're a programmer->you write source code->the business paying you to write source code builds your code->they run it->customer.
However, this facet, like all other facets in the big gem of our forever-changing industry, is not as prevalent in certain software markets - for example, web&etc. There are still plenty of software developers who are in fact sharing the source - directly with their customers. As per any one of a scale of licenses.
tl;dr - please don't conflate 'open source' with 'F/OSS', et al. If your customer owns the sources, you've opened your sources to them. This is a scale, not absolute, as other ends of the scale include closed-source business models.
What you're describing sounds more like https://en.wikipedia.org/wiki/Shared_source.
In my experience (mostly small business) there's a certain expectation that developers will work in isolation—where clients aren't expecting any involvement beyond the initial planning stages.