Hi @toddmorey - I am founder / CEO of Codenvy. Eclipse Che is our open source kernel and we had the opportunity to collaborate intimately with Red Hat's enginee

Hi @toddmorey - I am founder / CEO of Codenvy. Eclipse Che is our open source kernel and we had the opportunity to collaborate intimately with Red Hat's engineering teams in the design and development of OpenShift.io. Let me share some of the perspective that we have on what they are building. What happens if your app dev lifecycle tools (git, issue management, IDE, CI / pipeline) runs on the same platform that is running your production applications? From a market point of view, openshift.io is an approach to developing containerized applications in a way where the development team does not need to setup the infrastructure and tools required to create those workloads. Red Hat has: 1. Created their own agile issue management offering, competitive to Jira, GitHub issues, or Gitlab issues, based around the concept of a "work item". 2. A context-aware browser IDE based upon Eclipse Che, which "dev modes" a workspace based upon the containerized version of the application you are building. This injects things devs need for writing code including SSH, language intelligence like auto complete, debuggers. The workspaces are configured for the developer in-context based upon the work item that is under taken (ie, which branch, which repository, which languages, which files are referenced). 3. A continuous integration pipeline designed around building, testing, and deploying containerized servies built for the project using pipelines tailored for the team and for the individual. The pipeline capability is built from within, but takes advantage of a containerized Jenkins under the cover. 4. Deployment of the application to OpenShift. The application is packaged as a set of containers, which (OpenShift) is powering all the underlying services (Che workspaces, work items, pipelines, etc). The deployment automates complexity about how to set up a deployment profile, automatically adds canary deployment mechanisms (deploy for only the developer, for the team, or for production users (portion of users, etc)). Why not use canary deployment for managing the builds of commits for individual engineers along with your end users? 5. Analytics built in for doing intelligence of the code base that is being built to do analysis of the open source libraries included in the project you are creating to identify if any of those libraries are potential security issues, as identified through community flagging or a white / black list provided by an enterprise. 6. By building all of this on a common underlying infrastructure, there is additional context associations that are understood, so pipelines are connected to work items and the workspace, and vice versa. This alleviates certain overhead and setup requirements of developers long term. I am excited personally about this product because it solves the biggest pain that Codenvy sees with our paying customers. We have a number of F500 customers who pay and deploy a private Codenvy. But they are all becoming DevOps infrastructure wizards. It's hard for them having to figure out how to wire together Jenkins, Gitlab, Kubernetes, their IDE. They can do it, but they are seeking a DevOps in a box solution that makes that sort of setup effortless for the dev team, self-service (so that the DevOps team doesn't have to spend weeks getting it configured), and production grade (lets dev teams build enterprise applications that will be packaged as container workloads). So openshift.io is what happens when an organization tries to remove the effort out of DevOps, and they ultimately make optimizations and workflows based upon that point of view. I am also project leader for Eclipse Che, and we are making a commitment to migrating the management of our open source project (4K github stars and >100 contributors now from a diverse set of companies) onto openshift.io. It will be really interesting.