Getting the Most Out of Open Source with Yousaf Nabi

[00:00:01] 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.

[00:00:19] 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 Yousaf. If you don't know, Yousaf 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, and its impact on enhancing life through well-designed software. Throughout his career, he has really embraced various roles but a constant emphasis on quality. He's now a seasoned developer advocate at PactFlow and a community shepherd at Pact. He is also proud to contribute to prominent open source tools and SmartBear suite of solutions, leveraging his extensive toolkit 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.

[00:01:16] 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 Pactflow Pactflow 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 testguild.me/pactflow and you can find that link down below.

[00:01:44] Hey Yousaf, welcome to The Guild.

[00:01:49] Yousaf Nabi 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. So I'm 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.

[00:02:06] Joe Colantonio Thank you so much. It's an honor to have you. Really you have an awesome background. It 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 do you do have enter into open source software? What initially drew you to this field?

[00:02:21] Yousaf Nabi Yeah, sure. 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 being 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 there the source code behind it, but you'd be able to get functionality. And that was versus paying for a commercial tool suite. And also being a child, kind of exploring the internet that was in those paid tools weren't accessible to me. I was really interested in this idea of just trying out new tools and technology. And you mentioned that I moved into it in the 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. And there came a point where automation testing, we 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're able to use these automated testing tools to kind of replace the checking job. So the really boring kind of testing task and frees up to use our mental brain to explore other avenues of quality in software. I was able to use some of those technical skills I'd gathered at university that I hadn't really exercised in my manual testing career, and we had to do some automated testing. 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 what I have to implement that tool, but I 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.

[00:04:51] Joe Colantonio Oh yeah.

[00:04:51] Yousaf Nabi I've moved into an organization. I've not really flexed these automation skills in a professional job before. I've got intact with kind of implant and an automation testing framework. And 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 a Medium like GitHub. Over the course of my lifetime and kind of Git which created by Linus Torvalds of Linux fame, that kind of took off in terms of allowing people to collaborate and share code. GitHub was kind of the place where if you googled for a particular testing tool, you might be right 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.

[00:06:11] Joe Colantonio 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 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 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 in open source, and maybe how it can help with open source or help people learn better and become better developers?

[00:06:41] Yousaf Nabi Yeah, sure. I think it's how open source has been around collaboration. It always has been in sharing knowledge. And despite that we'll see this 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 or graphics cards. So that's led to any gamer will know. There's been a shortage of graphics cards, not just for bitcoin mining in the past, but now for AI. 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 open AI, Microsoft, and others. But with open source, people can still freely share their code. They can share learning models. 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 they 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, that cloud development kit that's been largely open source, that's seen huge reams of contributions through doing so. And there's often been large partnerships between commercial organizations and open source project. So Linux is an example of that. There's people who pay for support and stability. And 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. I would imagine that a lot of these commercial players with access to that 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 in bitcoin miners or you're actually doing stuff for your low code purposes. So the same 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 a lot a certain amount of open source capacity. So like run in minutes for open source project. 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.

[00:10:25] Joe Colantonio Awesome. That'd be great development for sure. What are some maybe misconceptions people might have with the gauging with open source projects? Because I notice a lot of projects, it's always seems to be like 1 or 2 core contributors that seem to get burned out over time while they're always getting hammered and like people kind of complaining, not necessarily contributing. I don't know any misconceptions people might have around open source around that?

[00:10:49] Yousaf Nabi Yeah, sure. Oh, there's probably loads, but 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 when 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, say no warranty implied or given that you might have an expectation that the software you're looking at works or works for the purpose that you want it to. 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 to waste your time. I think a misconception with open source is that it can be free. Sometimes open source software, it is free to look at and it can be free to use. But unless these software comes 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 a 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. 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 uses 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.

[00:14:08] Yousaf Nabi 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 relying 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. I actually was reading the 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 in 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 CI/CD systems and automation. You can use automation apps to update your dependencies. You can use automation to release your projects to various, to their 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. And 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.

[00:17:03] Joe Colantonio Awesome. I get asked a lot of questions for 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, except promoting open source projects. So I guess my question is how is contributing to open source shaped your career typically in your role at SmartBear software and with PactFlow, I guess?

[00:17:28] Yousaf Nabi Yeah. Sure thing. So I'll hop 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 talk to them about contract testing. I 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 their 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. As I was trialing out my usage in the software, I could engage with people in this slack community. And slack could be useful for us because we had slack in our work as well. As I began to use the Pact project, I came across in impediments in the project. So either bugs or features that I felt would be beneficial to me or to the project. 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 was introduced into the Pact framework. So that kind of spurred me on, and I remember reading blog posts from people in the past from when I've 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 actually came across my blog post, one of my blog posts. I kind of got flown in via zoom call to help this guy out, and he felt honored to have come from a blog post on the internet to get in 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 P act broker, which is a place to store your Pact contract and you have to self-hosted it. It 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 PactFlow, 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 PactFlow team, if you guys need any support at all, just give me a shout out. I'll help you out. It's the least I can do. And about 2 or 3 years later, as PactFlow had massively grown along with Pact in popularity because contract testing had gone from kind of a nascent topic to being reached the tip of people's minds. SmartBear 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 SmartBear, 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 APIs. It's now known and Pact, and we've recently acquired the Stoplight toolset, which includes Prism, Spectral, and Elements, which are a tool set around the open API suite. I'm sure, Joe, you've used Cucumber and Swagger in health throughout your career and 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 being able to sit alongside. At that first career, I was using soap UI as an end user, and now I'm potentially responsible for its fate. And I've gone from using SOAP UI as a user to kind of six years ago to being a custodian of the project. And it's friends now within SmartBear. I'm really honored that Smart Bear saw the value in that. And we get to join awesome open source friends.

[00:22:46] Joe Colantonio And I share like almost 14 years ago, I guess SOAP UI was one of my first viral YouTube videos. It was like just on setting it up and doing a quick test. I love soap UI.

[00:22:55] Yousaf Nabi Incredible. If you can set someone up for a quick testing in SOAP UI is golden material.

[00:23:00] Joe Colantonio Really for sure. I've been working with SmartBear forever. I've been aware with them forever. What's it like when they acquire a company, say like Pact or PactFlow? If someone is into open source, sometimes they may not understand what that means or be worried. Can we just dive into like, what does that mean when a vendor inquires an open source project? And are there any steps someone needs to worry about or think about in order to continue using the project?

[00:23:26] Yousaf Nabi Yeah, I think 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 would definitely concerns of mine, as I was part of the SmartBear to Pact. So the SmartBear acquisition of PactFlow and by nature, their kind of adoption and support of the Pact open source project. So prior to being adopted by SmartBear, Pact Flow 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 this goal is very particular to our project. Our project has been around empowering. In particular, that project Pact is around contract testing. It 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 and programing languages as possible. So that's why the framework has been designed in this particular way. We don't want barriers in terms of monetary or kind of licensing restrictions to be in place of that. We want software to be better for everyone, for developers and for end users. 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.

[00:26:07] Yousaf Nabi Now, I look at their 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 project. And as you'll see over the course of smart based kind of this year and next year will be moving towards an API, a three hub strategy. So API Insight and Test Hub, where we're beginning to consolidate our product sets into solutions. So and is part of that will 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 their developer relations team working with SmartBear is to kind of, project our open source strategy publicly so that people know 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 tail allaying people's fears at takeover. If people are curious about what kind of kind communication will hopefully my eyes looks like, and you can google, kind of SmartBear PactFlow 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 SmartBear 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 PactFlow itself has enabled people to get on board with Pact sooner because they don't have to self-hosted this pact broker. We've seen an uptick in users both in Pact and PactFlow, 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 in either sticking plasters on them or finding the right person to fix them.

[00:29:11] Joe Colantonio With AI, besides what you mentioned, I know what PactFlow, is anything on the roadmap to work it into AI? And I guess it's one of the benefits of working with the vendor. Any thoughts on that? Anything on the roadmap with AI?

[00:29:22] Yousaf Nabi 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 have been happening in PactFlow to ease one of our biggest pain points, which is generating contract tests, is PactFlow. I've been developing a generative AI feature. This is a kind of modification of open AI that has PactFlow 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 trialing 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. We're really beginning to roll out to uses that as part of our developer preview program. 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 in later in the year.

[00:30:55] Joe Colantonio Awesome. Okay, Yousaf, before we go, is that 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?

[00:31:05] Yousaf Nabi I'd say the best way to try out an open source project is to get on GitHub 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.Nabi@Smartbear.com. So via email you can check out our SmartBear 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 SmartBear's open source projects kind of joined together, and we have full, projects that showcases SmartBear's professional tooling in a condensed repo. You've got everything there in the toolkit that you can just play with. And we've got a associated webinar so you can follow along with an interactive story that's been played out.

[00:32:17] 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 PactFlow. PactFlow 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 TestGuild.me/PactFlow and you can find that link down below.

[00:32:45] And for links of everything of value we covered in this DevOps Toolchain Show. Head on over to Testguild.com/p146. And while you're there make sure to click on the Smart Bear link and learn all about Smart Bear's awesome solutions to give you the visibility you need to deliver great software that's Smartbear.com. That's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed in creating end-to-end full-stack DevOps Toolchain Awesomeness. As always, test everything and keep the good. Cheers.

[00:33:19] 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 at Testguild.com and if you're in the DevOps 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 love to hear from you head on over to testguild.info And let's make it happen.