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

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!"

Marketing and PR humans were writing sentences like this one long before LLMs

Sure but this has the strong odor of LLM. Like, very strong.

LLM or not LLM, bullshit smells like bullshit

Somehow LLM bullshit is a step above normal bullshit because they've added an extra layer of bullshit to the bullshit.

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.

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!

It's damn slow and overkill for such task.

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?

YVW. I'll have a think about some other sources, especially plain speaking non-academic takes on the ethics that help developers see the issues. For now this one is a good general overview [0].

The big one with telemetry, is unintended side effects due to correlation and deanonymisation - which is actually dead hard to anticipate - very easy to get wrong like rolling your own cryptography :)

The other, around consent and defaults, is that even if your telemetry is perfectly anonymous, benign and beneficial to the end user, you may trigger a security alert and over-zealous investigation and reporting. This can have a massive impact on your reputation, as happened to Audacity. It's really not worth taking the risk.

Hope that helps.

[0] https://www.emerald.com/insight/content/doi/10.1108/S2398-60...

Digger collects Github user and repository names. No attempt is made to obfuscate the data, these are sent in the clear.

This level of incompetence borders on malice, regardless of intent.

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.