 My name is Iwan Lee Nolke. I'm a senior researcher at RISE, Research Institute of Sweden. I've been working, collaborating, researching with both public and private sector for almost 10 years in terms of how they can use, share, collaborate on open source. And one question I come across in both private and public parts is this, can we release this, is it safe? What kind of gain out of it and so on? Should we share it? Both from the positive and negative sides. And what I'm presenting here today is based on a series of different case studies I've done in collaboration with different companies, really investigating what to share, what to think about how to align it with your business objectives and really trying to get a more nuanced feel for the plus and minus, the positives and negatives. So really contrasting why you should share it, but also looking at the back side, the potential drop side that could eradicate the potential value. So I'm going to also try to describe how one potential way of creating a decentralized contribution strategy could look like. There are many ways, but this is one way that's been applied in numerous companies that I've seen and helped apply. First off, I talk about contribution strategies, but what is a contribution strategy? Basically, it's your organization's answers to the questions if, why, when and how you'd want to release something as open source, both in general, but then coming down to the actual product, the roadmap, looking at the different contribution requests that comes in. And these contribution strategies basically a way for you to help execute your overarching open source strategy while you're engaging in open source, why you want to release something and contribute how that aligns with your business objectives, how it creates value for your context. So it helps you basically to promote and support contributions and streamline them in a way that aligns with your business objectives, basically putting the effort where motivated and needed. But it also helps you highlight the potential risks and costs, as I mentioned, up front so that you can consider it in a more proactive manner. And this is quite an important note because, I mean, rains and thunderstorms can easily turn away the happiness and the sunshine that you would expect. Potential risks and costs they can prevent, reduce or fully eradicate the potential value that you and the outcomes that you hoped to gain for by releasing this as open source. And from this contribution strategy, your company needs to develop guidelines and processes that can help individuals know what your organization values in terms of releasing and contributing. What can you gain out of it so that they know, okay, is this valuable? Will this add value to my company or my organization if I contribute it? And it also helps them to make their case explain this in a language that is better understood by the decision makers in your organization. But also highlighting the potential risks so that the individual submitting a contribution request can act on these early on and propose mitigation strategies. It also helps the decision makers to understand more better how the contribution sort of potential open sourcing of this product adds value to the company or to the organization. And it reduces the number of clarifications probably needed. And it also enables this more proactive release planning or contribution planning, for example, in your product planning process when you're setting up a roadmap and you can more look ahead which parts you should open source so you can plan this from the beginning. And also important here is to really lower the barriers so that you don't scare away people that they are comfortable and don't think that this is overly complex in any way and really highlighting the different steps but really reducing the friction and removing as much information that they don't need. They maybe just need to know the status of the actual contribution request. Certain decision options could be reject. No, we can't open source this conditional. Well, we could open source this, the enablers, the qualifiers, but not the secret sauce. That's these 10%. Or accept we can't contribute this. And then there are different options here. Do you want to submit it to existing community? A new community within a certain external entity such as a foundation or ecosystem? Or should you just release it into the wild? There are different benefits and negatives with each of these options that you need to weigh against each other. So you need to have the systematic approach in laying out and the structure and this contribution process really involving the stakeholders and getting their buy-in from start. For example, marketing is often forgotten here. But also IPR, legal, engineering, ecosystem partner management, sea level and business management. These are all stakeholders that you should involve from the beginning. And do not take anything for granted. I mean, some things are quite generalized or generalizable. But still everything I pick up on these slides may not be applicable to your context or be relevant for your context. So really consider based on your own needs and your own perceptions of risk and so on. And also what different types of projects that you're developing and what different contexts, tools, infrastructure, embedded, frontend and so on. So what we've done in this series of case studies and so on in interviews, we developed a set of what I call objectives and complexities. Objectives being different types of benefits that can be gained by a contribution or open sourcing. Complexities being different costs or risk or other aspects that could complicate or basically make the contribution nearby impossible. And yeah, these can be used as a basis for when you're developing a contribution strategy, a contribution process and so on. And this paper is available as open access. So you can go in and read everything about it. And for each objective, we have example quotes, contextualizing and providing also key concerns and risks and mitigation strategies for the different complexities to help guide you and put them into your context. And these slides are available on the schedule platform. So just to walk you through a bit. So the contribution request, we have about 12. We have 12 of them. One category is the more reputation-centric objectives highlighting how it may be important to build and improve on your relation with your external stakeholders. One way being engaging in key technologies, key communities, proving skill and influence that you can influence this technology and thereby working positively towards your customer base or your partner ecosystem. It can also be a way to show that you're a good open-source citizen, quote-unquote, both to the ecosystem, be it partners, customers, but also to your employers or your employees, your coworkers that often value this kind of way of working. And it's also a general strategy for improving your employer branding and the retention of your employees in allowing them to engage and contribute to open-source communities. Also, increasing transparency is another way. The Linux Foundation released a new report on the Europe part of the open-source ecosystem, I think it was yesterday. And transparency is highlighted specifically in terms of public sector, which I can verify. They released it because due to transparency reasons, but there's also for companies, commercial actors, a certain objective here by releasing, for example, a tool openly. You can show how you more transparently build trust in how you measure something, but also that's how, what kind of data you collect, in what manner and so on. So there are definitely business objectives here as well that you should or could consider. More supply-centric objectives relate to how you can really gain more value out of your supplier relations. And these were a bit surprising when we found them in the case studies. But one way is, say, a supplier is, you're procuring a product by supplier, but they are getting more and more aggressive in their pricing and so on. So you develop your own internal solution, but you don't want to run it operated, so you outsource it. You release it out of open-source here by creating a means to put price pressure on the vendors, but also as a way to outsource the infrastructure operations, enabling vendors to provide you with the service. More strategic objectives help you to stay more competitive. For example, in collecting data, be it for consumer insights or improving your ML models and so on. Another objective could be to standardize a solution in a community, in an industry, or in any kind of ecosystem, putting your solution out there so that you get to steer the agenda rather than having to adopt to other solutions. Building a software ecosystem, allowing third-party actors to add plugins or tools or different value adds to your open platform, is another way, expanding the market and so on. But also improving partner collaboration in terms of allowing them, your partners to take your tools, your platforms, improve them from their different perspectives, their use cases, but also enabling better integrations. And then we'll have the more classic engineering-centric objectives, such as improving the open innovation process, enabling new feature implementations coming in, but also leveraging the community as a force multiplier in the development. On the other side, the complexity side, so we have control-centric complexities, and these refer to the risk that the development of a community or the thing that you want to release heads in another direction, not favorable to you or that you would consider good. And this can refer to projects or artifacts that relates to your products and services, enabling your value proposition, but also that are key to your internal operations, your build pipeline that may provide a competitive advantage or the way that you release or deliver your services. So, key here could be that you are sure to have the influence in these communities that you want to contribute to or consider creating a new community where you have the initiative. More IPR-centric complexities, for example, differentiating functionality, maybe it's the most common one, the most common risk, giving away the secret sauce or what's competitive advantage to you. Usually, this is overrated. Usually, it's only 10% to 20% that is actually the secret sauce. The rest is usually enablers, qualifiers, commodity that you can contribute anyway. So this, by having this more selective revealing and way of looking at it, you can contribute and actually start staring the agenda in the communities while keeping the more differentiating parts closed. Commoditization is another risk more focused on not releasing it too early and not too late. Releasing it too early, you're giving away a competitive advantage. Releasing it too late means that someone else could have released just that functionality, so you have to adapt to that solution and then you can just scrap what you've developed or keep on building technical depth inside your own walls. Sensitive IPRs, I think the most common example is patents, either connecting to a patent revenue stream or defensive patent portfolio. Substitutes, there is a risk that there are alternatives out there that the developers miss, so quite common as I've heard about. So really trying to analyze what options are out there, how do they fit our use case, what can be added to make them fit rather than creating a new product. And then license compliance and more export regulations and data regulations and so on that also needs to be considered. More exposure-centric complexities. For example, you release something and it's used in a use case that you consider unethical. This was primarily highlighted by the public sector organizations we investigated where this could be more sensitive. The more general is that you would expose yourself to security threats or you would expose vulnerabilities that you did not know of, but then you of course have the other side here, enough eyeballs on the code and all bugs are shallow and so on. So I mean, this was raised in two of the case companies that we investigated, but this can be viewed from different angles. Cost-centric complexities, budget and resource constraint, it will cost you to prepare something for contribution. It will definitely be cheaper if you prepare it for open source to be open source from the beginning. If this is something you come to terms or realize late, then it will cost you a lot to abstract that and really prepare it for contribution. And also, what are you committing to? Are you committing to maintaining the contribution and building a community? Then it will cost you even more. Do we have the budget here and the resources that it needs? Modularity and architecture. I mean, if it's really grown in and if it's really a part of a larger spaghetti infrastructure, abstracting that afterwards, in some cases, it's not even worth thinking about. Code alignment. It may be that the code that you want to release, it's in another direction and then the community where you want to contribute to. So it may need refactoring in order to be contributed and it's that cost worth it. More community-centered complexities, for example, is there an external interest, be it in the community you want to contribute to or is there an external interest in creating a new community? Do you have the influence needed in the specific community where you want to release it? And is the community where you want to release it healthy? Is it going downhill? That could be a sign for that you want to create a new community but also it could be a sign that you should contribute because it needs contributions to stay healthy, that community, but also motivating a larger engagement. So these are basically two sides of the scale that you have to consider. These different objectives, aligning with your own business goals, which ones are these? Probably not all of them. Some need to be contextualized and some I have not mentioned because this is not a complete set. And also what's the downsides or the potential risks and how could we mitigate them or address them so that the scale weighs to the more positive side. Okay, so this was more like a smorgasbord of different parts that you could consider in your company, but how can you more operationalize it? So I'm going to talk about one way of setting up your contribution strategy that I know, at least originated by Ericsson, then I've seen it in Stan Shader, whereas I've seen parts or quite large parts of it in other organizations such as Sonomobile and other companies that I work with. And basically it starts with the individual submitting a contribution request and here they need to answer a contribution form with questions that should be based on your and your organization contribution strategy, basically aligning with the objectives and complexities that you identified. And asking these right questions may be difficult, but it's a mean to help streamline the process from submission to decision. I shared a doc here with the different questions that I've seen through a couple of companies, different contribution processes. So that can be one source of information or inspiration when you try to set up your contribution process. Then once submitted or before submitted, the individuals should have undergone some kind of basic open source training, really understanding what is open source, what does it imply to contribute and so on, but really understanding the objectives of your organization, why you want to contribute something, what you see and so on, and about the contribution process. Then it is sent to once filed, it's sent to one, an individual, could be called a contribution officer, I've seen other names as well, basically an individual near out in the teams that have the knowledge. They're usually some kind of network, knowledge network with these individuals inside your organization where they can share knowledge, where they can interact and be informed and educated by your open source program office or the function that works with the port's open source. Could be an architect, senior engineer, engineer manager, and this contribution officer does the initial check, some kind of basic review, really checking if the contribution is motivated, what risks are there, what mitigation strategies are proposed, but also determining the level here of complexity and size of the contribution is trivial, meaning it's just a simple bug fix, some kind of correction, smaller contributions, whereas the medium contribution may be some kind of feature implementation for an existing community or it's a major contribution, substantial IPR, creating a new community and so on. It requires different ways of addressing them. Trivial contributions can be approved by the contribution officer, usually, and for projects that are considered non-competitive or nonsensitive, usually can be whitelisted so that trivial contributions to these kinds of communities don't have to go through this process again, again simplifying and removing friction in the contribution process. All contributions that are cleared are then sent for technical review, which could be done by the contribution officer, but also the peers close by in that part of the organization. Basically checking that it's generalized enough, have, is the comments there, have all sensitive information referring to internal infrastructure being removed and so on. And then for medium and major contributions, these are then sent to an open source review board. There are other names, the advisory board or a supervisory board, basically some kind of cross-functional board with people from the different stakeholders internal which could be marketing legal IPR. Of course, the open source program office or the open source exec in your organization. These can then do the more overarching discussions if this should be released or not based on, or with help guided by your existing contribution strategy. For major contributions, usually there's a need for an explicit presence and okay by the business manager or C-level exec. And if you have a complex organization, multiple silos or business units, you can break this down, for example, in what could be referred to as fast track or for parts that are considered non-competitive. For example, tools and infrastructure. I've seen multiple examples being considered non-competitive, hence can enter this fast track. While things that relates to the products and services that you release and ship, those go into what we could call the standard track. They have to go through the full review process. Again, highlighting this perspective that each different case requires different attention, different objectives, different complexities and so on. Some general notes ensure basic open source training. It helps remove a lot of doubts, a lot of frictions, a lot of need for clarifications and so on. Really try to raise the awareness on what it implies to work open source and what you consider as beneficial in your company and the risks and so on. Try to decentralize the decision making as much as possible. Empower the teams to work on this rather than creating bottlenecks at the top. And have support functionality in place, be it with this contribution, officer structure or open source ambassador structure that I've seen also really trying to branch out the knowledge and the support. And also automate as much as possible. Really try to streamline the process and remove as much question and information that is not needed for the developers so that they just see as a simple process. So not overcomplicating it, but also enabling actionable insights in what communities you are contributing to, how much you are contributing, how much effort you are putting in, how much you're investing so that you can compare that against what you're gaining out of it. So that's all. Do you have any questions? Yes? You've got a process there that is quite extensive and your development teams might be committing dozens of times a day. So how often would you say they will be going through this kind of process? I would say if they're working upstream to a project like all the time, then there will probably be some kind of white-listing and cross-based decision, some kind of blanket approval. I mean, they should not have to go through this process for each bug or each commit if it's a trusted developer, if it's a white-listed product or project. So it's really about adapting it. It's all about removing as much friction as possible while still being able to managing the risks. Definitely. If this is decided or approved, then for all maybe two years or three years you won't need to go to the board again. Even though they might have enhancement of new features to this, what is the criteria? It's very difficult to kind of set it down. I mean, say you're working with some kind of project in your build infrastructure, in the tools and infrastructure departments, and they work upstream with a project, then they could have that project examined. Does this look okay? Is it considered competitive? Anything that we could contribute here, could that potentially substantiate our risk or giving away something sensitive? Or can we whitelist that and basically have those fast tracked? And then if there are, like, more releasing a plug-in, for example, to Jenkins, which is a plug-in-based ecosystem, releasing a plug-in, for example, that would substantiate a more medium or major contribution. It's really about communicating, okay, what space do you have to work upstream. But if you're submitting a plug-in or these larger things, then I would say it's a larger investment in time in your release planning or internal planning. And then that would be caught up and that would be considered here. So after a certain point of time, let's say after a few years, we'll be having a list of projects to which you'll be contributing. So how often do you go back and review the checks again? Because somebody can, some contributor, I would say the owner can change the license of it. Or probably he might get funding from somewhere which could be, like, you know, contradicting to your interest. Things like this could happen. According to you, how often should we go back and check this whitelist approach? I think if you whitelist a project, then you should have someone who's responsible, the community. I mean, if you're whitelisting a project, then you're seeing that you're having a long-term engagement there. So then you should have one individual that is the main contact here, the community representative or whatever that has this familiarity with this community. I think if you're whitelisting a project, then you should have a strategy for why you're going in there and what you want to accomplish. And then that individual should be responsible for that, being how implicit or explicit this strategy or community strategy would be. So then this would be continuous, like, awareness. Yes? So I know some companies, I guess, consider contributions made on behalf of the company versus maybe contributions that an employee makes in their personal time. Have you seen any sort of intersection between those two with regards to these contribution processes? Because there may be cases I'm thinking where you have a developer that is working on some open-source project, maybe in their spare time. It doesn't have any value to the company. But at the same time, you know, the company may want to at least be aware maybe there's some sort of approval process to go through for that. Exactly. So what I've seen there is that to avoid any confrontation or unnecessary confrontations, it should be there in the education and in the setup that individuals working, coding spare time on different products that this should be transparent and having some kind of formal okay via email if it's the engineering manager, what level is enough, but that you have contractual or email agreement that I will be working on this and it's okay to do this in my spare time. I've seen, I think it's Red Hat, for example, have some kind of this thing more concretely written in their contracts on what the developers can do in the spare time. But it's not always that explicit. How many of you have contribution processes in place in any way? That's quite good. Define. I'm a developer. I work in a company. I have my spare time. But when I contribute to the open-source project, if that project is nothing to do with the company's project or product or tool, then I think I am totally free to have freedom to do whatever I want. If this is not written in the open-source strategy, so I think this is a good point in the open-source strategy. As a company, are you allowed or not your employees to do any kind of reading? If it's a company's product or tool related, then you are not allowed to use your own for example. That's another aspect. Are you allowed to develop or use your work mail when doing contributions on your spare time? Exactly. And that connects back to the employee branding parts and really having a satisfied engineering part of the organization, enabling them to work on open-source. But they are empowered and not prohibited. And again, this contribution strategy aspect, way of working can help you more precisely to distinguish between what parts belong to the company or IPR, what are you developing on office time and what is considered not competitive. Your work hours are over, and you're using the company infrastructure to build the contribution. How do you account that? And it's not for the company. It's a project that you work with in your spare time. So it's not according to the company goal. In that case, you should have your own hardware to create the contribution, just to have a clear cut or agree with your manager. Definitely, that's a fair point. I mean, it goes back to what you're allowed to do and are empowered. I mean, if you're a small, friendly company, then this maybe is not an issue. But if you're a larger company where your resources are tied to where you have more structured monitoring, it could definitely be an issue. And also, on the other perspective, it can be a way to show the employer that you're actually working quite a lot more. Than expected. Interesting because it's very... I've seen reports where it varies, and I think yesterday the Spotlight Europe report, they highlighted that often a lot of companies or organizations, they don't have the processes in place for enabling these contributions. Or they may have, from our own experience, but they don't. It's more like a more stage gate process. It adds more friction necessary, and it's not necessarily aligned with your business goals. So what I really think here is that you should enable contributions and promote contributions, but try to set up the structure so that they are more streamlined with your business goals, and thereby creating more value. So you're getting more out of the communities that you prioritize, and that you can see how much you put in that you can make more actionable insights, really helping everyone to work together more calmly rather than in 10,000 different directions. I mean, developers should definitely be enabled to work on open source, but what really be helped to, okay, but these are the ones that we should focus on. These are the most aligned with what we want to do with how we gain profit. These are not that central. These are not at all. Any other questions? Yes? There's tooling getting figured to find out to contribute to your repository. Is there any kind of tooling for reviewing all CLAs of other repositories if any, yes, you can commit to that one? I would, I'm not aware on that level, but I would definitely check the to-do group. They have, in their Slack channel, they have a tools channel, and I think Thomas Steenberger. If there is one, he would probably know about it. Any other questions? Cool. The slides are on the schedule platform, along with the link to the papers and so on. And I'd be happy to take any questions later on in email form or whatever.