Improve overall explanation in README

Signed-off-by: Solomon Hykes <sh.github.6811@hykes.org>

README.md

@@ -1,67 +1,34 @@
-# Dagger: the devops superglu, by the creators of docker
+# Dagger
 
-Dagger is a scripting environment for automating the delivery of your application to the cloud,
+*WARNING: Dagger is alpha-quality software. It has many bugs, the user interface is minimal, and it may change in incompatible ways at any time. If you are still willing to try it, thank you! We appreciate your help and encourage you to ask questions and report issues.*
-from code to production.
 
-If you are familiar with PaaS services like Heroku, Firebase or Openshift:
+Dagger is a programmable PaaS (*platform-as-a-service*).
-Dagger makes it easy to create a custom PaaS that is perfectly tailored to each application,
-instead of forcing it into a rigid, homogeneous mold. The Dagger philosophy
-is that the platform should adapt to the application, not the other way around.
 
-This means that, unlike traditional PaaS, you can use Dagger with all your applications,
+Using Dagger, software teams can replace their artisanal deployment scripts with a state-of-the-art PaaS that is perfectly tailored to their application and infrastructure, in just a few lines of code.
-*without having to change your tooling, software stack or infrastructure*.
 
-TODO:
+- Do you spend too much time getting your home-made deployment scripts to work?
-*[... principles: productivity + compat]*
+- Do you wish you could just use a PaaS like Heroku or Firebase but can’t because your stack is too custom?
-*[.. do out-of-the-box things that would require months of work otherwise]*
+- Do you put off infrastructure and workflow improvements because changing your tooling is just too much work?
-*[.. alternative to the dilemna: paas or build your own?]*
+- Do you wish you could visualize your entire application delivery workflow as code, all in one place?
 
-## Warning: alpha software
+If you answered “yes” to any of the above, Dagger might be a good fit for you.
 
-Please note that Dagger is *alpha-quality software*. This means it has many bugs,
+## The problem with PaaS
-the user interface is minimal, and it may change in incompatible ways at any time.
 
-If you are still willing to try it, thank you! We appreciate your help.
+A PaaS, or platform-as-a-service, is the glue between an application and the cloud infrastructure running it. It automates the deployment process and provides a simplified view of the underlying infrastructure, which makes developers more productive.
-Please do not hesitate to ask questions, report bugs, or share feedback,
-either in a github or in the discord chatroom.
 
+However, despite the undeniable productivity benefits of using a PaaS, most applications today do not. Why? Because it's not flexible enough: each PaaS only supports certain types of application stacks and infrastructure. Applications that cannot adapt to the platform are simply not supported, and instead are deployed by a mosaic of specialized tools, usually glued together in an artisanal shell script or equivalent.
 
-## Platform as code
+But what if we didn’t have to choose between productivity and flexibility? What if we could have both? That’s where Dagger comes in. With Dagger, *each application defines its own PaaS*, perfectly tailored to its existing stack and infrastructure. The platform adapts to the application, instead of the other way around.
 
-The most important feature of Dagger is that it is *programmable*.
+And because it’s defined *as code*, this custom PaaS can easily be changed over time, as the application stack and infrastructure evolves.
-
-Thanks to its powerful scripting environment and growing catalog of reusable components,
-anyone with basic programming knowledge can assemble a custom platform for their application,
-and quickly start automating repetitive and complex tasks, so the entire team can spend
-less time getting deployment to work, and more time developing.
-
-Whether you're a seasoned SRE building a custom PAAS for your organization, a hobbyist on a fun
-over-engineered week-end project, or a developer trying to setup CICD because, well, someone has to do it..
-There's a whole community of fellow automation enthusiasts ready to help you write your first script.
-
-
-## Usage examples
-
-A few examples of how Dagger is used in the wild:
-
-- Use AWS Elastic Container Service to deploy the new API, while continuing to deploy the main app on Heroku.
-- Deploy lightweight staging environments on-demand for QA, integration testing or product demos.
-- Run integration tests on a live production-like deployment, automatically, for each pull request.
-- Deploy the same app on Netlify for testing, and on Kubernetes for production
-- Replace a 500-line deploy.sh with a 10-line configuration file
-- Control sprawl of serverless functions on AWS, Google Cloud, Cloudflare, Netlify etc. by gradually
-    moving them to a generic interface, and switching backend at will.
-- When the ML team uploads a new model to their S3 bucket, automatically incorporate it into staging
-    deployments, but not into production until manual confirmation!
-- Rotate database credentials, and automatically re-deploy all staging environments with the new credentials.
-- Allocate cool auto-generated URLs to development instances, and automatically configure your DNS,
-	load-balancer and SSL certificate manager to route traffic to them.
-- Orchestrate application deployment across 2 infrastructure siloes, one managed with CloudFormation, the other with Terraform.
-- Migrate from Helm to Kustomize, without disrupting next week's big release.
 
 
 ## Getting started
 
+
+### Installing the dagger command-line
+
 1. Build the `dagger` command-line tool. You will need [Go](https://golang.org) version 1.16 or later.
 
 ```
@@ -88,8 +55,7 @@ Here is an example command, using an example configuration:
 $ dagger compute ./examples/simple --input-string www.host=mysuperapp.com --input-dir www.source=.
 ```
 
-
+### Custom buildkit setup
-## Custom buildkit setup
 
 Dagger can be configured to use an existing buildkit daemon, running either locally or remotely. This can be done using two environment variables: `BUILDKIT_HOST` and `DOCKER_HOST`.
 
@@ -112,7 +78,7 @@ $ export BUILDKIT_HOST=docker-container://super-buildkit
 $ export DOCKER_HOST=tcp://my-remote-docker-host:2376
 ```
 
-## OpenTracing Support
+### OpenTracing Support
 
 Both Dagger and buildkit support opentracing. To capture traces to
 [Jaeger](https://github.com/jaegertracing/jaeger), ), set the `JAEGER_TRACE` environment variable to the collection address.
@@ -129,35 +95,15 @@ dagger compute ...
 
 You can then go to [http://localhost:16686/](http://localhost:16686/) in your browser to see the traces.
 
-## Comparison to other automation platforms
 
+## The Dagger programming model
 
-### CICD
+*FIXME*.
 
-Github, Gitlab, Jenkins, Spinnaker, Tekton
+## Dagger and your application
 
-### Build systems
+*FIXME*.
-
-Bazel, Nix, Skopeo
-
-### Infrastructure automation
-
-Terraform, Pulumi, Ansible
-
-### Traditional scripting
-
-Bash, Make, Python
-
-### PaaS
-
-Heroku, Elastic Beanstalk, Cloud Foundry, Openshift
-
-### Kubernetes management
-
-Kustomize, Helm, jsonnet
-
-### Gitops
-
-Flux, ...
 
+## Dagger and your infrastructure
 
+*FIXME*.