The status and future of open source resin.io
It's been a while since we promised to open source enough of resin.io so that, if you’re willing to do the work, you can run a fleet without our assistance or permission. A lot of progress has been made in this direction, and we have a clear plan on the way forward.
Open source status check
About two years ago, we promised that we’d release an open source version of resin.io that would allow users to manage fleets without using a hosted or on-premises offering. Let’s review the progress we’ve made since then:
- All software we install on devices is now open source, with the release of resinOS and the resin supervisor. This includes our support layers for over twenty device types, and much more, which you can find in the resin-os org on GitHub. In addition, this includes our popular resin-wifi-connect project that solves a big problem for people sending devices to remote locations.
- We also released resinOS as a standalone open source project for users wanting to run Docker containers on embedded devices but not commit to the managed resin.io platform.
- We have released as open source the hugely successful Etcher project, used by thousands of people every day, and recommended by the Raspberry Pi, Beaglebone, ODroid and Pine64 teams, amongst many others, as the best way to write SD cards for their communities.
- The resin-cli and resin SDK are both open source, allowing for a completely open source client experience.
- We have created, and released source for, thousands of docker base images for embedded devices. The source for these images can be found in the resin-io-library github org
- We have open sourced many of our internal tools like Versionist, Capitano, the Procbots framework, keyfctl, and more.
- We’ve created a culture of “open source by default” inside the team, leading to many many more repositories being released under our open source orgs, too many to list or describe here, but there for you to browse.
As such, the big remaining stumbling block has been the server side, our cluster of backend services. Here’s what we’ve accomplished with that, so far:
- The base image for all our internal services is now open source, and we’re working on the next level, our shared ssh authentication layer.
- The functionality of our build pipeline can be accomplished with open source code released on the resin-cli.
- The functionality of our image maker, which we use to generate resinOS images upon request from the dashboard, can be partially accomplished with open source code released on the resin-cli, along with additional advanced features that are only possible with the CLI.
First and foremost, the biggest thing holding back an open source resin.io is the open sourcing of our internal pine.js framework. Pine.js is our API framework on which all of resin.io is based, and how we are able to present such a powerful API to begin with. Pine.js actually goes back a lot longer than resin.io, all the way to 2004 when I sketched out the original architecture and then worked on it during my PhD years. Unfortunately, that codebase is large and broad, and due to its long history, presents complexities as to its auditing, etc. We’ve made a lot of progress in that regard, and we’re almost there. Expect some big news on that, any day now.
Secondly, we need to solve issues around the networking stack and the container registry. We want to make open source resin simple to set up, so we want to allow for the use of other existing components or services for networking and container registration.
Once these pieces are complete, we’ll be able to release the API server in a single-user configuration, which will pull everything together and allow anyone to set up an open source resin.io stack and manage their fleets.
Things will continue to be rough around the edges for a fair amount of time, of course, but as a community begins to form, we will be able to polish the project more and more, until it’s easy for all to use.
So when will resin.io be fully open sourced?
We expect the pine.js open sourcing to be completed early this summer. After that, the remaining services should have solutions in place by end of summer, leading to a projected date of release by the fall. Accounting for inevitable delays and blockers, the end of 2017 sounds like a reasonable prediction, as things currently stand.
What will open source resin.io look like?
First of all, we’ve centered on an experience that makes it easy to actually run an instance. This means focusing the resin.io server on the core resin.io service, which we call simply “the API” but should find a better name for by the time it's open sourced. The server will be available as a simple Docker container, needing a PostgreSQL database backend to run against, and a Dockerhub account in which to store containers.
After setting up and configuring the server, most of the interaction will happen via the resin.io CLI, which is already open source. The CLI can download and configure images, provision devices, build containers, and push them to the resin.io service. As such, all you’ll need to do is target it to your own instance of the resin.io service, rather than the one that’s managed by us. When you do that, you will be able to use the CLI to login with the admin account, create applications, add devices to them, push code, and in general perform all the core resin.io functions. The server will also have a full-powered API, and the resin.io SDKs will work against it just fine.
In terms of what will be missing: The open source resin.io server will be single-user, not come with a web dashboard, and will not have support for deltas or an internal VPN server. Leaving these features out means we can have an open source project that’s easy to set up and run without complicated configuration.
It's a similar model to that which Docker used for their open source Docker Registry, when compared to the cloud service it supports, known as Docker Hub. The two projects share a core, which is essentially the Docker Registry, with Docker Hub adding a UI, multi-tenant support, and some additional features. We find the balance the Docker team struck to be a good one, and have used it as a pattern that helped us decide how to go about creating an open source version of resin.io.
It’s extremely important to note that the open source version of resin.io will not be some fork that will be abandoned to its fate. The architecture we chose means that the same code that runs the resin.io service will be released as the open source resin.io project, and all improvements to that core will help both experiences. We will move development of these components completely to the open, and we hope the community will contribute back, making both the open source project and the hosted service better for it.
The open source resin.io server will finally make good on our promise to give you a version of resin.io you can use without our permission or assistance. We’re very excited to see where the community goes with it and what people are able to build with open source resin.io!