InnerSource @ BBC

The BBC is no foreigner to the InnerSource Commons, with some contributions to our patterns already.

This article (03/2022) highlights various collaboration challenges, and how the BBC overcame them. While they don't use the term "InnerSource", it certainly sounds like that model is at play here.

Some ideas for possible pattern connections:

• technology standardization

  • "Standardising onto a single technology set, building shared ‘horizontal’ capabilities, and sharing commodity components between teams".
  • Their Core Services team was building out the WebCore platform. They were presumably inviting other teams to start using the platform. What experience did they make in enable InnerSource contributions to the WebCore platform itself? And what effect did the technology standardization have here?
  • they also mention Golden path tooling: "used to accelerate teams and keep them within the guardrails of the known-good path"

• Inversion of Control

  • "When a product development team is used to owning and controlling its entire technology stack, moving to a situation where they are dependent on others can be uncomfortable. However, from operating systems to frameworks, no team writes everything from scratch."
  • "Bringing back the sense of control is important — and this is where maturing the platform to provide tenants with self-service interfaces and tooling is central."
  • making the platform self-service: "This may mean providing tenant teams with controls — configuration, tooling, user interfaces etc. — but it may also mean agreeing and enforcing certain standards."
  • Question: I am not reading enough detail here to actually understand what they mean. Is this about making the WebCore platform as much a self-service offering as say AWS? And why is that called Inversion of Control?

• Collaboration models between platform and tenant teams

  • the collaboration models between platform teams and tenant teams changed as the WebCore platform was maturing
  • Collaboration => Co-operation/Facilitation => Systemization
  • mentioned in the context of team topologies
  • I think they even call these "collaboration patterns". at least the word "pattern" us used once. not to be confused with our InnerSource patterns in this repo :)

• allow for "just enough" duplication

  • The answer has been to develop a more pragmatic mindset towards technical debt — developing tools to manage it while accepting that aiming for zero debt is not cost-effective.
  • Just like financial debt, technical debt is not always a bad thing. Debt becomes a problem if it is not tracked, becomes too large or if debtors cannot be held accountable.
  • Question: How to make this trackable in a helpful way?

• TODO

  • review the "Lessons learned" section one more time.

Note:
Besides extracting patterns from BBC's experience, we could also invite them to one of our Community Calls. With the article above as required reading ;)

まず、リンクされたBBCの記事を読み、WebCore、platform-team、tenant-team、technical debtに関する説明を、issue内でリンクされている既存のパターンと比較してください。「Lessons learned」セクションを確認し、どのパターン間のつながりが裏付けられているかを整理したうえで、導かれたInnerSourceパターンまたはフォローアップの質問を文書化してください。提案されているCommunity Callへの招待は、別の成果として扱ってください。