Orchestrate all the Things - Green software is a thing, and this is why you should care about it. Featuring Green Software Foundation Standards Working Group lead Abhishek Gupta

Episode Date: June 24, 2022

Everything counts in large amounts. You don't have to be Google, or to build large AI models, to benefit from writing efficient code. But how do you measure that? It's complicated, but that does not mean that people are not trying. That's what Abhishek Gupta and the Green Software Foundation (GSF) are relentlessly working on. Article published on VentureBeat

Welcome to the Orchestrate All the Things podcast. I'm George Amadiotis and we'll be connecting the dots together. Everything counts in large amounts. You don't have to be Google or to build large AI models to benefit from writing efficient code. But how do you measure that? It's complicated, but that does not mean that people are not trying. That's what Abhishek Gupta and the Green Software Foundation

are relentlessly working on. I hope you will enjoy the podcast. If you like my work, you can follow Link Data Orchestration on Twitter, LinkedIn, and Facebook. So yeah, I'm Abhishek Gupta, the founder and principal researcher at the Montreal AI Techs Institute. It's an international non-profit research institute with a mission to democratize AI ethics literacy. We do that through our work in community building, through developing and disseminating educational materials around AI ethics and responsible AI, and then finally through doing some fundamental research as well. I've recently taken up a new role at the Boston Consulting Group, BCG, as the senior responsible AI leader and expert there.

So I lead our responsible AI efforts at BCG alongside our chief AI ethics officer, both for the internal work that we do in terms of the products and services that BCG builds that use AI and how to think about the responsible AI aspects there and the work that we do for our clients externally in helping them implement responsible AI programs end-to-end. And then finally, I served as the chair for the standards working group at the Green Software Foundation, where the work that we're doing is to build a software carbon intensity specification that offers an action-oriented and standardized approach to measuring the carbon impacts of software systems. And to give you a little bit more on what the GSF is, so the Green Software Foundation,

it's essentially a trusted ecosystem of people, standards, tooling, and best practices. It is a nonprofit under the Linux Foundation with, broadly speaking, a mission to reduce the carbon impacts of software systems. And the core focus is on reductions and not on neutralization. So, you know, neutralizations being things like, you know, RECs, PPAs, so, you know, renewable energy credits, power purchase agreements, etc. So things that help to offset or neutralize are things that we don't, you know, focus on. We focus on actual reductions in how you, you know, design, develop and deploy software systems. So yeah, that's in a nutshell sort of an introduction to myself and of course the work at the Green Software Foundation as well. Great. And yeah, if I may offer a little bit of introduction myself. So this is an assignment that was originated by the VentureBeat editorial team.

And so they're working on a special issue, let's say on sustainability, and they have a number of topics there. And one of the topics that immediately picked my interest was, well, precisely that. So the impact, the sustainability impact, let's say of code, basically, in general, this is how they put it.

And the moment I saw it, well, I knew that yourself and the background that you have and the role that you have in the GSF would make for a very good match on that. So in order to approach that, I thought it would be good to start with a little bit mentioning just a couple of examples that people may be familiar with. One example that I think pretty much everybody should be familiar with, even though they probably aren't, is the impact that I think will make what we're talking about very tangible is the impact that applications have

on something that pretty much everyone has today. So mobile phones and devices, laptops and tablets and so on. I think what many people don't realize is that, well, basically the more applications you have running and the heavier, let's say, that those applications are, the more drain you have on your battery. And that's a very visible and tangible effect of the impact that software has on energy consumption.

And I think this is a very good starting point for everybody to understand that. Because I think that a large part of the conversation of the carbon footprint, let's say, of software today focuses on things that are very much abstract for more people. So like large language models and that sort of thing that most people will never really wrap their hands around, even though they may be using them indirectly in some ways. So I think the same principle applies to both ends of the spectrum. So applications on people's mobile phones, as well as large AI models running in super servers in the cloud somewhere. So the key question, I guess, is, well, OK, if there is, and obviously there is an impact on the way code is structured and executed on energy consumption,

how can we possibly measure that? And then because obviously measuring it is the first step towards, well, improving and reducing. No, that's actually a great way to frame it, right? And that a lot of this ends up being intangible and very abstract for people. So I think a nice way that you framed it was the software, the apps that are running on your phone. So, you know, you can imagine if you're watching a bunch of YouTube on your phone all day, you know, the battery is going to die much more quickly

than if you're just browsing emails on your phone. And of course, you know, we have a mix of those activities on a daily basis. And that translates, of course, to, you know, in some sense to, you know, how AI systems consume energy as well. frame and structure our conversation in terms of this key notion of carbon efficiency that we've adopted at the Green Software Foundation as a way of thinking about the carbon impacts of software systems. So when we're talking about carbon efficiency, it helps to break it down into three parts, which the way we frame it is as energy efficiency, as hardware efficiency, and as carbon awareness. And, you know, before diving into the details, you know, everything that we talk about here is applicable to software systems and, you know, by extension applicable to AI systems as well, because that's, you know's just one category of software systems. So all the comments or all the discussion that we have here, I'll frame it from the perspective of software systems,

because then I think it will help apply it to a broader set of things. But you can directly translate all of that stuff into AI, and I'll make AI-specific comments as well. So when we're talking about carbon efficiency, as I said, you know, we're talking about energy efficiency, hardware efficiency and carbon awareness. What is energy efficiency, right? Very broadly speaking, it's trying to consume the least amount of electricity as possible. Why are we concerned about electricity?

Because that's primarily the way energy gets consumed when we're talking about software systems is how do you, how do you run them? Right? So that's the the way energy gets consumed when we're talking about software systems is how do you run them, right? So that's the operational side of things. So, and electricity in most parts of the world still continues to be generated from fossil fuel burning sources, right? Which that's where the carbon impact comes from.

So that's energy efficiency. Hardware efficiency is trying to use the least amount of embodied carbon possible. So what is embodied carbon? When we're manufacturing the pieces of hardware like servers, we're talking about chips, we're talking about the smartphones that we use, everything that goes into the smartphone, all of that has a carbon impact, right? And that gets embodied. So, you know, think about the life cycle analysis in the world of sustainability that helps us think about embodied carbon. And then finally, carbon

awareness. So very broadly speaking, again, trying to do more work, right, work when the electricity is clean and less when the electricity is dirty is the way to think about what carbon awareness is. And so, again, here, you know, these three sort of service pillars towards achieving carbon efficiency. And, you know, then as we start to get into the specifics of software systems and specifically the hardware that they consume, it is worthwhile to talk about the idea of energy proportionality as an example. So that is the idea that the higher rates of utilization that you can achieve on a piece of hardware, that's when it starts to really turn

electricity into more useful work. Otherwise, what ends up happening at low rates of utilization is that the idle power consumption, as an example, tends to be a much bigger fraction of the total amount of electricity consumed, as opposed to the fraction of electricity used to do useful work, which could be, you know, for example, doing inference for whatever AI models that you have. When we're talking about how do you go about measuring the impacts, right, there are a variety of approaches to do that. Some folks look at flops, right? So the floating point operations per second. Some people look directly at the energy consumed by the systems. And there's a variety of approaches that lead to quite different results, right? And that's, I think, one of the

challenges that we face in the field. So the reason I mention all of that is because it ties in directly to the work that we're doing at the Green Software Foundation with the software carbon intensity specification, where essentially the goal is to have all of these components that I mentioned, the energy efficiency, the hardware efficiency and the carbon awareness, talked about very explicitly in the calculation. And the ultimate goal of the SCI, the software carbon intensity specification, is to achieve standardization and to achieve comparability. And the way we frame it there is to think about it in terms of operational and embodied emissions, right? So operational being the things that are required to run that particular software system and the embodied emissions are more so the emissions that are captured as a part of the hardware that is used to run that software system. And, you know, just really quickly on the operational emissions front, you know, we're talking now concretely about energyents are emitted per unit of kilowatt hour that is generated, right?

So a product of those two things together, the energy consumed in kilowatt hours times the location-based marginal intensity actually gives you an idea of the operational emissions for that software system. And then when you're thinking about the embodied emissions, we're talking about the total embodied emissions for all the hardware that that software system requires. And so that comes from the LCA, the lifecycle analysis for the hardware that is involved. And it also includes the time share and the resource share, which has been a unique contribution that we've been able to bring as a part of the SCI, the software carbon intensity specification. Because when we're talking about software

systems deployed in the cloud, a question that often gets asked is, well, you know, we're not using all of the hardware, right? We're only using a fraction of it, right? And we're using it only for a certain amount of time. So how do we account for that, right? And that's where we bring in this aspect of time sharing and resource sharing. So time sharing essentially is this idea that, you know, well, what is the time that you've reserved on the hardware for use for your software system. And we divide that by the expected lifespan of that hardware equipment to get a sense for the timeshare. And then for the resource share, we look at and talk about the resources that you've reserved for use divided by the total amount of resources that are available. And so a product of

all of these things helps you get a very granular and accurate sense of the embodied emissions. And so, you know, sort of putting both of those together, the operational emissions and the embodied emissions then helps you calculate the SCI, the software carbon intensity, which is a score. And of course, you know, when we're talking about actionability, when we're talking about how do you make it granular, you know, it helps, or at least the way that we framed it, is it helps to divide it by a functional unit. And what we mean by that functional unit is essentially this idea of how does your application or how does your software system scale, right?

And scaling in this sense is an important consideration because that is what tends to, like, if you build something that is only used by a few people, the carbon impact is, of course, going to be small. But if it's going to be used, if it's something that's going to be used by millions of people, the impact is going to be large. So how do you determine that, right? And just to give you a quick sense for what, you know, what some functional units are. It really depends on the context of your software system, but you can do that through, or you can choose your functional unit to be something like the number of users, the number of minutes or time units that are

consumed on your system, the number of API calls or requests that are made amongst, you know, a few other ways that you could go about choosing that. But framing it as, you know, the operational emissions plus the embodied emissions per functional unit really helps make all of this concrete because, you know, to your original question, which is how do we quantify this effect? We want to be quite granular, we want to be quite specific. Otherwise, you know, all of this, as you, as you, you know, framed it initially, ends up being very abstract and vague, right? So how do you make it practical? How do you make it very real? Not only for the people who are the end users, but also the people who are developing these systems. And that's, And that's another place that where we've been able

to have an impact is also to then talk about, well, what is included and what isn't, right? So thinking about a software boundary in that context is also very important. So what are the components that you should be including and what are the components that you should be including and what are the components that you shouldn't be including? And being transparent when you're reporting that is particularly important as well. So, you know, when we're talking about the software boundary, you can think about, you know, the memory consumption, the storage resources that you're consuming, the compute resources, of course, you know, that you're consuming, but also some things that we tend to forget.

So what is the logging infrastructure? Do you have any sort of monitoring in place? Do you have idle machines that are on standby for redundancy? Do you have some sort of build and deploy pipelines? Of course, if you have a CI and CD process in place. But then, you know, speaking of, you know, machine learning models, again, you know, you can have an inventory of models that are used. You know, you can have shadow deployments, canary bills.

You have all of these things, backups that are in place that also end up being, you know, part of that boundary, right? Where you should be considering the impact and being explicit, being transparent about what it is that you're including and what it is that you're not, I think, is important if we're to really and authentically answer your question, which is, how do we, you know, what are the ways that we quantify this effect and this impact? Yeah, indeed. And actually, well, there's many aspects to what you just said.

I'm just going to pick on two. So first, well, the dependency graph, if you want to call it that, of software, because, well, there's lots of relationships. So you may have like a central, let's say, piece or component to your software. But as you pointed out, you may as well be using a number of third-party libraries and services for things like logging and, you know, like testing your software and also API, external API calls and so on and so forth. So all of these things, all of these dependencies have to first be modeled and then they also have to be somehow quantified in isolation, let's say, in order to enable you to have the final product of your calculation.

And then the other thing is that if you're going to be including hardware, basically, in the equation, and I think it makes sense to do that, even though, you know, in theory, it's the green software foundation, but you can to go through the supply chain of the hardware that you're using and take into account things such as where the metal was extracted and how was it shipped and the whole production line, basically. And the more we talk about it, then I think the more you get to the realization that this is a very, very complex exercise. And I wonder what's the current status basically of development in the Green Software Foundation. And that's a great point, George, in the sense that, you know, when you're thinking about, you know, you mentioned an interesting thing there, which was that, you know, it's the green software foundation, right? And so, but hardware is, of course, inextricably tied into it. The way we talk about software is we talk about software systems, right? And so software systems

then incorporates hardware as well. And, you know, you bring up a very valid point is, well, how do you go and think about the, you know, the supply chain of hardware and think about the carbon impacts in that supply chain as well, right? And to support that work, the Green Software Foundation has an initiative on creating open data sets that will help people calculate that embodied emissions. Because we fully acknowledge that it's incredibly difficult, right? I mean, when you go and look at, okay, well, you know, you've reserved a particular instance in a cloud provider, you know, they'll give you some information about, okay, you know, what is the, you know the performance of that node?

And what are some of the parameters of that node? But then what are the specifics of that piece of hardware that is actually running your software? And getting transparency, getting data on that tends to be important as well. And that's why we're investing in creating some of that open data so that you can facilitate those calculations. The other thing that I think that you brought up, which is important to address, is in places where maybe we don't have complete or direct access to making those calculations.

We acknowledge that as well in the SCI as a part of the Green Software Foundation. And the approach that we've taken is in places where you are able to make those direct calculations, you should, right? And so be as granular as possible, but in places where you're not, that shouldn't discourage you from using it because that's been at the heart of the work

with the SCI at the Green Software Foundation is to ensure that this is something that is easy to implement and that, you know, hopefully gets as widely adopted as possible. And so to meet that gap or to bridge that gap rather, we advocate for a lab-based or model-based approach as well in places where you don't have the ability for direct observation. So, you know, when you were talking about consumption of third-party, you know, modules, APIs, libraries, if you don't have, you know, direct visibility,

making or taking a lab-based or model-based approach where you can approximate and get some, you know, the way we think of it, get some directional intelligence on what the carbon impacts are, that still is useful. And you can use that in your SCI score calculation with the requirement that you be transparent,

that that's what you've done, right? And I think that's the important part. Again, you'll see me mention the word transparency again and again, but just being explicit about documenting what it is that you're doing and how it is that you're doing it will just help other people who are going to be using whatever it is that you do in a well-informed manner to meet their own goals for sustainable practice. Okay, so then I guess an important question is,

who is this aimed for? Because the way that you've been talking about it so far, it gives me the impression that it's, let's say, in some ways the equivalent of organizations that issue like carbon CO2 certifications and this type of thing. So typically you get to these, well, third parties. If you have an organization and you want to get certified, you go to them and they do a sort of audit on your operations and they give you some sort of specification.

Is this aimed at this type of organization or do you also have components in your approach that may be usable as a standards building body working with the folks who have expertise on software systems, who have expertise on carbon impacts, right? And bringing them together to develop a standard that would hopefully be as comprehensive as possible, help to standardize how we go about doing these calculations, reporting them

and ensure comparability, we're certainly not set up at the moment to do any sort of audits or provide certificates. But maybe that's something that, you know, could be explored further down the line. It's just that that's not something that we do at the moment. Because our focus has been, and you know, you mentioned it yourself, in fact, and I was glad that you saw that it is an incredibly complicated investigation and process in the sense of just getting even to a meaningful formulation of what it means to do such an assessment is particularly involved. We've been at it for about, you know, more than a year at this point with, you know, weekly investments from the folks who are a part of the standards working group and going very, very deep into understanding every facet of what it takes to measure the carbon impacts of software systems. And, you know, it's certainly something that we're continuing to invest in to get to a point where, you know, we can serve our target audience, which is, you know, the people who are building these systems day in and day out.

At the moment, equipping them with the right tools, the right knowledge, the practices, the techniques, so that they can do this. And, you know, to answer your question in terms of, well, you know, are there tools that are available today? Yes, there is a, you know, panoply of tools that are out there. You know, things like Beaker from the Allen Institute, the Allen AI Institute. There is RAPL, there's Carbon Tracker, there's Code Carbon, there is EcoCode, there's PowerDroid, there's MLCO2, there's greenframe.io for measuring the carbon impacts of your web app. And all of those help you get a basic understanding of the energy consumption of your application. But I think what we found is that because everybody is doing it a little bit differently, the results that you get then also tend to be different, right? And so in terms

of practice, like what we encourage is for folks to start moving towards something like the SCI because, of course, we're biased because we're producing it and we'd like for folks to adopt it. But all jokes aside, the reason we encourage its use is because it is sensitive to energy efficiency, hardware efficiency, and carbon awareness. And the reason it is important to be sensitive to that is because it rewards behavior on the part of the designers, developers, and employers of these systems. When they make meaningful reductions, that gets reflected in the score. And a lot of the times, the existing accounting mechanisms, the tools that we have today miss some of those changes that you as a developer,

that you as a, you know, deployer of the system make in good spirit and good intentions, but those get missed by these tools. And that's when it becomes a discouraging effort on the part of the developers because they're doing all this good work

and then they don't see any positive impact for it, right? And so we wanna make sure that you get rewarded for engaging in that good behavior. And because the SCI takes a system level view as an example, and, you know, through all the support that we're building around, for example, the open data that we're working to provide, it is something that, you know, becomes easy to implement. We're very explicit with our methodology. And so that's, you know, that's sort of the hope is that we do that. And, you know, of course, I'm happy to also dive into specifics on how we do this for AI systems in particular, because, you know, I think so far everything that we've spoken about is for software systems, which, you know, a lot of it applies to AI as well.

But, you know, I think there's a lot that can be done on specifically on the AI front as well that would help to mitigate the carbon impacts. So you mentioned a number of tools, well, including the ones that you're developing. How does it work in practice? So can you, is it something that you can use while you're in development? Can you get like the recommendations, for example, I don't know, drop that infinite loop that you went into because it's going to kill your assumption or that sort of thing? Or is it more agnostic, like measuring the end result, let's say, and giving you some feedback on that? It's both, right? It's both in the sense that

some of these tools provide targeted recommendations on what parts of your code are, you know, let's say more energy hungry, right? And to give you an example in the case of, particularly in the case of AI systems, if you think about system design, if you think about training methodology, if you think about model architectures, so using things like quantizing your weights, using distilled networks, adopting tiny ML approaches

is actually quite useful in reducing the carbon impacts of your systems. And on the last point around tiny ML, there's been a tremendous push now for getting AI models to work on resource-constrained devices, as an example, right? And so there's a ton there that serves as a sort of byproduct to mitigating carbon impacts as well, because we're trying to run these performant models on small scale devices. And because they're small, they tend to have a smaller carbon footprint as well. And so that's another place that you can make some good choices, some greener choices. You can also think about using purpose-fit hardware like ASICs or application-specific integrated circuits, an example of which would be a TPU, right? So the tensor processing units

from Google, they tend to be much, much more efficient in terms of how you can utilize them for training, achieving significant reductions in the amount of energy that they consume when you're training a particular model. And then on the other side, if you're running a trained model, there are chips that are optimized for inference as well, right? So again, using purpose-fit hardware is another way that you can, you know, sort of reduce the carbon impacts of the system that you're using. And then in terms of, you know, how you're sort of going about deploying the system, you can think about approaches like where and when the model is trained, right? So being carbon aware, as an example, right, you know, region shifting and time shifting, your training processes can

also help, you know, mitigate the carbon impacts of the system as well. And I think ultimately, you know, both these are, you know, sort of very tactical steps, right? What I would say is, as we start to think about the environmental impacts, it's tremendously helpful that, you know, we make this as a transparent requirement where we elevate sustainability

as a first-class citizen alongside business and functional considerations, right? This is something that I've highlighted in my research that I've published with The Gradient in a piece called The Imperative for Sustainable AI Systems and a piece with the Green Software Foundation and research that we've done that, you know,

again, highlights why it is important to elevate sustainability as a first-class citizen. And I think that's, you know, when we get tactical and strategic at the same time, you know, providing very concrete guidance, right, in terms of how you can achieve that compliance as a part of, you know, sort of broader ESG requirements as well, right? If you ask me, like, where the state of things are today, right, and sort of what the future needs to look like, I think where we are today is that, you know, we're in a state where there is, it is rife with problems with a lack of standardization, lack of access to data, and honestly, a lack of understanding also of practitioner needs, right? So the folks who are actually on the ground were designing, developing, deploying these systems.

There is a lack of understanding of what those people need. And that is actually hindering the adoption of some of these tools, techniques, and best practices, you know, like the ones that I mentioned. And so there is, again, a roadmap, I would say, something that I highlight in my own research work. There is a roadmap that we can help to help, you know, fix some of these issues. And just, you know, as a quick point there, things like better integration into the native workflows of developers, you know, utilization of standards, for example, the SCI from the GSF, and incorporating reporting of some of these carbon impacts. For example, you know, if you calculate an SCI score,

I'm reporting that as a part of the larger ESG reports that are produced at firms, is another way that we can not only help get this more traction and make this a more normal part of our operations, but ultimately help even companies achieve their sustainability goals, right? And so I think all of that put together really, from a strategic standpoint helps provide us

with a direction, but then also that's not enough, right? Some of the things that I mentioned are very tactical things that folks can do in their everyday work so that they build greener software at the end of the day. Yeah. To your point about reporting and transparency, I think on some level it's beginning to happen, at least on the one end of the spectrum. So we've seen a couple of papers lately, specifically from Google, in which the latest one in which they elaborated on their PALM model. And part of that was a framework that they have developed called Model Cards that is used to publish different aspects of the model, including actually things such as carbon footprint and environmental impact and all of that. So that's a step in the right direction. publish different aspects of the model, including actually, you know, things such as carbon footprint

and environmental impact and all of that. So that's a step in the right direction, well, on the one end of the spectrum. And I wonder what it will take, and actually what you mentioned about sort of institutionalizing, let's say, the need to report on those things, not just on the very high end, which models like Palm operate and organizations like Google, but also on the more low end, let's say. So people building code every day. I'm guessing that most of them, in between project deadlines

and juggling many different tasks, they may not prioritize actually, you know, connecting the software and doing the measurement. But if it's an institutional requirement that, you know, you have to do this because it's, you know, a mandate from the organization, because the organization does have to report on all of those things and all software comes with, you know, their environmental impact tag,

then things may start looking different. Definitely. I think when you do that at an institutional level, I think that really galvanizes people interaction, right? People just sort of wake up and they're like, okay, well, this is not optional anymore. It's a mandatory requirement and we have to invest in doing it, right?

And so I think, and I love that you bring up the point around like business deadlines and pressures, right? Because those are very real things that sometimes don't get discussed enough, right? Is when you have a product that needs to go out the door, that needs to be shipped, the things that are optional are the first ones that are going

to be dropped, right? Because you want to make sure that you meet your deadlines. And so if we start to incorporate these as mandatory requirements, then I think, you know, people would start to pay more attention. And you know what, George, the other aspect to it is also, I think, as consumers become more savvy, right? When they look at these, you know, environmental impact scores and make choices based on that.

I think that also will be the place where then, you know, people, you know, will start to wake up and actually change their behavior because ultimately if your consumers, if your users are only willing to pay you dollars when, you know, you are green versus when you're not. And so, you know, if you're not green and your competitors are green and they switch over to their services and products, then that's, you

know, what else do we need, right? I mean, that's, I think, really when it starts to have an impact on your bottom line, that's when people wake up and they're like, okay, well, we got to make changes to our, our practices because we're losing customers. So I think that'll be another way that as we build broader awareness in the, in the consumer ecosystem saying, Hey, you know, there are green software alternatives to whatever product services that you're using. So if you care about this stuff, you should maybe, you know, spend your dollars with them, the people who are, you know, building green software.

I think that will also be a huge force in creating change. Yeah, absolutely. And obviously, you know, transparency and all those green labels, let's call them, are a prerequisite for that to happen. Just very quickly, because I know we have to wrap up, what are the next steps with GSF? So what's your next milestone, let's say? Yeah, the next milestone, the current SCI, the software carbon intensity specification, is an alpha at the moment. So we're looking forward to releasing V1 of that. So that's a huge milestone that's coming up for us.

We're aiming to do that with the COP later this year, where we'll have an opportunity then to unveil it, in a sense, to the broader world. But we've already had significant engagement on that front with the organizations who are a part of the GSF, who are thinking about incorporating this into their own measurement methodologies and the software systems that they build. The other thing that is going on at the moment is the GSF

is holding summits around the world. We've got one coming up in Boston next week. We had one in Paris. In fact, I think that was a couple of days ago that we had that as well. And so we're embarking on this mission to raise awareness that, hey, green software is a thing. Because I think, you know, you mentioned this at the start as well, that, you know, it's not something that people really think about today. And so just getting people to become aware that, hey, green software is a thing and that, you know, why you should care about it. And so this push with the global summit strategy as if is hosting around the world is one of the big milestones and we'll be concluding

in a few weeks having hosted dozens of events around the world to raise awareness on this front yeah yeah i think it's definitely needed to raise awareness on many levels on the on the levels of software developers on the level level of users, and also organizationally. And at the same time, you're also working on pushing forward the standards and the software and all of that. So, well, considering this is not even your day job in a way, I wonder how you even manage, but well, good luck to you anyway. Thank you so much.

I mean, you know, I'm very lucky to have support from my job at BCG that allows me to, you know, invest my time towards the work that we do at the Green Software Foundation. And it's something that I'm really passionate about and, you know, spend so much time thinking about. And of course it has an implication or intersection with responsible AI as well.

And so I'm more than happy to do that. And yeah, it's been such a pleasure. I always enjoy talking with you. You always have such great questions that I think really get to the meat of what it is that needs to happen in the space if we're to have meaningful impact. And so I always appreciate the opportunity to chat with you.

Yeah, likewise. And yeah, let's hope this is just a little stepping stone towards raising awareness, at least. I hope you enjoyed the podcast. If you like my work, you can follow Link Data Orchestration on Twitter, LinkedIn, and Facebook.