681–690 of 760 posts
Earlier quoted context omitted.
All of the current BigTech companies except Amazon were profitable before going public - Apple, Microsoft, Google, Facebook. The vast majority of tech companies that IPOd since Facebook have been a disaster of an investment.
Time didn't start in 2004.
Earlier quoted context omitted.
> This is purely a way for HashiCorp to ensure they are the only ones who can commercialize these formerly open source projects. Which is fine. But just go closed source, then, and own that, instead of trying to have it both ways. Pragmatically I would rather bsl than closed source and I am more likely to use a product that is bsl, with reasonable transfer time and license, than a 100% closed source product.
I mostly agree. But I also think it is a jerk move to change the license like this after accepting many external contributions, even if it is legal due to CLAs. At least they admit it isn't open source in the FAQ and are calling it the community version instead of the open source version.
Earlier quoted context omitted.
Are you pretending they aren't a competitor profiting off that work though? Pulumi is free, except you pay for the features that aren't free: https://www.pulumi.com/pricing/ . So, Pulumi has grown their directly competing product partially on top of the Terraform ecosystem - and I'd argue they'd be half as successful without reusing Terraform providers - and make money off of that product. It's at least understandabl…
> Pulumi is free, except you pay for the features that aren't free: https://www.pulumi.com/pricing/ . That's being disingenuous. The link you cite is the pricing of Pulumi Cloud. Of course hosting infra can cost money. The second non-heading line in your link shows a way to host Pulumi on your own infra and that is fully free: https://www.pulumi.com/docs/concepts/state#using-a-self-mana...
However, Pulumi Cloud is only as valuable as Pulumi itself. If Pulumi didn't support deploying to AWS, for example, then it is useless to my organization which uses AWS and I'm obviously not going to consider Pulumi Cloud. So Pulumi does gain a lot of value even from just the Terraform AWS provider that it uses under the hood (and which it can continue to use because it seems Terraform provider licenses are not changing, which is nice).
Earlier quoted context omitted.
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?
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?
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.
Earlier quoted context omitted.
Are you pretending they aren't a competitor profiting off that work though? Pulumi is free, except you pay for the features that aren't free: https://www.pulumi.com/pricing/ . So, Pulumi has grown their directly competing product partially on top of the Terraform ecosystem - and I'd argue they'd be half as successful without reusing Terraform providers - and make money off of that product. It's at least understandabl…
> Pulumi is free, except you pay for the features that aren't free: https://www.pulumi.com/pricing/ . The paid features have nothing to do with the providers; AFAICT that's competing with Hashicorps's backend / state management offerings - namely, Terraform Cloud: https://www.hashicorp.com/products/terraform/pricing?ajs_aid...
They absolutely do. If I use AWS and Pulumi could not deploy to AWS, well I'm certainly not going to buy Pulumi Cloud, am I? If I use multiple cloud providers and Pulumi doesn't support all of them, I'm unlikely to invest further in Pulumi Cloud, right?
The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
The fact that Pulumi leverages the Terraform AWS provider under the hood adds huge value for them, and I absolutely believe they indirectly profit off of that.
Earlier quoted context omitted.
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…
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.…
Earlier quoted context omitted.
[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 sec…
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 inc…
Earlier quoted context omitted.
> That commons has far far more value than any one or ten pieces of software. I don't think so. I suppose I can understand why people who feel strongly that the OSI definition is perfect (or at least extremely good) are very intent on protecting it, whereas I see it as flawed and am thus less concerned about this fracturing. So I understand your perspective upon reflection, though I honestly have a lot of trouble ima…
I don't think that the OSD is perfect, at all; I will readily acknowledge its problems. (And OSI more so.) I think it's a common shared understanding and a focal point, and there's huge value in preserving that. Having a different common understanding might be acceptable, and might even be an improvement, but only if people agree on it. Having no common understanding would mean something of great value was lost. Righ…
Yeah I guess this just seems like hyperbole to me. It seems good to me that there's a pretty widely agreed upon definition, sure, but I just don't think it matters all that much, in the scheme of things.
Agree to disagree I suppose!
Earlier quoted context omitted.
Thats exactly the point.
I'm not sure if we're agreeing or not to be honest. I'm not sure if you're implying it's a bad thing that people won't contribute to AGPL+CLA (and thereby justifies these more restrictive licenses), or agreeing that people shouldn't contribute to AGPL+CLA (and thereby volunteer their time to the benefit of one specific vendor).
I view that as a very different question from whether its ethical to advertize something agpl+cla as being open source.
Earlier quoted context omitted.
So, I don't think this is a generational thing. I think most people of all ages and generations have mostly just not thought about this. But the reason more people are thinking about it now is that the distribution model has changed on a way that has highlighted an existential weakness with this model.
I lack data, so I cannot say anything broadly. But in the devs that I know, this is 100% a generational thing. It may be different in different circles.