|
This was an very solid breakdown. If I may lend some color: (disclaimer: I'm part of a team doing architectural design of new SDKs at MS, and am somewhat proud that we're actually Trying To Get Outside Involvement, so willing to hold that up here, all thoughts and opinions are only my own.) To your points about "api-level" and "open source", in my end of the world I have the rare opportunity to share "Real world examples" of how we do architectural design, as we're extremely open with that process/do an increasing amount on github. @Op, feel free to take a peek if it'd be useful, we try to do enough of our discussions in issues/PRs (tagged per product) that you may be able to get a sense. [0] The parent's comment certainly covered the bulk of my bigCo experiences, but I'd be remiss to not give examples of the niches where more of this does happen; as we also tend to cover many of the questions OP asked (guidelines on tech and arch choices, documentation, alignment and freedoms, etc) The downsides may also be apparent from this example, especially to anyone who has been an open source participant: Many cooks in the kitchen, many competing interests, and many often conflicting idioms. While these are in some part specific to shared API architecture over e.g. system architecture, I do find they take the same broad shape (largely incentive/stakeholder based) as the compromises we make broadly, but indexing far higher on backcompat, consistency, and alignment. [0] https://github.com/Azure/azure-sdk-for-net/tree/master/sdk |