 Hello everyone, I am Divya Mohan and today I'm super stoked to be speaking at the open source in Japan. I shall be delving a bit into how we can make our open source communities more effective in terms of engaging and sustaining new contributors as well as the existing ones. Now before I dive right in, I would love to take out a couple of minutes and introduce you to myself. So as aforementioned, I am Divya Mohan and I am currently a team lead with HSBC. Over and above which I am the co-chair for a special interest group documentation on the Kubernetes as well as the litmus chaos project. I also had the extreme good fortune of being awarded the CNCF ambassador title last year and I'm extremely passionate about getting folks started on their open source journey. So I sort of wiggled my way into the co-organizer role for the CNCF student user group as well. I also am an author of the Friday 4 newsletter which I just started as an accountability tool a couple of weeks back and there are a bunch of other stuff that I do including speaking at conferences and events globally which have sort of helped me in my cloud native journey. But to be really honest, I did not start off like this. None of us do right? We all start at the rock bottom not knowing how to sort of navigate our path in the open source ecosystem and we all are in requirement of some sort of help or mentorship. Now it's not the same that open source communities are unwelcoming or extremely hostile that is not the takeaway here but as veterans if I may call us all, call us all that particular term we forget how it is to actually have started off and how tough it is to navigate the ecosystem because from the standpoint that we are in currently we seem to sort of have all figured it out but that's not the case obviously and even in a you know in a contributed journey wherein a person is pretty far ahead they probably still might need assistance in navigating their ecosystem. No shame in that because I was one of those people so and it's very easy to sort of get demotivated as well because let's face it open source communities are primarily based on voluntary contributions from contributors across the globe and if we are speaking about engaging and sustaining these contributors it is not a one stop shop answer you basically are looking at a multi-faceted problem and some of those problems or barriers are what I am hoping to cover today and towards the end of the presentation I do hope to sort of come from the standpoint of now being a co-chair and you know help with you know I wouldn't say advice but help with some suggestions that can sort of make our communities more inclusive so let's dive right in. Now when we speak about open source right we have a very vast ecosystem to start off with so when we when I started personally contributing to open source what was confusing to me is at what point am I supposed to be a member and this is not because there was no clear contribution ladder defined it was there within the communities that I got involved but it's just that those contribution ladders and guides that are supposed to surface during a potential contributors search right they did it they did not surface and to be honest was really confused for around say the first couple of months as to when I actually you know could call myself a member of you know a particular open source project and I know for a fact that a lot of people who start with open source have the same problem because yes there are many projects have contribution guides listed down since now with people from all areas trickling in we definitely understand that not everybody knows it or you know the programming languages associated with your project but what there is a lack of is a contribution ladder and that to a clear contribution ladder explaining to that particular contributor how they will be able to sort of go up to the next level sure there's a diagram sure there is you know you know a detailing of how the different contributor levels are organized within the hierarchy of a particular project but how do you get from level a to say level B that is something that is very vague and to be very honest it again differs from project to project most projects do not have this so there is a definite lack of incentive for the contributor getting involved to actually aspire to become a contributor because after I start contributing then what is this just going to be a line on my resume what do I continue doing here there's no there's no guidance and and I mean it in the best possible way we need to have really clear contribution ladders defined in terms of it not just being a diagram but it needs to have specific directions on how contributors who are new to the project can ascend that ladder what are the actual what are the actual tenants or the actual preconditions that a contributor must fulfill when moving from level 8 to level B to level Z so that sort of gives a structure to the contribution journey of an individual contributor to the project and also gives an aspirational level for the contributor to you know have while starting out his journey again this is not a one-stop shop and is not a one-size-fits-all solution because even with contribution ladders defined there are and contribution guides being in place there are there are several other barriers that come in during you know your contribution journey one of them which really you know is pretty close to my heart is that of time zone jet lag now as we already probably know open source communities are global in nature and it's one of the factors that makes it appealing to any new contributor imagine having to you know work on something alongside folks from across the globe and gain from you know gain knowledge from those conversations and interactions you have what and all of this is you know at you know at a very visible level wherein you actually get to interact with other folks in the same industry as you when you are in a particular organization whether it be academic or you know corporate or you know any other type of organization you are restricted to your own tech bubble you are restricted to the people you work with you're restricted to the colleagues that you interact with on a day-to-day basis but imagine having colleagues that colleagues who are situated across the globe that's what an open source community offers you but with this comes the flip side that most meetings are exclusionary for some time zones primarily because you know the open source movement has sort of started gaining traction in these time zones later than they did in the initial stages so obviously you know when when it comes to engagement of contributors from that time zone it's it's clearly on a low and the contributor basically does not have any avenue for sort of you know interacting with their global colleagues as I call them and when you know there are initially very less contributors from a particular part of the world there aren't going to be a lot that follow because only when you see somebody who looks like you who probably well you know speaks your language who is a lot like you in every sense of the term will you be will you be confident enough to join a community because otherwise you are going to deem a particular you know group exclusionary so representation matters and having that representation in the form of the various time zones that sorry that the community operates in is extremely essential without which what tends to happen is you know obviously the engagement decreases as I offer mentioned the contributor is demotivated and even if they actually sustain manage to sustain or you know juggle their professional and you know open source commitments they are setting themselves up for burnout and not for success because burning the midnight oil has never ever really benefited anyone especially when you are a working professional who has to sort of balance your personal life your professional life and your open source commitment on the side so over and about just the time zone bit right we have various languages coming in as well from each of these time zones and most of them do not have English as their primary language but when you look at the documentation that's available on the internet for all of the you know open source projects out there the primary language that they're written in is in English now English is not the primary or native language in most of the countries outside of the US or EU and I wouldn't say that this is a hindering factor but it definitely would help if we have you know these differences accounted for when we you know write documentation or any sort of material that is consumed by audience towards adoption during the adoption of the project because languages at this point in time when technology has come so far should not be a deterring factor for the adoption of a technology or a tool and it definitely should not be one of the reasons why you know contributors who are from a non-English native country are sort of you know not able to get involved so we definitely must account for this and like I said towards the end of the presentation I hope to leave you all with some pointers on how this can be done at the last one that I really would like to talk extensively about because a lot of the you know problems stem from this particular point open source projects so far have been voluntary contributions by the respective contributors and only some contributors have support from their employers towards actually contributing which means that they are either paid for you know working on whatever project they're working on during that during their hours of working or they are incentivized in some other fashion to actually work on that open source project like building you know building their own building their own organization around the project or something of that sort but most corporate consumers and by most I really do mean most are passive adopters of the you know open source projects that are out there open source has actually enabled open source projects have actually enabled you know thousands of managed offerings to come out from various service providers and even you know the actual offering itself has sort of various benefits for people who have adopted it but unfortunately corporate consumers corporate customers or corporate you know organizations do not find the incentive to actually you know contribute in this in this space the reason being why would I let my employee work during the working hours on a project that basically is just a tool that is sort of being used in my organization it's a very good question but it also has a very good answer at this point so when you are sort of allowing your employee to work on an open source project you are in an upstream manner or in whatever other fashion that you you choose to support you are actually enabling that project to receive feedback from your company's side which means that at some point in time consumers like you can have a say in the way that projects end goal shapes up and of course when you actually have an employee interacting with so many other folks from across the IT space they definitely stand to learn a lot more than what they would when they just are relegated to their tech bubble so there is a benefit but it is not an immediate and a quick one which is probably why you know corporate customers do not you know view open source projects as something that they can you know fit into their employees working hours but as of now the sustainability of all open source projects is at stake because as vastly as this ecosystem is growing we are in in a state wherein there's an excessive demand of contributors there always was a demand but there is an excessive demand given the scale at which we are growing and if there is no support from corporate customers towards you know the helping these projects flourish it is the projects that will suffer and how if you may if you're asking that the contributors a even if you know they are not incentivized in terms of monetary compensation or however else the organization chooses to compensate them they are more prone to burnout because whatever work upstream or otherwise that they will be doing is out of their working hours now the pandemic sort of allows us to do work or you know juggle work when we are in the comfort of our homes but once you know we return back to normalcy whenever that is it's not going to be as easy for a lot of us to sort of contribute and you know have a day job and manage our personal life if there is no support from the organization over and about which a lot of organizations also have restrictive policies which clearly you know state that voluntary contributions are not allowed unfortunately that's a very sad space to be in at this point given that almost all the all the software that's out there all the products that we use in our day to day life including your laptops your cell phones your whatever are in some way or the other powered by an open source project so it's extremely essential that corporate organizations are as much a part of this whole you know ecosystem as you know a contributor is because only when there's support from you know corporate organizations that are actively consuming this will the you know balance sort of be restored because at this point in time there are more takers than there are makers so there is a clear you know tilt in the balance current you know of the ecosystem because you can only give up to a point of exhaustion after which it's not possible for a project to you know sort of continue sustainably any further so that's a bit about you know how corporate organizations lack of support can affect the project and you know potentially be a barrier in sort of engaging and sustaining contributors but fret not there are options and there are solutions but again since this is a multifaceted problem you have to choose what works best for you and how you you should best engage the relevant stakeholders I know stakeholder is a very um corporatey term but the way ahead for many open source communities would be to a tighten and standardize their governance codes of conduct and their licensing now codes of conduct are all of these that I've mentioned actually are very important for contributors and for the participating organizations to a certain who does what and how they end up doing it so basically defining contributor that us in a way that would possibly help the you know contributor and potentially their employer or you know wherever whatever organization they're affiliated to understand how they will fit into the ecosystem and what is the level they can aspire to you know jump to would be a great starting point in this whole journey codes of conduct obviously you know is I believe a very I believe a very you know fundamental thing that should be a part of every open source community because the stronger the code of conduct the safer your contributor audience feels because it's at the end of the day community driven initiative and if there are no contributors you know if there is no safe space for the contributors to you know participate in and it is not governed by a code of conduct that enforces certain rules around the interaction there can be bad actors at play so that's that's how it works and once you have your contributor ladder defined it's also very essential to have well detailed contribution guides now I don't mean that the existing ones are really bad but they definitely could do with you know improving improving the reason being contribution guides are your are supposed to be surfaced when your contributor actually searches for you know how to get started on an open source project if that is not surfacing there is clearly a problem because they won't know where to start and that is not a very good thing given that you know you know they might be devoted at step one itself so having better contribution guides and having them surface during actual you know searches is a very important thing and I mentioned a lot about you know time zone jet lag and being more inclusive so one of the things that code of conduct does is or at least should do is promote inclusivity within you know a project but over and about that I believe that having a having an async mode of communication such as an IRC slag discord there are multiple products out there at this point so using one of those and preferring those channels to you know be avenues for decision making as opposed to you know in-person zoom meetings would be really beneficial for everyone involved primarily because a lot of us tend to view meetings and this is not blaming anyone a lot of us tend to view meetings as an avenue for decision making and if people are not able to sort of attend you know a meeting because of you know time zone problems they are not in the loop and the moment they are out of the loop it's it's a you know spiral from there so have having async meetings or slack stand-ups or discord stand-ups or whatever else is a better way to facilitate that decision making over an async platform and if we have you know if we have you know concerns over there not being actual in-person zoom meetings for certain time zones you can also actually include separate time separate meetings for the time zones that have lesser representation in your current meetings because that will help folks from that particular time zone to gather and ask questions and you know see the people who they are talking to rather than just being you know picture on slack or discord or whatever the other you know modes of communication are and of course I also spoke about linguistic differences being one of the barriers now the way we at Kubernetes you know try to solve this is by introducing documentation localization which basically is nice word for multiple language support it would help in a lot of ways because like I said before the audience that you're catering to is global and not you know country or continent specific having documentation that caters to a wider audience and a more global audience is only going to make your project more accessible and inclusive as well as diverse and like like the last like I mentioned in the last slide sorry we require more support from corporate consumers who are who have so far been passive consumers or adopters it is necessary for them to become part of that feedback loop and ensure that there are contributors to that product project because without their feedback and without their you know input the project is going to suffer from an imbalance like I mentioned and the way they can do that is by incentivizing employees to actually work on the project during company time or you know having them work on it via other you know compensatory methods but as standard it is required for them to actually incentivize their employees to work on open source projects because there is definitely an imbalance and a massive one at that if we don't you know if we actually continue doing the same that we are if we actually continue on the same path that we are on right now so um that's it from me for today and I hope you enjoyed uh you know the slightly dry presentation on a lot of community engagement thank you for you know all your time and your attention and I hope you have a great event ahead thank you once again bye bye