Welcome, everybody. I'm Johannes, working for Postman at the moment. And when I'm not on stage at Moulin Rouge, which actually happened, I was randomly picked out of the audience. I'm spending most of my time with developer platforms.

So first with SourceForge. Hands up if you still remember SourceForge. Everybody does. Cool. Then Garrett, then most of my time, GitHub, and nowadays Postman, the GitHub for APIs. And during that time, I was privileged to work with many, many different companies

on collecting feedback on how to do InnerSource and OpenSource. This is by no means any sales pitch, so don't be afraid. It's not about those unicorns and rainbows. It's really about OpenSource comments. InnerSource comments, actually.

And I still struggle a bit. Well, what is InnerSource about? Well, it's basically applying the practices of OpenSource for commercial software development. And why would you actually want to do that? Well, I don't have to preach to the choir, right? If I have to convince you about the benefits of OpenSource, that would be like telling you why water is liquid.

But for those folks who, like in rich talk, wanted to know what InnerSource is about, for companies, it's mostly about having great recruitment abilities, keep your developers happy, ship faster to your markets, have the same shipping

velocity that you have in distributed teams, and have a high quality. And the question is, how can you achieve that? In an InnerSource project, the idea is to be as transparent as possible, find all of your code or APIs immediately, have also access to the issue trackers and find out where the roadmap is going,

be able to collaborate and also accept contributions outside of your ordinary team, right? Including that with a CI and CD processes so that when you get a contribution, you already know it, it already satisfies the certain quality criteria before you actually have to spend time investing into a human code review.

The question now is, is there any difference when it comes to APIs and those InnerSource practices as opposed to code? Because most of those challenges or findings also of InnerSource comments are specifically about source code. And during those workshops, we figured out there's quite some differences, not too many,

but one is about discoverability of APIs, like searching for them. Searching open API specification, for instance, is no fun. It's typically lots and lots of YAML code. And also, if there's any changes you want to propose, it's difficult to find out what has actually changed. Like if you added some security protocol to it,

it can easily be 2,000 lines of changes in your API specification. Nobody wants to review that. Everybody wants just to know whether this is breaking backward compatibility. Backward compatibility is really important for APIs. It's also important that you can actually test out APIs

when you want to contribute to those projects. For most open source projects or InnerSource project, if it's code, you can just start it up and play with it. For APIs, it's often just the contract. In many cases, you don't have access to the back end. So in this case, you would need a way to play around with it, get feedback. And then last but not least, one challenge is,

what actually does it mean to use an API? For source code, you can often just scan package dependencies. There's SBOMs as some very mature way of finding out what packages you depend upon when it's about APIs. It could be just that you're calling a certain API and you won't find any import statement in your code.

So last challenge there is to keep things in sync between API code specification and the actual implementation. The good thing in my last minute is most of those technical problems have been solved. There's tools like Optics, GitHub, Postman

to work around all of those technical challenges. But the main challenges about InnerSource and APIs is still cultural things like Rich mentioned, like Wolfgang mentioned today. It's mostly about cultivating the pride, having upper management understand

that this is not just about wild west and contributing to whatever you want, but actually helping your companies as well. It's a broad topic. What's in for you? I hope that during the gathering afterwards, the get together, we can talk about the API specific and thanks for your time.