The flow control loss is important in the sense that if you choose to opt into a framework, it's very hard to opt out.
You need to think about it in terms of risk mitigation. So that's why we say “Frameworks, no. Libraries, yes.”, because if you have a library, as long as something else matches those function calls, you're pretty good, right? You can swap it out.
Or you can build a little adapter there. You don't have to rewrite your entire program if you decide you don't like your time library or something like that. That's why we focus on frameworks.
With everything, of course, there's trade-offs, right? A big trade-off is that we have to implement a lot of stuff that maybe you see, “Oh, I can just get that. I can do npm install and I'm good to go.”
The benefit for me, based on how I like to think about problems and approach problems, is that the control that we gain, the power that we gain, by inventing these things ourselves, is worth the time spent. We never spend future time trying to debug a new release or understand how some things change or being forced into doing a big refactoring because we need to get the latest version… like a security fix or something like that.
Especially as a lean, really small team where we want to be very conscious of, here's the time that we want to spend on an engineering problem and here's the time we don't want to spend. And here's the point where we know we want to change some dependencies or something like that. For us, that's been really valuable to be able to have that control and not be forced into someone else's release cycle.
Yeah, so as you pointed out, we're a bootstrap company - small, lean. And we don't have a huge marketing budget, to say the least. And we also just consume so much open source software.
We thought for a really long time, you know, is this… if we decide… we wanted to open source for a while, and we thought, is this going to destroy the business if we do this? Are people just going to copy it or just run it without upselling to the paid version or something like that?
So we thought for a really long time about how we wanted to break up the feature set. So we are open source, but technically we're open core. And we took three features and we said, these are the ones that we think larger organizations are the only ones that really benefit from these. And in our case, that is a centralized configuration - so a center place you can configure everything. Like all these security compliance things - RBAC is another one. And then our audit trail functionality as well.
And we think that for smaller groups, they don't need those things. They're not going to really benefit that much from them. That's kind of like where we started.
Once we agreed on this is the feature set, we thought about, all right, what's the benefit here to open sourcing? And really it's about, you can just talk to people in a different way, right?
People kind of feel when you're trying to sell them on your thing because you want them to pay for it versus, hey, you can just use it or not use it, that's up to you.Here's what it does. If you want to make it better, please submit a pull request and that'd be great and we'd love to have you.
And I think that is just a great way to be able to talk to people and a lot of people end up being like, “All right, well, you're actually doing a great job. I want to get the other features or I just want to find some way to help you guys out to maintain this because that's making my life a lot easier.”
The 10th episode. And it's just when we're getting into like the different ways of like running it. So it's like, “Oh, you can run it in Atlantis… I've seen this, that, that… Like this is one way…” but it's like five minutes and we're off.
And then we have a couple of other ones, like more deep dive. So it's like… the importing existing infrastructure one. So these are more like very specific, like, hey, here's how to do this complicated thing in OpenTofu.
But these are also resources that aren't… like, I went around, I was like, what isn't there great resources on in the Terraform space? And that's how I got the idea for the importing one. Every blog you read is like, I run Terraform import. And it's like, okay, but it generates the shittiest code.
And for somebody who's never written IaC before, you're like, “Oh, it generated code for me. I'm good.” And it's like, “No! No, you are nowhere close to good. You're 5% of the way there.” Like you have a lot of refactoring to do to make this thing be able to produce multiple environments. You literally have code to manage that specific resource.
So, you know, we wanted to be able to do stuff that like would not just benefit the OpenTofu community, but also like, hey, if you're in the Terraform space and you're trying to figure out how do I get all my existing cloud stuff into Terraform and generate some Terraform code - Like I want them to benefit too.
