- It is a PaaS, which would compete with Docker, EC2, and Heroku.
- It's development environment. Sublime?
- It's a collaboration tool. Github?
More to the point, it probably doesn't do any of those things in particular quite as well as those specific solutions do, but they're hoping you see the value in everything together. Would there be value in an IDE that had a deploy button that automatically marked a task as done?
I'm not sure that's exactly it, and I agree that this site isn't wonderfully done, but it's hard to get across "the thing" when there isn't a perfect comp to "the thing" already out there. Bad comparisons will pigeonhole your product forever.
We see similar value in it, but so far I've seen it explained more via products that play nicely together versus packaging a single platform.
I guess the question to ask is: if I take away this part of the circle, how much worse off am I? The anticipated pain gives some inkling of how important it is to provide it. Take any of Tracker, Cloud Foundry or Concourse away and it all becomes much harder.
Where I personally differ is that I like plain ol' IDEs and text editors. The web-based IDE thing keeps coming up. It may be that it's one of those ideas waiting for its time. Or may be one of those ideas that is a bad idea. I personally think the latter, but my predictions about technology are so frequently wrong that I should write for Wired. (Edit: it's also possible that I don't understand what Eclipse Che is)
Kudos to Red Hat for tying it all together. People forget how many smart PMs, designers and engineers love working there.
Disclosure: I work on Cloud Foundry on behalf of Pivotal. I'm just an engineer, I shouldn't be cited as authority about plans or whathaveyou.
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.
One quick question for them to address is if the entire stack (suite?) will be runnable on your own hardware or if it can only be consumed as a service.
As for your question - initially it will be released as a service. But it's Red Hat, and their customers are primarily on-premises with OpenShift sales, so the demand for on-premises deployment on your own hardware will be through the roof. So we'll see if RHT targets that demand.
https://che.eclipse.org/openshift-io-and-eclipse-che-97a89e0...
You'll literally be able to demo it yourself for free, on demand, in production (IF YOU DARE!), within the next few days.
Furthermore, I would probably have to read the manual, etc before I can do anything useful with it. A good screenshot or even video can really help you with that impression
There is now openshift.com (enterprise), openshift.org (OSS), and openshift.io (???) and none of these websites do a great job of explaining why you should be on that website and not the others.
If you want customers, you have to actually convince them to try your product.
The expectation of a customer that they might want to understand what the heck they're signing up for... before they sign up for it is hardly controversial.
I think this thread makes it abundantly clear that a days work creating some screen casts instead of fluffing out some marketing fairyfloss would have significantly improved the reception of this product.
It's just plain marketing fail.
A missed opportunity, but there is still time to recover.
Until that question is answered, you have ZERO patience for any marketing you read: especially fluffy visionary commentary about "digital transformation". You are quite literally making your readers angry because you are not answering their questions.
For anyone launching anything:
1. Make the first goal of your homepage just explaining what the thing is. Be clear. Be specific. People just want to know how to reason about it.
2. Show photos, video, or screenshots. (Even if you don't think it's amazingly sexy.) Seeing the product makes it so much more real.
3. Compare it liberally with what's out in the market now: this is your chance to show how it's similar and why it's different. Can be chart or table.
Then and only then, can you move on to how your product improves the lives of devs, chefs, athletes, etc. who uses it. (But you may not even need to.)