In this new episode of Tech Leaders Unplugged, host engages in a light-shedding conversation with , CTO of , to dissect the intricacies of Open Source as a standard engineering policy. Listen in to the conversation, and comment away! ...
In this new episode of Tech Leaders Unplugged, host Tullio Siragusa engages in a light-shedding conversation with Patrick Cason, CTO of Raise Financial, to dissect the intricacies of Open Source as a standard engineering policy.
Listen in to the conversation, and comment away!
#opensource #opensourcedevelopment #opensourcetechnology
Tullio Siragusa (00:09):
Good day everyone. This is Tullio Siragusa your host here at Tech Leaders Unplugged. Today I am getting unplugged with Patrick Cason, who's the CTO at Raise Financial. Hi, Patrick. Good to have you with us on the show today.
Patrick Cason (00:23):
Hey Tullio nice to see you.
Tullio Siragusa (00:26):
So, we're talking about the open-source revolution. I'm really looking forward to this conversation, and specifically what we're going to discuss is the power of open-source as a standard engineering policy. Before we go and dig into that Patrick, how did you get here? Tell me a little bit about what excites you about this particular topic, and then let's dig right into it and see what we can learn today.
Patrick Cason (00:53):
Yeah. Thanks. Thanks again for having me, Tullio. I've had a bit of an unorthodox career as a software developer. Primarily going straight out of college, working in startups, and then going directly into freelance. Never really had kind of that safe and secure full-time job. And so mostly just bounced around from idea to idea and paying the bills with, with freelancing contract work along the way. I've really enjoyed that freedom. And, and I guess one of the things it's, it's taught me is that it's, it's really important to be able to give back to community-driven projects working in open-source. I ended up being one of the co-founders of an open-source community in the artificial intelligence space for a little bit. And then went on to lead the engineering team, which was partially funded, partially unfunded of about 80 or so full-time members in the engineering org working on open-source software related to differential privacy, federated learning, and this such. So really kind of the intersection of cryptography and privacy, preserving data science and, and artificial intelligence. So always been very passionate about open-source and trying to take some of the lessons I learned, I learned there, and, and apply them to some of the companies and startups like Raise Financial.
Tullio Siragusa (02:12):
Great. Let's talk a little bit about the history of Open-source before we dig into this a little bit more. Just going back, I don't know, 20 years. You know, before we had such a thing as a democratization of software, which that's really what Open-source allowed us to do, is democratizing the ability to develop software. What was it like before and what's it like today because of Open-source?
Patrick Cason (02:37):
Yeah, I mean, I guess if you were to go back even further, you would go back to you know, a software developer would write something and they'd put it on a floppy drive and then go to a computer club and hand it out to the friends and such. That may be a little bit before my time. I guess my version of that would be the CD or the Flat remember? But <laugh>, yeah, you could maybe talk to that more than me. But yeah, kind of upgrading from the floppy to the CD and then from the CV to the flash drive. But the premise is the same. You would have open-source development purely done through means of hardware. And then of course, with the advent of the internet being able to eventually email if you can imagine zipping up an entire code basin and then emailing it to your colleagues or sending it over MS and Messenger or whatever sort of instant messaging platform was popular at the time. That's pretty much how it would be done. This is in the pre-GitHub, pre-GitLab days where source control technologies like Git and Mercurial did exist, but they were primarily used within internal networks, and they weren't really commercialized or you know, done, done across the internet in a remote work context. So, open-source has morphed quite a bit. I even remember when I was, God, in my teen years being maybe 12 or 13, I had a brief strength as a hobbyist video game developer. And my buddies would zip up the code base and send it over MS and Messenger, and then someone else would pick up and do the same. And merging was a nightmare <laugh>. But that was how it was done. And it's evolved quite a lot since then.
Tullio Siragusa (04:17):
Yeah. Interesting. Also, the evolution of cloud computing really made it even more possible. So let's talk about it. I, I've noticed because of open-source, the strategy that both enterprise companies and technology companies deploy in how they build software has changed dramatically, the libraries and content are available, making it possible to speed up the development of software. There are even technology companies who use it, but of course, they don't necessarily use it for competitive IP. But from an enterprise perspective, I mean, realistically, they could actually build an entire app using open-source, could they not?
Patrick Cason (05:05):
Absolutely. Yeah. So, you will have I kind of like to joke when I'm mentoring earlier software developers in the engineering space, they'll come to me and they'll say, oh, you know, I, I want to develop this website and I'm using these tools like React and Node and so on and so forth, or Angular, or whatever it is. And they don't ever really look at, the actual compiled source code of it. But if you do, you would realize that the majority of the source code that goes into a modern website or a modern application, 99, 90, 95, 90 8% of it is not your code. And so, you're talking about the majority of your work is actually done either by, you know, open-source projects or projects that, that your company, your enterprise has built that then also consume open-source projects themselves or, or directly copy and paste. Hopefully not, but yeah. I mean, you're, you're talking about the majority of applications or websites, or mobile applications are, are almost always built using other people's code. And from an enterprise perspective, it gets really interesting. You see in startups, this is kind of par for the course, this kind of fast-running gun style of development. You know, the devil may care, but in an enterprise organization where considerations like security or different compliance agreements are, you know, tantamount to that kind of running gun style, you have to be a little bit more cautious. And so, you see organizations in the enterprise gradually adopting open-source software, but, but they end up lagging behind other types of companies, smaller companies that just need to move quicker by design. So you see a lot of this shift. And then you also see open-source projects starting to find ways to kind of democratize their own work and potentially even be compensated. So open-source by design is, you know, inherently free software. Sometimes back in the day, we would call it beer wear where it's, you know, I'll develop software and you maybe chip in five bucks and buy me a beer or buy me a coffee, or something like that. But there are now all sorts of platforms now by which open-source software developers can actually monetize their work and, and be paid directly for it, either by other software developers on GitHub, GitLab, Bitbucket, or by organizations. And those are prominently listed in the sponsors. So, it ends up actually being a way it's kind of come full circle where enterprises who have no shortage of money, as opposed to startups, can go in and, and sponsor popular open-source tech projects that they're using in their code base like reactor node. And in turn, they get their logo prominently displayed on the readme of that you know, of the website of that open-source project, or directly on the project on GitHub itself. So, it ends up also kind of being a little bit of a dual-purpose marketing tool for the enterprise. So there's lots of these sort of creative ways that I'm, I'm sure we'll dive into later in this call, in which enterprises have started to adopt open source pretty holistically.
Tullio Siragusa (08:10):
So, I got some notes here from the producer about some of the benefits of using open source. I'm going to just talk about them in a second and then see if we can dig into them. One of them is to improve collaboration and innovation to get your feedback on how that's possible, including the higher quality creation of software and intelligence around bug fixes and things of that sort, and proof security. We touched on that a little bit. The other one is transparency and trust. You know, just there's integrity built into the open nature of the environment in the library. Actually kind of reminds me of, dare I say, they might be the first generation of blockchain.
Patrick Cason (08:55):
Yeah. Yeah.
Tullio Siragusa (08:56):
If you think about it, if it's open and transparent and there are contributions that can be made to it, and there's a library, which is no different than a ledger ultimately open source is kind of the first iteration of blockchain. I mean, some people will challenge me on that, but.
Patrick Cason (09:13):
I get the comparison. Yeah.
Tullio Siragusa (09:15):
If you dig into it deep enough, you'll see that open-source is probably the first iteration. And then there's a question about flexibility and customization cost effectiveness, of course, you know, the speed on how you can get things done, and the longevity and continuity, which is really about not only just taking from the libraries, but contributing. So let's dig in a little bit. You, you, you want to talk about having open-source as a policy within your team. Tell me a little bit about what you’re thinking is there.
Patrick Cason (09:45):
Yeah, so I, I think those, those four-ish points that you brought up are just, just about nail kind of the main benefits of it. To talk a little bit about what I mean by having an open-source policy largely what I mean is that developers have always been just by their nature, by the culture of software development, very passionate about open-source technology, whether or not they've contributed to it or not. Every developer who has done anything in their career understands the importance and the power of consuming free software. It's just a natural part of what you do. I don't know a single developer that has been able to make a living without utilizing open-source technology, either in the companies that they work for, in the startups that they develop, or in the code basis they develop themselves. Very rarely do you have these kinds of zero-dependency libraries, that truly have no touch with open-source. So, what I mean by this is that when you're hiring an engineering team, and when you're establishing a culture for your engineering organization, I think it's actually very important and, and also selfishly beneficial for the org itself to encourage developers to regularly contribute towards open-source software development. So, the first reason it's, it's beneficial for developers to be able to have, you know, passion projects or ways to kind of expand their learning. A lot of the work that they may be doing on a day-to-day basis may not scratch that itch, so to speak. So, from an employee retention standpoint or from a you know, personal development, professional development standpoint, contributing to open-source is a great way to get developers, especially junior developers, to be able to upskill within your organization. It's almost like a kind of built-in self-training for your org in a way that keeps the work interesting. The second thing is that it, it just kind of fulfills a little bit of a, I don't want to say an ethical or a moral responsibility, but just kind of an, an interest that developers have. As I mentioned, open-source is very integral to what it means to be a software developer, whether you contribute to it or not. But by encouraging developers within your own org to contribute to it, you're kind of scratching that curiosity, you're scratching that itch for them. And last, the last thing I want to mention, about what it means for an organization strictly from a selfish perspective, from the organization’s
perspective is that if you have your developers contributing back to open-source, make sure that they're contributing back to libraries that you're actually using. So, if you're using reactor, if you are using chakra ui or Material ui, or no JS or something like that, have your developers contribute back to those projects. This is a way in which the organization can actually benefit from increased stability from increased knowledge of the tools that you're using to develop your products. And, and the stability of the ecosystem as a whole. That's what I mean, really, by having kind of open sources as kind of a first-class citizen of an engineering org from a policy perspective.
Tullio Siragusa (12:50):
Now, Patrick, I want to go a little deeper on this topic as it relates to what we're seeing in the marketplace as you know, with the advent of no-code, low-code, and also alternative ai, how these two are coming together to, in, in essence, begin to, to a certain degree, replace the need for all the manual coding. And we've seen the evolution, for example, with WordPress, you know, you needed to be a developer to build a WordPress, now you can just license a theme, and it's very modular. It's actually a no-code theme. You can just build your own site. So, it’s open-source and connected to some generative AI solution, a competitive alternative to low-code, no-code, or all those things, do you think coming together?
Patrick Cason (13:43):
So at the end of the day, any low-code, no-code platform is, is almost certainly going to utilize open-source libraries under the hood right? For all sorts of tasks. All artificial intelligence models, any sort of machine learning models, or whatnot. Anything related to data science is also built on, on the shoulders of open-source software development, whether it's, you know, pandas or Nampa or Pi Torch or TensorFlow, or any of these popular machine learning libraries. They're all either open-source or, you know, majority open-source with maybe some c bindings for, for performance reasons that companies like Google and Meta will hold onto internally, but just release the compiled version.
Tullio Siragusa (14:26):
No code or low code is more like hidden code
Patrick Cason (14:28):
It's, yeah. So, I mean, and at the end of the day, I mean, if you're doing low code, which will involve some coding to some degree at least to augment functionality you're almost certainly going to utilize open-source software, whether you, you know it or not. And again, it's kind of that mentality of as a developer, you understand that any app, any website, any mobile application that gets released into the wild ultimately is partly using your code. But really your code that you and your team are writing, doesn't even hold a candle to the number of lines of code, that you are consuming via open-source and then, and then re-releasing. So at the end of the day, whether it's directly related to like a low-code solution you know, where you augment your code base using code at the end of the day, all of these no-code and low-code solutions under the hood are consuming open-source technology. So even when you abstract away software development from the direct process of developing an app, you're still encountering it. You're just encountering it under the hood. It's, it's kind of like you know, to say otherwise would be like driving a car and pretending there's no engine. So exactly. It's definitely there.
Tullio Siragusa (15:45):
All right. Let, let's get really unplugged now, right? In essence, what I'm hearing is that potentially in the future, the open-source libraries become even more valuable and even potentially a marketplace where developers can contribute their code. And then all these no-code local platforms or even AI chat, or even generate AI bots, they all need to have sources of this code. And that code's not going to generate by itself. Maybe at some point, they will, but someone has to contribute to this. Do you think that in the future what we're going to see is an open-source sort of marketplace where developers are just contributing to certain requirements, but everything's going to be built by generative AI and just a business user, who needs this data? I mean, let's fast forward 10 years from now, maybe even five years from now. Yeah. What's going to look like, again, I'm getting really unplugged here from where they come from, because usually leaps happen, you know, they don't happen iteratively, they're huge, right? So a huge leap would look like, I don't need a developer, I mean, not directly working with me. They need to contribute to some libraries. And I've got this AI orchestration that puts it all together. Is that where we're going? Do you think?
Patrick Cason (17:02):
To some degree? I, I, I don't want to be fatalistic, maybe I'm also, it's very, I'm also may, maybe I'm also getting a little existential and hoping I have job security in five to 10 years. Maybe you're feeling the same, but no, I, I, I don't worry about this from a developer's perspective too much. And at the end of the day, ultimately what we're here to do is we're here to serve our stakeholders at the end of the day. So whether that's through a you know, a no-code or a low-code solution, whether that's through generative AI or, or manually creating an, an artificial intelligence, whether that's through coding an app yourself manually and utilizing open-source or not, at the end of the day, we're all at the will of our, of our stakeholders, which are our users, our customers, or fiduciary stakeholders. So it doesn't matter to me what the solution is. I'm purely interested in the end result in how it best affects our customers and, and our stakeholders at large. So at the end of the day, whether that's a no-code or a low-code solution, whether or not I have job security in five to 10 years, <laugh> is you know, something I hope for, but I, I don't think it's going to be overnight. I would say that a lot of this a lot of the stuff that you can do with generative AI or no-code, low-code kind of, kind of being in the same arena is that you can do a lot of basic regular tasks. So, I, I kind of, maybe I would mentally compare this to what happened when, you know, wicks or Squarespace or any of these kinds of site builders came out and, and web developers started to get really concerned and think, oh, I'm not going to have a job. You know, you're going to have a job. The average person, if they need a website for their small business, can use something like Squarespace or Wick and easily design their site however they want. It may look like crap, but at least you know it's up, right? And it works. And that's probably good enough for them. But if you really want to take it to the next level, you're almost going to, certainly going to need a specialist, I will probably say, for the next five to 10 years. So, I don't, I don't really get too fatalistic about generative AI or no-code, low-code, you know, coming in and, and taking our jobs overnight. I think this will be a gradual process, and developers will probably shift less into the actual day-to-day work of programming itself and more into the realm of being technical advisors or architects of systems that, that then AI can, can construct for you. But to be honest, Tullio, I don't think any of this is terribly new. Software developers have been using ai whether they knew it or not, through things like GitHub co-pilot or, or any other sorts of tools that integrate right there into their IDE to be able to write code for, for many years now, even before things like ChatGPT kind of hit the, the general public and kind of caused this big stir in ai, developers have been using these tools for years and it's commonplace in our development process. So I don't think this is going to be some overnight storm that sweeps us all, but I do think that as stewards of technology, we owe it to ourselves and to our greater stakeholders to be stewards of good and, and ethical technology rather than necessarily serving the role of a CodeMonkey on a day-to-day basis.
Tullio Siragusa (20:16):
What do you think developers should be focusing on in terms of leveling up let's just play this out for a second. They're spending all day coding and with some of these tools that could do some of the grunt work, what's going to probably be needed as more intellectual horsepower to figure out what is the business problem that we're actually serving? How does this align better? And so really potentially what a developer's role will evolve to is not just developing code, but really a coordinator for solving a business problem. Yeah. And just the same way they would learn a language, whether there's no JS or React or whatever. Now you're just using how, now you're just learning how to use different tools to still concoct, you know, a solution, right? But it's not an assembly line, like, which is typical of agile today. So, I think potentially what we're going to see is a, a reinvention of, you know, of a new methodology that's not necessarily agile, that's more business-oriented seeing, are you hearing any inklings around this? In, in, in the open-source community?
Patrick Cason (21:29):
I, more or less, yeah, I, I do see that as, as the future to where programmers and, and software engineers would more be kind of the, the great minds or the great architects behind the software. But really it would be something like AI or, or other such technologies kind of driving the show and then having humans be able to kind of oversee a lot of that effort. So I, again, I don't think it's going to be some overnight storm where all of our jobs disappear overnight, but I definitely do think it's going to shift more towards software developers becoming more actively engaged in business processes and serving business goals. The other thing I would say, and this is kind of a, a little bit of a grand irony to, to enterprise, is that having tools like no-code, low-code or generative ai models, being able to, to actually write code itself I, I think is actually somewhat of a great threat to, to enterprises, which by their very nature typically run a little bit slower. You're going to see a lot of startups, you're going to see a lot of open-source communities or startups spinning out of open-source communities going and, and, and using these sorts of tools to be able to generate software that, that actually puts enterprise organizations at great risk, simply because they could just move faster, they can move quicker. And as developers switch more or, or less, less from being day-to-day programmers and more to being day-to-day kind of business leaders or business model innovators that happen to understand the technology and be able to implement it well, you're going to be able to see smaller teams being able to punch above their weight quite a bit more. And so I think for large enterprise organizations, this could be a great concern. But at the end of the day, I think if we're talking strictly about users, this is a good thing. This allows the little, the little guy to have a little bit more power. It allows it allows the software to drive innovation and listen to more of the needs of consumers and, and be less kind of stuck in the ways of, of serving, you know, the same traditional customer when you're driving innovation because you're able to move so much quicker so much faster, be much more agile with your development process. You don't have a lot of the kind of cogs or wheels that need to be spun by traditional enterprise processes. So enterprises are going to have a great challenge, I think, in the next couple of years to have to adapt to the increase in speed of software development and the increase of accuracy as these generative models get, get more and more adept at writing solid reusable code.
Tullio Siragusa (24:07):
Yeah, it'll be interesting to see I mean, this is probably a, a topic for a whole other conversation.
Patrick Cason (24:13):
You can have me back on. I'm happy to talk about it more.
Tullio Siragusa (24:18):
Think about it, automation and speed do not translate into competitive advantage or creativity that makes you a unique business. Sure. So you'll end up having a very clinical world where everybody looks and feels the same. Where's the competitive advantage? Sure. So there's a risk, I agree, there's a risk of implementing and adopting these things too quickly to the… basically create a detrimental outcome where you have no unique differentiation in the marketplace. That's going to only come through human ingenuity and creativity. And the challenge with too much automation is that it also stifles creativity. So we're, we're going down a path where we could find ourselves really efficient by, on incapable of actually having quality relationships. Just in, in the, in your team, but as a company with potential clients, you know, and so it's, it'll be interesting to see how we balance that out. Hopefully, creativity will increase with the use of the tools, not the other way around. We'll see. Yeah, that's a topic for another day.
Patrick Cason (25:22):
Oh, yeah, yeah. No kidding.
Tullio Siragusa (25:24):
Patrick it has been great to have you this morning. You know, so, you know, if you're not utilizing open-source fully, look into it. If you are, give back to it. Participate. It's, it's a fantastic way to have democratized access to software, increasing collaboration, and innovation. There's a lot more transparency, which enables trust, and it is very cost-effective to do it too. So, this is definitely an ROI, from that point of view. Thanks for being with me again, Patrick. Just stay with me in a second as we go off the air and we've got more guests coming up. Just visit tech leadersunplugged.com to see the lineup. And stay tuned for what we got coming up and look out for our blogs. We take every podcast and turn it into a block for this week. We have char remaining this week. We have Charro Goel, who is the senior technology leader at Bank of America. So I'm looking forward to speaking with her on Thursday. See you again all soon. Take care.
CTO
Patrick Cason is a seasoned, hands-on engineering manager with 12+ years of experience building web and mobile applications and 5+ years leading large-scale teams with upwards of 80 members. He is happy working as both a full-stack IC and as a technical manager and codebase architect.
In addition to software engineering, he is also a UI/UX designer: fluent in Figma, Sketch, and the Adobe Creative Suite. The vast majority of his career has been spent freelancing for startups and enterprises in a variety of industries: finance, healthcare, human intelligence, data science, music, entertainment, and civics.