Update entry page to better explain the benefits of podman

[ofalk]

Hi!

I've received the following comment on Twitter:

https://twitter.com/bobschi/status/1262740627160064000?s=20

While for the tech. ppl. the explanation on podman.io is eventually fine, for non-tech. ppl., this might not be that obvious. Could the start page be reworked so it clearly points out the benefits in contrast to ?

Thanks,
Oliver

[rhatdan]

PR's are helpful, we have a longer description on the documentation page.

[ofalk]

@rhatdan Yes, I know PRs are helpful. I'd love to, but I'm missing the time and I'm not really good at such "marketing activities". I can imagine there is more in the docs, what I'd love to see is something catchy on the front page that even (non-tech) C-level ppl will not only understand, but give them a reason to get back to their ppl and say: "Hey yah, why are we not using Podman instead of >xyz<."

Pretty sure you get my point Dan :-)

[TomSweeneyRedHat]

@ofalk thanks for the heads up. I'm pretty Twitter illiterate, do you know how that link was created and/or what twitter grabs? If you've suggestions that you could at least roughly sketch out, I'd be happy to put a PR together.

[ofalk]

Hey Tom!

Thanks for following up. So it started with Dan Walsh posting about podman being accepted to Debian unstable - which was great news. UnixCraft retweeted with the comment that podman is something developer/IT manager don't care about [ ... ]
I've pointed out that the main problem is that Docker became a de facto synonym for container [ ... ], followed by my comment that one can easily replace Docker with podman [ ...]
And now comes the point, the following comment was posted:
"""
It's a communication problem. The site does a p*** poor job explaining why I should use podman over docker, while docker's USP was pretty clear when it hit the market.
"""

So, I promised this guy that I'll reach out to the podman ppl to think about this - and that's why I've opened this issue now.

Let me know if you need to know anything else!
I can also forward you screenshots of the whole conversation, but I think the above summary should be fine.

Oliver

[TomSweeneyRedHat]

Thanks @ofalk ! And thanks for the follow up. I'd the wrong initial impression, I thought the issue was the way Podman was default displaying itself on Twitter when linking a blog or such to Twitter.

We've had a few other comments on the site not having enough information on the home page despite the "More details here" link. The thing is the site was originally developed as a spot to publish blogs on Podman. That mission hasn't changed, but I think the perception of many coming to the site is it's the spot to go to to get Podman information.

Maybe it's time to rethink that mission, @rhatdan, @fatherlinux WDYT? I'm thinking maybe putting the Intro to Podman page that @fatherlinux put together up on the home page on Podman.io and add a small "What's New" section on the home page.

[fatherlinux]

Yeah, the Introduction page on docs.podman.io does a good job of explaining why containers as a whole. The new landing page (docs.podman.io/) I think does a good job of explaining why Podman but I don't think we strongly contrast it with Docker. I think that's on purpose at this point.

While true, 99% will come from Docker to Podman, I'm not sure how strongly we want to make that comparison.

I think it could definitely make sense to port some of the landing page to the landing page on the project landing page. I guess the question is, do we want that in two places? Maybe we could come up with a small blurb on both?

[ofalk]

Just stumbled upon the following blog:

https://developers.redhat.com/blog/2019/02/21/jpodman-and-buildah-for-docker-users/

Maybe use the (current) momentum and re-use one of the headings from the above article:

Podman helps users move to Kubernetes

I think that's a catchy message and I, as a visitor of the website, would be eager to continue reading on that.

My 2 cents :-)

Oliver

[mbbroberg]

Hey, I'm one of those folks who enjoys technology and wordsmithing. I'm looking into an edit based on this discussion. The crux of it for me is "Manage containers with fewer moving parts," though the keyword of Kubernetes and catchiness of @ofalk's point is not missed. I'll think on it further.

While true, 99% will come from Docker to Podman, I'm not sure how strongly we want to make that comparison.

FWIW @fatherlinux, the 1% that isn't coming from Docker will certainly be comparing Podman to Docker because it's the de facto technology. I think it's not only fair but wise to anchor the discussion based on the larger context of the reader, which hinges on the question "Why not use Docker? Everyone else does."

[mbbroberg]

Adding a brief update: I'm midway through research that explores common themes for why people might care to use podman. That is both in the context where it's now the default choice (RHEL/CentOS/Fedora) and when transitioning from Docker. The higher level use cases are falling into these buckets:

• It's the default: when you run RHEL/etc, no need to install anything else
• Security: you don't want to run a daemon, you don't want to run containers with root privileges, you care about your audit log, you sweat the details (like namespace isolation by UID)
• Knowledge: you're learning the difference between 'containers' and 'Docker' or are primarily a Kubernetes user and want to use the same runtime (CRI-O)
• Features: pods work like they do in kubernetes, containers have systemd access without customization

And reasons not to use podman:

• Highly dependent on Windows environments without WSL2
• Regular user of Docker Compose

I'm drafting a PR that puts this together with links to articles across the ecosystem, but I welcome comments and preferred references, or early feedback.

[rhatdan]

Podman works fine on Windows and MACs, in remote mode, and we are working on improving its ease of use.
Docker Compose should be somewhat fixed with Podman APIv2 in 2.0.

[rhatdan]

I actually believe a huge benefit of Podman is you don't need to run a container to run a service. So setting up server to run one container, does not require you to run a service to run the container. Just run a single command and you are done.

The other cool thing is the integration with systemd, not so much of running systemd inside of containers, but being able to plug easily into systemd unit files. Look at podman generate systemd --new.

You can generate a simple systemd unit file and distribute it to all of your servers or cloud instances and maintain a containerized service everywhere.