 All right everybody welcome to the open source on-ramp mini-conference where we explore IT topics at an introductory level Here to help us navigate to the choice of choosing an open source project is Heela Fish. Heela take it away. Thank you Hi everyone And can everybody hear me okay awesome cool So first of all, thank you for coming especially at that time of the day I know it's a bit Everybody's tired and want to go home So I really appreciate that you're here and I want to Talk to you today about open source and open source is open choice Right because everyone can use it choose when to do it and I'm gonna share with you the DevOps perspective towards open source and also when you should consider using open source and Practical tips that will help you choose the right open source project for you So first of all hi, and my name is Heela Fish. I'm a senior DevOps engineer and I work for Wix I have 15 years of experience in the tech industry Recently I have joined the AWS community builders program Which is good and allows me to expand my community, which is this is what we are all about I help co-organize a conferences in Israel where I live DevOps days Tel Aviv and starts craft more into an conference I'm a mentor in courses and communities I also manage a co-manage community in Israel called pull request for open source We have almost a 5,000 members and I'm gonna touch a bit about it at the end if I will have time I'm a DevOps culture fan. I think this is what helps companies achieve great things and I'm a lead singer and carol band as you can See this picture. It is a lot of fun Okay, so open source is basically publicly available right and can be modified at will and a lot of tools that we use in our day-to-day is open source so github and react and in Firefox and a lot of things and I will just break through a bit because it did like an issue where I forgot to close my Slack and all and I hear notifications. So just so me for me to be fully with you I'm so sorry about that. I'm professional. Don't do that Okay Okay, now I'm fully with you. Cool So all tools that we use in our day-to-day is open source and it is awesome to know because we all want to Amplify the open source a rem whenever we can so in the late 90s Open source was considered to be a bad strategy for companies and they didn't really want to open source projects or help boost this community and Starting from and coming forward from 2020 onwards. We can see that open source basically became Just a mainstream right and a lot of companies contribute to it Outsource their code and stuff like that So what's so good about open source? Let's talk. I mean, I'm sure that you all think it's good because we are in open source conference, but we will touch a bit and maybe Help amplify it even better So open source is a rich developer community right and it really is based on knowledge But without communication and collaboration. It wouldn't be at the place. It is right now and Many Sharma who's the general manager of github India He basically said that open source is an enabler of innovation and companies that a Go towards and turn to open source. It helps speed up their business Transformation which is good because we all know that if we are able to Influence the tech landscape. We can achieve a lot of good things and help shape our future So open source helps boost code quality and security because has Lionel Storvalt with which was in a panel yesterday The creation of Linux and git right he said that given enough eyeballs all bugs are shallow meaning that if you If a lot of people review the code They can spot errors and omissions and if they don't only spot them They actually correct them then the code will be in much higher quality And it will be a more secured Also adaptivity right so more use cases as long as a project has more users It will have more use cases and then the code will be a much more robust It's also encourages more modularity because it avoids the one-size-fits-all assumption Resulting in greater flexibility and lower customization costs in the long run And also agility so Open source tools usually follow modern a software development processes which leads to rapid development cycles Which leads to more frequent releases without sacrificing a quality And we have last said bureaucracy right because a proprietary software has its own development cycle And as opposed to open source with just They release projects and we can use them whenever we want and there is no Really, you know regular Stands to it right they just release it and that's that Okay, so let's talk about the devos perspective towards open source because I think that usually this is something that is more discussed from Developer angle and I want to share with you how me and I think a lot of devops and people see it So in order to understand that let's touch on the developer perspective Developers say we want functionality and we want to make sure that the code That I get from the library the open source library will get integrated in my code properly And I need to see what effort are needed to do so as opposed to that We develop we devops think about our environment and we need to think about how they project now It's not a library. It's usually a project or a tool how it will get into integrated in our environment and we have peripheral Things to consider right like security and maintenance and stuff like that So we have a lot of other things to consider when we introduce an open source project to our environment Another thing is that when it comes to challenges collaboration leads to better conclusions and solutions So a common ground between devops and open source is Collaboration and when I need help with something or I need to do some stuff I feel at least in my experience I can feel I can go to open source and Just I assume good faith and I know that they will help me because we are all a community and we want to help each other so it's very easy for me to go to open source and Achieve what I need and not as opposed to just go to a proprietor software and that's that and Since my focus is the environment I want to make sure that I have the best solution offered for my environment So since a lot of people come together a lot of people means a lot of minds and then it will surface better Conclusions and solutions which is always good because I always want to aim for the best solution possible for my environment We treat open source as tools and we ask ourselves Do we want to introduce this project to to the system because it will allow me to deliver this code? Or it will allow me to automate this or introduce this capability, right? So since a lot of devops engineers came from the system background system engineering a background or system administration background Then the concept of integration is no strange to us So you can just integrate another tool to our tool belt and our tool chain and they that's basically it So of course not everything is is bright and early a bright and good in In the world, right? And there are also risks involved and since our Focuses our environment. We want to make sure that we don't walk the boat too much So let's take for example Jenkins It is open source and I don't know one single person that is able to upgrade Jenkins version Or Jenkins plug-ins without having any Fear that something will break just last week I had an issue that someone upgraded because he said it's only a version No, and even the whole bit didn't work. So it is Something to consider and we want to make sure we don't Rock the boat too much and we also have a lot of variety out there, right? A lot of car a project that we need to think about is this good enough is this cover my use case and a lot of Things to consider with a certain complexities like Jenkins also Kubernetes has its own dependencies and stuff like that So we have these trade-offs all the time of if I want to upgrade now because it's worth it And I need this version and these features right now Or I should wait and not work the boat too much because I care about the environment and the environment stability and In the middle of everything we have the research So each time I have a project to to consider whether to integrate or not I read about it I Google it. I see videos overviews to make sure that I really know what I introduce to the environment And other things that we always need to keep tabs and being formed of what's going on and I will explain for example Let's take CentOS CentOS Operating system rich end-of-life at the end of 2021 if I didn't know about that Then I'm putting my systems at risk because end-of-life means no security patches getting released So I should be informed and know what's going on because if not my systems will be at risk and another Another option or example that I can give you is that let's say I found an open-source tool Version 1.0 is not that great but If I wait and see and follow the project status I will see that hey version 2.0 is good because that bug fixed that bug was fixed and This feature that I waited because that this feature really fits my use case now got released So now this version is good for me. So that's why a Keeping tabs and getting informed of what's going on is very very important not only in the open-source realm But also as a DevOps engineer or any engineer for that matter And I really like this picture because it says keep moving people without as you can see no one is there because this is the mindset You should always be proactive and think Of what's going on and check what's going on and keep tabs without having your team leader Breathing down your neck and saying hey, please check this and this because I think this way You will be a better engineer in my opinion Okay, so when should we consider a open source because there are a lot of Scenarios, let's cover. I think I don't think these are the entirety, but these are the major ones in my opinion So uncommon use case I can share with you an example in which I in one of my previous jobs I used we had Applications running on Kubernetes on GKE And there was a certain application that didn't need to run all the time And we want to save some money right because if it doesn't have to run all the time why should it and at that time GKE I don't I think it's still the case now GKE allows only downscaling to one the pods to one and not to zero so we search online and found and wanted to see if there is a solution for that and we found a Tool called Keda Keda is awesome tool production ready And it allows you to downscale ports to one based on several Criteria's like pop sub a consumption and some stuff like that So once we found this option awesome We can use that and it was really fitted our use case and basically that's that so if you have an uncommon use case You can Google for an open source tool that will maybe cover that use case for you Limited budget so of course if you don't have the budget for it You can either use a free version of a proprietary software or use an open source and boost open source while you're at it And the thing about it is you need to think about that the lower total cost of ownership So open source is usually free, right? You need to check the licenses I will also touch a bit about it later on but it's usually free and proprietary software isn't and there is the same amount of a training in maintenance and integration time That and efforts that are invested a whether you choose to integrate an open source tool or proprietary software, so If you know it's equally invested might as well Choose the open source option if you don't really have You know something very critical that prevents you from choosing that Okay, so you know This is pretty much the straightforward one When you have insufficient in-house resources ability wise like this family guy right here or capacity wise to either create a solution from scratch or to enhance Something of your own then you can just go to open source tool and and use one that fits your needs because there was also this saying why reinvent the wheel right so if the If there is already an open source tool that covers your needs So just use that and that's that Okay, so we covered of why to choose open source and good things that come out of using open source But like everything in life. We have also disadvantages So of course again, these are not the only ones that available But these are the ones that I thought that it's really worth mentioning so first of all a security by obscurity this concept is not applied right because a Close source companies can say that since they are closed source Huckers can't view the code for a you know spot a security loopholes and stuff like that. So this Notion doesn't apply on open source and something to just to think about and bear in mind when we choose an open source project Born to abuse so It doesn't happen a lot I would say because people are usually good especially open source Contributors they want to achieve good and create good things but sometimes stuff happen, right? And I have two examples in mind One of them is the colors npm package in which the maintainer added a loop in the code and a lot of a lot of companies suffered from it and another Example is the fake address package in which the maintainer had a bankruptcy And then the next version that he released was actually to delete the project He removed this project in it in its entirety So it doesn't happen a lot and you can say yeah I will I can just put maybe if it's a library I can put the Version in packages Jason Locke or requirements the XT and that's that but if everyone would do it I wouldn't be here talking to you about this scenario because probably not a lot of people would hear about it And I'm from Israel. I'm all the way there. So It is happening it could happen So we need to just bear that in mind and and think about it when we choose open source project Compliance so in its raw form a open source tools and and libraries doesn't a provide like a warranty or a The call the world official guarantee is what I want or official guarantee for a compliance So there are companies that needs that right they had they need to be compliant They need to do some regulations and audits and stuff like that. So it's also something to consider when and Going down this path It's not always free right you need to examine the licenses carefully before you Choose an open source project, especially if you choose it because of a budget thing This continued projects so not all projects are Backed up by vendors a lot of projects are maintained by people like you and me so they can you know just decide to stop Maintaining the project and it's okay that this is their prerogative, right? So if that's the case and you chose an open source project and integrated and it got Discontinued then it means that either you need to migrate to another solution Or you will be the ones to maintain this project from now on so it's also something to consider Support is not guaranteed. So you need to assume good faith, but as I mentioned with Kedah I I do assume good faith and we had just before it became production I had some issues with it. I opened the PR. I explained the issue and said please guys It's going to be production very very soon I would really appreciate your help with that and they released a verdict for me It was really not a not no business hours. Okay, it was I think Saturday or something like that So they were really really helpful So yeah support is not guaranteed. You should really assume good faith, but like a disclaimer proprietary software does and Provide a support guarantee, but it doesn't guarantee the support will be good so just something to think about and Sus alternatives, it's not really the opposite of open source, but a lot of companies will Sense a lot of companies shift more and more Resources to the cloud then you we will see more and more adaptations of men's services because a lot of companies prefer to have a Like a cloud lock scenario rather than have their DevOps teams maintain open source tools So to some things up in regards to adapting a open source in general, there is no right or wrong It's a matter of perspective and there are multiple factors to consider. So you should they choose the best open source project that fits your needs and Speaking about fits your needs How do we choose an open source project because there are a lot of projects out there and maybe I googled My use case and found two three options So let's see how we can choose the right one that fits our needs So first of all, these are the questions that you can basically ask yourself in order to to get this To to have this understanding so I'm gonna cover popularity activity readiness documentation ecosystem is of use and roadmap. So let's cover each one a Popularity so check how many github styles the project has It's not always the the only thing that you should Check because a lot of companies a lot of product open source projects does have a vendor behind them So maybe they have also marketing and stuff like that. So don't look only about and the github styles but coupled with other And metrics as well Is the project part of CNCF and incubator because if so it means that you have a stamp that this project is probably popular and Follows certain standards that will mean that this project is mature enough to use You should Google the project alone to check for online presence But you should also Google it versus similar products to check for reviews and see maybe Someone said something about the use case or issues that they had that will Be relevant for you as well Activity so check the commit rate. Are they daily weekly monthly? How many issues are there? How many releases are there? Are there is the product maintained by one developer or more is the product has? Sponsored believe in the product future and willing to put good money to to see the project Evolve so all of these questions are meant for you to understand that if you decide to integrate this Project and you will need maybe bug fixes or you will need features. How long should you wait until you get those? So if you have a heavy use case, you probably wouldn't go with a project that is not very Active because if you will have issues, you wouldn't have any support with that because it's not very active So this is very important Especially for heavy use case to know how active is the project Um documentation so Not a petition sorry readiness So is the because I see the next slide in my computer. So it's a bit confusing. So readiness Is the project declared as a production ready third times a charm? I'm gonna mention Kedda again. So Kedda is production ready They declare it is such where I saw use cases of users in production so it is awesome for me as a DevOps engineer to know that is production ready because I Care about the environment and if something is production ready, it means that it will be good for the production environment are the current features enough to sustain usage and Is my use case covered fully in the current state and if not am I okay with it? Because if not, maybe as I said, maybe we need to wait for the next version to come out That will be more a suitable for my needs documentation so I think and correct me if I'm wrong afterwards but The condition is like the gateway for the project right? You don't know anything about this project and the condition is your way to understand Stuff like how to integrate and known issues and explanations about features. So this will help you understand how maturities and how well thought of and The extent of the features and which bugs are there So the conversation is very very important when you face a new project that you need to integrate It will help you in the integration process. It will help you in your day-to-day maintenance So if a project is not well documented probably I wouldn't say just still way like In its entirety, but it is something to consider because Because documentation and ecosystem in which I will cover in a bit is very very important to your day-to-day Ecosystem so I think this is the most important metric out there because this is the metric that will help you In your day-to-day and I will give you an example for that in one of my previous jobs I used a randek as the CI tool and back at the time The documentation wasn't really good in my opinion and the ecosystem was pretty much small So I had to create more flows and introduce more capabilities It was pretty hard because I didn't have Documentation or the ecosystem to reach out to as opposed to that in other company that I work for I use Jenkins and you can say a lot of things about Jenkins, but the ecosystem is very very big They have their own slack workspace. So you can Use the committee to help you with a lot of issues. So Ecosystem is very very important because it will help you in your day-to-day So because think about it this way integration of a tool is in one time, right? So if the integration was hard That's okay because you don't do it a lot and you can also create the condition after that to help you with the integration process And make it better and easier next time But the documentation and ecosystem are the ones that help you in your day-to-day and will help you maintain it easier In the long run when you use it a daily. So, yeah And finally not finally it's very confusing to have the next slide Never mind. So easy views do appear see see how well the project got integrated in your environment and also the ratio between The amount of time to implement until the integration is done So, you know What to say time is it stuff internally on your company or the documentation wasn't great enough to and to Explain how to integrate properly and stuff like that and another important reason Another important thing to to consider is check the issues how the issues on GitHub about features or about how do I do X? Because if the issues are about how do I do X probably it's not that easy to use that project So you also need to think about it And finally road map. So is the project defined as an open source or is it planned to go towards my monetization? Which means it will be a soon close source Some come some may projects declare that so that way that way you can I know about it and also features planning so if the project is well thought of and you know that Features are planned ahead and they know what they are going to introduce and they know what they are planning to do then Hey, you can you know check and see maybe are you I will wait for the next version that has this feature and Be you know that these it is active and very well maintained and thought of you can also check again Keda, I know I they didn't pay me to to say that I promise you so Keda They have like a very well thought of feature planning. They announce it. So it is very well maintained so Road map is also good to understand What's going to be happen in the future with this project? So yeah, so I covered all these questions So to sum things up in regards to how to choose an open source project You should ask the general questions to cover the basics Meaning is the project in a ready enough state to you to be used or not? And you should cover and and ask the tail specific questions for your use case and your pain points So for example, if you have a heavy use case you should focus and put the emphasis on the documentation and ecosystem metric as I explained a bit before and if you for example don't have capacity for Maintenance, then you should focus and put the emphasis on the readiness and ease of use a matrix so choose the ones and put the weight on the ones that fit your use case and your pain points and then You will know that these projects will be more suitable for your needs And do do a PRC see how well it gets integrated in your environment and rely on your research so ecosystem for the win and engage in github and raise issues and basically that way you will contribute to the project success and eventually your success and Small token for me just before we wrap up if you want to contribute to open source Without writing a single line of code because you don't know how to write code or because you don't have the time to do it so these are the ways that I thought about Open issues bug issues or feature requests that way this project will get enhanced and more Users will be able to use that Documentation documentation is very very very important as I explained before and writing documentation is a skill So if you have the skill leverage it because that way the documentation of the project could be more enhanced more Thorough and as you saw it is a metric to choose a project So maybe people will adopt this specific project that you Contributed documentation for just because of you just because of the stuff that you added So it's very very important and even if you have this Skill please leverage it. I will thank you everyone will thank you Share your use case for example I've written a blog post about the script server which is an open source tool that make Terraform code and Ansible and other scripts Available through UI and it was good because I wanted to make a Non-techie people use stuff and without ability to win stuff and it has also a permissions mechanism So I wrote a blog post about it and hopefully that way people knew about this project and maybe adopted it And I showed you know open source to the world and saw that to show that We have good things going on Share other tools that you found with your colleagues and techie friends because if they know about it, they can use it Sponsorship, you know money makes the world go around and money always is good to help tools that needs to be maintained and sometimes they rely on that money to Keep maintaining this project. So if you're able to chip in Individually or have your company sponsor a project. This is awesome to have hold an open source mindset, so Think about it this way if I have a use case I can go to search for a proprietary software that covers my use case or I can Google for an open source solution that will help me and be Not less good as the proprietary software option and if I do it I can share it with my Environment at work team members or other teams and they maybe Will get inspired by that and will start thinking about open source themselves so open source mindset is good because others can get inspired and do it as well and Last but not least spread the world on open source on conferences like I'm doing just now And I think I have a little bit more time to cover another thing that I'm doing in regards of open source I Co-manage an open source community in Facebook called pull request in Israel where I live we have almost 5,000 members and We try to do you know workshops and stuff like that to help push people to contribute more and more to open source And one of the initiatives that we have called a open source rail like dev rel but open source Well, so as I've written in this report Repository you will find testimonies by companies stating their vision about open source and how they actively contribute to the open source Well, so you will find a lot of things. I mean it just started out so you see only a few companies but It covers a lot of things that they do like Works for example they I work for weeks, but you know, I will cover another example. So you you won't think I'm biased Checkmarks they release a project to open source. They have like a slack channel that helps others contribute as well. So You can read about it. And if you have this is Omnum Omnum. I had a Hebrew word coming out. Sorry if if This is a this is a Community in Israel, but it's not only for Israeli because as you can see I've written in English. I have also a Hebrew edition But if you want to have your company featured in this and I will share it with the Israeli Community, but not only will share it also in LinkedIn stuff like that It will help amplify open source as it's very important, you know, this track is called open source on ramp we want to Help amplify the open source voice and have a good PR for our company Why not and the reason why we did it like Individuals why we did this initiative is since this is an open source community It means that a lot of people there are passionate about open source and they contribute in their spare time so think about it this way if I contribute to open source and I care about it deeply and then I see companies that Actually dedicate a week in a quarter. Okay, not a month in a quarter to contribute to open source a During the time the work hours like weeks does then it makes me want to go work for this company because I want to I want to contribute to open source in that time And I want to be in a company that share my values About open source like that. So this is also good to know for me because that way I can actually choose The next company that I work for because of that. So if you want to have your Company featured you can reach out to me If not, you can just read and get inspired and maybe show it to other companies And maybe they will get inspired to do more and more stuff in the open source realm And you know, this is our way to try and boost open source in Israel So, yeah, that's it. I hope that I will were able to Demonstrate both the DevOps perspective amplify the open source voice and give you Practical tips as I showed of how to select an open source project because there are a lot of project out there So we need sometimes this guidance So I hope the questions that I showed you will provide you the guidance that you need to adopt open source in your environment Thank you so much. And I think we have time for questions. So if you have any questions Feel free Going once. Ah There is one out there Do we have a mic or just speak up? We have a mic Hi, hi, I start with a disclaimer. I'm a security person. So important. Yeah quite many of the Criteria's that you have listed. They also help Choosing software that will be also secure and not just popular Okay, so But my question is when you are choosing a software for your DevOps installation do you also look at Pending bugs for example security vulnerabilities and such issues and I Can tell you that Some time ago. I haven't but since the you know all the supply chain issues that surface today is As the examples that I gave of the colors and PM and stuff like that. They surface more and more Recently then I am also looking at that. I could I can't say it's the main thing that I look because usually We use tools that not that are pretty Boxed and since I don't integrate them in code but integrated in environment Then we are not as exposed as it's when it's integrated in code But nevertheless, I do look at that and maybe I will also edit and refine my presentation because of it because it really is important and it's Not always people think about security as they should so if I can help, you know Amplify amplify that as well. I will do it and thank you for that So for sure it's something that needs to be considered and and I will also check How and and discuss it with other DevOps engineers how they Perceive it in regards to our tools and our toolchain that we use so thanks for that Anything else? Yeah, I will repeat the questions if you didn't hear for people that want to contribute to open source and and Open source tools in the DevOps realm and not specifically code how they do it if they are not seniors and juniors So the way for DevOps to contribute to open source is usually the peripheral stuff like not writing the call itself But help with the GitHub actions or help with the CICD of a project or the commutation or If it's Kubernetes then maybe help with the operators and stuff like that So more in the peripheral stuff and not like hard code code because not all DevOps engineers know how to write code as Programmers, but I really believe that a lot of you can see a lot of open source tools that have like a foot a first good issue then They should be doing it doing it for for every tool because since you want to help ease people into You know contributing to that project then everyone should have like a first good commit and But this is in general But also the fact that the other DevOps contributions are usually in the peripheral that makes us feel comfortable that Okay, this is my area of expertise the CICD to make it a more maintained or more rich, you know have greater reach so that way even if we are Juniors since we know this is what expected of us then juniors will know that okay This is a good time to practice it It's best to do it in an open source and not in production and I hope that this will help them Feel that they can do it just right off the bat and not be afraid of that Anything else? Okay. Thank you so much for being here. I really appreciate it. Thank you