The pool next to the ocean: How to bring OpenSource skills to more people
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Tigges, Johannes
The pool next to the ocean: How to bring OpenSource skills to more people OpenSource powers the world and is everywhere with more and more enterprises and large companies understanding the value of it and the need to be able to be a good OpenSource citizen. However, not everyone in those enterprises has the skills to participate in OpenSource communities, feels ready to contribute something or to create and run a vibrant OpenSource community. I observed that there are two distinct groups of people - one with OSS background, ability and willingness to operate in that domain and those that will likely only use OSS without any likeliness to contribute or participate. Let's change that and build a bridge between those two groups while generating value for the enterprise making it more likely to receive support for this activity. InnerSource, the application of OpenSource principles and practices within the enterprise, can be this bridge. You'll learn about creating opportunities for people who haven't been exposed to OpenSource collaboration to learn about the OpenSource ways of collaboration in a safe environment within their organization by creating shared projects internally that follow OpenSource practices and principles. You'll also learn about how organizations can profit from cross-team/silo collaboration and knowledge exchange. Also, the acquisition of very valuable skills by their employees that can facilitate the successful transition of those internal projects into OpenSource and creation of vibrant communities around them. This approach is successfully used by many enterprises, and I'm part of a community who has built and is building OpenSource-d training material for this. Attend this talk if you want to learn about how to deal with silo issues within your company, how to facilitate your companies way to transition projects to OpenSource or how to build up skills to successfully interact with OpenSource projects. Also attend if you want to hear a bit about freely available training material explaining InnerSource concepts for people who haven't been involved in it yet.
 And our next speaker is Johannes Teegs, who's going to speak to us about bringing open source skills to more people. So please give a warm welcome to Johannes. Right. So hello everyone. I'm here as part of the InnoCyclist Commons community. It's one member. If I am not here, I'm giving a talk. I do open collaboration, consulting, community stuff, and some DevOps and special things. But let me go on. So who of you ends up working in a large company like, say, 3K people or more? There are a few. And who can regularly contribute on behalf of their company to open source? Well, less. Right. So what I do see that are there are people from different sizes of companies, and there might be different approaches to open source. MyTalk actually spends all of these environments and roles. Inner source is a topic that is focused on enabling and encouraging collaboration across boundaries. But let me start with a metaphor. We see here the ocean. That can be somewhat dangerous, like tides and currents and that. But swimming in it can be really fun if you are good at swimming for that. And then there's a nice pool. And pools are a safe place to actually learn to swim. And this nice ocean pool in Bondi would allow you to learn to swim next to a real thing and to feel the gusts and the smell of salt and then to just jump right into the ocean once you feel ready for that. And let's go to our things. So while working in companies, I observed my personal observation. There are sort of two groups of people. First, the enterprise people, which just go about their daily coding business and possibly take advantage of OSS, the free as in free be away. And then there are the open source communities and their members who are actually involved in that and do contribute and all of that. And unfortunately, they do not really have that much of an overlap. But for this talk, let's focus on the ways of working. There are lots of other aspects. And actually, these days, there is some overlap with more and more of these large enterprises having open source programs offices and all the nice foundations such as, for example, the Apache Foundation or the Linux Foundation gaining more and more impact. And if OSS, like open source, would be the absolute norm, would not be having these open source focused and open collaboration focused conferences like the nice foster meeting or open source programs offices because of that would be just standard daily business. And so what that exists, let's assume for this talk that there are still a lot of these really close off enterprises and enterprises. Yeah, right. So they do work and to some degree and brought us nice things such as these laptops or your laptops of flight booking services and some parts of our cars. However, they do have their changes, challenges. Like they are hierarchical. They are often focused on spoken interaction and all sorts of meetings. And there's lots and lots of tribal knowledge. And you need to actually find the right person first for whatever. And often you have to talk to them for a while to get somewhere and get to that terrible knowledge. And they have silos. And those silos have quite some adverse effects, actually. So imagine you are depending on some other team and you need something from them. And they just do not have it on their plan what you might need. Some other teams might need that too. But yeah, probably you will wait for a very long time if you get it at all. What might happen is that you might end up building a workaround and a mass extra code that you actually have to maintain or you duplicate existing work by that. And then you actually are responsible for the box you introduced and that extra stuff. And this could happen per team that faces this issue. Another thing that HAP, Meti and I have seen is the case of escalation. All my things get escalated to all those higher ups, the big cheeses, if you will. And if you do that too often, you basically lose credibility and end up as the boy who cried wolf. So that's maybe some of you have seen some of those corporate things. Then open source. So it's great, actually. And it has a lot of positive aspects. And I'm sure many of us here have likely experienced some of those firsthand. And I'll just name a few approaches related. For example, there is collaboration to arrive at a solution. This could have fixed the workaround and escalation and weighted out scenarios that I mentioned. The focus on written, archived and searchable communication often, which makes this tribal knowledge more explicit and reconstructable and this facilitates onboarding and distributed work approaches. And there's working in the open, as we all know, public requests and publicly visible that enables fast feedback and the distribution of knowledge. And actually, there's a lot of fun in it. At least for me, there is outside visibility and you can do the good thing. And there are lots of other advantages for these large enterprises, far aside of cost. So there are, however, some challenges because it is not entirely free. Maybe some of you have experienced some of those yourself. For example, in the case of working in the open, you have to be comfortable to share unfinished work and open it for criticism and scrutiny by others. And for this, you actually need to create communities where people feel safe and comfortable to do exactly that and you have to keep them productive and positive. And you have to develop an acceptance and a way to deal with mistakes in a positive way. There is this case of text-focused communication, which means a synchronicity and hence the loss of important non-verbal aspects. And you need to be able to establish a report with far less personal presence with people. And you need to be able to create an environment that is welcoming to often unknown people with unknown motivations to join and an unknown time budget and stay duration. So there are actually also these governance and licensing issues. And many of us likely have learned to do this on their way through the open source community and the larger site. And you likely grew while doing so. And you built valuable relationships and likely also had quite a bit of fun. Probably you learned to swim in the ocean directly and obviously you survived. Maybe some others didn't. And right, so do you actually remember how you would got you into the open source community and how you learned to handle these challenges I mentioned? And how possibly you were afraid that some suboptimal public contribution might come back to haunt you. And in most cases actually didn't. And maybe someone was even thankful that there is something instead of nothing. And you had to learn about all these licensing things and the math around it. Or if you have a company, you try to open source or work in one, open source something. And yeah, maybe you would have wished that your colleagues, some of them, might have more of a grasp of these open source ways of working. Or you try to hire people to work on your open source software. And you needed them to have these open collaboration skills. And wouldn't it actually be great to have a safe space to enable people to learn about these open source ways in a safe and productive environment. And maybe if you could even get some relief with the CELO, Innovation and Knowledge Transfer issues while along the way. Or just have a bit more fun while you still have to work on proprietary stuff. Right, so inner source can actually act as this space that allows people to learn. Fail without fear and grow their open collaboration skills on the way. It can be the proverbial pool next to the wild ocean of open source. And it can allow people who don't feel comfortable to learn to swim in the ocean to prepare for this in a safe way. And if you grow internal projects like open source projects from the start, you can actually transition them into full open source easier often. And the people that are when participating in the end equipped with these skills will likely have an easier time adapting to other open source communities and will be able to act with confidence and kindness there. And additionally, it actually can bring the advantages of quite a bit of open source to your enterprise. That would be collaboration, for example, this working in the open. Yeah, and some reduction of issues on silos and large distribution that they might even actually get to have been more fun in their everyday business. Yeah, that is actually valuable too. Right, so does all this magic that I mentioned happen on its own? Actually very unlikely so. So need to have some people with great open source and community skills to mentor the new and interested people. If you have a large company, they can't be everywhere though. And what if you don't have them in the first place, wouldn't having a similar model that encompasses a few important things to start with and some documentation on that would be great. Now what we found a few roles in terms to start with making it easier to reason about that and allow you to start building and customizing your own. These are some of the hosts and the guest teams for the both involved parties, a trusted committer, which is what is usually known as maintainer or committer. The guy who's or the person who's trusted with the code base and community contributor, yeah, probably be what you know. And if you have a very large project, a product owner, and yeah, some of those people may have multiple roles at the same time, often product owner, trusted committer, a few. You might have more than one trusted committer and yeah, just like with normal open source projects. Is any of that supposed to replace everything or age or I know what actually no, you can replace that, you can integrate the intent to solve something via source in your normal spring places for your big cathedral software project or you can have grassroot style site projects and maybe they'll evolve into something bigger or just be this nice release or build automation script that is in fact used everywhere and there's surely more and because in yourself actually comes in all shapes and sizes. I mentioned a bit of documentation on the model for people to use to learn and a set of volunteers actually created that and it's still created up me included and there is a set of videos and a set of articles in case you don't like or want to watch a video right now and all of those are open source on the creative commons license and yeah, welcome computer contributors if you would like to. They're available on this nice website on YouTube also as well. There's all sorts of links. If any of these doesn't work, just hit me up on Twitter and if you happen to have an orally account, they have a very nice version of that prepared to write. Just as with open source, there are actually some challenges. Some similar to what you might know from open source and some more specific to inner source and the enterprise context and like for example, measurement of success, incentivization of middle management, some nasty text issues and there are attempt prove somewhat proven attempts to handle them and they are collected by community members in something that is called the inner source patterns community and yeah, there's our observation of those challenges approaches that happen to have worked or hypothesis and collected in a sort of pattern format. I've got a link at the end and they're actually pretty useful. All right, so an important question is should actually be the goal to stop it inner source? Absolutely, please not. Let's not allow companies to open source greenwash if you will themself and call that inner source. Got this nice washing label here. And if you have the right people with open source skills and you can make this case to directly open source something, absolutely please do it. It's the right way to go. But what if you cannot make the case to directly open source something or you let the people with the skills actually do that properly? Wouldn't it be great to still be able to profit from some open source work approach advantages and get to build open source skills with people on the way that might or will come in handy once you're ready to open source something actually? I think this is actually a way to help more people embrace open source who might otherwise not have considered it. So that's what brought me here. And we have also a nice small ad, a nice summit in the middle of April in Madrid, Spain. And there's a website if you're interested in that and I have a few flyers in the other case. Right. And you're welcome to join us there. And so that is all I have. Here's a bunch of links. If you have any questions or other things you're interested in, use those hashtags or just message me. And thanks for listening. And yeah, some of us are here as well. Maybe you can put up your hand and talk to us. If that was interesting, talk to them. Yeah. So thank you. That was all. Thank you.
 And our next speaker is Johannes Teegs, who's going to speak to us about bringing open source  skills to more people.  So please give a warm welcome to Johannes.  Right.  So hello everyone.  I'm here as part of the InnoCyclist Commons community.  It's one member.  If I am not here, I'm giving a talk.  I do open collaboration, consulting, community stuff, and some DevOps and special things.  But let me go on.  So who of you ends up working in a large company like, say, 3K people or more?  There are a few.  And who can regularly contribute on behalf of their company to open source?  Well, less.  Right.  So what I do see that are there are people from different sizes of companies, and there  might be different approaches to open source.  MyTalk actually spends all of these environments and roles.  Inner source is a topic that is focused on enabling and encouraging collaboration across  boundaries.  But let me start with a metaphor.  We see here the ocean.  That can be somewhat dangerous, like tides and currents and that.  But swimming in it can be really fun if you are good at swimming for that.  And then there's a nice pool.  And pools are a safe place to actually learn to swim.  And this nice ocean pool in Bondi would allow you to learn to swim next to a real thing  and to feel the gusts and the smell of salt and then to just jump right into the ocean  once you feel ready for that.  And let's go to our things.  So while working in companies, I observed my personal observation.  There are sort of two groups of people.  First, the enterprise people, which just go about their daily coding business and possibly  take advantage of OSS, the free as in free be away.  And then there are the open source communities and their members who are actually involved  in that and do contribute and all of that.  And unfortunately, they do not really have that much of an overlap.  But for this talk, let's focus on the ways of working.  There are lots of other aspects.  And actually, these days, there is some overlap with more and more of these large enterprises  having open source programs offices and all the nice foundations such as, for example,  the Apache Foundation or the Linux Foundation gaining more and more impact.  And if OSS, like open source, would be the absolute norm, would not be having these  open source focused and open collaboration focused conferences like the nice foster  meeting or open source programs offices because of that would be just standard daily business.  And so what that exists, let's assume for this talk that there are still a lot of these  really close off enterprises and enterprises.  Yeah, right.  So they do work and to some degree and brought us nice things such as these laptops or your  laptops of flight booking services and some parts of our cars.  However, they do have their changes, challenges.  Like they are hierarchical.  They are often focused on spoken interaction and all sorts of meetings.  And there's lots and lots of tribal knowledge.  And you need to actually find the right person first for whatever.  And often you have to talk to them for a while to get somewhere and get to that terrible  knowledge.  And they have silos.  And those silos have quite some adverse effects, actually.  So imagine you are depending on some other team and you need something from them.  And they just do not have it on their plan what you might need.  Some other teams might need that too.  But yeah, probably you will wait for a very long time if you get it at all.  What might happen is that you might end up building a workaround and a mass extra code  that you actually have to maintain or you duplicate existing work by that.  And then you actually are responsible for the box you introduced and that extra stuff.  And this could happen per team that faces this issue.  Another thing that HAP, Meti and I have seen is the case of escalation.  All my things get escalated to all those higher ups, the big cheeses, if you will.  And if you do that too often, you basically lose credibility and end up as the boy who  cried wolf.  So that's maybe some of you have seen some of those corporate things.  Then open source.  So it's great, actually.  And it has a lot of positive aspects.  And I'm sure many of us here have likely experienced some of those firsthand.  And I'll just name a few approaches related.  For example, there is collaboration to arrive at a solution.  This could have fixed the workaround and escalation and weighted out scenarios that I mentioned.  The focus on written, archived and searchable communication often, which makes this tribal  knowledge more explicit and reconstructable and this facilitates onboarding and distributed  work approaches.  And there's working in the open, as we all know, public requests and publicly visible  that enables fast feedback and the distribution of knowledge.  And actually, there's a lot of fun in it.  At least for me, there is outside visibility and you can do the good thing.  And there are lots of other advantages for these large enterprises, far aside of cost.  So there are, however, some challenges because it is not entirely free.  Maybe some of you have experienced some of those yourself.  For example, in the case of working in the open, you have to be comfortable to share  unfinished work and open it for criticism and scrutiny by others.  And for this, you actually need to create communities where people feel safe and comfortable  to do exactly that and you have to keep them productive and positive.  And you have to develop an acceptance and a way to deal with mistakes in a positive  way.  There is this case of text-focused communication, which means a synchronicity and hence the  loss of important non-verbal aspects.  And you need to be able to establish a report with far less personal presence with people.  And you need to be able to create an environment that is welcoming to often unknown people  with unknown motivations to join and an unknown time budget and stay duration.  So there are actually also these governance and licensing issues.  And many of us likely have learned to do this on their way through the open source community  and the larger site.  And you likely grew while doing so.  And you built valuable relationships and likely also had quite a bit of fun.  Probably you learned to swim in the ocean directly and obviously you survived.  Maybe some others didn't.  And right, so do you actually remember how you would got you into the open source community  and how you learned to handle these challenges I mentioned?  And how possibly you were afraid that some suboptimal public contribution might come  back to haunt you.  And in most cases actually didn't.  And maybe someone was even thankful that there is something instead of nothing.  And you had to learn about all these licensing things and the math around it.  Or if you have a company, you try to open source or work in one, open source something.  And yeah, maybe you would have wished that your colleagues, some of them, might have  more of a grasp of these open source ways of working.  Or you try to hire people to work on your open source software.  And you needed them to have these open collaboration skills.  And wouldn't it actually be great to have a safe space to enable people to learn about  these open source ways in a safe and productive environment.  And maybe if you could even get some relief with the CELO, Innovation and Knowledge Transfer  issues while along the way.  Or just have a bit more fun while you still have to work on proprietary stuff.  Right, so inner source can actually act as this space that allows people to learn.  Fail without fear and grow their open collaboration skills on the way.  It can be the proverbial pool next to the wild ocean of open source.  And it can allow people who don't feel comfortable to learn to swim in the ocean to prepare for  this in a safe way.  And if you grow internal projects like open source projects from the start, you can actually  transition them into full open source easier often.  And the people that are when participating in the end equipped with these skills will  likely have an easier time adapting to other open source communities and will be able to  act with confidence and kindness there.  And additionally, it actually can bring the advantages of quite a bit of open source to  your enterprise.  That would be collaboration, for example, this working in the open.  Yeah, and some reduction of issues on silos and large distribution that they might even  actually get to have been more fun in their everyday business.  Yeah, that is actually valuable too.  Right, so does all this magic that I mentioned happen on its own?  Actually very unlikely so.  So need to have some people with great open source and community skills to mentor the  new and interested people.  If you have a large company, they can't be everywhere though.  And what if you don't have them in the first place, wouldn't having a similar model that  encompasses a few important things to start with and some documentation on that would  be great.  Now what we found a few roles in terms to start with making it easier to reason about that  and allow you to start building and customizing your own.  These are some of the hosts and the guest teams for the both involved parties, a trusted  committer, which is what is usually known as maintainer or committer.  The guy who's or the person who's trusted with the code base and community contributor,  yeah, probably be what you know.  And if you have a very large project, a product owner, and yeah, some of those people may  have multiple roles at the same time, often product owner, trusted committer, a few.  You might have more than one trusted committer and yeah, just like with normal open source  projects.  Is any of that supposed to replace everything or age or I know what actually no, you can  replace that, you can integrate the intent to solve something via source in your normal  spring places for your big cathedral software project or you can have grassroot style site  projects and maybe they'll evolve into something bigger or just be this nice release or build  automation script that is in fact used everywhere and there's surely more and because in yourself  actually comes in all shapes and sizes.  I mentioned a bit of documentation on the model for people to use to learn and a set  of volunteers actually created that and it's still created up me included and there is  a set of videos and a set of articles in case you don't like or want to watch a video right  now and all of those are open source on the creative commons license and yeah, welcome  computer contributors if you would like to.  They're available on this nice website on YouTube also as well.  There's all sorts of links.  If any of these doesn't work, just hit me up on Twitter and if you happen to have an  orally account, they have a very nice version of that prepared to write.  Just as with open source, there are actually some challenges.  Some similar to what you might know from open source and some more specific to inner source  and the enterprise context and like for example, measurement of success, incentivization of  middle management, some nasty text issues and there are attempt prove somewhat proven  attempts to handle them and they are collected by community members in something that is  called the inner source patterns community and yeah, there's our observation of those  challenges approaches that happen to have worked or hypothesis and collected in a sort  of pattern format.  I've got a link at the end and they're actually pretty useful.  All right, so an important question is should actually be the goal to stop it inner source?  Absolutely, please not.  Let's not allow companies to open source greenwash if you will themself and call that inner  source.  Got this nice washing label here.  And if you have the right people with open source skills and you can make this case to  directly open source something, absolutely please do it.  It's the right way to go.  But what if you cannot make the case to directly open source something or you let the people  with the skills actually do that properly?  Wouldn't it be great to still be able to profit from some open source work approach advantages  and get to build open source skills with people on the way that might or will come in handy  once you're ready to open source something actually?  I think this is actually a way to help more people embrace open source who might otherwise  not have considered it.  So that's what brought me here.  And we have also a nice small ad, a nice summit in the middle of April in Madrid, Spain.  And there's a website if you're interested in that and I have a few flyers in the other  case.  Right.  And you're welcome to join us there.  And so that is all I have.  Here's a bunch of links.  If you have any questions or other things you're interested in, use those hashtags or just  message me.  And thanks for listening.  And yeah, some of us are here as well.  Maybe you can put up your hand and talk to us.  If that was interesting, talk to them.  Yeah.  So thank you.  That was all.  Thank you.
innersource_skills_0_167.png innersource_skills_168_2039.png innersource_skills_2040_2963.png innersource_skills_2964_5015.png innersource_skills_5016_5903.png innersource_skills_5904_6839.png innersource_skills_6840_7283.png innersource_skills_7284_8951.png innersource_skills_8952_10247.png innersource_skills_10248_11363.png innersource_skills_11364_13355.png innersource_skills_13356_15215.png innersource_skills_15216_15287.png innersource_skills_15288_16223.png innersource_skills_16224_17063.png innersource_skills_17064_17243.png innersource_skills_17244_17519.png innersource_skills_17520_17987.png innersource_skills_17988_18299.png innersource_skills_18300_18659.png innersource_skills_18660_19091.png innersource_skills_19092_20279.png innersource_skills_20280_21947.png innersource_skills_21948_22331.png innersource_skills_22332_22943.png innersource_skills_22944_22991.png innersource_skills_22992_23051.png innersource_skills_23052_23174.png