#So far I have:
stone widget
@frail marlin @weak gorge <@&946480760016207902> @limpid otter @torn spruce I updated my proposed README change (and also changed the homepage accordingly).
- No longer focusing on end-to-end tests at all. Instead just "software delivery" which I defined as "build, test and ship"
- 4 high-level "pillars": programmable, repeatable, local-first, observable. It's not perfect but captures a lot of everyone's favorite features.
- Enumerated a few features, we can keep iterating
- No more mention of "agent-first" at all
I appreciate everyone's suggestions on how to best market Dagger and help people "get it". Our README and home page don't need to be perfect in this regard. They just need to be directionally correct. I think this will do for now.
Next, I will turn my attention to our learning and onboarding flow - which needs some major changes to leverage the new features: toolchains, checks, and soon - cloud checks 🙂
frail marlin
Omg yes! This is perfect, I love it! I mostly skimmed it but I'll give it another read tomorrow. Nice work!
weak gorge
@stone widget - Thank you! I have some more suggestions, if you don't mind. 🙂
For the 4 points you set up, Programmable, Local-first, Repeatable and Observable, those points are spoken at someone who already knows and loves Dagger. To win the "meh" crowd, I feel these 4 points could be improved to be more emotional. Poke the target audiences' own "scars" if you will to build emotion and more importantly, speak in the "You form" in the sense of what Dagger can resolve for them. Unfortunately, words like "We believe" in marketing do two things: it sets up doubt and turns the prose to your opinion, and not the user's reality. It creates scepticism-by-default, which is basically a marketing foot gun.
Here is my attempt at somewhat better sections: 😊 (and yes, AI helped me, so it isn't all that much work - 15 minutes at best).
Programmable: End the DevOps vs. Devs Cold War
**Stop fighting over the pipeline. **DevOps teams are tired of fixing brittle YAML; developers are tired of waiting for "the experts" to unblock their builds. Dagger replaces "Human Glue" with a Functional Contract. By using real SDKs—Go, Python, TypeScript and more — DevOps truly defines the Interfaces and the process (the safety) and Developers write the Logic (the speed) in the languages they each love and yes, they can even be different. No more YAML tickets. No more friction, no more "Human Glue"—just a shared, type-safe and testable languages for shipping software.
Local-First: Kill the "It Works on My Machine" Lie.
Stop using your CI server as a debugger. It's slow, it's expensive, and it's a context-switching nightmare. With Dagger, your laptop is the production environment. If a build passes in your Local Environment, it passes in the cloud — guaranteed. Run your entire production-grade pipeline on your own machine and get green lights in seconds, not hours. No more "Push and Pray," no more "junk" troubleshooting commits. Just total parity from dev to deploy.
.
Repeatable: Total Certainty, Zero Flakiness
Eliminate the "Ghost in the Machine." Dagger orchestrates every tool in a Clean-room Container, ensuring that hidden host dependencies never leak into your build. Every operation is strictly typed and deterministic. With incremental-by-default execution and surgical cache control, you get the speed of a cached local build with the ironclad reliability of a fresh, automated install every single time.
Observable: Debug with a Map, Not a Wall of Text
See the signal, ignore the noise. Stop playing detective in a "Wall of Text." Dagger transforms raw, chaotic logs into a granular, interactive roadmap. With native OpenTelemetry traces and a real-time terminal UI, you don't just see that it failed—you see exactly where and why. Debugging is no longer a guessing game; it’s a surgical strike that gets you back to coding faster.
I hope this was ok. 🙂 😊
weak gorge
I somehow get the feeling my concept of interfacing with Dagger isn't understood (or is it?). As an example, this is our own cli's ci list command ran against a dagger module. App devs don't touch the Dagger cli at all. That is way too much "power" to give them. 🙂
Our ci list command is basically Dagger cli's own dagger functions command, but better. Better because, our cli explains what the dagger module fulfils in terms of the ci pipeline process and the tasks that are mandatory, which tasks are optional, which functions in the module that are ignored and which tasks are available, but unused by the module. This is of a visual explanation of what I meant by interfacing Dagger. We allow the devs to do anything within each task (their function) via the module, but their tasks must run within these functional hooks. I have to add too, our secret sauce is a ci_profile data store for each repository, which holds the needed config and is injected during task running or used to make decisions about how to run the pipeline.
This separation allows devs to concern themselves only with their "tasks" and let's devOps only worry about the process. To me, this is where Dagger blows away competition. 🙂 There is a little bit more to this than I'm showing, but I hope the idea of the devOps and dev "interface" and how we are solving it is now a bit more understandable.
weak gorge
This is the "split" I believe could benefit Dagger too, if it were to be part of Dagger.
Now also imagine we aren't speaking only about a CI pipeline, but Data & MLOps Pipelines, Infrastructure-as-Code Pipelines, Database Migration Pipelines, etc. etc. Basically anything that could use a Dagger function to do anything smartly in a containerized way.... but "interfaced". Wow! 🤩 Dagger just needs the interface framework to add to its tools.
I'll now stop. I am probably getting on nerves and of course, that isn't my intention. I'm just seeing huge potential and I'd love to see that potential realized for the greater community. 🙂
torn spruce
I like some things from the original text in the Why Dagger section and @weak gorge's wording. Scott I think really hits home at those annoying/painful situations that can draw somone in. Maybe combine the content from scott and what's there in the PR now?
frail marlin
I somehow get the feeling my concept of interfacing with Dagger isn't understood...
I think this is too opinionated for dagger to implement but it's a good example of a platform implementation using Dagger.
stone widget
Could be a guest blog post about your perspective as a power user. There are certain things that a user can say, that a vendor just can't.