Item — HN Reader

I wonder if there's a name for this: that impatience and discomfort you feel about anything new until you understand what it is exactly and what to compare it to.

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.)

7 comments

You seem like one of those guys who simply can't appreciate a vertically integrated, synergistic solution that delivers on the promise of strategic technical innovation with seamless delivery.

This is my biggest gripe as well, and you're spot on. Vague promises of how the thing is going to "revolutionize the way I do things" just make me file it under "things to impress enterprise middle managers with", rather than something I can use to make my life easier.

It's a hard problem, especially for a product that has as much surface area as OpenShift.

- 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.

At Pivotal we call this idea the "Circle of Code"[0], which lends itself nicely to a diagram.

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.

[0] https://youtu.be/7APZD0me1nU?t=23m10s

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.

Whoever is in charge of openshift.io really ought to just delete their landing page and paste this post in its place. This is a thousand times more helpful than the meaningless buzzword soup that's there right now.

Thanks for the detailed writeup. I totally agree—there are corners of the product that seem pretty exciting, and I'm certainly a fan of redhat. I just think they could really help the effort by explaining the product better in their launch materials.

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.

I have bumped into all of the OpenShift.io managers and executives today at Red Hat Summit. They have all been discussing this very HN thread (they have all read it), and taking it to heart that they want to clean up the marketing items immediately.

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.

We will. (12 year Red Hat veteran speaking)

I have had a chance to write a proper blog post about my views on OpenShift.io and what it does, and how it makes use of Eclipse Che.

https://che.eclipse.org/openshift-io-and-eclipse-che-97a89e0...

This is really neat.

And the "Learn more" link for every single tile and bullet point on the home page. How can someone in their right mind think "Lets scatter the information on the home page into 20 links so the user can click on them one by one and handle the navigation themselves"

It's what happens when you write your content for search engines instead of humans.

> 2. Show photos, video, or screenshots.

You'll literally be able to demo it yourself for free, on demand, in production (IF YOU DARE!), within the next few days.

Well, that's still not the same. Pictures, videos, etc are supposed to give you an impression what the product is, how it tries to solve that problem, etc. Before you invest anything in it. Even the time investment of singing up, and playing around in the "member's area" can be a hassle if you could tell that this project is not for you from a simple screenshot.

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

Then they should have announced it when it was ready.

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.

You want everything explained, you want to use it for free and you don't want to participate. Everything that's wrong with the world ;-)

Don't be silly.

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.

There is video link in this blog post: https://developers.redhat.com/blog/2017/05/02/announcing-red...

Why would I be digging through Red Hat's blog to find this, and not find it on the site of the actual thing itself?

I was expecting to find a video in the link you pasted, almost missed it. Here's the actual link to the video https://vimeo.com/215402513/02867b4aea

That video adresses a bunch of the issues noted. It briefly shows provisioning, the editor, deployment, issue tracking in action, and the narrator overviews the vision & reasoning. It should be touted more prominently.

Then wait a few days and provide a video-backed live walkthrough.

The intro is intended as a teaser for the demo. If you don't show people what it is, they won't demo it.

A missed opportunity, but there is still time to recover.

Seems like people haven't used openshift. It is fun, it is easy, and it is free stuff. Pretty much a replacement of aws do azure gc etc. Atleast for poc and mvp. And if u r smart enough then u can process millions of request per second for free in ur choosen stack.