Hacker News Reader

Comment by joeduffy | Hacker News Reader

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.

View on HN

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

Spacelift co-founder here - please don’t panic. We will make sure you can continue to use Spacelift :)

You, humanitec, and env0 should start a community fork of pre-BSL Terraform and donate it to the CNCF.

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.

Massdriver would contribute here.

I really hope this happens.

I don't know the details of BSL, but can HashiCorp now require compensation/$$$ from Spacelift, Scalr, Env0, etc? In that case, these products can be forced to offer similar pricing as Terraform Cloud.

IANAL but I believe the BSL restrictions only apply to new upstream code versions. All HashiCorp repos can and always will be usable under MPL as they were up until the moment immediately before the license change.

In other words: if you hard fork now, you don't need to pay.

>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.

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.

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.

Sure, OSS doesn't mean you have to take all PRs, but if your claim is that others are just taking your code and not giving anything back, one of the alleged leeches showing up to talk about how they've tried to give back is very much pertinent.

Having been on the upstream side of things, it's very he-said-she-said. HashiCorp code could be a PITA to contribute to, or maybe this particular provider was bad at contributing.

The only way to know for sure is to dive into the merged and unmerged PRs and see how they were handled.

I'm not affiliated in any way with one of their competitors. Co-workers and I sent bug fix PR's to for example Vault. The last couple of years almost none of them were merged. These were small bug fixes, not (large) feature additions.

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.

Then don't complain about people not contributing to your projects. You reserve the right to reject my PR, and I reserve the right not to contribute any more.

I don't know if it is the case for the fixes pulumi sent, but for PRs I've made to terraform providers it can take a very long time for them to be looked at, and even longer to get merged. And I think it is mostly from nor having enough resources to approve and merge PRs. Although that could possibly be fixed by inviting developers outside the company to help with approval and merging, especially for providers.

That's a lot of assumptions you're making here. From my little use of terraform it did had a bunch of issues that were purely a bug and laying unfixed for a long time.

For example, the widely used 'count' anti-pattern is still present, and no actions have been taken up to this day. This topic has persisted for 5 years. 5 YEARS!!! That's what triggered my decision to migrate to Pulumi.

> Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp.

Fair enough, let's see the PRs so we can judge for ourselves.

isn't the simpler explanation that they would in effect lose the ability to relicense the project and therefore lose control of their baby?

To not lose control you need to have people assign copyright which is generally a headache. I've only heard of the FSF doing that .. (not sure why this hasn't been streamlined electronically somehow)

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?

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).

[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).

So here's my perspective on these two competing models:

1. I can read all of the code, modify it, and self-host it for my own purposes, but the license disallows me from re-selling it.

2. I can read, modify, self-host, and commercialize a subset of the code, and the rest is an opaque SaaS.

To me, as a customer with no interest in re-selling this code, I don't see how #2 is better than #1 in any way. And I find it incredibly mystifying that I keep seeing companies ragged on here for doing #1 while the model in #2 is somehow held up as the paragon of ethical virtue or something.

Can you help me understand? Why is it better for me to be able to read less of the code I'm running?

Convenience and reliability from a business perspective

For #2 in good faith using the github model here,

Sure there’s Git and Github. Also sourcehut, using google cloud source repository or any managed git service.

Either 1) I need the software and I can have a team maintain it.

Electing for the software-as-a-service vs self hosted model is in itself.

1. I can compute, resources, maintenance and time The proprietary or a version of the product myself or a fork and get the feature functionality from other open source or provider.

2. Pay for the GitHub licensing cost and using the service and ok with magic abstractions to operate the software. (Which admirably lately has been bad.

Also frame it as from the beginning of the git project elected to also build all the same parity features, would it be the same tool, be the product that exists, or brain share it has today. Maybe not.

I maybe misunderstanding you here but in these cases opaqueness is part your trade off to offload fairly complex for a marginal cost that’s s decision by you.

Yeah I think you misunderstood my point a bit.

What I like best is to use a fully managed service that I can contribute changes or even self host a modified version if that's what I need to do to get what I need. But I don't want to self-host. But I highly value the option. And I highly value the ability to go read the code when I wonder "hmmm why is it doing that?" and maybe contribute a bug fix if it shouldn't be.

All of this works great with model #1 - with full "source available" with a license that limits re-sale - but is limited with model #2, where it only works for the "open core" portions of the product, but not the proprietary SaaS portion.

It’s also fair to say this isnt black and white and open source is vast and there are certain software and companies where opting for #2 that definitely feel like a big rug pull, money grab, and smack in the face to the community that supported them. (Is red hat in my opinion)

If you want to build something with a bunch of smart people for a long period of time the outcome is raising venture capital, paying people salaries that are competitive to share holders, and won’t implode. The bsl is a consequence of that but it is a rule to guard from the few bad apple in this case.

What’s ethical or virtuous or perfect is very nuanced

Yeah, I think this is right, and well put.

Usually the two are not mutually exclusive. Terraform Cloud (the HC equivalent of the aforementioned "opaque SaaS") is afaik not open source and never has been, you can't read the code for it or self-host it. Not opining on the broader issue, just clarifying this point.

Yes thank you for the clarification.

I prefer #1 too, given that the source code will eventually become FOSS one day.

SSPL is unacceptable for me because it have its restrictions last forever.

Is the Pulumi Individual Edition open for use by solo founders operating as a sole proprietership? I can't find anything clarifying whether it's individual (as in hobbyist, nonprofessional) or individual, as in, one person not collaborating with anyone else.

Yes it is open to individual comercial use (companies much larger then sole proprieterships may only have one person doing inferstructure). They also have a version for nonprofits https://www.pulumi.com/pricing/open-source-free-tier/

Do you have a source for that (or are you affiliated)?

Pulumi engineer here. There’s no restriction —- you’re free to use the Individual Edition commercially if you like.

Plausible is amazing, I love it. I moved off of another platform that started as open source and then went closed source, but Plausible ended up being a better platform over all anyways.

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/

Being in the Apache Foundation gives me all the assurance I need alone, though.

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.

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.

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.

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?

> this is difficult for me to think about in the same way as trying to picture a 4th dimension.

Why? There are many possibilities, just not that efficient. One of them would involve tagging. The problem with that approach is that not all resources are taggable, and it would take longer to query them.

tagging provider resources? not speaking for every provider or api, but at least on AWS not everything that can be managed supports tagging.

also this requires N api calls each time you check the state for an update. scaling that to a larger team may be difficult due to rate limits.

infra as code tools have to operate within the parameters that the provider apis allow. so when i say it’s hard to imagine, i’m thinking about limitations of the underlying apis.

totally possible im missing something obvious, but there’s a good reason that centralized state exists today. genuinely curious about how we could ditch it in a reasonable way with the existing big cloud APIs.

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?

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.

The state file is more than a cache. If it was just a cache, it wouldn't be problematic.

exactly. relying purely on the provider’s api seems like an untenable solution with the current state of things.

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.

Bicep does that, but it's Azure only, and you can't really 'destroy', just apply.

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-manag...

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.

> 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.

<3 pulumi

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.

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?

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.

It is powered by Terraform underneath-- but Pulumi has done a ton of work to make the abstraction seamless.

Only some of the providers are based on Terraform. I think it would be incorrect to say it's "powered by Terraform."

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. :/

It is not powered by Terraform AFAIK

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

As far as I know Pulumi is not powered by Terraform underneath.

Open-source at big companies has a different financial structure.

It's not comparable.

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

It's definitely possible. I patched the AWS Terraform provider. It took three months to merge the two line bugfix though. Terraform's biggest weakness may be that it's too ambitious for its own good. 1.7k issues on Terraform itself and another 3.7k on the AWS provider. Ended up using boto3 to build out my CD platform.

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.

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.

(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.

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.

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 ?

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.

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.

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.

Reply on news.ycombinator.com