Sounds like you were working at a terrible organisation, not that there is anything wrong with running a platform team. Teams with stressful deadlines, having to involve VIPs or architects at the org to make decisions rather than giving teams autonomy to make their own decisions.
Not sure I'd like to use a platform with a code base that has the whole organisation contributing to it. Sounds like a design-by-committee dumpster fire. Teams need ownership of their product to perform effectively. You can claim that this is collective ownership of the platform, but in reality no one will feel any responsibility for the platform when things don't work or don't align entirely with the particular thing they are currently working on.
And have you ever looked at the source code for most open source software? It's an absolute mess that requires the collective effort of large numbers of people to keep it going. It works, but it's not exactly a good or effective model for internal software.
I don't think the org is/was dysfunctional. Tight deadlines are a reality of certain business sectors, especially when selling big expensive B2B software, where you have to sell something in your customers' budget windows or lose the opportunity. And I don't see how a platform team could be empowered to decide on its own which of two competing business goals, from two separate business groups, to pursue, and which to postpone for months.
Related to collective dev/ownership, that is a risk, I absolutely agree. That is going to be the hardest part for sure, maintaining a uniform standard and a high bar for contributions to a common platform.
Finally, I believe the general opinion is that open-source software is higher quality and especially has higher code quality than internal company software. I can't say I studied any directly comparable open-source projects VS our internal tools, but code quality definitely varies significantly between our own internal projects, with some extremely clean and well written, while others are messes of hasty bug fixes and accumulated tech debt.
What kind of services did you push to the platform team? If product teams need to wait for the platform team to deliver on some features then it doesn’t sound like a platform team.
A platform team is there to consolidate tooling and provide services that enable product teams to move faster.
Think of it as an internal AWS. In small companies AWS is the platform team. If you’re talking about an upstream service that your product team depends on, it’s just an internal product team that’s understaffed. Or poor organization if your product team’s domain has been split up into two teams arbitrarily based on e.g. managerial politics or front end/backend division.
The platform team was developing the core framework that a few applications ran on. At one point this was either a C#-based GUI framework for Windows apps, extending WinForms and later WPF with various business-area specific controls (e.g. network topologies, protocol stacks etc.) and various communication frameworks to talk to some shared embedded hardware or to do cross-product integrations. At other times it was a Java based web framework to help move these Windows apps to the cross-platform world of VM HTTP servers, handling things like authorization in a unified way, apart from some of the same concerns as the original C#.
The products using the shared frameworks had slightly different histories and were mostly addressed to different market segments with different conventions, but still neede plenty of common scaffolding that a platform provided. A common platform team seemed to be a natural fit, and to a great extent in worked, but the problems I was discussing earlier were also pretty constant throughout its lifetime.
Not sure I'd like to use a platform with a code base that has the whole organisation contributing to it. Sounds like a design-by-committee dumpster fire. Teams need ownership of their product to perform effectively. You can claim that this is collective ownership of the platform, but in reality no one will feel any responsibility for the platform when things don't work or don't align entirely with the particular thing they are currently working on.
And have you ever looked at the source code for most open source software? It's an absolute mess that requires the collective effort of large numbers of people to keep it going. It works, but it's not exactly a good or effective model for internal software.