Over the coming weeks we will announce the availability of Portainer Community Edition 2.0. We expect to ship code mid Q3, however it’s always dangerous to announce a date too early.
But before I talk about 2.0, I want to talk a bit about prioritization and decision making.
We have limited resources at Portainer, and a list of feature requests and opportunities as long as Route 66. We must make priority decisions every day, and inevitably, someone somewhere gets upset because we haven’t delivered to their expectations. We know this, and it’s something that we don’t like to see happening, but we must work within our means.
The way we make decisions on requested functionality additions / fixes to Portainer is as follows:
- is this addressing a security vulnerability or potential exploit? if so, add it;
- is this a feature that we feel would have wide appeal? if so, add it;
- is this a feature that has at least 20 “thumbs up” or “hearts” inside Github? if so, add it;
- is this a feature that would benefit professional users of Portainer? if so, add it.
When there are feature requests / issues that exist only with a specific use cases, judged either by us or through a lack of community “thumbs up” then these sit “pending” until enough demand is identified for them (so don’t forget to thumbs up issues you care about). Also, it’s important to note that we don’t automatically maintain feature parity with Docker, so when they bring out new features in Docker CE, we evaluate each based on the 4 criteria above before deciding whether to add it to Portainer. With our current resources, we only add support for features we feel have real demand.
So, what’s going to be in Portainer Community Edition 2.0…
Of all the platforms Portainer supports, Docker and Docker Swarm are our fundamental roots; we would not be where we are today without what we built for these two underlying technologies, and as such, we plan to keep support for them as long as it makes sense. Lately though we have seen several issues opened with us relating to Swarm and these users are either hitting undocumented limitations in Swarm (eg 128 max ports exposed via Ingress) or known issues in Swarm that have been open and unresolved for 2+ years. This concerns us, as we cannot work around these issues in Portainer, so these issues/limitations become our issues/limitations too. We will be guided by our community on what features we need to continue to bring to Swarm deployments; we have our view and have collated a list of feature requests that meet our 4 criteria, and these will be added in the next 1-2 releases.
The biggest feature we will be adding to Portainer 2.0 is support for Kubernetes. We sat on the Kubernetes feature request for a long time as we struggled to come up with a simple UI/UX for it, but after cracking that nut late last year, we have advanced our development significantly. We want to add Kubernetes “without compromise”, and by that, what we mean is that we want to offer as many of the features we offer today for swarm, tomorrow for Kubernetes.
We have a lot of work to do though, and this means that most of our developers are focused on this Kubernetes activity. That said, we have assigned developers to keep working through the backlog of Swarm / standalone issues, starting with the most “in demand” and working down from there. We are also continuing to add functionality to our “serverless” options (Azure ACI support), and plan to keep building out our edge compute management functionality too.
In the diagram below (click to enlarge), we have tried to depict where we are focusing our development efforts over the coming 6 months.