 All right, we're gonna start a little bit early on this one because I'm sure we're gonna get a ton of questions for the panelists here. So again, thanks everyone for joining. I'm Sebastian. I'm the co-founder of a company called Scaler. We've got an incredible panel here with folks that have a lot of experience with Open Tofu. They will introduce themselves in just a second, but this is a panel mostly for you, a little bit for me, but mostly for you. To give the opportunity to ask questions, share stories of migrating from Terraform to Tofu, and just a sharing experience of operating at scale and with all the warts and all the issues of running infrastructure. So with that, Daniel, can you introduce yourself and then can you introduce yourselves? Yeah, thanks very much. So I'm Daniel, I'm from Berlin. I'm the former director of engineering for Team Mobility. So maybe you've seen our bikes or scooters around the streets in Europe. Now freelancing and just give them some background there. Team Mobility is running Terraform at scale, was running Terraform at scale. What to that later, 250 stacks self-service in Spaced have toasted by current client. We are nearly at 1,000 Terraform stacks also in a good style. So I'd like to talk about that later with the other people here as well. Cool, my name is Stephen Kutseer. I'm a senior platform engineer at Denso. Our team is running roughly 750 Terraform stacks and recently migrated over to a newer Terraform 157. And then with the bomb drop, we've now been looking at open Tofu and migration. Hello, I'm Ronnie. Yeah, so I'm a software engineer for the last 10 years. And the last four and a half I've been switching hats between the DevOps hat and the developer hat, which is something I really love. I'm working in N0 for almost two years and currently part of the open Tofu core team for the last four months. Good morning, guys. I'm Hugh from Ireland. I'm one of the co-founders of Hestio. We do Terraform adoption and we have a commercial infrastructure library, a commercial module library, similar to Gluntworks, except it's very much for low code. Using Terraform since 0.4, so a long time, unfortunately, for better or in some cases worse. We work primarily with large enterprise customers and there are both technical and non-technical challenges that we encounter very often. One of our customers, a large global company, is running approximately about 8,000 Terraform-based stacks. And what's interesting about customers, enterprise customers, is that they often don't, they manage an incredible amount of infrastructure, but they do not iterate and update that infrastructure very, very often. That's simply the way they consume. So even though it's a huge amount of registry that artifacts that are managed, it's not something that updates very often. And so the potential for breakage is significantly increased when we come back to visit those. Excellent. Thank you. All right, let's get started. So Daniel, you're saying that that you just led a large migration project. Can you tell us a little bit more about how that went? What went well and did not? Then let's start from there. Yeah, cool. Thanks. To be honest, I did not let it, but my former colleagues let it, but they finished it. And right in time for the OpenTofu days, so tier mobility migrated everything over from Terraform to OpenTofu without any problems. That's what they told me. There was some quirks. Most, the one quirk was in the modules, they hard-coded the version, which is to be used with that module of Terraform. And they used semantic versioning, so with the nice little tilde, and which gives you a range. It gives you a range of lower and an upper bound. So that broke because with OpenTofu, it's now 1.6. They hard-coded everything to be Terraform, whatever, 1.5 or something. So this was the only change they had to introduce to stay with the recommendation, give a lower bound, don't give a upper bound with your modules. So, and with that, yeah, OpenTofu SpaceLift is already supporting the founding member of the OpenTofu here. So that was not an issue. So from their perspective, everything went absolutely well. And you might ask why. They are looking into the state encryption, the private state encryption, the feature to come because everything is managed in one state bucket, but too many people have too much access to those state buckets basically. And this is what they want to avoid in the future. So preparing the grounds for more security there. Awesome. What has been the rest of your experience with Stephen? Maybe you want to talk a little bit about your experience or? Sure thing. So we've been doing quite a lot of research into this migration and testing a few stacks and things like that. And so far we've found we've needed no changes. Everything is just simply work from moving over. So we may encounter an issue at some point. We haven't found it yet. Yeah, same for us. Like we haven't really migrated everything, but every new project is obviously OpenTofu and we're starting to migrate existing project. And until now, like we've seen no issues. That's interesting. In that it's great that there's almost a one for one swapping between Terraform and OpenTofu. And from a technical point of view, we would see exactly the same. There's very little involved technically in making the switch. Where we encounter a lot of challenges with our customers is really just simply around awareness. Like this is preaching to the choir. Everybody here knows that OpenTofu exists, I hope. But a very common conversation that we have with many of our larger customers is that OpenTofu is simply Open Terraform. It's a separate thing. It's not a HashiCorp thing. It is the name of the language and it is also the name of the tool. There's a little bit of confusion there, but what's really interesting about our engagement with customers is that there's an awareness and there's sort of a knowledge building exercise that we do need to go on. And as members of the community, I mean it's certainly our role to increase visibility of OpenTofu just to reinforce that it's still Terraform onto the hood. Terraform is the language. It's built. It's the same language. It's an easy swap to make, as we've heard here many, many times. And just more to reinforce that it is its own thing and it isn't a complicated thing to do. There are some technical challenges, but you can do a one-for-one swap in and incur almost no overhead very, very quickly. And I think a large burden on us as community members is really just reinforcing more and more of that OpenTofu awareness, really, really is. If I can respond to that, like I think you're absolutely right. I've been in an OpenTofu made up in Israel a month ago or so. And yeah, there are so many questions, so many people still not knowing about OpenTofu, specifically about how the registry works. And I think that having the registry talk that Aurel and James did was absolutely amazing. And as a core team, we're also discussing how do we explain to the community that all the providers are there, all the models are there. It's really easy to add the stuff that are missing. It updates automatically for new versions. And yeah, that's part of our job to teach the community about that. So one thing that I'd actually like to mention absolutely, I come from a very open source, heavy background. And the word of mouth that OpenTofu has been spreading is fantastic and I absolutely love it. And I actually had the same conversation recently about not many people know it and especially those in senior leadership who may not be up to date with the latest versions and everything like that. I actually made a joke this very week where I said what we need to do is we need to start OpenTofu from version 10. Because then all we have to do is say, look, it's 10 versus one, it's much newer, it's better. Yeah, but honestly, I'm talking also to peers and also to clients there. The main focus is on long-term support, basically. So how is the landscape evolving? How is it going to support it there? Are the providers staying compatible? Is are these two branches going apart? Whatever, so that's the thing. And also looking into new features and maybe iterating back here to Ronnie then. What also my colleagues at TM Mobility said, this is something they are really interested in and this is where the community actually has a chance to bring new features. And this is sadly something which we could look back into the past years. There was not many features actively pushed into Terraform and now there's a chance and there are new features rolling out now. So Ronnie, how are you actually deciding what to implement? Okay, then maybe you touched a little bit about state encryption beforehand and I think it's a really good opportunity to say that we released an alpha just a few days ago. No! We're 1.7 and it includes the state encryption and you should try it and see how it works and break it, please break it. But yeah, how we decide about features then mainly it comes from the community. We're going over each and every issue and we're pruning issues at least once a week and we're seeing what people are opening and we're seeing how many upvotes these features have and basically that's how we decide. We're really trying to push the stuff that the community wants. It's super encouraging to see how the one that the migration has created basically zero issues for anyone and two, how the open governance process makes it much easier for the community to suggest things. What do you think OpenTofu needs to grow in your conversations with folks? How can we make the community grow faster? What's needed? Stephen, do you want to start with that? Sure thing. So growing OpenTofu will largely be an organic event and it's already happening. OpenTofu's success story is writing itself and the more we succeed and the more people learn about it and the faster things we'll get and you'll have to prune faster than once a week. We could be going to start getting more and more requests and more hopeful community involvement on writing that code. So I can just comment on that. What I thought was really interesting about the community involvement was in terms of new features, state encryption I know is a big ask for many. But what I thought was really interesting was something that James had touched on this morning. Don't panic James, it's okay. It touched on this morning in terms of just building the registry and hosting it. There was something that really struck a chord with me and that was that the example that he gave was the Cloud Posse utility provider that merges two YAML files. Now for those of you who don't know it's downloaded approximately 47,000 times a week. Now I'm sure James knows that having had to serve it and build it. But what's really interesting to me as a builder of components or Lego if you will that we want our customers to use whether that's providers or modules, patterns or examples or reference architectures is that that capability alone of merging two YAML files that's been an open PR in Terraform for a long time. And if the entire community is having that problem 47,000 times a week that's definitely going to be something I would like to see us all upvote over the next couple of weeks. And it's not only YAML, it's HCL as well. So there's no deep merge for maps. Even better. Yeah, it's just interesting to see that security is obviously a big concern and given the what you can do with access to Terraform state given that it's generating credentials for many of the services that all of the workloads run on. It's obviously one of the most important things. But I think it's important also that we ensure that the community of builders are also getting more of the things that they need. And I think that brings us sort of back to what we'd had in an earlier conversation around Terraform as a language. Is it a DSL or is it slowly creeping its way towards a programming language? Yeah, what's your take? Yeah. So we talked about it a little bit and I really tried thinking about it because I was a developer that mainly worked with TypeScript and they had to learn Terraform four and a half years ago, like in a month and had to learn Kubernetes and Helm and all of that. And like I was really trying to remember how it was for me, like learning the DSL. And I honestly think that the fact that Terraform is a DSL, it's the main specific language, it's not an issue. Like probably when I wanted to do like some kind of an if, then I just went to Google and searched how to do that in Terraform. And then I saw the count syntax and I was like, okay, that's weird, but okay, manageable, why not? I think the issue and we tofu and Terraform for developers specifically learning and how to use the language is not the language itself, not the DSL specifically, but it's more understanding the provider's ecosystem, understanding how the cloud infrastructure works, learning all of that, that's the real issue in my opinion. And like I think Terraform being a DSL and Open Dofu being a DSL is really convenient. Like I change a property and attribute of a resource and I can imagine how the plan will look like. Same thing happens when an unplanned change happens. It's really easy for me to go back and understand where it explicitly happened. So yeah, that's my take. I think it's really convenient, but that's not up to me, that's up to the community we're Open Tofu will go to. So how do we help them do that? What would we ask of the community to help us do that, to pick the right next things? How do we do that? I think it just opening issues about things that bother them and upvoting and engaging. And that's how we know that you want something, that's how we know what we should focus on. And yeah, and teaching the community to do that. It's also not that easy to expect people to do that. They need to learn the process. Daniel, you have a... Just asking, I mean, you're talking about issues and upvoting, how about contributions? A, how easy is that to contribute to the core? And B, is it welcome from that perspective, especially deeper like replay or introduce an if statement? Finally, if else to make it more complex? Yeah, that's a good question. When we're pruning issues, then we're definitely coming with a state of mind that we want to, if we want to accept that issue and we usually do, then if we can, we want to open it to the community. People are amazing. The community is amazing. They're jumping over everything that gets accepted. And it's amazing to see that. And is it easy? I'm not entirely sure it's easy to contribute. Like as a person who dive deep into TOEFL for the last four months, I'm also still learning. But I think there are people in the community that have a lot of knowledge and we should learn from them. So sometimes we open an issue for contributors about really internal stuff and we get pull requests and then we also have to learn about the solution and about the specific internals. And I think it's welcome. It's the best way to learn. And if I'm gonna say that that request in issues is actually for me the most exciting thing about Open Tofu because I'm sitting here and I'm thinking about all the pain points you know I've had over this time and someone will actually take me seriously on like if I would really like something. Even down to the silliest thing, like not being able to use counts in outputs. I've got multiple resources on count. Why can't I create an output for each of those as well? But now I can. Now someone will listen and that'll be you. So on that topic, what's on your wish list? What are some of the things you'd like to see in 1.8 and forward? Hugh, you wanna start with that one? Okay, in less than two hours, right? So I would like to see merge properly bought brought into Tofu natively. Having to download something 47,000 times a week for me is a real indicator that that should just be baked in. We have merge, but it's, we can't curse, so I'll just beep, but it's a really horrible experience as a module developer and an infrastructure coder. It's horrible because it's very, very limited. So the fact that so many of the community are using that one capability to combine sort of initial and user values and build a sort of combined map or dictionary of the real target that we want to build against. For me, that's number one. Number two, I think, if I'm allowed to second one, would be to fix two bull. So by a show of hands, how many values do you think are supported by the two bull function? Two bull, two bullion, true and false. By a show of hands, hold up one or two hands. How many values do you think the two bull function actually supports? Well, we're all wrong because nobody's got three hands. It's true, false, and null. Perfectly logical, right? And I think there are a lot of examples like that where the language itself in having started out in HCL one as a configuration syntax and having then got huge adoption like it did in the early days prior to one.x And then coming through to, okay, now we need to add some more programming primitives, the counts, the lips, the conditionals as those come in. And I think coming from, in our earlier conversation, Daniel had mentioned that one of the really interesting observations he had was that Terraform, as a developer, Terraform is nothing like all the other languages that you learn in that there are constructs, there are types, there are primitives, there are conditionals, and not all of that is true in Terraform. And again, it's part of that challenge that Ronnie had mentioned there where it's a target state language, not necessarily a fully evolved programming language yet, but I think how the community are actually using it is very much like a programming language. And if we decide as a community that that is how we'll use Terraform, then I think we do need to make sure that it behaves much more like a programming language. How about you, Steven? How about you, Steven? What would be on your wish list? So number one item on my wish list is I've had to do some horrible things in the dark of night to simulate those if, else if, and things like that. I would really like to see that in. It would be nice to be proud of my work again. So, yeah, go ahead, Daniel, but then I have a follow-up. No, no, it can completely support that. So nothing to add here. It's more like an experience thing. So really nothing to do with the core language, but it's more like how to use modules. I would love to have a chance to mark a variable as this is something you should think about. This is something you may think about and this thing is really obscure. So leave it as a default. Only touch it at some point, just from a developer experience perspective. So it sounds like you'd like for the language to evolve in particular directions. Do you, in addition to loops and conditionals, anything else? Not right now, not on the top of my head. It's really like coming from a platform team here. So I provide modules to my teams, to the developers. So how are they used? So better support in IDEs, better hints, better. So if you're using or accepting that module now, okay, what should be there as a variable already to be filled in? Because at the moment you have to look those up, at least in JetBrains, I don't think Visual Studio Code is different there. So more support on the usage of these things. The primitives, I don't know, it's fine. These annoyances, once they are gone, I think I'm kind of happy there, but now take it up to the next level. And I'd just like to mention that whole idea of, we may not have more annoyances than BOSC 102 is what makes a community involvement such a fantastic thing, because there are thousands of talented Terraform developers out there that work on these things and they're like, if only we could do this one thing and all together, if we all contribute and everything like that, I think it'll be a really neat product. Well, I totally agree. And guys, I'll wait for your issues submission by Monday, okay? How large is your mailbox? What? How large is your mailbox? No, I think I don't get a third, I've already had two. So Ronnie, we were talking a little bit before about the difference between how Hashacorp was running the governance for Terraform and how, so you and with all the other maintainers and with the community are running governance for the TOEFL project. Can you tell us a little bit more about kind of how you see that impacting, being able to leverage the community and all that? Yeah. So as we said, yeah, we're really trying to, like we're still kind of figuring it out. Like we have processes, I think they're good but we keep polishing them and making them much better than like when it comes to engaging with the community. So I talked a little bit about issues and I can also say that we have an open TOEFL community slack and we're pretty responsive there. And pretty quickly, you can go there, you can ask whichever question you want. If somebody is working currently on an issue, he can get guidance, he can ask questions. We're posting updates there. Obviously we have like the weekly updates of the core team and the updates of the technical steering committee and their decisions. Yeah, and we also have a public sync every Wednesday that everybody can hop on. We especially like developers that took issues that are working and they're currently contributing and like you can just hop on and see what we're working about, ask questions. And yeah, even if you have ideas about the process and about how to make it more engaging with the community, you're more than welcome to say to us, to suggest. Actually I love that openness because this was completely hidden from the user base. So forgot about that weekly statement, so where are we, so releases, et cetera, et cetera. So thanks for doing that. Can you elaborate a little bit about how the TSC works and how our differences of opinion get resolved, et cetera? Yeah, of course. Then sometimes like there are issues that are just massive. They might take a lot of time to implement, like a new feature. It might be a big change in tofu and then we just decide or you just need some more leadership decisions and then we have an agenda for the technical steering committee and we write it there and I think they're meeting like once a week, week, twice a week, something like that. Sebastian, you can tell us a little bit more about that. But yeah, and then they're discussing it and telling us their decisions. We just recently opened an internal channel. We're still trying to create a really good process also with the technical steering committee and we have an internal channel and we're discussing about stuff. They're asking questions. We're responding and yeah, that's how we do it. For now it looks like it's going really well. So I have a few other questions but I'd like to start opening it up to the much better questions you guys are going to ask. So we are limited on microphones. So if you have any questions, raise your hand and I'll take your question, repeat it. Otherwise I'll just keep going. Yes, go ahead. Can we import or bring stuff, the good stuff from Terak runs? That's a great question. Yeah, that's a great question. Honestly, if you want it, like, let's talk about it. Let's see some upvotes, let's get these issues. I don't think we actively have a... Like, we're going to do that actively until, again, the community will ask for that and then we might reconsider. Was that particular things you had in mind? Can I get a quick show of hands? Who here uses Terak runs? Okay, so about a quarter to a third. So go for it. So that's a really interesting question. Teragrand's relationship with Terraform, the language. And I think there's two ends of that spectrum. There's the, I need things done before Terraform runs, which is essentially Teragrand's significant value. It's awesome too, it's kind of, it really is awesome. And then you've got the Cloud Crossy approach, which you see in a lot of their modules online and they've taken the opposite approach, which is don't worry about it, we'll use an awful lot of null resources and we'll figure out a way and there's some really clever, creative, awesome stuff in those patterns. And what's most interesting is that as a long time user from far too long ago is that because Terraform has a language itself, because we haven't decided what it's going to be, is it a programming language or is it a puppet-like target state definition? We've had to build other capabilities before it runs and things that run under the hood before Terraform actually executes. It's almost as if we needed to be a compiler. We almost need Terraform to be a better compiler tool than it currently is. More like a sort of a fully evolved programming language, more of those capabilities, more of the primitives, more of the conditionals that we expect and a lot of the very basic stuff that we'd like to do that we find ourselves doing in Terragrunt, the region setting, the version pinning, a lot of the very basic stuff that we could also code in Terraform but because it happens much, much earlier before Terraform actually invokes, the tool doesn't support it yet. So it's really interesting to have that question to be asked in that for me it's another indicator of if the tool could do more, not only in terms of utility functionality for the users but also in the pre-run almost like hooks, almost in the same way that get evolved into have pre-commit, post-commit type hooks. Even if it wasn't going to implement it natively, if it was able to handle that hook and do invocations, it would allow the community to build all the tools. Terragrunt is still an awesome one but it would allow us to swap in other things. Horrible shell scripts that would do exactly what we needed but nobody would want to manage those. You really, I like that question, it's good. Do we have another one? Do you mind passing on it? Okay, I'll have that. It's already in it. Which one is it? Can you repeat the question? So if I heard it correctly, it's that it's already an existing PR but is it against the HashiCorp Terraform or is it against the OpenTofu Terraform? Yeah. Thank you. So, Kuba, I'm also on the core team. So there's actually an RFC against tofu by one of the core team members which he's very passionate about and is working to push forward for constant, for initialization time, evaluation of constant expressions which more simply means if you use at the beginning constants that just depend on input variables, then you might be able to parametrize the regions, the backends, the module versions, pin the versions. So a lot of those, like for each is on constant arrays like regions, those are kind of things that would be unblocked by that. With support for environment variables because we all live on environment variables too, right? Are they common to the issue? Oh. Actually, when you talked about the wish list, this is the thing I want to see. Yeah. I think this feature is amazing. It will really let us configure stuff much easily. And we're talking about making the backend block much more like you could use variables and locals. And again, and using it also in source attributes of module blocks. And yeah, this is the one on my wish list. Any other questions? Yeah. I have a question and I have the mic. And I used to work in Cloud Posse, so I'm a hardcore user of Atmos. And I don't know how many people use Atmos here. Maybe I'm the only one? Yes, I'm the only one. So Atmos, one of the greatest things is variable inheritance. And then the YAMUs tags are defined and then it creates the telephone variables out of that. So I always wonder why actually, telephone never had that because it's like, you have for example, tags. And then there's a company tags and you want to pass it to the tags variable. Why do you have to redefine them in every environment? So to keep the code dry is very simple in Atmos to just create one YAMU file and then inherit that file to every single stack. It could be a whole company with thousands of stacks and you just define it in one place. So I was wondering if there is, should I open an issue for that? So that it gets implemented or at some point or if you guys ever talk about kind of like variable inheritance or even dynamic variable inheritance? I actually think it's also made mentioned as part of the RFC if I remember correctly. Yeah, and go to that RFC and just comment on that. Say that you want that specific part and we're definitely discussing it. Thank you. Just in relation to your question, I would like to see an approach that allows a sort of Git based version of the implementation in that it allows hooks to be pulled in that don't have to be goal specific. One of the things that I love about Terraform the most is also the thing I hate about it the most in that it's the barrier is the goal language. And on the earlier talk, I was like, somebody's written a provider and something other than go. I was like, finally, he's gonna say no. He's gonna say Python. And then he said, no, we're just digging. We're going further down guys. We're going down to the bottom. Next one's in assembly. Next one's in assembly. And I think, yeah, maybe I don't know. But I think what I really like to see is that more and more of the additions that we make into Tofu, that they allow more languages to be used because there while goal is great language, it's often the language that is least seen in the people that need to use Terraform the most. Especially when you're coming from like a web, traditional user development or web development and it's Python and Node feature heavily there. There are a lot of other public technologies too as well. But I think as we add more features to Open Tofu, I would very much like to see it be capable of pulling in more of the same tech and approach patterns like pulling in a verb variables or hooks that build in Python or Node. We just open it up to a lot more involvement from the community. And it would allow us to figure out more of what we need without having to worry about finding somebody to write it in Go. That touches upon a really interesting point which is like as platform engineers, you work with a lot of folks that are adopting Open Tofu. Where do you see the friction? Is it the language versus DSL framework? What is it? Stephen, you wanna try to take a stab at that? So for me, my biggest almost barrier to contributing myself is that I don't know Go. So in order to be able to contribute, I'd have to go learn a whole new language which frankly I don't always have the time for. So as you say, if we can open it up to more languages, I would have tried to solve a lot of the pain points I've had over the time myself. Yeah, I mean a couple of lines of Python would have fixed that merge, easy. But yeah, exactly that. I think it doesn't have to be in Go and I think if we're able to find a way to just hook in other tools, scripts, it would at least allow people to build their own implementation using the language that they know. And answer your question, where do we come across it? I think what's really interesting about Terraform, the language is that it is very easy to pick up. But then you reach the point where you begin to treat it like a programming language because it looks and feels like it's got awesome docs, the docs are there, the open-toffee docs are good, it's got the CLI, you've got the compiler, that's the compiler right, then you've got all the other documentation and then all of a sudden you're like, this is a programming language, I'm gonna learn, I know this programming language, I need to do a condition. Oh boy, is it a count of zero am I using a ternary or all for each? That'll be easy, right? Oh boy. And then over we go to chat, gbt and all of the tools, all the LM based tools that we're all using, we are, it's helpful. They're all based off very early versions of very old code and at a time when the advice was, don't worry about it, put everything into workspaces, it'll be fine. Don't worry about how many environments you destroy, I mean manage, it'll be perfectly okay, guys. Like I talked a little bit about that before, so I don't think we need to repeat that, but I also, like when I say that I was a web developer starting to learn Terraform and I think that one of the main shifts when learning Terraform and now tofu, that as a developer you're always trying to succeeding to program a stateless applications and then infrastructure is code is stateful by nature and I think that's a really like big change for a programmer when they think about what change they're about to do and now they think they need to think about the existing infrastructure, how it will affect the existing infrastructure. I can't just delete this resource, like it will just harm like the entire infrastructure and it really need to understand what happens there and I don't think, I can't think of a way that changing like the syntax will help for that, it just, we still need to do the change in the way we think. Yeah, plus to extent on that, it's still, it's a cloud world, so you have to understand how AWS, for example, is working under the hood, I mean, creating a database, yes, true, easy, but what do you need else? What else do you need? You need a network, you need a security group, blah, blah, blah, all of these things. So where's the domain? So I'm a user, I'm a contributor to the internal modules, for example, so something like that. So talking about entry points, we talked about the extending the language by own providers, this is great, it's a great addition, but then again, look at it from the other side, from your end users and your end users are the developers actually who take the module, who wants to create a database, so in the end, so you provide the tools to it, but how can that be done? Just saying, so it's two. We had a question over here, James, go ahead. Yeah, I may get attacked by this one because I think it's a Twitter argument that pops up every six months or so, and a lot of the conversations that have been going on today have already kind of made an assumption that we're gonna go down this programming language, introductions of, there's had functions, there's had loops, there's had conditionals everywhere. Do you think there's value in doing what HashiCop did and keeping it declarative and keeping it simplified, but somehow integrating tighter with tools such as Terracran or other templating languages and things like this? Excellent question. Oh, why? So for me, I like to use Puppet as a good example in that very much so from the outset, they were, this is a DSL, you're gonna define your target state and don't get any illusions about complex programming language. They're very clear from the outset, but what they did manage to do was they iterated on the capabilities within Puppet to build in functionality that users and developers need and whether it was switching case statements. There's a lot of really good examples in Puppet that I would refer to and their approach has largely been from the same place. We need it needs to be declarative, we need to have some basic support to allow conditions to happen during evaluation at effectively a compile time. And what's really interesting about Puppet is that being written on Ruby, they did lean heavily into that if you want to extend it, you can. You should do it in Ruby, but you don't necessarily have to. And I think my answer to that question would really be I would like to follow the model that sort of Puppet labs have used in that that approach worked well and they have maintained that healthy balance of user and developer enablement without having to go, oh, we got functions here guys. You can extend it, you can build your own, essentially your own providers and they've established that healthy happy medium that seems to support almost all of the use cases. And as evidenced by all of the additions and extensions for Puppet have been in the modules that have been developed and the patterns that have been built, whereas in Terraform, because we haven't had those capabilities early on, the entire community has built it at the other side, the pre-execution, pre-compile stage in the likes of Terragrunt, which again, really popular, really awesome. And then at the, let's hide it from the user and let's build it in 27 layers of nulls. And as a heavy user of null resources for a long time, I'll hold on to it with my dying breath. We're running out of time here. Can we get some final thoughts from the other panelists and then we will have to make time for the lightning talks. Final thoughts, yeah, all the best for the community. Do it, enjoy, participate, bring PRs, put pressure on the developers here and then let's see where our journey continues. Echoing that, take part, start to learn to complain more about the tools you're using because once you start to complain, you can get things fixed, the squeaky wheel gets the grease off the wall. That's a really good point, yeah. Yeah, as the other guy said, the same thing, but yeah, also criticize the way we work, the way we work as open tofu and tell us what you think that's not working, suggest new ways and new methods and we're here to listen. My own perspective would be that I would, the only reason that the open tofu initiative really took off was that companies who make money from Terraform were able to fund full-time resources to allow this to happen. We wouldn't be here without it, no, number one, thank you. So for my part, I would like to see more bits that are Terraform adjacent commercialized because ultimately those will fund the things that have value to the community, whether that is tools like Terragrant that have commercial support. It needs to be okay to make money off Terraform, participate in the community. There was a couple of things that got really well, but open community, participation in the community, being involved in that and it is very important to be able to generate revenue or money of some sort out of the tools that you build, whether that's to sustain your own sort of hobby that you contribute to open tofu or whether it's that you work for an organization and there's value in doing that. I think it needs to be okay to commercialize some aspects of the supporting ecosystem that wrap around Terraform. And I'd like to see more of the tools that do that because the ones that do succeed will be the tools that we know we need most. Thank you very much for joining the panel and let's give them a big thank you.