6 ms·

Pulumi Founder/CEO here. The blog post is disingenuous. We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never acce

Pulumi Founder/CEO here. The blog post is disingenuous. We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin. Thankfully over time, they already pushed responsibility for most Terraform providers back onto their partners, so I'm hopeful the ecosystem of providers can still stay vibrant and open. We are deep believers in open source---heck my last project at Microsoft was to take .NET open source and cross-platform, our CTO helped found TypeScript, and Pulumi is an Apache open source project---it seems HashiCorp no longer is.

vmatsiiako 3y ago
I'm a huge fan of Pulumi. After HCP's license switch, I'm even more sure that Pulumi will be a clear winner over Terraform in the long term.
- Aeolun 3y ago
  I really don’t think that was ever in doubt. You only need to use it for a very short time to find that the ergonomics are infinitely nicer than Terraform.
  - vbezhenar 3y ago
    My biggest issue with terraform is concept of state file. It seems that Pulumi continues on this model. I wish someone came up with innovative idea of not needing state file.
    - grudg3 3y ago
      Bicep does that, but it's Azure only, and you can't really 'destroy', just apply.
      - rirze 3y ago
        From my prelimary search, Bicep does utilize a state file, but it is completely hidden from the end users. Seems to be managed in Azure directly and automagically. https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep https://learn.microsoft.com/en-us/azure/azure-resource-manag...
        chokolad 3y ago
        I think you might be misunderstanding this page. Bicep's "state file" is actual Azure state. Bicep is a nicer way to write ARM (Azure Resource Manager), which is pretty much an Azure API. if you are familiar with Kubernetes, ARM represents Azure internal state in the same way kubernetes YAML represents actual kubernetes objects stored in the cluster.
        rirze 3y ago
        > No state or state files to manage: All state is stored in Azure. Users can collaborate and have confidence their updates are handled as expected. Not sure how I could "misunderstand" this quote to mean anything else. By that logic, CloudFormation is also the same; end users don't have access to the state so therefore the state file is the state of the environment itself? We, as users, have no idea what intermediate step exists between the configuration yaml and actual representation of an account's resources.
    - notnmeyer 3y ago
      this is difficult for me to think about in the same way as trying to picture a 4th dimension. surely, state needs to be tracked somehow. what would an alternative even be?
      - verve_rat 3y ago
        Querying the cloud provider apis for current state? Go to the actual source of truth? I'm sure there are complications i don't care to see here, but why is "this is what is actually deployed" not the default case?
        Aeolun 3y ago
        Querying cloud provider API’s takes a while. It can be done, but the results are cached afterwards, which is the state file. Refreshing the state file (and reconciling differences) also uses the cloud provider API’s. I don’t think we’re going to get better than that. Unless someone makes a common standard for resource reporting that all cloud providers implement.
        notnmeyer 3y ago
        exactly. relying purely on the provider’s api seems like an untenable solution with the current state of things.
        yencabulator 3y ago
        The state file is more than a cache. If it was just a cache, it wouldn't be problematic.
        notnmeyer 3y ago
        you’d be subject to rate limits and all manner of potential issues and outages if you only query the providers api. that’s part of the case for a centralized state, to have an additional place that describes what should exist and what it looks like.
      - hdjjhhvvhga 3y ago
- hughesjj 3y ago
  <3 pulumi
fishpen0 3y ago
If they think we'll go crawling back to their 100x more expensive 6-7 figure Terraform Enterprise garbage just because we can't use spacelift anymore, then I'll show them the team of engineers we can hire for the same dollars to move the whole stack to pure pulumi or crossplane or the various CDKs The bald faced disingenuous nature of this change here is wild. They can't compete at their pricing because their pricing is absolutely insane over what the market can bear and they refuse to accept it. They are going out of their way to make it less expensive to stop using terraform altogether right as so many new options have entered the market
- fishnchips 3y ago
  Spacelift co-founder here - please don’t panic. We will make sure you can continue to use Spacelift :)
  - candiddevmike 3y ago
    You, humanitec, and env0 should start a community fork of pre-BSL Terraform and donate it to the CNCF.
    - mattl 3y ago
      I really hope this happens.
    - networkchad 3y ago
      [dead]
    - Coryodaniel 3y ago
      Massdriver would contribute here.
    - fishnchips 3y ago
      I believe it's a bit too early to make this call but based on the experience of interacting with Terraform the binary it would be absolutely amazing for the community if Terraform could be turned into a library that can become a building block for higher level services.
lifeisstillgood 3y ago
Can I ask where Pulumi gets revenue from? (Honest question first time I have heard of you, quick look seems to be a CentOS for hashicorp ?) I love the ethos of open source and have spoken at and helped run conferences, and had the pleasure of being paid to develop it - but the productivity I had when paid ten hours a day to work on OSS compared to whenever I get a chance between work family and everything else, well, it's better for everyone to get paid and release code, than not get paid and not write the code. I see these semi-commercial licenses as the equivalent of a legal "just don't take the piss". Would be interested in your side of the question. How do we keep on developing the code as well as keeping it open?
- paulgb 3y ago
  I am a paying Pulumi user. Their tool integrates with a cloud platform and we pay per resource managed by Pulumi. Pulumi is one of several products where I like that it’s open source in case I need to move off their cloud, but hope that I don’t have to (Plausible is another).
  - joeduffy 3y ago
    [Joe, Pulumi Founder here.] Said well (and thank you for being a customer and valuable member of our community!) The analogy I draw sometimes is that our open source infrastructure as code SDK ("Pulumi") is like Git, and our commercial offering ("Pulumi Cloud") is like GitHub. Like GitHub, the Pulumi Cloud offers valuable features that go beyond the open source project for teams looking to manage lots of projects securely at scale, but we definitely love our open source community and want folks to have the choice to use Pulumi however makes the most sense for them. This approach also has the nice consequence that we can be fully transparent with our community at all times while also building a strong, long-term business. If a new feature is part of the infrastructure as code SDK, it's open source and free; if it's part of the Pulumi Cloud SaaS, it's part of our commercial offering. This avoids needing to do things like artificially hold back features (like open core) or violating our commitment to the open source community (like Hashi's new license).
    - 3y ago
scarface_74 3y ago
Opposite anecdote, I know a few SAs at AWS who contribute to Terraform.
- lolinder 3y ago
  This anecdote is a lot less interesting, both because of the separation (you know some people vs they run a company with direct exposure) and lack of detail. I'm sure you do know some people who contribute, but you haven't given any details about their experience that would contradict OP's claim that contributing is hard.
  - scarface_74 3y ago
    Is this enough detail? I work at AWS in Professional Services until tomorrow. I worked with the SA and had meetings with the service team responsible for the AWS Service in question to discuss the API shortcomings that we needed for automations. He contributed to Terraform once the APIs became available from our service team and I wrote the equivalent CloudFormation custom resources for a project (and open sourced on the public AWS Samples GitHub repo after going through the approval process) as part of a larger project. I found a bug in the underlying service API that affected both my implementation and the Terraform provider my coworker wrote. I posted a sample in our internal Slack channel where the developers of the AWS service hang out and they fixed the API bug relatively quickly. My coworker, had no problem getting his TF code merged in. I know the code he wrote and I went to the GitHub page before posting this and it is in there. Later as native CloudFormation support was added, I replaced my custom resources with the native equivalent as part of the larger project I was working on.
    - glenngillen 3y ago
      (former product lead for Terraform here) There's probably not much AWS contribution to the core of Terraform from AWS, but there's very little contribution to that from anybody outside of HashiCorp because contributions happen on the providers. AWS is definitely involved with their provider though. AWS ProServ built out a whole account vending machine thing that was in Terraform (the name escapes me atm), and various other service teams and SAs are regularly involved in contributing to and growing the Terraform ecosystem. It would be super disingenuous to imply AWS is not contributing to the success and growth of Terraform.
redeux 3y ago
>We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin. OSS doesn't mean that you have to accept any PRs that showed up in your repo, nor does it mean that you have to let a competitor steer your project simply because you're building in the open. Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp. As I'm sure you're well aware, every contribution has to be maintained and each increasing contribution comes with an additional burden. Responsible maintainers on large scale OSS projects must be selective about the code they let in.
- alexandre_m 3y ago
  You have to acknowledge that all these OSS projects officially backed by a corporation don't want you to contribute certain features that are part of their enterprise offering. As soon as there's an "enterprise" tier, contributions are not only based on their merit, but also evaluated as a threat to their business model. Sometimes it's not even obvious for external contributors, but there may be some small overlap with other paid features that are part of their product roadmap. If a project on Github only has maintainers from the corporate side, you can be certain that they will ultimately drive the product for their own interest solely. We should always pay close attention to the governance model of projects we depend on or that we wish to contribute to.
  - jupp0r 3y ago
    Of course, but the major difference is that if I don't like the maintainers, I can create a fork, build a community around it and happily run it in production. Imagine where nodejs would be right now if they had been BSL licensed in the iojs times.
- jen20 3y ago
  I’m sorry, but no. These are usually simple bugs like “forgot to a set a field during refresh”. They almost always correspond to one or more Terraform issues too, often ones that have been open for 4-5 years or have been “marked as stale” by some infuriating bot.
aatd86 3y ago
Open-source at big companies has a different financial structure. It's not comparable.
_cenw 3y ago
I'm not sure if open sourcing .NET is the best bit to put on your resume when Microsoft has been sabotaging the developer ecosystem to keep VS relevant. [1] Not that I don't appreciate the effort. I'm sure what has been achieved involved a fair share of convincing too. [1]: https://isdotnetopen.com/ https://isdotnetopen.com/ Being in the Apache Foundation gives me all the assurance I need alone, though.
mst 3y ago
They appear to be aware that the ecosystem is important and providers have remained under an OSS license (at least as of this change). So without defending the change they -have- made, that doesn't seem like where you're going to run into problems as a result of said change.
justinclift 3y ago
Hadn't heard of Pulumi before. It sounds like a Terraform alternative, but looking at the website it doesn't really convey if it's a Terraform fork or ground-up re-write, or something else?
- nailer 3y ago
  Pulumi is infra as code. Not like Terraform define it - using the world's most hated config file format - but actual code - Python, TypeScript, etc.
  - rirze 3y ago
    It is powered by Terraform underneath-- but Pulumi has done a ton of work to make the abstraction seamless.
    - justinclift 3y ago
      Thanks all. I'll add it to my ToDo list for checking out. :) --- Actually, on second thought it sounds like the platform they're built on top of (Terraform) is now undergoing some fundamental business model changes. Probably best to see how that plays out first. :/
      - chokolad 3y ago
        It is not powered by Terraform AFAIK
        rirze 3y ago
        Not sure why you're so insistent on this when Pulumi folks themselves on this post have said that they contribute back up to the AWS provider source repo (1). Maybe not all their providers utilize Terraform, but it was definitely how their product started out. When you run Pulimi using their AWS provider and get errors at runtime, some of those are verbatim Terraform errors. Their docs and site is very clear to muddle this connection but if you ever used their API, you'd know this. (1): https://news.ycombinator.com/item?id=37081306 https://news.ycombinator.com/item?id=37081306
nailer 3y ago
Just want to say I love Pulumi and think using actual code (rather than HCL config files) is the ideal realisation of the infra-as-code vision. Pulumi being open source while Terraform is now proprietary cements that.
melezhik 3y ago
However I wonder what’s pulumi future gonna be with that move ? So you guys now are going to maintain a transpiller for a closed product, huh ?
- anuraaga 3y ago
  I am very much wondering this too. I've used Pulumi and like it a lot, it has a great UX in general. But the ecosystem for Terraform is orders of magnitude bigger, e.g. searching for help on Terraform is going to give a lot more results than Pulumi. As someone who can dig into details, this is not a big deal and can use Pulumi on personal projects but cannot in good faith recommend it for team projects only because of the ability to find resources is more important then. I don't know if the license change actually means providers will not be able to work with Pulumi, but if it does, it seems risky to use Pulumi even for personal projects if newer provider versions (i.e., versions that work with newer products released by the cloud provider) will not work with Pulumi, it's a dead end. And that's not to mention the useful providers that aren't cloud and completely community developed that will not have the resources to maintain two codebases in any case (I'm thinking of Sendgrid). I looked at terraform-sdk license - it still seems to be MPL. I think this means that all providers can continue to be open and work with both platforms, it will be important for Pulumi to clarify this to prevent the death spiral. Given some negative feedback towards the Hashicorp blog post from Pulumi employees on this thread, I am somewhat skeptical of this since if everything is fine, then complaining will otherwise have a negative effect, that us users have to assume that Hashicorp is actually stomping them out. And if it's the case, sorry but in good faith to everyone else that may need to work on infrastructure I make, I will have to be complicit in the stomping.
_0c0t 3y ago
Pulumi is arguably the worst software I’ve ever used in my 15y career. I’d rather pay Hashicorp than use that dogshit. On top of that, whether or not an OSS project accepts your PR means nothing about its quality or utility. This change appears to have very little or nothing to do with most of us engineers and everything to do with companies wrapping and reselling. As far as I’m concerned it’s a good change. Anyone who’s thinking about it. Stay away from Pulumi unless you’re okay moving from declarative IAC to some bullshit imperative Python or node constructors and for loops, and everything else that comes with writing OOP. I don’t care about the Hashicorp brand. I care about writing quality IAC and Pulumi is not it.
thrixton 3y ago
Hey Joe, Would this prevent you from integrating some modules such as AWS (I believe) from TF? So much love for Pulumi from me, it’s an amazing product.

vmatsiiako 3y ago

I'm a huge fan of Pulumi. After HCP's license switch, I'm even more sure that Pulumi will be a clear winner over Terraform in the long term.

Aeolun 3y ago
I really don’t think that was ever in doubt. You only need to use it for a very short time to find that the ergonomics are infinitely nicer than Terraform.
- vbezhenar 3y ago
  My biggest issue with terraform is concept of state file. It seems that Pulumi continues on this model. I wish someone came up with innovative idea of not needing state file.
  - grudg3 3y ago
    Bicep does that, but it's Azure only, and you can't really 'destroy', just apply.
    - rirze 3y ago
      From my prelimary search, Bicep does utilize a state file, but it is completely hidden from the end users. Seems to be managed in Azure directly and automagically. https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep https://learn.microsoft.com/en-us/azure/azure-resource-manag...
      - chokolad 3y ago
        I think you might be misunderstanding this page. Bicep's "state file" is actual Azure state. Bicep is a nicer way to write ARM (Azure Resource Manager), which is pretty much an Azure API. if you are familiar with Kubernetes, ARM represents Azure internal state in the same way kubernetes YAML represents actual kubernetes objects stored in the cluster.
        rirze 3y ago
        > No state or state files to manage: All state is stored in Azure. Users can collaborate and have confidence their updates are handled as expected. Not sure how I could "misunderstand" this quote to mean anything else. By that logic, CloudFormation is also the same; end users don't have access to the state so therefore the state file is the state of the environment itself? We, as users, have no idea what intermediate step exists between the configuration yaml and actual representation of an account's resources.
  - notnmeyer 3y ago
    this is difficult for me to think about in the same way as trying to picture a 4th dimension. surely, state needs to be tracked somehow. what would an alternative even be?
    - verve_rat 3y ago
      Querying the cloud provider apis for current state? Go to the actual source of truth? I'm sure there are complications i don't care to see here, but why is "this is what is actually deployed" not the default case?
      - Aeolun 3y ago
        Querying cloud provider API’s takes a while. It can be done, but the results are cached afterwards, which is the state file. Refreshing the state file (and reconciling differences) also uses the cloud provider API’s. I don’t think we’re going to get better than that. Unless someone makes a common standard for resource reporting that all cloud providers implement.
        notnmeyer 3y ago
        exactly. relying purely on the provider’s api seems like an untenable solution with the current state of things.
        yencabulator 3y ago
        The state file is more than a cache. If it was just a cache, it wouldn't be problematic.
      - notnmeyer 3y ago
        you’d be subject to rate limits and all manner of potential issues and outages if you only query the providers api. that’s part of the case for a centralized state, to have an additional place that describes what should exist and what it looks like.
    - hdjjhhvvhga 3y ago
hughesjj 3y ago
<3 pulumi

fishpen0 3y ago

If they think we'll go crawling back to their 100x more expensive 6-7 figure Terraform Enterprise garbage just because we can't use spacelift anymore, then I'll show them the team of engineers we can hire for the same dollars to move the whole stack to pure pulumi or crossplane or the various CDKs The bald faced disingenuous nature of this change here is wild. They can't compete at their pricing because their pricing is absolutely insane over what the market can bear and they refuse to accept it. They are going out of their way to make it less expensive to stop using terraform altogether right as so many new options have entered the market

fishnchips 3y ago
Spacelift co-founder here - please don’t panic. We will make sure you can continue to use Spacelift :)
- candiddevmike 3y ago
  You, humanitec, and env0 should start a community fork of pre-BSL Terraform and donate it to the CNCF.
  - mattl 3y ago
    I really hope this happens.
  - networkchad 3y ago
    [dead]
  - Coryodaniel 3y ago
    Massdriver would contribute here.
  - fishnchips 3y ago
    I believe it's a bit too early to make this call but based on the experience of interacting with Terraform the binary it would be absolutely amazing for the community if Terraform could be turned into a library that can become a building block for higher level services.

lifeisstillgood 3y ago

Can I ask where Pulumi gets revenue from? (Honest question first time I have heard of you, quick look seems to be a CentOS for hashicorp ?) I love the ethos of open source and have spoken at and helped run conferences, and had the pleasure of being paid to develop it - but the productivity I had when paid ten hours a day to work on OSS compared to whenever I get a chance between work family and everything else, well, it's better for everyone to get paid and release code, than not get paid and not write the code. I see these semi-commercial licenses as the equivalent of a legal "just don't take the piss". Would be interested in your side of the question. How do we keep on developing the code as well as keeping it open?

paulgb 3y ago
I am a paying Pulumi user. Their tool integrates with a cloud platform and we pay per resource managed by Pulumi. Pulumi is one of several products where I like that it’s open source in case I need to move off their cloud, but hope that I don’t have to (Plausible is another).
- joeduffy 3y ago
  [Joe, Pulumi Founder here.] Said well (and thank you for being a customer and valuable member of our community!) The analogy I draw sometimes is that our open source infrastructure as code SDK ("Pulumi") is like Git, and our commercial offering ("Pulumi Cloud") is like GitHub. Like GitHub, the Pulumi Cloud offers valuable features that go beyond the open source project for teams looking to manage lots of projects securely at scale, but we definitely love our open source community and want folks to have the choice to use Pulumi however makes the most sense for them. This approach also has the nice consequence that we can be fully transparent with our community at all times while also building a strong, long-term business. If a new feature is part of the infrastructure as code SDK, it's open source and free; if it's part of the Pulumi Cloud SaaS, it's part of our commercial offering. This avoids needing to do things like artificially hold back features (like open core) or violating our commitment to the open source community (like Hashi's new license).
  - 3y ago

scarface_74 3y ago

Opposite anecdote, I know a few SAs at AWS who contribute to Terraform.

lolinder 3y ago
This anecdote is a lot less interesting, both because of the separation (you know some people vs they run a company with direct exposure) and lack of detail. I'm sure you do know some people who contribute, but you haven't given any details about their experience that would contradict OP's claim that contributing is hard.
- scarface_74 3y ago
  Is this enough detail? I work at AWS in Professional Services until tomorrow. I worked with the SA and had meetings with the service team responsible for the AWS Service in question to discuss the API shortcomings that we needed for automations. He contributed to Terraform once the APIs became available from our service team and I wrote the equivalent CloudFormation custom resources for a project (and open sourced on the public AWS Samples GitHub repo after going through the approval process) as part of a larger project. I found a bug in the underlying service API that affected both my implementation and the Terraform provider my coworker wrote. I posted a sample in our internal Slack channel where the developers of the AWS service hang out and they fixed the API bug relatively quickly. My coworker, had no problem getting his TF code merged in. I know the code he wrote and I went to the GitHub page before posting this and it is in there. Later as native CloudFormation support was added, I replaced my custom resources with the native equivalent as part of the larger project I was working on.
  - glenngillen 3y ago
    (former product lead for Terraform here) There's probably not much AWS contribution to the core of Terraform from AWS, but there's very little contribution to that from anybody outside of HashiCorp because contributions happen on the providers. AWS is definitely involved with their provider though. AWS ProServ built out a whole account vending machine thing that was in Terraform (the name escapes me atm), and various other service teams and SAs are regularly involved in contributing to and growing the Terraform ecosystem. It would be super disingenuous to imply AWS is not contributing to the success and growth of Terraform.

redeux 3y ago

>We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin. OSS doesn't mean that you have to accept any PRs that showed up in your repo, nor does it mean that you have to let a competitor steer your project simply because you're building in the open. Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp. As I'm sure you're well aware, every contribution has to be maintained and each increasing contribution comes with an additional burden. Responsible maintainers on large scale OSS projects must be selective about the code they let in.

alexandre_m 3y ago
You have to acknowledge that all these OSS projects officially backed by a corporation don't want you to contribute certain features that are part of their enterprise offering. As soon as there's an "enterprise" tier, contributions are not only based on their merit, but also evaluated as a threat to their business model. Sometimes it's not even obvious for external contributors, but there may be some small overlap with other paid features that are part of their product roadmap. If a project on Github only has maintainers from the corporate side, you can be certain that they will ultimately drive the product for their own interest solely. We should always pay close attention to the governance model of projects we depend on or that we wish to contribute to.
- jupp0r 3y ago
  Of course, but the major difference is that if I don't like the maintainers, I can create a fork, build a community around it and happily run it in production. Imagine where nodejs would be right now if they had been BSL licensed in the iojs times.
jen20 3y ago
I’m sorry, but no. These are usually simple bugs like “forgot to a set a field during refresh”. They almost always correspond to one or more Terraform issues too, often ones that have been open for 4-5 years or have been “marked as stale” by some infuriating bot.

aatd86 3y ago

Open-source at big companies has a different financial structure. It's not comparable.

_cenw 3y ago

I'm not sure if open sourcing .NET is the best bit to put on your resume when Microsoft has been sabotaging the developer ecosystem to keep VS relevant. [1] Not that I don't appreciate the effort. I'm sure what has been achieved involved a fair share of convincing too. [1]: https://isdotnetopen.com/ https://isdotnetopen.com/ Being in the Apache Foundation gives me all the assurance I need alone, though.

mst 3y ago

They appear to be aware that the ecosystem is important and providers have remained under an OSS license (at least as of this change). So without defending the change they -have- made, that doesn't seem like where you're going to run into problems as a result of said change.

justinclift 3y ago

Hadn't heard of Pulumi before. It sounds like a Terraform alternative, but looking at the website it doesn't really convey if it's a Terraform fork or ground-up re-write, or something else?

nailer 3y ago
Pulumi is infra as code. Not like Terraform define it - using the world's most hated config file format - but actual code - Python, TypeScript, etc.
- rirze 3y ago
  It is powered by Terraform underneath-- but Pulumi has done a ton of work to make the abstraction seamless.
  - justinclift 3y ago
    Thanks all. I'll add it to my ToDo list for checking out. :) --- Actually, on second thought it sounds like the platform they're built on top of (Terraform) is now undergoing some fundamental business model changes. Probably best to see how that plays out first. :/
    - chokolad 3y ago
      It is not powered by Terraform AFAIK
      - rirze 3y ago
        Not sure why you're so insistent on this when Pulumi folks themselves on this post have said that they contribute back up to the AWS provider source repo (1). Maybe not all their providers utilize Terraform, but it was definitely how their product started out. When you run Pulimi using their AWS provider and get errors at runtime, some of those are verbatim Terraform errors. Their docs and site is very clear to muddle this connection but if you ever used their API, you'd know this. (1): https://news.ycombinator.com/item?id=37081306 https://news.ycombinator.com/item?id=37081306

nailer 3y ago

Just want to say I love Pulumi and think using actual code (rather than HCL config files) is the ideal realisation of the infra-as-code vision. Pulumi being open source while Terraform is now proprietary cements that.

melezhik 3y ago

However I wonder what’s pulumi future gonna be with that move ? So you guys now are going to maintain a transpiller for a closed product, huh ?

anuraaga 3y ago
I am very much wondering this too. I've used Pulumi and like it a lot, it has a great UX in general. But the ecosystem for Terraform is orders of magnitude bigger, e.g. searching for help on Terraform is going to give a lot more results than Pulumi. As someone who can dig into details, this is not a big deal and can use Pulumi on personal projects but cannot in good faith recommend it for team projects only because of the ability to find resources is more important then. I don't know if the license change actually means providers will not be able to work with Pulumi, but if it does, it seems risky to use Pulumi even for personal projects if newer provider versions (i.e., versions that work with newer products released by the cloud provider) will not work with Pulumi, it's a dead end. And that's not to mention the useful providers that aren't cloud and completely community developed that will not have the resources to maintain two codebases in any case (I'm thinking of Sendgrid). I looked at terraform-sdk license - it still seems to be MPL. I think this means that all providers can continue to be open and work with both platforms, it will be important for Pulumi to clarify this to prevent the death spiral. Given some negative feedback towards the Hashicorp blog post from Pulumi employees on this thread, I am somewhat skeptical of this since if everything is fine, then complaining will otherwise have a negative effect, that us users have to assume that Hashicorp is actually stomping them out. And if it's the case, sorry but in good faith to everyone else that may need to work on infrastructure I make, I will have to be complicit in the stomping.

_0c0t 3y ago

Pulumi is arguably the worst software I’ve ever used in my 15y career. I’d rather pay Hashicorp than use that dogshit. On top of that, whether or not an OSS project accepts your PR means nothing about its quality or utility. This change appears to have very little or nothing to do with most of us engineers and everything to do with companies wrapping and reselling. As far as I’m concerned it’s a good change. Anyone who’s thinking about it. Stay away from Pulumi unless you’re okay moving from declarative IAC to some bullshit imperative Python or node constructors and for loops, and everything else that comes with writing OOP. I don’t care about the Hashicorp brand. I care about writing quality IAC and Pulumi is not it.

thrixton 3y ago

Hey Joe, Would this prevent you from integrating some modules such as AWS (I believe) from TF? So much love for Pulumi from me, it’s an amazing product.