 I think it's a little bit too loud, so I wanted to talk about social aspects of open source and for those of you who have been here on Wednesday in the main track I gave a small overview so some of the the first slides are the same but then I would expand in more detail. So one of the things I I mean open source is so popular and it's just such an incredible thing really if you think about it there is so much great technology but what I really like is the whole community around open source like coming to a conference like this you know meeting people from all around the world and just on a daily basis participating in open source projects collaborating with people all around the world it's just it's just really exciting but at the same time for people who are new to open source sometimes it can be a little bit challenging you know how do you get started or what are the things you have to consider what are the things you have to avoid so I'm going to talk about some of these social aspects and so first of all a lot of people talk about the open source community and and I think and I think that's to some extent it's a mistake because there are actually many many different open source communities and they differentiate themselves in many different ways so you can't assume that every open source project works in the same way if you look at different projects they actually operate in different ways and if you want to get engaged you need to know what the differences are and so some of those differences can be in terms of technologies right you know some you know different programming languages or the different things they do and then some differences can be in terms of the the infrastructure you know what kind of bug tracking system does the project use what kind of CI system there is a lot of a lot of diversity out there even though nowadays with GitHub I think I think a lot of projects are using the same sort of infrastructure and processes but if you look at some of the large open source projects they have their own infrastructure you know they have different bug tracking systems or just different ways of doing things and then the processes are also different like how for example do you submit a patch I mean nowadays in many cases it is submit a you know a pull request but sometimes you have to send patches to mailing lists like there are different ways of doing things or how do you get the change accepted also how do you become you know an official developer in the project there are a lot of different like a lot of differences another area is governance so how does the project work how does it operate how does it govern itself we have some projects where you have sort of a committee some projects which has several you know core members core contributors and then some projects where you have like one benevolent dictator who at the end of the day makes makes the decision another difference is in terms of philosophy so and you can see that in a number of ways just in how projects approach things one good example is licensing where on the one hand you have permissive licensed projects like BSD Apache which basically the philosophy is you know freedom open source means that you can do whatever you want and that includes taking the software proprietary but then on the other hand you have the like the the copy left people who basically say well the software the freedom needs to be preserved for everyone so that means you can't do everything and then another difference is the culture just just how you know the project is how things happen so I'm involved in Debian and I can I can tell you a lot of things about Debian you know it is one of the most popular Linux distributions we have a lot of packages we've done a lot of cool stuff and and I could go for all of that but I'm gonna skip it now because when I think of Debian really I think of the community I think this is what really makes Debian special and you can see here a picture of the world where the various Debian developers are found so we have a lot of people in Europe a lot of people in America and then we do have some people in Asia although I'd like to see more people another picture is this so once a year we have a conference Debcon and this is from Debcon in in Edinburgh and this is really for me what Debian is all about that those people and I've been involved in Debian for about 20 years now and and some of those people have known you know for 20 years and it's just amazing how you know we grow up together we see how people change and also you know when I travel I can I know people everywhere around the world you know I can meet up with people I can maybe stay at their places and this is just really incredible what open source has allowed me to do it to understand different cultures work with those people so community has has a number of aspects so one is etiquette and norms like basically how you behave or how you you know do things or things you shouldn't do then there are also rich rituals like you know certain things we tend to do which sort of show that you are part of this community and another thing that's important is history so sometimes when you when you when you come to a project and you knew you look at something and you like why are they doing things in this particular way like it doesn't make sense you know if if you would do it you would do it in a different way but then you go back in history and you see oh because of this thing you know which happened ten years ago this is why you know things are the way they are now and and with open source it's it's really interesting because a lot of the history is actually available in you know mailing archive so you can actually find out you know why things are the way they are and and and that also includes like things like like personality conflicts I mean I just have to be honest open source I mean it involves people and generally we want to work together we want to collaborate but obviously not everyone gets you know along with each other and and the history you know that might also explain certain things you know maybe you know something was implemented to work around someone or things like that and I mentioned rituals and and actually let me go back because this is such a good example so you can see here so this is in Edinburgh in Scotland where people were killed and so basically Debian got some kills done and we actually have our own pattern so Debian actually has a specific killed pattern and and it's quite interesting because nowadays when you go to Debcon you can always see some people wearing you know wearing kills and if you see them you might think oh well they're probably Scottish right that's why they wear it but no actually it's it's a Debian tradition I mean not everyone wears it but some people do and and you only understand it again if you look at the history of how these things happened and now people people so show it to show you know that they are part of the project that they belong to this community sometimes we also talk about tribes you know you belong to this tribe so anyway so back to two norms and an etiquette so the thing is with humans is that violating community norms is is really bad it just it's very obvious if you if you get something wrong and it's interesting that for Asia I'm here in Asia because I'm from Europe and when I travel to Asia I get things wrong right and and again I probably shouldn't even say Asia because there is a big difference between Singapore and a lot of the other countries but for example in Europe when I eat noodles you know I'm not allowed to make any noise because if I make noise that's impolite but I think here you know I have to make noise it shows that I like the food and there are a lot of these these norms that as like a foreigner you don't know you know when I come here I do things which which violates your norm and and it's very obvious but the thing is you also see oh you know he's a foreigner he he is not supposed to know all of those things you know you cut me some slack and it's the same with open source so one example is email because usually our interaction is based on email and that's how you make your first impression they always say you know the first impression how you know when you meet someone for the first time that's the most important and your first impression with open source is probably gonna be on an email on a mailing list you send an email and some people get it wrong and and again I mentioned before that there isn't the open source community a lot of the things I say now only apply to more traditional open source communities a lot of the more newer ones actually are quite different in this way but historically sending stuff like HTML email to a mailing list like people really really hate it and if you do that it's obvious you're a foreigner you know you you don't know how the project works you know from here you're not one of us some some people also send garbled patches because they use they use stuff like outlook another thing I often see is long email footers so especially companies they have those legal requirements to state you know the address and the CEO and all those details text numbers and it's like 20 lines of of email and people in the at least in the past again things are changing really hate that kind of stuff and another another example is top posting and this is actually a really good example which also shows that these norms change over time so in the past if you would top post to a mailing list so top post just means that you write your reply at you know at the top of the email like people would really really hate it like you would have to do it this way you know you quote and then you send your reply you quote some more this is in line and in a lot of a lot of you know the traditional up source communities like this is how you have to respond if you if you top quote people hate it but this is actually such a good example of things changing because now top quoting is getting much much much more you know widely used and I also do it sometimes so so what what I'm trying to say so I don't know if you notice this comic where is what Waldo I think Waldo has different names in in in all kind of different languages but you have to to find him somewhere in the picture and he's really hard to find and and that's what I'm trying to say is that when you join a community you don't want to stick out in a negative way you know you should try to blend in you try to learn the culture and do things in in the way that the community expects but at the same time of course you should you should build a reputation for yourself you know you should stick out in a positive way by making a good contribution so I wanted to talk a little bit about corporate involvement and because it's it's getting much more common nowadays that people like software engineers who have like a traditional corporate background and they are being told oh you know you should work on this open source project we want to get engaged you know can you start working on this open source project and the culture between you know a corporate environment where you do in-house development can be quite different to the open source world and sometimes that's a big learning curve for people so one example is writing down information in open source we really like writing down everything we enjoy you know communicating on a mailing list which are archived or in chat systems which are archived and this has a lot of benefits because other people can get involved they can read what's going on and they can participate but a lot of a lot of the corporate culture is to just you know get a room and talk about stuff and sometimes corporations even avoid writing down stuff because you know they don't want to be taken accountable later another thing is distributed development versus co-located development so if if the whole team is in the same building you know you get used to just shouting across the aisle and again if everyone is in the same building you just get a meeting you talk about it and then everyone knows what's going on but there is no need to really write it down but we've open source we always need to write things down and sometimes we meet at conferences and have you know chats in person but then it's important to go back to the mailing list to document what you have discussed what you have decided because there are a lot of people from the project who won't be able to be at the conference technologies obviously are different as well but I think the you know learning the obstacles technologies and tools is very easy and something that some people need to do is if they work in a in a corporate environment they need to adopt different styles you know if you if you work internally you know in the corporate environment you have to behave a certain way you have to follow their traditions and their rules but then if you work on the open source project you have to adopt a different style and you have to do what they do so this is sort of a skill that you you need to you know work in different ways depending on on what you do another big difference is is being open community is all about being open you know the work is is in the open and this to be honest can be a big challenge for people especially if you're new to open source because internally if you if you create the patch yeah your colleagues your manager might review it they might give you some feedback you may have to change it but if you do it in open source suddenly the whole world can look at your changes and they can critique them right and this stuff is archived you know forever and this can be a little bit scary and and again that's also a cultural thing because like for example in America and the US you know they're quite direct with giving feedback and they can be quite blunt whereas in some Asian cultures it's you know it's all about saving face and you know saying things indirectly so this is a big challenge I think for a lot of Asian contributors to be involved in open source which are really like the culture is a very very Western dominated in many ways another thing which which is like it like a challenge for some people but I find it really rewarding is that with open source you work with your competitors like obviously your companies compete on some in some ways but on the open source project you might collaborate you know with them so if you look at the Linux kernel you know that has people from Intel and AMD working together side-by-side IBM and HB are working on Linux side-by-side but then they compete in other areas so this is something which which is very you know unusually in a way and I actually have this example so I have a friend and he used to work at HP so I used to work at HP we both worked at HP and he was working on the Linux kernel and then one day he moved on the country member he moved to Google or Red Hat but he still continued working on the Linux kernel and so he told me that his family asked oh so he changed jobs what are you doing now and he said oh I do exactly the same I do before you know I worked on the Linux kernel before and I work on the Linux kernel now and they were like how can you change employer and still do the same stuff and and and yeah and I think it's incredible because again it comes back to friendships even though we change employers you know my friends they still stay around in the same you know environment yeah we might work for different employers but we all work on the same project yeah documentation NDA can be a problem with like corporate involvement so one of the questions is why should you get involved in open source in the first place because open source it means you know you can do anything you can take the software you can modify it internally in your corporate environment there is no need there is no requirement to give it back but there are a lot of benefits in doing so because at the end of the day upstream so upstream is basically the project where you get the software from they are the authoritative source so if you make changes internally the project doesn't stand still and they also move on and they make changes and then for you it's a it's a huge maintenance requirement to to you know get your changes into the new version but instead if you take your changes and you put them upstream then you can just adopt the new version without any changes and in fact other people might get involved and improve the changes you have made so so one of the things I see in terms of corporations getting involved in open source is they don't understand that in the long term open source pays off but in the short term it can be more work because you need to get up to speed to contributing to the project you need to do all that work to get your changes in and that's a lot of work but in the long term it makes things so much easier for you so this is sometimes a challenge explaining to management you know why do you need to work to invest all of that time now well because it pays off in the long term another another reason for getting in involved upstream is getting new ideas I always I mean you know some of the big companies like Google they hire a lot of smart people right but there is no single company that can hire all the small smart people in the world and again that's the beauty of open source is that you know you have all those smart people working on the same project and it doesn't really matter who they work for you get those ideas from all of those people and you can also contribute your ideas so how how to get started with open source so it's very hard to give like a step by step how to because a lot of the things depend on the project every project works in a different way so the way you get engaged the way you contribute are very specific to the project but obviously some of the things are generic so one thing I always recommend is that people start by using the software and then when you use the software I'm sure you're gonna find things that don't work and then you can find a bug report or maybe the documentation is accurate and you can improve it and the more you help out the more opportunities you find to get involved another thing that's important is that in open source you have to be very independent there isn't really anyone in open source who tells you oh you know you should be doing this you should be doing this it's very like people very self-determined like you get involved you do something and you contributed so don't wait around for people to tell you what to do just do something and and I mean a lot of projects nowadays try to make it easier by having sort of mentorship programs where they either describe certain things that are easy to do you know here are some bug reports which are easy to fix or here is you know documentation area that can be improved and also they provide guidance like they work with you to get you up to speed but a lot of projects don't have that so you just need to get started and then and then contribute and see how things work so one of one of my advice is find a niche find something that hasn't been done before because if you just do something which everyone does where you can make a contribution but it's it's gonna be you know but if you do something completely different then you know your impact is much higher so and in open source there's always something to do like no software project is perfect right no project is finished there is always something you can contribute so just start by using the project and you're gonna find a ton of stuff that you can improve one of the really nice things about open source is that as you get engaged in projects you build up a reputation you know people start to recognize your name and if you do a good work they will record you know they will associate your name with that good work they know they can trust you they know that if you do something it's going to be high quality and the great thing is that that reputation if you want to change employers that stays with you you know people can look at your your github your repository or they know name your name and that makes it really easy to get new jobs so how to get involved so one of the things I always say is I mean I'm sure you're eager to get involved you just want to start but take things slow the first thing you should do is observe observe how the project operates and the great thing is we hope so this is very easy to do you can just subscribe to a number of mailing lists and you can read and then you can see how people interact how do people discuss how do people make decisions who are the people who have influence in the project you see all of these just by observing you know the mailing list conversations and try to understand the culture try to figure out how the project works and don't assume that it works a certain way that it works like a company or that it works like a like another open-source project and if you make changes then contribute them back so that's it I think we have some time for questions thank you one idea that I've been that I've been trying around with is for for companies to more so traditional companies to implement an open-source culture within the company itself I'm just wondering if you have seen this done anywhere so so make sure that there are no sort of clans inside the company if people are open about the work that they're doing and invite other departments in to come and take a look and for coats with the company and then spin that off see see the advantage of having multiple stakeholders and contributors and then spin that off in finally into an external project after the momentum has been built out right yeah I think there are there are two things I see so one of them is called inner source which is basically where companies adopt open-source methodologies internally so you know they use stuff like like git and pull requests and and bug bug tracking systems and and basically they adopt open-source methodologies internally but sometimes it is for proprietary code so there's never any plan to actually you know up like get it open so like get it out out of the door it just internally to facilitate collaboration and for example when I worked at HB we actually bought a license for GitHub to to to create this this environment and people were saying like I mean it was like a big company with 300,000 people and it was like you know why are there so many silos why the different teams not working together why do we not know what the other people are doing and by having this inner source you know some of those challenges can be addressed but then I think the other thing is which I think is more aligned to what you said is is where people sort of start doing open source internally but with the plan to to eventually get it out there so one thing for example I see is that you might have a team where you have some experienced open source developers and some people who don't have the experience and basically they provide some internal coaching so you do stuff internally there's internal code review and once the team decides yeah it's ready then you approach the open source project you actually submit it outside but but yeah like the whole inner source model is getting quite quite popular and and hopefully some of that will be released as open source as well but some of it is just you know proprietary software development done in like a more modern way actually I have a question so archiving this email list and PR so those have kind of a personal comment or like information does it anything violate GDPR things or anything because it's archived forever right so this is actually a really big topic for a lot of open source projects right now because we have traditionally relied on I mean open source is all about being open about being transparent we don't want to hide you know problems or things so we you know the whole idea is to archive stuff as as much as much as possible but at the same time you know projects need to comply with with you know the law and and so now you know if someone wants something removed that the project would have to do that I don't think I think it takes some more time to see how it pans out in reality I don't think we have seen like a lot of you know requests for remover but it's definitely something that the various projects are aware and working on any other questions we have like two and a half minutes okay thanks so much yeah thank you please give a round of applause for Martin in that way