I'm nearing 6,000 contributions on GitHub. I mix personal and private contributions but I estimate a large portion of of the changes are from work. This is up from about 1,700 contributions back in 2018. Not all valuable contributions to a tech business are GitHub related; people write documentation, sketch out strategic plans for the business, spend time researching technical details, design user experiences, analyze user data for purposes of sales and marketing, and so on. All of these things don't wind up being issues, pull-requests, code review, or direct commits into a codebase and yet nonetheless help keep the company move forward.
Nonetheless, a tech company has healthy codebase(s) when there is a fervor of activity. Likewise, if your codebase(s) are highly active they may suffer a lot of churn, where changes that are introduced are swiftly eased back out only to be re-introduced again in rapid cycle. The true mark of health on codebase(s) is a mark of steady progress despite the occasional setback. Sure, stable systems do exist where activity is but the occasional patch but when something is deemed stable can vary drastically depending on the complexity of the project and the requirements that steer its growth.
Giving ownership away can be scary. What if we render control to members of the team and all we get in return is a product running in circles? What if nothing of value gets built and the product stagnates and rots?
Top down management makes sense in a factory setting; if you have a large room full of people manually slaving away building widgets, you can treat them and their process much like a chariot driver and its steeds; whip and hurl insults at will and the workers will move faster. There is enough generality to optimizing assembly lines that the illusion of optimizing all forms of business or systems are alike. Wrong. This management by microscope devolves into micromanagement and creative output can't be managed in the same way. Jobs that require a lot of thought in addition to output require a more hands-off approach to achieve excellent results. Optimizing for output for creative output means giving away the keys.
You can't create an illusion of ownership, either. Managers sometimes think they can retain authority over decisions on a project while paying lip-service to 'owners'. This is a recipe for disaster when the truth is unveiled. Allowing others to own systems (or projects) or subsections of systems (or projects) allows them to thrive. Ownership leads one towards home making where members focus on the pursuit of an ideal lifestyle and surroundings.
A product rarely has a single project as a neighborhood rarely has a single home. Imagine a partially isolated village with inhabits of various skills; for the village to prosper everyone has to have a certain level of interdependence for their survival and happiness.
And here's the rub, owners of projects put demands on other owners, without expecting some central authority to put the demands on them instead. The sign of ownership is peer pressure. Work gets queued up and prioritized in manageable pools. All of our goals needed to be aligned to the business, sure, but it is up to these owners to figure out how to best accomplish that goal within reason. A central authority can still keep watch that things are on theme. People can still move across a system and do changes where they need to with respect to owners of the system the proposed changes are occurring. Ownership imbues a sense of care on all parties. If no one owns anything, then everyone will do as they please with little regard to 2nd or 3rd order consequences.
If you can't start fresh with respective owners at the get-go, try starting small and handing out keys to smaller chunks of the larger system. You need trust to make this work otherwise you'll wind up with a self-fulfilling prophecy. The experiment will change you and your teams for the better.