If you’re asking why aren’t DevOps/SRE mentioned specifically on the OpenTofu front page, I don’t think you understand how common this software is… Like if someone forked Google, you wouldn’t need to describe what Google is. Everyone already knows it. For the people in this industry, terraform is essentially a defacto monopoly. Even if you don’t use it, if you’re working in SRE, you know what it is and what it does.
Think about it, you’re a novice, or maybe a sales guy, project manager, or even just a developer. I’m a senior software developer and my understanding of what Terraform is doing, is rather vague - and 99% of that knowledge comes from a single guy I talked to a whole ago. These depths of infrastructure have been hardly of any relevance to me for quite some time.
Now, imagine one of the aforementioned people being told something about some weird soy based software and starting to google. This site won’t tell them, what they need to know. That’s what I meant above: this site is not intended for people who already know.
I still don’t really see the argument. OpenTofu exists because of internal drama about licensing on a tool that you don’t use…
Someone building a different banana picker that looks just like another banana picker doesn’t need to explain their reasoning in terms a coal miner would understand…
Also, literally just clicking the intro doc linked from the main page tells you everything you need to know…
Again, put yourself in the shoes of someone not familiar with that. You’re a project manager. You read somewhere about it, hear an engineer talk about it, etc. You see this site. You don’t even know, if you’re on the right site.
I’m saying that not as an insult, but you are seemingly unable to understand, that there’s a huge world outside of IT, that still has contact points with IT and wants to know about some parts. And that is exactly what the homepage is supposed to convey. What is it? What is it doing? Why should I pick this? Where can I get it?
Why should a project manager pick an IaaC tool? There is something fundamentally wrong if people without the required technical knowledge are making technical choices. The website explains things in a way that requires a good bit of knowledge, but that’s because you’re not the right person to make these decisions if you don’t have that knowledge. DevOps and IaaC are complex fields if done right, and trying to explain them in simple terms will not improve decision making.
Let’s think of a simple example: you’re starting a new project, the current infrastructure is technology A, but one engineer proposes technology B, since it’s better in categories X,Y,Z. You can plug in anything you want here. Now, the engineers can give their opinions and estimates, but they can’t decide it. The PM can. It’s his job to weigh the risks and uncertainties and decide on the path forward.
Again, as the guy above, you’re thinking way too narrowly focused on your small slice of the world. IT departments aren’t magical omnipotent collections of super smart people, revolving mainly around themselves and their superior technology. They’re just cogs, we are cogs, and our job is, to keep a machine running.
Let’s think of a simple example: you’re starting a new project, the current infrastructure is technology A, but one engineer proposes technology B, since it’s better in categories X,Y,Z. You can plug in anything you want here. Now, the engineers can give their opinions and estimates, but they can’t decide it. The PM can. It’s his job to weigh the risks and uncertainties and decide on the path forward.
This has absolutely not been the case in any corporation I’ve worked, the PM is not allowed to make these kinds of decisions. They are made by technical or solution architects. It’s also in no way a PMs job to weigh risks and uncertainties when making technical choices, since they literally can’t.
Again, as the guy above, you’re thinking way too narrowly focused on your small slice of the world. IT departments aren’t magical omnipotent collections of super smart people, revolving mainly around themselves and their superior technology. They’re just cogs, we are cogs, and our job is, to keep a machine running.
You’ve obviously never worked in a corporation if you think a PM is allowed to make this kind of choice.
Man, I didn’t agree with any of your comments before this one, but I could at least see your point of view, but this…
You can plug in anything you want here. Now, the engineers can give their opinions and estimates, but they can’t decide it. The PM can. It’s his job to weigh the risks and uncertainties and decide on the path forward.
You are either a PM yourself or are just making shit up to argue. The PM, at best should only be responsible for signing off on tech choices. If PMs were making decisions, then we would all be using Excel as an enterprise database, documentation tool, and version control.
I’m not a PM, but I can actually see, how decisions are made. You actually wrote it yourself without realizing: a PM signs it off. He has to take the risk. If it seems too risky, he won’t accept it.
Just go to your PM next meeting and propose to rewrite everything in, say, Rust. Will he agree? Probably not. Did he make a technical decision? Probably not.
Don’t kid yourself with technological grandeur. If your PM doesn’t want to do X, X won’t happen.
Is that the crowd you want to address people on your frontpage?
If you’re asking why aren’t DevOps/SRE mentioned specifically on the OpenTofu front page, I don’t think you understand how common this software is… Like if someone forked Google, you wouldn’t need to describe what Google is. Everyone already knows it. For the people in this industry, terraform is essentially a defacto monopoly. Even if you don’t use it, if you’re working in SRE, you know what it is and what it does.
But what if you’re not in that business?
Think about it, you’re a novice, or maybe a sales guy, project manager, or even just a developer. I’m a senior software developer and my understanding of what Terraform is doing, is rather vague - and 99% of that knowledge comes from a single guy I talked to a whole ago. These depths of infrastructure have been hardly of any relevance to me for quite some time.
Now, imagine one of the aforementioned people being told something about some weird soy based software and starting to google. This site won’t tell them, what they need to know. That’s what I meant above: this site is not intended for people who already know.
I still don’t really see the argument. OpenTofu exists because of internal drama about licensing on a tool that you don’t use…
Someone building a different banana picker that looks just like another banana picker doesn’t need to explain their reasoning in terms a coal miner would understand…
Also, literally just clicking the intro doc linked from the main page tells you everything you need to know…
Again, put yourself in the shoes of someone not familiar with that. You’re a project manager. You read somewhere about it, hear an engineer talk about it, etc. You see this site. You don’t even know, if you’re on the right site.
I’m saying that not as an insult, but you are seemingly unable to understand, that there’s a huge world outside of IT, that still has contact points with IT and wants to know about some parts. And that is exactly what the homepage is supposed to convey. What is it? What is it doing? Why should I pick this? Where can I get it?
You summarized my thoughts perfectly through the thread.
Why should a project manager pick an IaaC tool? There is something fundamentally wrong if people without the required technical knowledge are making technical choices. The website explains things in a way that requires a good bit of knowledge, but that’s because you’re not the right person to make these decisions if you don’t have that knowledge. DevOps and IaaC are complex fields if done right, and trying to explain them in simple terms will not improve decision making.
You obviously never worked in a corporation.
Let’s think of a simple example: you’re starting a new project, the current infrastructure is technology A, but one engineer proposes technology B, since it’s better in categories X,Y,Z. You can plug in anything you want here. Now, the engineers can give their opinions and estimates, but they can’t decide it. The PM can. It’s his job to weigh the risks and uncertainties and decide on the path forward.
Again, as the guy above, you’re thinking way too narrowly focused on your small slice of the world. IT departments aren’t magical omnipotent collections of super smart people, revolving mainly around themselves and their superior technology. They’re just cogs, we are cogs, and our job is, to keep a machine running.
I’ve worked in a couple corporations, thank you.
This has absolutely not been the case in any corporation I’ve worked, the PM is not allowed to make these kinds of decisions. They are made by technical or solution architects. It’s also in no way a PMs job to weigh risks and uncertainties when making technical choices, since they literally can’t.
You’ve obviously never worked in a corporation if you think a PM is allowed to make this kind of choice.
Then ask yourself: who is taking the risk? Who will get blamed, if the project fails? The architect? Or the guy who let the architect do his thing?
Man, I didn’t agree with any of your comments before this one, but I could at least see your point of view, but this…
You are either a PM yourself or are just making shit up to argue. The PM, at best should only be responsible for signing off on tech choices. If PMs were making decisions, then we would all be using Excel as an enterprise database, documentation tool, and version control.
I’m not a PM, but I can actually see, how decisions are made. You actually wrote it yourself without realizing: a PM signs it off. He has to take the risk. If it seems too risky, he won’t accept it.
Just go to your PM next meeting and propose to rewrite everything in, say, Rust. Will he agree? Probably not. Did he make a technical decision? Probably not.
Don’t kid yourself with technological grandeur. If your PM doesn’t want to do X, X won’t happen.