Friendly naming for our concepts #17

New Issue

2020-09-24T22:46:42Z

3wordchant commented

2020-09-24 22:46:42 +00:00

Currently:

CoöpCloud is a platform..
.. to get started, you create a host ("box"? "node"?), e.g. a new Hetzner VPS..
.. then, you probably add a local (Docker) context to point to the host..
.. check out a stack ("config"? "app"? "template"?), like wordpress or nextcloud, which is made up of multiple services..
.. and configure your app.

Prior art (using above naming):

Docker (Swarm)
- Host = "Node"
- Context = "Context"
- Stack = ?
- Service = "Service"
- App = "Stack"
Cloudron
- Host = ?
- Context = N/A
- Stack = "App"
- Service = N/A
- App = "App"
Kubernetes / Helm
- Host = "Node"
- Context = ?
- Stack = "Chart"
- Service = ?
- App = ?

Maybe there's a balance to be struck between metaphors people will already be familiar with (hello "app") and helping people learn the esoteric Docker CLI API ("stack").

Currently: - CoöpCloud is a **platform**.. - .. to get started, you create a **host** ("box"? "node"?), e.g. a new Hetzner VPS.. - .. then, you probably add a local (Docker) **context** to point to the host.. - .. check out a **stack** ("config"? "app"? "template"?), like `wordpress` or `nextcloud`, which is made up of multiple **services**.. - .. and configure your **app**. Prior art (using above naming): - Docker (Swarm) - Host = "Node" - Context = "Context" - Stack = ? - Service = "Service" - App = "Stack" - Cloudron - Host = ? - Context = N/A - Stack = "App" - Service = N/A - App = "App" - Kubernetes / Helm - Host = "Node" - Context = ? - Stack = "Chart" - Service = ? - App = ? Maybe there's a balance to be struck between metaphors people will already be familiar with (hello "app") and helping people learn the esoteric Docker CLI API ("stack").

decentral1se commented

2020-09-25 07:52:34 +00:00

Yes, excellent. Good to think about this. Here is a brain dump...

I think it is very important to keep in mind who is the public of this project. We seem to be fuzzily settled on "other people who do hosting" but then in some of our conversations we want Autonomic to be doing the hosting and then say, some CoTech member to be receiving services - therefore, they would be reading the documentation not as "a person who does hosting". We can orientate towards mulitple publics though, like YunoHost does in https://yunohost.org/#/docs "admin guide", "contributor guide". Maybe we want both?

CoöpCloud is a platform..
.. to get started, you create a host (“box”? “node”?), e.g. a new Hetzner VPS..
.. then, you probably add a local (Docker) context to point to the host..
.. check out a stack (“config”? “app”? “template”?), like wordpress or nextcloud, which is made up of multiple services..
.. and configure your app.

I do very much like this overall breakdown. This would be the "forest" view, I guess. Something like this in the eventually published documentation would be super useful IMHO.

CoöpCloud is a platform.

It's kinda like a social infrastructure or? We have some aspirations to have some governance, Autonomic provides some infrastructure to get the ball rolling, we have some design vision for the the thing. There isn't like, a central place to log in or anything.

"Platform" is such a muddled term at this point and can easily be mistaken for some sort of neo-feudal SaaS monopoloy driven social relation that I would be up for trying to dig into some new terms. Things like "Cypherspace" and "Sunrise Choir" (coming out of scuttleverse) are inspiring in this regard - trying to put some terms on this thing that is actually quite new!

Yes, excellent. Good to think about this. Here is a brain dump... I think it is very important to keep in mind who is the public of this project. We seem to be fuzzily settled on "other people who do hosting" but then in some of our conversations we want Autonomic to be doing the hosting and then say, some CoTech member to be receiving services - therefore, they would be reading the documentation not as "a person who does hosting". We can orientate towards mulitple publics though, like YunoHost does in https://yunohost.org/#/docs "admin guide", "contributor guide". Maybe we want both? > CoöpCloud is a platform.. > .. to get started, you create a host (“box”? “node”?), e.g. a new Hetzner VPS.. > .. then, you probably add a local (Docker) context to point to the host.. > .. check out a stack (“config”? “app”? “template”?), like wordpress or nextcloud, which is made up of multiple services.. > .. and configure your app. I do very much like this overall breakdown. This would be the "forest" view, I guess. Something like this in the eventually published documentation would be super useful IMHO. > CoöpCloud is a platform. It's kinda like a social infrastructure or? We have some aspirations to have some governance, Autonomic provides some infrastructure to get the ball rolling, we have some design vision for the the thing. There isn't like, a central place to log in or anything. "Platform" is such a muddled term at this point and can easily be mistaken for some sort of neo-feudal SaaS monopoloy driven social relation that I would be up for trying to dig into some new terms. Things like "Cypherspace" and "Sunrise Choir" (coming out of scuttleverse) are inspiring in this regard - trying to put some terms on this thing that is actually quite new!

❤️ 1

3wordchant commented

2020-09-25 11:00:55 +00:00

“Platform” is such a muddled term at this point and can easily be mistaken for some sort of neo-feudal SaaS monopoloy driven social relation that I would be up for trying to dig into some new terms.

Lol indeed, I am wide open to replacement names for any of this ("platform" is my least favourite of the current lingo, "stack" a close second).

I think it is very important to keep in mind who is the public of this project .. We can orientate towards mulitple publics though, like YunoHost does in https://yunohost.org/#/docs “admin guide”, “contributor guide”. Maybe we want both?

Definitely! I think in my mind our first target people are user-collaborators, i.e. other outfits roughly our size who would like to use CoöpCloud themselves to host, and might help us with app packaging or maintenance.

I think "not persons who do hosting" are going to be much easier to reach if and when we have some kind of UI for app management, and in the mean-time we can maybe direct them to autonomic.zone and expand the list of "cloud" services we offer there? Anyway also open to a separate ticket or pad for the "target audience" question, it's a good'un.

> “Platform” is such a muddled term at this point and can easily be mistaken for some sort of neo-feudal SaaS monopoloy driven social relation that I would be up for trying to dig into some new terms. Lol indeed, I am wide open to replacement names for any of this ("platform" is my least favourite of the current lingo, "stack" a close second). > I think it is very important to keep in mind who is the public of this project .. We can orientate towards mulitple publics though, like YunoHost does in https://yunohost.org/#/docs “admin guide”, “contributor guide”. Maybe we want both? Definitely! I think in my mind our first target people are user-collaborators, i.e. other outfits roughly our size who would like to use CoöpCloud themselves to host, and might help us with app packaging or maintenance. I think "not persons who do hosting" are going to be much easier to reach if and when we have some kind of UI for app management, and in the mean-time we can maybe direct them to autonomic.zone and expand the list of "cloud" services we offer there? Anyway also open to a separate ticket or pad for the "target audience" question, it's a good'un.

3wordchant added this to the (deleted) milestone 2020-10-01 10:54:05 +00:00

decentral1se commented

2020-10-22 19:39:32 +00:00

Thinking about this again...

I'd like to suggest that we merge the idea of the "host" and the "context" together. I think reducing the number of high-level concepts is a good thing for the first take on understanding what this is. Later, you get the difference. So, I would propose then that we use "server"? I think nearly most people would recognise that for what it means. Sooo, the CLI thing would be abra server ls abra server use abra server add etc. instead of abra context. Whatcha think?

Then I think stack should just become app. Everyone gets that one too.

Then we'd just have to deal with 2 things: "servers" and "apps". This would even the playing field in terms of language for technical and non-technical people. "How it works" is then a question of knowing about Docker contexts, swarm, stacks and the rest.

I am bringing this up because I somehow feel like naming is important and I shouldn't follow my own advice to avoid it :)

Thinking about this again... I'd like to suggest that we merge the idea of the "host" and the "context" together. I think reducing the number of high-level concepts is a good thing for the first take on understanding what this is. Later, you get the difference. So, I would propose then that we use "server"? I think nearly most people would recognise that for what it means. Sooo, the CLI thing would be `abra server ls` `abra server use` `abra server add` etc. instead of `abra context`. Whatcha think? Then I think stack should just become app. Everyone gets that one too. Then we'd just have to deal with 2 things: "servers" and "apps". This would even the playing field in terms of language for technical and non-technical people. "How it works" is then a question of knowing about Docker contexts, swarm, stacks and the rest. I am bringing this up because I somehow feel like naming is important and I shouldn't follow my own advice to avoid it :)

3wordchant commented

2020-10-22 22:46:33 +00:00

I’d like to suggest that we merge the idea of the “host” and the “context” together.. So, I would propose then that we use “server”? .. abra server ls abra server use abra server add etc. instead of abra context. Whatcha think?

Yep seems ideal 👍 👍 👍

Then I think stack should just become app. Everyone gets that one too.

I like this too.

My heart still longs for some way of separating "app definition" from "app instance" but overloading "app" for both doesn't seem like a bad compromise for the moment.

> I’d like to suggest that we merge the idea of the “host” and the “context” together.. So, I would propose then that we use “server”? .. `abra server ls abra server use abra server add` etc. instead of `abra context`. Whatcha think? Yep seems ideal 👍 👍 👍 > Then I think stack should just become app. Everyone gets that one too. I like this too. My heart still longs for some way of separating "app definition" from "app instance" but overloading "app" for both doesn't seem like a bad compromise for the moment.

decentral1se commented

2020-10-23 11:02:15 +00:00

Ok, nice! I will leave this open so that I document this on the new docs.

decentral1se added the documentation label 2020-10-27 07:58:23 +00:00

3wordchant referenced this issue from a commit

2020-12-23 22:32:00 +00:00

Add definitions to the front page.

3wordchant closed this issue

2020-12-23 22:32:00 +00:00

knoflook referenced this issue

2021-11-25 12:43:12 +00:00

rename app to stack? or make the relationship between abra and docker words clear #269