igorzij

also forgot to mention that 90% of the work (and time) is bouncing markdown files back and forth until the design is clear and I feel happy about it. design docs, working docs, etc. implementing then is where I can engage way less and switch to a different tab in cmux to drive it

im finding it way way more "flowy" than pre-ai. all the boring trivia is gone, i can focus on what i actually care about - the shape of what i am building, tradeoffs, second- and third-order consequences of decisions.

the trick to get it uninterrupted is "selective multitasking". i don't like having too many Claudes / Codexes in parallel on auto-pilot; this way im finding i'm getting _something_ that is perfectly plausible, but rarely what i wanted. but I have N going at any given time, just enough to be basically non-stop reading. problems need to be related; within one project, ideally adjacent areas that are complementary. then my "flow" is just switching between reading and typing non-stop. never felt time flying by faster in my life, pure flow

Hi HN - one of the founders of Digger here, the company behind Project OpenTaco.

Allow me to explain the initiative. Under per-run and resources-under-management pricing models many organizations have adopted workarounds and shortcuts that slow the growth of IaC adoption, and are incredibly frustrated by the arrangement. ([1], [2])

But wait - what about OpenTofu?

With OpenTofu, the community already has a credible open-source CLI alternative to BSL-licensed Terraform by Hashicorp. However that only solves half the problem: while the CLI helps teams avoid lock in to BSL licensed Terraform, it doesn’t address governance or collaboration challenges at scale any bigger than a single laptop. That's what TACOs are for; but so far, no open source project was able to challenge Terraform Cloud / Terraform Enterprise.

This is what led to the idea behind project opentaco. The project aims to add the missing enterprise workflows (currently proprietary and extractively priced) to Terraform and OpenTofu: secure remote runs, granular access controls, automated drift detection, enterprise SSO, and stack management, to be delivered as an open, self-hostable tool.

We feel this is Terraform’s “backstage” moment. Backstage did for Internal Developer Portals what we believe Project OpenTaco will do for IaC automation. Before Backstage, enterprises had scattered service catalogs and homegrown portals; Backstage created a standard, defined the category of IDPs, and won adoption at some of the world’s most recognizable companies [3]. We are building OpenTaco to follow the same path for Terraform and OpenTofu orchestration as the open standard.

We’re happy to launch v0.0 today (demo here [4], docs here (5)), you can try it starting today, we’d love any and all feedback!

[1] https://www.linkedin.com/feed/update/urn:li:activity:7376235... [2]:https://www.linkedin.com/posts/coquinn_am-i-getting-this-rig... [3]:https://github.com/backstage/backstage/blob/master/ADOPTERS.... [4]:https://www.loom.com/share/046b75fdc4e54cfa8d5089a1eb02f272 [5]:https://docs.digger.dev/ce/state-management/architecture

Yeah the ultimate impact of LLMs might be the end of SEO and copywriting. Rhetoric is cool again, as in skill to convey as much meaning as possible using as little words as possible. "Content" was always a bit of a silly term: the inherent value of it is always negative (proportionate to size), offset by the new knowledge conveyed in a piece. The attention economy is collapsing right in front of our eyes.

I feel betrayed after reading the first few sentences. No human ever would write like this:

"Qatar Airways has taken the future of in-flight connectivity to greater heights by operating the world’s first Starlink-equipped Boeing 777 aircraft..."

"Qatar Airways has just made aviation history by launching the world's first Starlink-equipped Boeing 777 flight. This groundbreaking development promises to revolutionize how we stay connected at 35,000 feet. Let's dive into what this means for travellers!"

Founding Sales

Also while not exactly about sales, "Softwar" (a bio of Larry Ellison) has a ton of great insights on enterprise sales

Why Claude 3.5 Sonnet is missing from the benchmark? Even if the real reason is different and completely legitimate, or perhaps purely random, it comes across as "claude does better than our new model so we omitted it because we wanted the tallest bars on the chart to be ours". And as soon as the reader thinks that, they may start to question everything else in your work, which is genuinely awesome!

Because that's what people go to HN for.

If I'm building something new, or launching a startup, there is not much benefit from encouragement. I don't want to hear "well done, this is so cool".

I want to know as many flaws that I might have overlooked as possible, as quickly as possible - so that in the (highly likely) event that my idea is fundamentally flawed, I can move on to smth else instead of keeping wasting time on it.

thanks!!

it's anything but trivial (otherwise we wouldn't ask); the case for not following certain feature requests goes roughly like this: are those potential users asking for a new feature _same people_ as your ICP or _different people_?

If the former, as in one can imagine an actual person using both features A and B, then obviously, you should ship what users are asking for. But if they are different people - meaning that no one person would use both A and B - then instead of making product better for your customer base, you'd be making the product available to more people. Which conventional startup wisdom advises against (YC, lenny, etc because one can ask - why are the remaining people who need A not using your product yet? It's either product not good enough (then you should improve the product for group A first), or the group A too small (then why do A at all and not focus on B?)

Now, with multiple CI backends is not clear-cut at all. We keep debating this internally but seeing both sides of it. On the one hand, it's highly unlikely that an organisation is using multiple CI tools simultaneously. But then how do we know that GitHub Actions is the one? We are self-hostable commercial oss and one of the selling points over Terraform Cloud is security. This seems to be naturally aligned with Gitlab as customers who'd use a self-hosted VCS are probably our perfect targets. And then the case against Bitbucket is that it's kind of fading away, there are still people using it but their share is definitely not growing, somewhat similar to say Travis or Circle.

So yeah, a lot of unknowns

Thanks! I'm glad we asked. Felt uneasy either way. Also would appreciate any pointers, perhaps someone you know has written on ethics of it?

Thanks! This is helpful. None of us at Digger have led or maintained significant OSS projects before - so discovering things as we go

This is super cool. Private runners are often so much cheaper, especially in large teams. Comes with a "fat tail" of reliability risk though: taking maintenance of runners means that that say 0.01% of builds would be failing for unknown reasons and it'd take significant effort to fix those. But then again that'd probably be only relevant in large organisations which likely have bigger bottlenecks in their devops practice than that; and if that's just about cost then a no-brainer.

Many are outlined in this great piece by Yi Lu (no affiliation, I just don't think I could put it as well as he did): https://itnext.io/pains-in-terraform-collaboration-249a56b45...

Because of that bucket of problems people end up using these tools to manage terraform runs (also known as TACOs). Terraform Cloud is one of them; there's also Spacelift, Atlantis and a bunch of others covering various aspects of what terraform the language doesn't handle natively (ci/cd, state, tfvars management, dependencies, etc).

At the core though, this seems to boil down to a multi-graph comprised of states with some extra stateful pieces on top, like TFVars, inputs/outputs etc. All that's needed is a reliable service that manages these stateful bits in a manner that supports security and compliance needs (secrets stored safely, audit trail, etc). Currently all that is either not there at all, or part of a large "package offering" like Terraform Cloud or Spacelift.

The case I'm making is that this "logical core" needs to exist in a way that's not coupled to a do-it-all cloud-based solution. It probably should not be part of the language itself; but also shouldn't be an all-or-nothing proposition. Hence the VM / runtime parallel

Another parallel to express a similar concept could be "instrumentation for terraform" - it'd be odd if all the observability tooling for a particular language (say Java) were coupled to a cloud-based offering by the company that created said language (Oracle) right? There's a bunch of stuff outside of Java that most Java applications need nevertheless - like application server (eg Tomcat) and so on. Okay that's not exactly instrumentation; but then logging tools, monitoring tools, etc.

A list of tools that make developer experience with cloud providers better

I took the definition from Lightspeed's OSS GTM workshop that was held in May this year. Upon further googling, it appears that a broadly accepted meaning of "fauxpen source" is indeed different. Thank you!

Digger here

The future of Terraform is open-source

We are beyond excited to be part of this great initiative. We did of course expect a fork to be of significant interest to people; what we did not expect is this crazy level of support for it. 2k+ stars, 100+ companies and 400+ individuals pledged, and there is already more full-time engineering positions committed to it by pledging companies than the whole Terraform Core team at Hashicorp (source: terraform commit history)

An earlier version of the manifesto contained pledged resources from each company (you can still find it in commit history). It totalled to ~10 full-time engineers just from founding orgs. It was removed to simplify adding their entries for new pledgees

Digger here

Our statement: https://medium.com/@DiggerHQ/diggers-statement-on-the-hashic...

if Hashi chooses to enforce it to such extent that even calling a terraform binary (which is open source itself for now) constitues "embedding"... then good luck Hashi staying an "open source company". The days of proprietary programming languages are long gone. They appear to be confusing the languages / frameworks space with self-hostables. BSL makes total sense for Mongo / Elastic (as well as Vault or Consul). Not so much for a CLI / compiler thingie which Terraform is.

thanks!!

We are in some sense a competitor too, alongside Spacelift, Env0, Scalr and a few others. Our product is built differently though, Digger is orchestrating terraform jobs in your existing CI instead of taking over the whole CI stack and effectively duplicating it just to run terraform. We built it this way almost by accident; our original product was very different (think "heroku-like UI for AWS" that generated and ran terraform on the server) and this is how we arrived at what Digger is now. Luckily we don't seem to be affected by the licensing change as we neither embed nor distribute any of hashicorp's code (it's on the user to set up the right version of it in say GH Actions).

https://github.com/diggerhq/digger

Anyways, fully agree that if you have a great product, you don't need to make such moves. We designed our product the way we did purely out of technical considerations - it didn't seem to make any sense to duplicate the CI stack. But it looks like this whole idea behind Terraform Cloud of having an "infra-specific CI" was driven exclusively by commercial interest. You can charge per minute! You can charge even more per resource! Now it's catching up with Hashi; so they have to make such defensive moves. If the product made sense technically, if it was designed the way someone would design it with no commercial considerations whatsoever, they wouldn't have to make such moves.

with Vault and Consul that makes a ton of sense; they're centralised backend services that are inherently SaaS-like. But expanding the "on top of terraform" definition to a CLI / language? That's insane. It's like making a programming language or framework proprietary and saying you can't sell anything written in the language without the language creator's permission. I guess such languages did exist in the early days of the industry but those days are long gone

that's the most puzzling bit. Do they not want to anyone offering anything that could compete with any of Hashi's products to be able to use terraform binary at all?

if so, that's similar to proprietary programming languages. Not a thing. The community can just agree on a similar but open alternative and the original company is left behind. That's why all languages and frameworks are open-source with permissive licenses.

and if not, if it's just about the hosted / managed parts - then what exactly is it that I can use wrongly? Terraform Cloud / Enterprise was never open source. There's nothing I can self-host and charge users for...

thanks! indeed, totally valid concern

oh wow didn't know thanks!!

Not necessarily; only if that CI/CD pipeline actually benefits from Hashicorp's code one way or another (embed, distribute, etc). I highly doubt that Hashi would consider Gitlab in breach of their license because they have support of Terraform state in their pipelines. Classic TACOS eg Scalr and similar might be in a somewhat bigger trouble as they have to have the terraform binary as part of their solution. But even then, they can remove all traces of terraform from their product and require the user to install a docker image with terraform version of user's choice.

they might well be! As well as all other TACO providers eg Spacelift, Scalr, Env0

Yes we are competing in the same market; customers using Spacelift probably wont be using Digger and vice versa. But we feel like having a community-friendly fork would benefit everyone, without harming anyone.

We are sort of competitors... kind of... but nevertheless feel free to switch to our MPL fork of Terraform :) https://github.com/diggerhq/open-terraform

Hashicorp switched Terraform from MPL to BSL yesterday. Many other companies did that in the past to prevent others taking their code and charging for running it as a managed service (eg Mongo, Elastic). With Hashi however, the server-side part was never open-source to start with. There was no such thing as "open-source Terraform Server". And now it seems that any commercial product that uses the Terraform language under the hood is at risk of violating the terms of the license. Funny enough, our own product (Digger, an open-source CI runner for Terraform) is not using Terraform (or any other Hashicorp's code) under the hood. So this change probably hits other TACOS (Spacelift, Env0) much harder than us. But with the recent pricing changes and now the license there is no guarantee that Hashicorp won't make another move in the future that would one way or another hurt us. So if there was an MPL fork, we'd rather swith to that, just to stay on the safe side. And since there isn't one yet, we thought why not make one?