Change list title #42

New Issue

GiteaMirror · 2025-11-06T11:24:14-06:00

GiteaMirror commented

2025-11-06 11:24:14 -06:00

Originally created by @veggiemonk on GitHub (May 31, 2018).

Originally assigned to: @gesellix, @vegasbrianc, @moshloop, @agebhar1, @veggiemonk, @dmitrytokarev on GitHub.

Hi all,

Do you think we should adapt and make this repo a more OCI (https://www.opencontainers.org/) rather than just "Docker" ?

So the list would be "A curated list of open container resources and projects"

What do you think about that? What are the implication of this?

Originally created by @veggiemonk on GitHub (May 31, 2018). Originally assigned to: @gesellix, @vegasbrianc, @moshloop, @agebhar1, @veggiemonk, @dmitrytokarev on GitHub. Hi all, Do you think we should adapt and make this repo a more OCI (https://www.opencontainers.org/) rather than just "Docker" ? So the list would be "A curated list of open container resources and projects" What do you think about that? What are the implication of this?

GiteaMirror added the help wanted team discussion question labels 2025-11-06 11:24:14 -06:00

GiteaMirror closed this issue

2025-11-06 11:24:15 -06:00

GiteaMirror commented

2025-11-06 11:24:15 -06:00

@dmitrytokarev commented on GitHub (Jun 1, 2018):

Well then the repo will need to be renamed. IMHO it's better to create another list: awesome-containers?
Optionally can have some sort of sub-list dedicated to OCI.

@dmitrytokarev commented on GitHub (Jun 1, 2018): Well then the repo will need to be renamed. IMHO it's better to create another list: awesome-containers? Optionally can have some sort of sub-list dedicated to OCI.

GiteaMirror commented

2025-11-06 11:24:16 -06:00

@agebhar1 commented on GitHub (Jun 3, 2018):

I like the idea to be more open and not only focused on docker. @dmitrytokarev create another with the initial content of »awesome-docker«? There are already some »awesome-container« on GitHub. Pro for renaming this list is, it redirects everyone from an old bookmark to the new repository. There might be a short sentence of the history of this awesome list at the top.

@agebhar1 commented on GitHub (Jun 3, 2018): I like the idea to be more open and not only focused on docker. @dmitrytokarev create another with the initial content of »awesome-docker«? There are already some »awesome-container« on GitHub. Pro for renaming this list is, it redirects everyone from an old bookmark to the new repository. There might be a short sentence of the history of this awesome list at the top.

GiteaMirror commented

2025-11-06 11:24:17 -06:00

@veggiemonk commented on GitHub (Jun 3, 2018):

What do you think about this?

keeping the list as "awesome-docker" since it's popular and referenced to many places
we extend to content to more than just docker by adding new labels and categories (emojis?)
we clearly state when the content is docker specific and when it is not.

The awesome list called awesome-linux-containers doesn't have a lot of attention. And in the name there is "Linux" which would exclude many project running on windows.

If we want to create a new list, let's make it a organisation on its own.

There is a lot of options, let us know what you think. There is no right or wrong answer.

@veggiemonk commented on GitHub (Jun 3, 2018): What do you think about this? * keeping the list as "awesome-docker" since it's popular and referenced to many places * we extend to content to more than just docker by adding new labels and categories (emojis?) * we clearly state when the content is docker specific and when it is not. The awesome list called [awesome-linux-containers](https://github.com/Friz-zy/awesome-linux-containers) doesn't have a lot of attention. And in the name there is "Linux" which would exclude many project running on windows. If we want to create a new list, let's make it a organisation on its own. There is a lot of options, let us know what you think. There is no right or wrong answer.

GiteaMirror commented

2025-11-06 11:24:17 -06:00

@vegasbrianc commented on GitHub (Jun 4, 2018):

Hi all,

I have been thinking about this and I align with @veggiemonk The awesome-dockerlist is very popular and reference everywhere from official Docker documentation to Kubernetes projects.

My vote is to extend the current list with labels, categories, etc. Additionally, creating a new list parralel to awesome-dockerwould be great. We should make sure it is generic enough to cover all use cases in the future i.e. serverless, unikernel, etc that somehow fall under containers as well. Much like the CNCF projects we should set criteria/certain functionlity which admits projects to the repo or not like must utilize containers or something similar.

My braindump. I am open for suggestions.

@vegasbrianc commented on GitHub (Jun 4, 2018): Hi all, I have been thinking about this and I align with @veggiemonk The `awesome-docker`list is very popular and reference everywhere from official Docker documentation to Kubernetes projects. My vote is to extend the current list with labels, categories, etc. Additionally, creating a new list parralel to `awesome-docker`would be great. We should make sure it is generic enough to cover all use cases in the future i.e. serverless, unikernel, etc that somehow fall under containers as well. Much like the CNCF projects we should set criteria/certain functionlity which admits projects to the repo or not like must utilize containers or something similar. My braindump. I am open for suggestions.

GiteaMirror commented

2025-11-06 11:24:17 -06:00

@gesellix commented on GitHub (Jun 4, 2018):

Incoming braindump....

I would keep awesome-docker. That doesn't imply to keep the content here, though. We could split the list into bigger "sub-lists", if need be, and awesome-docker would only be an overview of those sub-lists or categories.
Maybe we could create a family of lists using a naming pattern, e.g. awesome-containers-<sublist>, where <sublist> can be empty, docker, orchestration.
Is Docker a sub-category of containers? We should always try to think like our consumers: are they searching for Docker or containers? I suppose that most people think and write Docker, but mean containers. If we assume that most people use Docker as synonym for containers then we shouldn't be too restrictive and also accept non-Docker links. Maybe it would be enough to label Docker-specific links with a whale and non-Docker links with a container?
Docker isn't container-only, but also provides other abstractions... thinking of Swarm (orchestration), LinuxKit (virtual machines), InfraKit (high-level orchestration?). Given a category orchestration we should either include Kubernetes or clearly state that we focus on Docker. Including Kubernetes would show our openness, but might also overwhelm ourselves with the sheer amount of tools and pace the community is evolving.

I guess the important (maybe the hardest) part is finding the right categories. How we're going to structure them depends on how much they overlap. I would still propose to keep the name awesome-docker, regardless of the actual contents or links to other awesome-<list>s.

@gesellix commented on GitHub (Jun 4, 2018): Incoming braindump.... - I would keep `awesome-docker`. That doesn't imply to keep the content here, though. We could split the list into bigger "sub-lists", if need be, and awesome-docker would only be an overview of those sub-lists or categories. - Maybe we could create a family of lists using a naming pattern, e.g. `awesome-containers-<sublist>`, where `<sublist>` can be _empty_, docker, orchestration. - Is Docker a sub-category of containers? We should always try to think like our consumers: are they searching for Docker or containers? I suppose that most people think and write Docker, but _mean_ containers. If we assume that most people use Docker as synonym for containers then we shouldn't be too restrictive and also accept non-Docker links. Maybe it would be enough to label Docker-specific links with a whale and non-Docker links with a container? - Docker isn't container-only, but also provides other abstractions... thinking of Swarm (_orchestration_), LinuxKit (_virtual machines_), InfraKit (_high-level orchestration?_). Given a category _orchestration_ we should either include Kubernetes or clearly state that we focus on Docker. Including Kubernetes would show our openness, but might also overwhelm ourselves with the sheer amount of tools and pace the community is evolving. I guess the important (maybe the hardest) part is finding the right categories. How we're going to structure them depends on how much they overlap. I would still propose to keep the name `awesome-docker`, regardless of the actual contents or links to other `awesome-<list>s`.

GiteaMirror commented

2025-11-06 11:24:17 -06:00

@moshloop commented on GitHub (Jun 5, 2018):

I would keep awesome-docker. I think that docker has evolved from a product to an API/ecosystem and we should include things like OCI, containerd and anything else that is docker compatible e.g. (vSphere integrated containers).

We can also include a short section of very popular related projects (LXD, LinuxKit, InfraKit, Kubernetes,Unikernels etc..) so that visitors who come looking for something else at least have a good navigation point.

Extending the scope to include orchestration I think would be too overwhelming - maybe we should just more prominently display the link to https://github.com/ramitsurana/awesome-kubernetes ?

@moshloop commented on GitHub (Jun 5, 2018): I would keep awesome-docker. I think that docker has evolved from a product to an API/ecosystem and we should include things like OCI, containerd and anything else that is docker compatible e.g. (vSphere integrated containers). We can also include a short section of very popular related projects (LXD, LinuxKit, InfraKit, Kubernetes,Unikernels etc..) so that visitors who come looking for something else at least have a good navigation point. Extending the scope to include orchestration I think would be too overwhelming - maybe we should just more prominently display the link to https://github.com/ramitsurana/awesome-kubernetes ?

GiteaMirror commented

2025-11-06 11:24:18 -06:00

@veggiemonk commented on GitHub (Jun 6, 2018):

So far the ideas are:

keep the name awesome-docker
extend the current list with labels, categories, etc.
create a new list
split into sub-lists
create a family of list e.g. awesome-containers-<sublist>, where <sublist> can be empty, docker, orchestration.
include a short section of very popular related projects (LXD, LinuxKit, InfraKit, Kubernetes, Unikernels etc..)

What are the concerns?

amount of work: we might overwhelm ourselves with the sheer amount of tools and pace the community is evolving
Overlap with awesome-kubernetes, and https://landscape.cncf.io/

@veggiemonk commented on GitHub (Jun 6, 2018): So far the ideas are: * keep the name `awesome-docker` * extend the current list with labels, categories, etc. * create a new list * split into sub-lists * create a family of list e.g. `awesome-containers-<sublist>`, where `<sublist>` can be empty, docker, orchestration. * include a short section of very popular related projects (LXD, LinuxKit, InfraKit, Kubernetes, Unikernels etc..) What are the concerns? * amount of work: we might overwhelm ourselves with the sheer amount of tools and pace the community is evolving * Overlap with awesome-kubernetes, and https://landscape.cncf.io/

GiteaMirror commented

2025-11-06 11:24:18 -06:00

@veggiemonk commented on GitHub (Jun 6, 2018):

Ok, I had a few ideas and this got out of hand quickly....

The fact that we have only one page makes it's easy to press CTRL/CMD + F to search for keywords. So splitting into many lists might be more a hassle just for the sake of having clearly defined category but that's just my personal opinion. I would like to have one list with filtering and sorting.
The way to display the content is important. One thing I really like about the CNCF landscape is the ability to apply many filter and sort order. This requires some data to be stored, this is why I started working on this a while ago: https://github.com/veggiemonk/awesome-docker/tree/master/data
The list is a README.md of a github repository, converting it into a website is kind of a big change. But that change can prevent us from being overwhelmed by the amount of projects that we need to evaluate if we have tools and the data.
I want to keep the commitment low. Like a side project, not a full time job. So we are talking automation. We can already gather some data from github. For the documentation, the installation instructions and a "try it yourself" example, we can create a form to store it. So when a PR is created, some fields of the PR are parsed. If the field are not filled, they will appear blank in the table. So we can quickly see what are the projects that are higher quality than others. Let me know what kind of data would you like to see in the table. Like how many starts since last month/week ? Number of open issue? number of PR? and so forth...
When the scope of a project is too big, it is time to scope it down and iterate over. Everybody seems to agree that we should include all OCI related projects. Instead of curating a list, we gather every projects and their metadata in order to categorize/list them in the best way possible. Then we curate predefined filters such as "docker-only", "windows-only", "osx-only", "for-developers", "for-sysadmin", "for-learning", "beginner-friendly" and so on...
Let's keep the Where to start section and stay beginner-friendly. Many projects are too complex to understand just by reading a description. Containers are completely new concept for a lot of people and we should aim at making their learning curve less steep.

Let me know your thoughts...

@veggiemonk commented on GitHub (Jun 6, 2018): Ok, I had a few ideas and this got out of hand quickly.... * The fact that we have only one page makes it's easy to press `CTRL/CMD + F` to search for keywords. So splitting into many lists might be more a hassle just for the sake of having clearly defined category but that's just my personal opinion. I would like to have one list with filtering and sorting. * The way to display the content is important. One thing I really like about the [CNCF landscape](https://landscape.cncf.io/) is the ability to apply many filter and sort order. This requires some data to be stored, this is why I started working on this a while ago: https://github.com/veggiemonk/awesome-docker/tree/master/data * The list is a `README.md` of a github repository, converting it into a website is kind of a big change. But that change can prevent us from being overwhelmed by the amount of projects that we need to evaluate if we have tools and the data. * I want to keep the commitment low. Like a side project, not a full time job. So we are talking automation. [We can already gather some data from github](https://github.com/veggiemonk/awesome-docker/blob/master/data/table.md). For the documentation, the installation instructions and a "try it yourself" example, we can create a form to store it. So when a PR is created, some fields of the PR are parsed. If the field are not filled, they will appear blank in the table. So we can quickly see what are the projects that are higher quality than others. Let me know what kind of data would you like to see in the table. Like how many starts since last month/week ? Number of open issue? number of PR? and so forth... * When the scope of a project is too big, it is time to scope it down and iterate over. Everybody seems to agree that we should include all OCI related projects. Instead of curating a list, we gather every projects and **their metadata** in order to categorize/list them in the best way possible. Then we curate predefined filters such as "docker-only", "windows-only", "osx-only", "for-developers", "for-sysadmin", "for-learning", "beginner-friendly" and so on... * Let's keep the `Where to start` section and stay beginner-friendly. Many projects are too complex to understand just by reading a description. Containers are completely new concept for a lot of people and we should aim at making their learning curve less steep. Let me know your thoughts...

GiteaMirror commented

2025-11-06 11:24:19 -06:00

@agebhar1 commented on GitHub (Jun 7, 2018):

@veggiemonk, will leave my feedback at weekend

@agebhar1 commented on GitHub (Jun 7, 2018): @veggiemonk, will leave my feedback at weekend

GiteaMirror commented

2025-11-06 11:24:19 -06:00

@veggiemonk commented on GitHub (Jun 9, 2018):

Made a little something to try things out (see #584)

@veggiemonk commented on GitHub (Jun 9, 2018): Made a little something to try things out (see #584)

GiteaMirror commented

2025-11-06 11:24:19 -06:00

@agebhar1 commented on GitHub (Jun 10, 2018):

@veggiemonk your PoC #584 is a very nice start to go further. The ability to filter the list by some keyword(s) is handy to find the needle in the haystack (if any). To generate the metadata one can utilize Travis CIs cronjob feature for one ore two builds each day or even each hour 😜 The number of open and closed issues and push requests might by interesting as a indicator of 'activity'. The number of forks might be interesting too. The card (a project) might be look like an entry of the periodic system with its key numbers ...

I agree on keeping the introduction aka »Where to start«.

IMHO if #584 is stable (some minor issues exists) it should be contained within the website. We can improve it step by step as we done some months ago by re-organizing the list.

@agebhar1 commented on GitHub (Jun 10, 2018): @veggiemonk your PoC #584 is a very nice start to go further. The ability to filter the list by some keyword(s) is handy to find the needle in the haystack (if any). To generate the metadata one can utilize Travis CIs cronjob feature for one ore two builds each day or even each hour :stuck_out_tongue_winking_eye: The number of open and closed issues and push requests might by interesting as a indicator of 'activity'. The number of forks might be interesting too. The card (a project) might be look like an entry of the periodic system with its key numbers ... I agree on keeping the introduction aka »Where to start«. IMHO if #584 is stable (some minor issues exists) it should be contained within the website. We can improve it step by step as we done some months ago by re-organizing the list.

GiteaMirror commented

2025-11-06 11:24:20 -06:00

@veggiemonk commented on GitHub (Jun 16, 2018):

Still fixing the #584 with the sorting...

I think having those data being fetch automatically once a day is good enough.

We still need to think of something to integrate the "where to start" section.

@veggiemonk commented on GitHub (Jun 16, 2018): Still fixing the #584 with the sorting... I think having those data being fetch automatically once a day is good enough. We still need to think of something to integrate the "where to start" section.

GiteaMirror commented

2025-11-06 11:24:20 -06:00

@veggiemonk commented on GitHub (Sep 13, 2018):

Gradually getting there.... it needs a few more features though before we can migrate

@veggiemonk commented on GitHub (Sep 13, 2018): Gradually getting there.... it needs a few more features though before we can migrate

GiteaMirror referenced this issue

2025-11-06 11:29:05 -06:00

[PR #42] [MERGED] Include the article: Dockerizing Flask With Compose and Machine - From Localhost to the Cloud #172

Sign in to join this conversation.