More feedback

.github/config/en-custom.txt

@@ -949,3 +949,12 @@ CRD
 composable
 gatewaydemo
 tlsdemo
+Appi
+ness
+DevOps
+DevSecOps
+learnings
+architected
+customizable
+Gitops
+OSS

docs/content/concepts/why-radius-concept/index.md

@@ -8,15 +8,15 @@ weight: 300
 
 ## Our starting point
 
-We started Radius to simplify and improve upon tools application developers use to deploy and manage applications. Our initial goal was just to create a platform for deployment that developers would love but, as we talked to more customers, we realized almost every enterprise is creating a custom internal developer platform to standardize and modernize the way developers think about their jobs.
+We started Radius to simplify and improve upon tools application developers use to deploy and manage applications. Our initial goal was just to create a platform for deployment that developers would love but, as we talked to more cloud customers, we realized almost every enterprise is creating a custom internal developer platform to standardize the way they deploy and manage cloud-native applications
 
-Most enterprises are not dev-tools experts and as a result they struggle with the cost and complexity of building a home-grown solution. If we could use open-source to solve the same problems enterprises were solving we could have a big impact.
+Most enterprises are not dev-tools experts and as a result they struggle with the cost and complexity of building a home-grown solution. If we could provide an open-source solution that solved these problems for enterprises we could have a big impact.
 
 A few common problems rose to the top:
 
 - Applications are more than just Kubernetes: applications developers are tasked with managing applications on Kubernetes and resources in the cloud where complexity is high, and compliance with best-practices is a full-time job.
-- Developers and platform engineers need to collaborate: to manage the complexity of the cloud, enterprises have specialized disciplines like sec-ops, fin-ops, and cloud centers of excellence. Application developers need to interface with all of these roles, and the tools they use should aid, not impede collaboration.
-- Applications need a industry-standard definition: the IT operators, SREs and other specialists that support an application usually lack context about the architecture. Application developers lack context about the underlying cloud infrastructure. As application developers and IT operators collaborate they need a common understanding and vizualization of what an application **is**.
+- Developers, platform engineers, and  IT operators need to collaborate: to manage the complexity of the cloud, enterprises have specialized disciplines like sec-ops, fin-ops, and cloud centers of excellence. Application developers need to interface with all of these roles, and the tools they use should aid, not impede collaboration.
+- Applications need a industry-standard definition: the IT operators, SREs and other specialists that support an application usually lack context about the architecture. Application developers lack context about the underlying cloud infrastructure. As application developers and IT operators collaborate they need a common understanding and visualization of what an application **is**.
 
 So, we started Radius to address these concerns and provide **our** opinions about how application management should work in today's complex cloud-native landscape. Along the way we came up with the concept of **Appi-ness**: the feeling of satisfaction one has when the application is at the center of every workflow.
 
@@ -28,9 +28,9 @@ Our philosophy is to be inclusive when considering what is *part of the applicat
 
 ## Developers and platform engineers need to collaborate
 
-Enterprises are creating specialized roles and initiatives to improve their speed, efficiency, and security when adopting the cloud. Platform engineering is an emerging discipline that's combining a product mindset with learnings from DevOps and DevSecOps teams to create internal development platforms. When successful, platform engineers deliver a set of tools that provide sufficient automation, tracking, governance, and observability that guide development teams naturally fall “into the pit of success.” Often these endeavors can come up a little short, looking like a set of repository templates, cloud resource templates, and a software catalog for application developers to use. Unfortunately, the tools and assets that are frequently used don't encourage collaboration between developers and the platform engineers supporting those developers.
+Enterprises are creating specialized roles and initiatives to improve their speed, efficiency, and security when adopting the cloud. Platform engineering is an emerging discipline that's combining a product mindset with learnings from DevOps and DevSecOps teams to create internal development platforms. When successful, platform engineers deliver a set of tools that provide sufficient automation, tracking, governance, and observability that guide development teams naturally fall “into the pit of success.” Often these endeavors can come up a little short, looking like a set of repository templates, cloud resource templates, and a software catalog for application developers to use. Unfortunately, the tools and assets that are frequently used don't encourage collaboration between developers and the platform engineers supporting those developers. Platform engineering is new as a discipline, and the patterns that will make enterprises successful long-term are still emerging.
 
-Radius provides concepts like Environments and Recipes that support a separation of concerns. Platform engineers can create repository templates with CI/CD pipelines and starter code for deployment. IT operators can deploy and govern the Environments where those pipelines deploy applications. Cloud experts can provide the Recipes used to create and update cloud resources. Developers are only responsible for describing the requirements and architecture of the application, understanding which environments to use, and choosing dependencies from the supported set of Recipes.
+Radius provides concepts like Environments and Recipes that support a separation of concerns. Platform engineers can create repository templates with CI/CD pipelines and starter code for deployment. IT operators can deploy and govern the Environments where those pipelines deploy applications. Cloud and security experts can provide the Recipes used to create and update cloud resources. Developers are only responsible for describing the requirements and architecture of the application, understanding which environments to use, and choosing dependencies from the supported set of Recipes.
 
 ## Applications need an industry-standard definition
 
@@ -49,6 +49,8 @@ Many practices and technologies in cloud-native development are a success and do
 - We like infrastructure-as-code as for its repeatability and use it for both Recipes and application descriptions. 
 - There are plenty of great CI/CD systems, application delivery pipelines, and Gitops systems out there and Radius can work with any of them.
 
-## Open Source
+## Open-source from the start
 
-@ryanwaite - what would you think about your section on OSS being included here instead?
+We planned for Radius to be open-source from the start because we want to reach as many developers, organizations, and ecosystem partners as we can. Open-source can mean different things to different people. For Radius, open-source means that our source code is publicly available under an OSI-approved permissive license. It also means that the Radius project uses an neutral and open governance model to continue the evolution of Radius as a multi-cloud technology going forward. Anyone should be able to contribute to Radius, extend the platform, self-host Radius for internal use, or use it to build a business hosting other people's applications.
+
+We know from our conversations with enterprises that customization, extensibility, and a large ecosystem are key. Every organization is unique and will make different policy, workflow, and technology choices. Every large organization has critical internal technologies. Extensibility is the way to put those internal technologies on even-footing with the cloud. A large ecosystem of partners and integrations enables everyone to keep using the technologies they are already committed to. By participating in open-source, users have a direct channel to propose changes, give feedback, add features, or customize the version of Radius they use. Our commitment to open-source and neutral, open governance means any technology vendor can join the ecosystem and benefit from the level playing-field that's being created.