 Hello, welcome to my talk today, the importance of non-code contributions to code-centric open source projects. So my name is Masse Kossmann. I'm employed at Bosch IO. So Bosch IO, this is the spare hat of the internet of things, Bosch. So we try to connect everything, primarily the things that we produce at Bosch. Within Bosch IO, I'm working in the open source services section, and there especially I care about the open source office. And also in this case, I came to this topic, I will talk today. Apparently I'm also part of the open chain. I'm representing Bosch as a governing in the governing board. And so I also have part of my heart in the open chain, and you will see later also some advertisement for this community. So from my company, we have an open source strategy based on our IoT platform that we're heavily promoting in the Eclipse IoT. And with this, you potentially know these presentations with the maturities of open source involvement. So you start with usage going via contribution and then final champion. And once you did this, then you can really drive your business with it. And that's what we try. And therefore from an open source office perspective, we had the pleasure to accompany this over the last years within Bosch IO. And so what we thought then a few years ago, if our developers, if our business is doing it, so we should also eat our own dog food. So you can see my talk two years ago in the open source summit, when I talked about leveraging open source projects for open source management. And today I want to present you now that we are some steps further away now. And also with the open source management. So there had happened some now in the last years. And also from the processes that we use, here we have a specific, we developed a specific perspective. So this is the highest level of our process landscape that we use for open source management. So we see there typically those four process areas that are in there. And the talk today is primarily about open source usage and handling. So I talk about non-code contributions and we in code-centric projects, open source projects. And here this is kind of obvious if we use them and we miss some parts in it that is primarily affected in the usage and handling. But there are also some implications in the contribution and also in the community management that we see in here. And to start with here, I have some personal experience I had when I went to my workshop and because I had inherited some tools in the family and they are made this picture here. And I want to point out some of those aspects in here that I would transfer later. So I saw this really beautiful tool that I have now and it's very sophisticated. And yeah, but the problem I see here for me at least I have no clue how to use it. So I inherited the tool but there was no manual or something or and also couldn't ask them on how to use it. But well, it's looking nice and well, I tried my best. But potentially I've crashed it, I don't know. But at least I had to pass some time with this tool. And then I also asked myself as the second aspect, so well, the craftsman who did this was obviously very gifted. It has nice smooth surfaces and it's very well done. But if I would get the manual from this craftsman, I don't know if he would have written it while in the same quality then he did this brilliant woodwork. And if you transfer this now to the software here that we talk about today and open source software projects, I see some parallels in this and also for transferring this here. So typically we observe software developers that really have fun to code and also in the open source, they have their heart in the open source in the community and they're, yeah, they concentrate on the code. So therefore I also call this talk, yeah, importance of non-code contributions to code-centric open source projects. On the other hand, I observe also that while they have a lot of also the features, new features adding new features, so they potentially primarily implement functional requirements. On the other hand, if you look at non-code contents, what could that be? So for example, tests, documentation, installation guides for users, and most important from our point of view, it's SD open source office, also the licensing stuff and also the third party dependencies and their licenses. And if you step back and look at it, so you would say, okay, yeah, this is the upper part is the fun for the developer, but this part is potentially not so funny. It's rather boring. And yeah, on the other hand, these represent typically the non-functional requirements. So if you have good documentation, you have a nice user convenience. If you have all the installation guides and that's what I meant earlier, then you have a community attractiveness so you can really build your community around it and they will welcome your tool and your software. And last but not least, also the transparency about what's in there and also the licensing for compliance reasons. And so now there's where this transfer doesn't really work is with the tool that you saw earlier, this is a one by one. So it's typically you go to the vendor, you get this tool, you buy it or whatever and you get handed over. So we will not have the situation, the context like we have here with software that's spread all over the world by open source. So in this case, if you have a really cool application or tool, it might be heavily reused. And then if there are missing things in there, missing non-code contents, missing non-functional requirements, then that could have a much higher impact. So now also going through this only code side, what we observe is how do you handle if you have a defect, if you detect a defect. So the typical thing that we observe is, okay, there's a defect, let's fix it. And there are two ways. On the one side you have, if you are in an organization and I am in a business organization who provides also contribution possibilities, but sometimes you don't have that. And what would happen, you want to use open source component and you potentially find a bug or a missing feature. So what would you do? You would modify it to fix the bug or add this new feature. If you have a very vital community, so they are producing next versions of the tool and every time they produce a new version with new features and potentially also secured, purchased and so on, and you might be interested also to participate in these new improvements, then you would have the need to merge your modifications with the bug or the missing feature every time they do it. So you always have a lot of effort in maintaining this internal approach branch. As an alternative, if you are able to contribute, if your organization has that open source fitness that you can do this, so that's much easier because then you have your modification and you contribute it back. And if the pullover grass is accepted, then you're fine. Then because the upstream project will care about your modification and you can just use it right away with your bug fix or potentially even the missing feature that you had. That's what I call now fixing it at the root. And I guess most of you will also agree that it's also good citizenship if you find a bug that you fix it at the root end. Even if you don't, you are not able to contribute it directly as a code, at least one would expect that you will give a hint in the issue tracker, things like that, so that the community may improve. Then the other question is, as one point I already talked about years ago is about, yeah, when would I be rather reluctant in sharing something? So this is typically then when you have a high level of differentiation because if you're an organization with some business needs, then you would say, okay, we do not want to harm our business. But here we talk about, well, rather the raw material that we use, like here in this case where you have those refined goods there at the right side, on the left side, you rather have the raw material. And this is what we transferred two years ago already on the open source management. And this is where we currently already have an active community here in Open Chain and the Tooling Group. So that's in the To Do Group. And this is really nice, also nice to work together where we said, okay, yeah, we all can only win if we share here because first, this is no big differentiation that we have here, everyone profits. But now with these non-code contributions, this is the question and you have to judge by yourself, well, if I use this tooling for clearing the material and fixing those non-functional bugs, is this then also already so much differentiating so that you won't share it or not? So this is what you have to share that you have to judge by yourself. And now to summarize those observations from what we do in the daily scans, here we still observe a non-functional requirements not covered, namely the IP issues like unclear license situation, et cetera, et cetera. The difference now between now and then was that now with the Open Change Reference Tooling that we currently developing together and collaboration, it's the detection gets much better. So we see more and more. The other observation I see at the moment is that, yeah, we detect those now with the tooling but potentially also fix it several times, multiple times in our internal patch branches, even company internally, if you don't know of each other but also company or organization-wide and between different organization might be that there are different patch branches in every organization. So instead of just fixing it only once at the root. So this is the one observation, something is missing potentially. The other observation also about what is this? So care about licensing, care about this third party dependency, so this is potentially boring for the software developer and there might be other professional groups in the software area that, yeah, for them it's potentially also easier to cover those tasks. I know this from a former colleague who was tested and we said, yeah, I just have a different way to approach things because I want to test it until it smokes, kind of, whereas the developer is a creator, he wants to create new features. And so there's the question of, is it fun? And then the other thing also, do you need special skills? So if you look at this, so who shall do it then if not the developer? So there we have two options. The one option is, well, it's still the developer but we have to make it fun for the developer so that, or at least that's easier to perform tasks where we currently see gaps or miss non-code contributions. On the other hand, we can also raise the awareness among us, for example, the open source offices or other people in the company or in the organizations that are not the developers or coders, but have other functionalities and also make them aware, yay, you can also contribute. There we value your non-code contributions and you're welcome as a non-code contributor. So if we wrap that up, so this is the one thing, so who should do it? But the other thing is we have those main trails. So you have material from the past so we can't change that anymore. How should we do it? So here we see, okay, we have to overlay the metadata if there's missing something. Here for example, we have the clearly defined project. Then for the present, that's what we try with the open source tooling, reference tooling to automate as much as possible and also provide the tooling so that it's easy to detect it and handy. And so for the present project but also if you use dependencies in your projects that direct or transitive dependencies that you also detect in those past projects, if you want to say. And for the future, that's also what some of the communities are targeting to is that also raising awareness by training and also provide much more tools and checklists to automate it as much as possible. And there as the overview, so how to fix it and here as you can see, I'm focusing on open source management because you could talk about non-contributions and non-code contributions and testing or documentation whatever but let's say when you open source management. So if you see those three main trails past, present, future and then you have the developer and then you have all the non-developers. So for the developers, as I said, for the past they would be clearly defined. So with data that would overlay and they can also contribute. Developers are, well, they know how to do this. Then for the present, if you have a present project there they could leverage our open source reference tooling. For example, the reporter or false compliance bundle is automatically generated so that would already improve the results of the present project and avoid that new gaps come up. And for the future part, they can check and avoid also that they have gaps at least from the IP side and also licensing issues. So you have the reuse software community that provides help to reuse API that they can use to check their project. So this would be the developer part also potentially non-coding stuff but also non-developers could contribute here. So first of all, let's start here with this reference tooling. Now we have analyzers and scanners that we can use even if we are not developers. This is what we're doing in our office. So we have a lot of colleagues that support the projects with scanning and then also curating the missing data. So they use this tooling and everyone can use it. That's also what we try to make it really easy to use for everyone and automate it. And once they find those gaps, they can also contribute them to clearly find help to grow this community and the set of data. And last but not least, also open chain in the curriculum working group here. So also contributions are welcome to raise awareness and also to make the whole level much better for everyone. So that is also fun and to everyone to do this. And last but not least, then also for the past, we have this software heritage. So here you can at least donate that you can do in all those open source projects. But here, I think depending on your skills, then you also have the possibility to make that yeah, persisting over the next years as a software heritage. Okay, so here, this is what I want to give you as a message. So we do not need to wait for developers to fix this. So we miss non-code content in so or potentially there. Yeah, the license is not at the right place or it's hard to find things like that. So here as a quote and talk is cheap, show me the code. I would extend this and please show me all the rest as well. Yeah, so don't talk only, but yeah, you're welcome. So everyone is invited to join the communities and collaborate on the non-code pushers. And you can tell it to everyone, to your tasks, to technical writers, technical editors and also to your IP staff. So you're welcome, we welcome your pull requests here. And for my talk that will be later, just I added here for the handout later, you don't have to read it here, but also some details about the projects I talked about. So the one was clearly defined where you can find all the details about where can reach it and how can you contribute if there's CLA, how's the contribution process, everything. But about format, I talk in my second talk and here later, once the documents are spread, then you're welcome to check this. Also the reference tooling, the open chain and the review software. Okay, so thank you very much for listening and yeah, you're welcome, your pull requests.