%% date:: [[2023-11-14]] parent:: %% # [[Becoming an open sourcerer]] conference:: [[Agile Testing Days 2023]] speaker:: [[Craig Risi]] > Become a wizard in working with and testing open-source software > [!abstract] Abstract > We live in a tech world filled with hundreds of tools all offering to be the next big thing on the market. However, while many of these tools are fantastic, they don’t always live up to the type and leave many companies never regaining full ROI from their investment in them. > > This is what has led many companies to focus on open-source tooling instead. But making the move to open-source software is not a straightforward one, whether it be at a development, DevOps, or testing level. And so, in this talk, I will highlight the benefits and potential risks facing teams who are looking to make the move towards greater open-source adoption. It’s more than just utilizing tools though and there is a need for a specific skill set to achieve this too and so I will also focus on some technical skills that can be developed that can help testers be better prepared for working with open-source tools and help prepare them teams for greater success. > > Outline for Talk: > > - Benefits and pitfalls of open-source adoption > > - Strategies for working with open-source tools > > - Provide some skills in how to work effectively with open-source tools > > - Testing approaches to working with open-source software [[Open source]] has always been considered a bit of a dark art or a swear word for big companies, but no longer. - [[Risci Games]] - Book: *Quality by Design: Designing quality software systems* - From [[Cape Town]], [[South Africa]] Disclaimer: Non-open-source tools are not evil. Why go open-source? - Save money? But there are some situations where it's not about money (such as in high security environments). Where do you want to use open-source? - Processes, CRM, automation, app dev? Which areas? - Low hanging fruit of things that are easily open-sourced. Advantages - Cost - Flexibility - Shared experience: There are few truly unique problems that someone hasn't solved somewhere. - Not needing to reinvent the wheel - Community support - Benefitting from recent advancements - Upgrading developer skills - Engagement and retention - Disadvantages - Support - Documentation - Complexity - Need for customisation - Vulnerabilities: But nowadays, he would argue that open-source is actually safer. - Risk Types of open source models - Company-led model - Mostly closed model: one entity controls design, development and releases - Final release is open source - May be external contributions, opinions, reviews - No external discussion, reviews, controversies - Ex: [[Android]] - Benevolent dictatorship - strong leadership - One individual makes the final decision/overriding influence - Depends on the dictator's wisdom - Avoids endless discussions - Ex: [[Linux]] - Governing board model - Complete open process - Small group, tight control - Democratic votes might be needed - Tends to have fewer releases and slower - Ex: [[FreeBSD]], [[Debian]] Deploying open-source software into an organization - Know your strengths (as an org) - Understand licensing models available - Open-source is not always free. - Start off in a trial environment - Make provision for Iplementation costs - Create governance structures around your open-source code - Strong CI/CD pipelines - Guidelines in place to with other people's code Technical preparations - Security scanning - Load and performance testing (component level, not just end-to-end) - Automate testing pipelines - Maintenance - Community involvement - Helps you understand the software and community better - Have clear processes for deployment Successfully integrating open source - Open source is not always free - understand legal implications - Don't change the open-source solution directly - Put together guidelines for integration - Document open-source implementation - Allow time for defect fixes What about personal projects? - Find projects that interest you - Pick issues to work on - particularly those that you are interested in or those that are relevant to your work too - Start by sticking to your strengths: coding, testing, documenting, CI/CD, project management - Collaborate and gather feedback - Jump into reviewing pull requests - Challenge yourself