Getting the Most Out of Open Source with Yousaf Nabi

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey it's Joe and welcome to another episode. Really excited to dive into an awesome topic on open source compatibility and all the things that that entails with Yousef. If you don't know, Yousef is a developer advocate at SmartBear. He began his tech journey, which I think is really cool, especially nowadays with the focus on AI and ethics, aiming to steer clear of Skynet like future. Hopefully he has some thoughts around that. He discovered his passion for software testing during an accessibility testing placement, appreciating its impact on enhancing life through well designed software. Throughout his career he has really embraced various roles with a constant emphasis on quality. He's now a seasoned developer advocate at PacFlow and a community shepherd at Pack. He's also proud to contribute to prominent open source tools and Smart Bear's suite of solutions, leveraging his extensive toolkit to advocate for and nurture the open source community. That's what we'll be talking all about today. You don't want to miss it. Check it out. Oh hey, before we get into it, if you want to worry less about testing and deploying in distributed Systems in your DevOps lifecycle, then you definitely want to check out smart bears. PackFlow. PacFlow makes contract testing accessible to everyone on your team. So say farewell to costly flaky tests and increase your developer confidence. Check them out now and support the show by using the Link Test Guild Me packflow and you can find that link down below. Hi Yousef, welcome to the Guild.

Hey Joe, that was a mouthful. I do indeed wear many, many hats and I think the one I'll be talking about most today is the open source one. Really pleased to be joining you. I've had the great fortune of seeing your show and many of the guests on here, so I'm honored to be amongst them.

Thank you so much. It's an honor to have you. Really. You have an awesome background. Seems like you've done a lot of different things. Just curious to get an idea of like maybe give us a journey. Where did you start? How did you enter into Open source software? What initially drew you to this field?

Yeah, sure. So I suppose I was born in 1984 and loved the George Orwell novel that shares the same year. I remember kind of late in my dad's life he got into computing. He bought a computer and it had a hard drive in it. I think it was measured in kilobits at that time. And I got a stool and I'd sit there for many hours kind of watching my dad be mesmerized by this computer. And I eventually got a computer of my own. And we didn't have much money growing up and there was this advent of freeware and shareware kind of software. So you could get software and you could download it from various sources and normally you won't get the source code behind it, but you'd be able to get functionality. And that was versus paying for a commercial tool suite. And obviously being a child kind of exploring the Internet that wasn't. Those paid tools weren't accessible to me. So I was really interested in this idea of just trying out new tools and technology. And you mentioned that I moved into an accessibility testing role and I got to see the joy that software testing and quality could bring to users. And through after moving from university into a testing career, it was predominantly manual testing. So and when we, there came a point where automation testing kind of came into the fold and people were worried about automation testing replacing manual testers jobs. And we kind of saw it as an avenue to allow us to work kind of smarter, not harder. So we were able to use these automated testing tools to kind of replace the checking jobs. So they're really boring kind of testing tasks and free us up to, to use our mental brain to explore other avenues of quality and software. So was able to use some of those technical skills I'd gathered at university that hadn't really exercised in my manual testing career. And we had to do some automated testing. So I immediately kind of leveraged open source tools because I knew that if I was to buy a commercial testing tool, I would have kind of, not only would I have to implement that tool, but I'd probably have to make a business case in justification to my organization to purchase that tool. I'm sure that this is a topic that might be familiar to some of your listeners. Imposter syndrome.

Oh yeah.

So I've moved into an organization, I've not really flexed these automation skills in a professional job before. I've been tasked with kind of implementing an automation testing framework and you know, if I do all this coding in my work time, I might be exposed as being a fraud and not being as technical as I'm supposed to be. So being able to leverage these open source tools that were accessible to me via mediums like GitHub. So over the course of my lifetime, kind of git which created by Linus Torvald of Linux fame, that kind of took off in terms of allowing people to collaborate and share code. So GitHub was kind of the place where if you googled for a particular testing tool, you might be to GitHub and you could see the source code. So after picking up this kind of source code for an open source testing project, I was able to play with it in my own kind of space, locally at home and kind of exercise some of these testing strategies that I wanted to exercise. And then I was able to bring them into my organization so that access to these open source testing technologies and the freedom to be able to play with them in my own time allowed me to gain skills and kind of battle that imposter syndrome.

Love it. So I think a lot of people struggle with that. I think a lot of people also have a lot of angst nowadays. I don't want to focus a lot in on this, but I know you do have a focus on AI and ethics. If you were to start your journey now with open source, do you see AI playing any role as in making people that think have an imposter syndrome or even like, why even get into this if I'm gonna be replaced? Any thoughts around AI and open source and maybe how it can help with open source or help people learn better and become better developers?

Yeah, sure. I think it's hard. Open source has been around collaboration, it always has been in sharing knowledge. And despite the, you know, we'll see there's AI, there's like the commercial sector of AI and there's this open source sector of AI and AI itself, the computation behind it, it's computationally expensive and at the moment a lot of that computation is done on GPUs. So graphics cards. So that's led to. Any gamer will know there's been a shortage of of graphics cards not just for bitcoin mining in the past, but now for AI. So if you need a lot of GPU compute power that is out of the reach for the individual open source contributor, they might have a single graphics card at home, but they can't compete with the likes of OpenAI and Microsoft and others. But with open source people can still freely share their code, they can share learning models. So there's a particular thing called hugging face believe and lots of people are sharing their learning models on there. So open source here is allowing people to have access to the Tools and technologies that power these large language models, but not necessarily the COMPUTE power in order to really leverage that usage of that. Now I've seen over the course of my career with open source that there's lots of large open source projects that are also backed by commercial organizations. So we could take AWS and their cdk, their cloud development kit, that's been largely open source and it's seen huge reams of contributions through doing so. And there's often been large partnerships between commercial organizations and open source projects. So Linux is an example of that. There's people who pay for support and stability through organizations like Red Hat and other providers, but also people appreciate the freedom of having that source code available to them so they can innovate on the bleeding edge. So I would imagine that a lot of these commercial players with access to the AI GPU COMPUTE power will more than likely provide that to the open source, probably with restrictions. So if you imagine as a. Let's take if I'm working in the open source, you can use CI CD systems to test your projects now that compute is taking place on someone else's computer. So for example it might be GitHub self hosted runners with GitHub actions. They need to put mitigations in place that you're not running, you know, bitcoin miners or you know, you're actually doing stuff for your your code purposes. So the same kind it may be that. And I believe I've been seeing some announcements from GitHub that they'll be actually opening up GPU based runners for doing AI compute. I would imagine they will allot a certain amount of open source capacity. So like runner minutes for open source projects. And a lot of these commercial organizations have open source supported programs that can allow you to leverage these either for research purposes or for furthering open source development.

Awesome. That'd be great development for sure. So you know, what are some maybe misconceptions people might have with engaging with open source projects? Because I notice a lot of projects it's always seems to be like one or two core contributors that seem to get burned out over time. They're always getting hammered and like people kind of complaining, not necessarily contributing. So I don't know any misconceptions people might have around open source around that.

Yeah, sure. Oh, there's probably loads, but I'll just, I'm just going to pick on a couple from the top of my head. So there's this weird trade off between open source I've talked a couple of times maybe about Access to money because we're poor and we grew up like Open Source isn't free. It's not free in terms of it's not free to use it because there's a cost involved, I suppose, in using any software because you have to kind of read it and understand it and be able to use it and integrate it in your workflow. But there's a license. Open Source licenses probably have a line in it saying no warranty implied or given, but you might have an expectation that the software you're looking at works or works for the purpose that you want it to. You know, you've probably googled, you try to do something and you want this tool really to do something, otherwise it's not going to meet your expectations and you don't want it to waste your time. So I think a misconception with Open Source is that it can be free. Sometimes Open source software is free to look at and it can be free to use, but unless the software comes, say in binary form, you might have to build that project and that some people just want to be able to use a product and be able to get on with their day job. A lot of the times you're using tools and they are means to an end. So for example, if you're a software engineer and you work for a large furniture company, your business is probably your core business is selling furniture. It's not building the tools that build your software empire. So the being able to select an open source project is based on its viability is important. And that viability can come in many forms. So you mentioned about a kind of a single maintainer or a couple of core maintainers, and that might be versus many, many, many stars on a repo. So you might see there's a lot of users to a single couple of maintainers. Most repositories may have things like contributing guidelines or some kind of blurb from those authors or contributors as to what their aims are for the project and how they feel about contributions to that project. So it might be that the project does most of what you want it to do, but there are aspects of the project that you wish to change or improve, or it doesn't quite hit the mark. So if the author has put contribution guidelines that may allow for that, you can engage with the project through issues or pull requests and kind of provide hopefully constructive criticism or input into improving that project. You can also have the ability to what's known as fork a project. So forking a project allows you to effectively take a clone of that repository in its current state and you can actually make the changes to that project yourself. Now, you don't necessarily need to contribute those changes back to the original project. It may be that the original project did 90% of what you were aiming to do originally. But for your niche use case you needed this additional extra thing. It might be that other people really like that thing that you are doing. And now you become a maintainer of a project that people are reliant on. I'm in that situation both in a personal capacity and a professional capacity. So I've got some open source projects that I look after that people use that are under my own, that I've just created myself and they were just out of a need. And interestingly, the reason I created this project, it's a Slack reporter for Cypress, a testing tool. And I actually was reading a blog post and the blog post implored someone at the end of reading a blog post to kind of take some of the ideas from this blog post and extend it. And I extended that and I put it in a repository and I wanted to learn about packaging a project and publishing it to npm. And I did so. And lots of people ended up consuming the project. Now there's a burden in maintaining it and sometimes you don't get round to doing stuff. But as a maintainer, there are things you can do to make your life easier. So for example, we talked about CICD systems and automation. You can use automation apps to update your dependencies, you can use automation to release your projects to various, you know, to the packaging sources they're going to go to, if it's npm, etc. If you are looking at a project and there's only a couple of core maintainers and it does the things that you want it to do, but it doesn't have some of the key features that you feel will be there for longevity. The beauty of an open source project is you can add those additional features. So if, for example, the project, you wish that project to stay maintained for the future and you feel that a single maintainer might not be able to do that, you could propose that they put automation in to update their dependencies. Now that's a really great way you can aid that maintainer and say to them, hey, I'm using your project, I find it really valuable, here's an improvement that will ease the burden on you in the future. But sometimes even just jumping in on the project and saying, hey, I think your project is awesome, keep doing what you're doing can just Be enough to kind of maybe to get me to open my laptop up on a Saturday and publish a new release of the package.

Awesome. You know, I get asked a lot of questions from people, hey, I'm just starting out or I've been laid off. How do I get attention of companies? Or how can I set myself apart? I always think contributing to an open source project would help. Maybe I'm wrong. I haven't done it myself, but except promoting open source. Open source project. So I guess my question is how has contributing to open source shaped your career, particularly in your role at SmartBear Software and with PacFlow? I guess.

Yeah, sure thing. So I'll hark back to imposter syndrome again. So I joined a computer consultancy firm around six years ago and I felt a massive burden of imposter syndrome. I was just around incredibly technically smart people and they were really gifted with sharing their learning. And I was talking about contract testing. I'd previously kind of built a kind of contract testing solution homegrown in house. And as I was talking to my team, the previous team had experience in using pact, an open source tool. So I looked at the project and it looked brilliant. It could do all the things that I previously home rolled and it had a great level of adoption. So I knew that there would be. I wouldn't have to reinvent the wheel. They also had a supportive Slack community that was really active. So as I was trialing out my usage in the software, I could engage with people in this Slack community. And Slack was really useful for us because we had Slack in our work as well. So as I began to use the Patch project, I came across certain impediments in the project. So either bugs or features that I felt would be beneficial to me or to the project. So I began to add these fixes and pull requests into the project. And one of the engineers at my work actually wrote a blog post and he highlighted some of the fixes and bugs and features that I was introducing to the PACT framework. So, so that kind of spurred me on. And I remember reading blog posts from people in the past from when I'd been stuck on something and it helped me. So I thought, I need to play it forward. I'll start writing some blog posts about the work I've been doing. And I remember I got a phone call or a Slack message from work and a client had a problem and they'd actually came across my blog post, one of my blog posts. So I kind of got flown in via Zoom call to help this guy out. And he felt honored to have gone from a blog post on the Internet to getting someone on a zoom call who'd authored that post. And then to cut kind of a very long story short, when the Pact project has something called a Pact Broker, which is a place to store your Pact contract and you have to self host comes as a Docker image, so people kept asking the PACT maintainers, can we have a self hosted version? So that was kind of the beginnings of Pact Flow, the commercial arm. And because Pact ended up being so beneficial for me in overcoming my imposter syndrome and gaining being able to elevate my career in terms of work, I remember saying to the Pact Flow team, if you guys need any support at all, just give me a shout, I'll help you out. It's the least I can do. And about two or three years later, as Pact Flow had massively grown along with Pact in popularity, because contract testing had gone from kind of a nascent topic to being the tip of people's minds, Smart Bear saw the value in integrating that into a wider view of the holistic kind of view of delivering software, where it evolves around a suite of techniques and you are going to ultimately need a range of tools to facilitate those techniques to deliver your quality software. So Smart Bear, as we got adopted both pact and the Pactflow project into SmartBear, we actually had the great fortune of sitting alongside other open source tools. So I think in chronological order we have SOAP ui, Cucumber Swagger, or Open API as it's now known, and Pact. And we've recently acquired the Stoplight tool set, which includes Prism Spectral and Elements, which are a tool set around the Open API suite. So I'm sure, Joe, you've used Cucumber and Swagger and heard of them throughout your career in SOAP ui. So from my humble beginnings of kind of writing a blog post or being picked up from an engineer in my work, I very much looked up to, he picked up on these changes I was making to be able to sit alongside, you know, at that first career I was using SOAP UI as an end user and now I'm potentially responsible for its fate. I've gone from using SoapUI as a user kind of six years ago to being a custodian of the project and its friends now within SmartBear. So I'm really honored that SmartBear saw the value in that and we get to join awesome open source friends.

Nice. Yeah, like almost 14 years ago, I guess. SoapUI was one of my first viral YouTube videos. It was like just on setting it up and doing a quick test. So love SoapUI.

Incredible if you can set someone up for a quick test in soapui, it's golden material really, for sure.

So I've been working with Smart Bi forever. I've been aware with them forever. What's it like when they acquire a company, say like Pack or pacflow? If someone is into open source, sometimes they may not understand what that means or be worried. Can we just dive into what does that mean when a vendor acquires an open source project? And are there any steps that someone needs to worry about or think about in order to continue using the project?

Yeah, sure, definitely. It's going to vary massively from vendor to vendor and acquisition to acquisition. However, a lot of the concerns from open source users, maintainers and contributors to the project are often the same. So they often wonder about the future of the project. Will the open source project change in any material way? So be it the licensing, the pricing structure, features, etc. Or the kind of frequency of changes or potentially how those features get folded into a commercial project. So they were definitely concerns of mine as I was part of the Smart Bear to Pack, sorry, the Smart Bear acquisition of PACT Flow and by nature their kind of adoption and support of the PACT open source project. So prior to being adopted by Smart Bear, they felt that pactflow felt it was incumbent on them to employ a community shepherd. So someone who was kind of tasked with looking after the best interests of the project and ensuring that. And this goal is very particular to our project. Our project has been around empowering the particular the project. PACT is around contract testing and is around testing service to service integrations without the need for integration tests. And we want to do that and make that accessible for as many people and as many languages, programming languages as possible. So that's why the framework has been designed in its particular way. So we don't want barriers in terms of monetary or kind of licensing restrictions to be in place of that. We want to make, we want software to be better for everyone, for developers and for end users. So part of that is making a framework that supports building quality software openly accessible. Our existing licenses predominantly MIT, but we have some Apache 2.0 and we don't foresee them closing. Now I looked at the history and track record of SOAP UI of Cucumber and Swagger and see that they're still thriving communities since Smart Bear have adopted those communities. However, I do know that Smart Bear have grown organically through acquiring many different companies and adopting many different open Source projects As you'll see over the course of SmartBiz kind of this year and next year we'll be moving towards an API A3 hub strategy. So API Insight and Test hub where we're beginning to consolidate our product sets into solutions. So and as part of that we'll be started up a developer relations team. So I'm a member of the developer relations team along with Joe Lang who's a community shepherd and Frank Kilcommins as our technical evangelist and part of the developer relations team. Working with SmartBear is to kind of project our open source strategy publicly so that people know how how we feel about open source, where we plan to go with it, how people can contribute to it and where their contributions will go. Because I think setting clear expectations is really key to allaying people's fears at takeover. So if people are curious about what kind of kind communication, well hopefully in my eyes looks like and you can Google kind of Smart Bear, Pact Flow or why we Love OSS and that goes through It's a post from our founding members who kind of started the open source project as to why the commercial project came into existence, why we felt Smart Bear was the right vendor to kind of acquire us adopt the open source project and what it means for the future. What we have seen from contributors is as Pact Flow itself has enabled people to get on board with Pact sooner because they don't have to self host this Pact broker. We've seen an uptick in users both in Pact and Pact Flow and that in turn has seen people with issues or the need for new features and they've been driving into our ecosystem. So our ecosystem is growing through making the software easier to use. And that kind of brings us back to my hat in developer relations as a developer advocate, which is finding those sticking points for engineers and users and kind of going around and either sticking plasters on them or finding the right person to fix them.

So with AI, besides what you mentioned, I know with PacFlow, are you is there anything on the roadmap to work it into AI? And I guess that's one of the benefits of working with a vendor. Any thoughts on that or anything on your roadmap with AI?

Yes, there's loads of things happening in the SmartBear camp around AI and we can't wait to share some of them. We've recently acquired Reflect Run and we'll be bringing more of that AI capabilities into our product. But one of the recent things has been happening in pactflow to ease one of our biggest Pain Points, which is generating contract tests is PacFlow have been developing a generative AI feature. So this is a kind of modification of OpenAI that has pact Flow specific knowledge or PACT specific knowledge that's been baked in from our engineers that will allow people to quickly onboard themselves with contract testing. So currently we've been trying it out in Java and JavaScript and TypeScript. These will effectively allow people to generate code generate code from an open API spec, or they could use an open API spec and their own client code in order to provide kind of richer context. Or we can do it from request and response pairs. So we're really beginning to roll that out to users as part of our Developer Preview program. So if anyone wants to get in contact with me and they'll be able to check the contact details at the end of the show where they can get involved in that Developer Preview program and we can give them early access and we'll look forward to sharing details of that later in the year.

Awesome. Okay Yusuf, before we go, is there one piece of quick, actionable advice you can give to someone to help them with their open source efforts? And what's the best way to find or contact you?

I'd say the best way to try out an open source project is to get on GitHub, search for something that you like, check out some projects, read the contributing guidelines and don't be afraid to get stuck in. Whether it's hacking away on your own computer or raising some issues, or participating in the online discussions. People love talking, so you'll be around a familiar crowd. The best way to contact me is yousaf.nabbymartbear.com so via email you can check out our smart bear devrel GitHub so you can go to GitHub.com smartbear devrel we've got a nice landing page that will give you an overview of all the events that Devrel have been attending, links to slides and videos, and we also have some repos that showcases both Smart Bears open source projects kind of joined together. And we have full projects that showcases Smart Bears professional tooling in a condensed repo. So you've got everything there in a toolkit that you can just play with. And we've got an associated webinar so you can follow along with an interactive story that's been played out.

Oh hey, before we get into it, if you want to worry less about testing and deploying in distributed Systems in your DevOps lifecycle, then you definitely want to check out SmartBear's PacFlow PacFlow makes contract testing accessible to everyone on your team, so say farewell to costly, flaky tests and increase your developer confidence. Check them out now and support the show by using the Link Test Guild Me packflow and you can find that link down below. And for links of everything of value we covered in this DevOps toolchain show, head on over to test guild.com forward/p146 and while you're there, make sure to click on the SmartBear link and learn all about SmartBear's awesome solutions to give you the visibility you need to deliver great software. That's smartbear.com so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed, creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps or automation software testing space, or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head on over to TestGuild Info and let's make it happen.