Platform Engineering Maturity Model: is InnerSource part of 'Level 4, Optimizing — Enabled ecosystem'

[jkleinlercher]

Hi, first of all I am very thankful for the platform maturity model! Great work! When we applied an innersource model, where people outside of the platform team can contribute to the platform, is this already then a part of "level 4 - enabled ecosystem" or is this still leve 3? what do you think?

[abangser]

Very cool question @jkleinlercher! I have posted into the WG Slack here asking for more input as well!

To kick off, what you may notices is that none of the levels are named with implementations (or hopefully they aren't!). This is in part to make sure that the levels have better durability over time, but also because an implementation term can mean different things to different people.

With that in mind, I think that it is a fair question to ask inner sourcing indicates level 4 or something lower on the investment aspect. IMHO the devil is in the details on that. When I look at the description of level 4 for investment I see:

These core maintainers are focused on enabling capability specialists to seamlessly integrate their requirements and offerings into existing and new parts of platforms. Further, the organization focuses people and resources from specialist domains like security, performance, quality on engaging with provided platform frameworks to introduce advanced features that can enable product teams to accelerate their adherence to company goals without depending on a centralized team backlog.

This "focus on" the "enablement" of others is what makes this optimising. I have seen inner sourcing at its worst that may even fit more at level 1 with the following description:

These capabilities are built and maintained out of necessity rather than planned and intentionally funded.

These capabilities are built and maintained by people assigned temporarily or voluntarily; no central funding or staffing are intentionally allocated to them. They depend on the current tactical requirements of their users.

As in, people can commit code to repositories but there is no clear ownership nor structure around it.

I am by no means suggesting your company is operating in this version of inner sourcing, but I am using that to indicate that IMO the technique used (in this case inner sourcing) can't immediately set a level. So I would ask you a few more questions to maybe help you self select. I would ask:

• Are people allowed to release beta type versions without significant gates to enable early adoption before maturity is needed?
• How diverse and extensive is the community engaging in inner sourcing?
• Does making a contribution in one area of the platform inherently improve the likelihood that someone could contribute to another area without reskilling/learning how to do so?
• If someone contributes something that would be counter to the platform roadmap how is this handled?

These may help you decide if you are inner sourcing as a sort of OSS code base that is single team governed, or if it is an ecosystem with more distributed ownership.

Last note I will make, when I ask these questions I don't do degrade one experience version another. In some organisations/industries an ecosystem isn't the right solution and that is why we all advocate quite strongly that this is not a ladder to climb as much as a model to review.

[menzenski]

In one sense I think that

we applied an innersource model, where people outside of the platform team can contribute to the platform

maps pretty directly onto the "participatory" adoption stage .

One way I would personally summarize the "adoption" stages is:

• Stage 1 - people use the platform erratically (people might not even know about it)
• Stage 2 - people use the platform because they have to / because there are top-down incentives to use it
• Stage 3 - people use the platform because they choose to
• Stage 4 - people not only use the platform, but contribute to it

And in that summary the innersource model you mention feels squarely in Stage 4.

However, I agree with @abangser that there's always a lot of iceberg under the surface when trying to map a specific organization or specific set of practices onto a general model like this one.

I'm referencing the "adoption" aspect here, rather than the "investment" aspect that you and @abangser reference. I think the "adoption" and "investment" aspects can generally be framed as "bottom-up" and "top-down", respectively, and I tend to view innersource models as "bottom-up", where people may choose to contribute to the organizaton's codebases but don't "have to" do so. So I go to "adoption" vs "investment" in that sense.

I'll echo Abby's questions, and especially this one:

if you are inner sourcing as a sort of OSS code base that is single team governed, or if it is an ecosystem with more distributed ownership

That, to me, is maybe the most important element of this - the relationship between the platform team and the other teams that make contributions to the platform. Does the platform team see themselves (and does the organization see them) as "owners" of the platform, who accept occasional contributions from non-owners? Or do they see themselves more like "stewards" of a robust and sustaining ecosystem, where (potentially) the people outside the platform team are the "owners"?

[puja108]

Very much agree that "innersourcing" would be rather adoption category (or you could argue it also has some role in interface) and I'd add to that, that the maturity level especially in adoption depends not just on the fact that sth, here contribution, is available, it depends on if it's widely used. This is something that can then be measured and analyzed and if wanted be acted upon.

However, as Abby also mentioned these are not black and white good or bad. Continuing with contribution rate: It might be that contribution rate of single digit percentage of users is fully fine as long as your org is happy with it. One needs to also always look at the bigger picture, e.g. are people contributing because they are unhappy with how fast the platform team delivers and they feel blocked then high contribution rate might actually be an indicator that sth is wrong, or are they just super motivated and happy to work in the community and this does not distract them from their job then it is rather a good sign of adoption. Same measurement, very different story 😉 which is why some qualitative data next to quantitative sources is super important.

[abangser]

These are awesome points to bring in adoption.

I am curious @jkleinlercher, I would be keen to hear how these responses resonate with your experience / context? One of the things we most want to learn in this first phase post maturity model release is how it is being applied so this is the type of conversation I think everyone is excited to engage in!

[earth2marsh]

I've been playing with a GPT called Platform Gardening whose knowledge includes the platform maturity model and whitepaper. I thought it might be interesting to ask your question, and here was its response:

In the context of the Platform Engineering Maturity Model, incorporating an "innersource" model, where people outside of the platform team can contribute to the platform, aligns most closely with "Level 4 - Enabled Ecosystem" of the Adoption aspect.

Here's why:

1. Participatory Ecosystem: Level 4 in the Adoption aspect is characterized by a participatory ecosystem where users from product teams contribute back to the platform. This participation is not just in terms of feedback but also in terms of actual contributions, like improving existing capabilities or introducing new ones. This is a core principle of the innersource approach.
2. Empowering Users to Contribute: Innersource is about empowering all users to contribute, similar to how open source projects operate. This matches with the Level 4 idea where the platform is not just a service provided by a central team but a collaborative ecosystem that includes contributions from across the organization.
3. Beyond Just Adoption: Level 3 focuses more on intrinsic motivation for using the platform - where users are drawn to the platform due to its value in reducing cognitive load and providing high-quality services. While this level may include some degree of feedback and minor contributions from users, it doesn't necessarily imply a robust, active contribution model that is central to innersourcing.
4. Strategic Extension of the Platform: At Level 4, the platform is seen as a strategic asset that evolves through contributions from a broad range of stakeholders, aligning well with the innersource philosophy of open, collaborative development across organizational boundaries.

In summary, adopting an innersource model for your platform aligns with achieving a Level 4 - Enabled Ecosystem in the Adoption aspect of the Platform Engineering Maturity Model. It's about creating a participatory and collaborative environment where contributions to the platform are not just welcomed but actively encouraged from across the organization.

I think that is a decent application of the principles of the maturity model, and it echoes some of of Matt's points above.

My personal take is slightly different... It seems to me that innersourcing is an aspect of development culture that seems mostly independent of your platform approach. However, if the goal is to invite participation of teams into the building of your platform, then innersourcing might be a strategy you could pioneer here (if you weren't doing it already).

In other words, I think these things are complementary. Innersourcing is not necessarily a requirement of L4, though it may be a great stage to consider introducing it as an internal practice.

[abangser]

This issues has a lot of really great points and powerful voices. Is there anyone here who has the interest and vision for how to capture this in something we could publish as a blog? 💭

Just to say, this is not a suggestion that the discussion needs to be done here, more so that I would love to see this continued and offering an opportunity to make it available more widely if people have an interest!

[puja108]

That's a good idea. I'd be up for a blog post and open to colab on obe if someone else from this thread likes to join up.

[abangser]

Awesome! 🎉🎉

My suggestion would be to create a Google doc with global comment permissions and add collaborators as editors if/when they want to join.

You can share the doc here and then as it solidifies and is ready for posting it can become a PR.

[abangser]

In trying to get alignment on current WG priorities, I am going to suggest we close this topic. But before doing so, I want to give 1 week for anyone who is interested to revive the focus on this, else we can reopen in the future when we have the right people/energies to commit to this topic (or create an associated blog post).

Thanks!

[abangser]

Per my last message, I am closing for now but am happy to reopen this conversation if it becomes higher priority / has a sponsor to drive it!