I was proud to launch Equinox last week: a service that makes it easy to package and distribute production Go applications.
In some ways, I’ve finally come full circle. My first job in the tech industry was packaging software. The first company I worked for had offices in a converted warehouse - a squat, colorless building with offices ringing a great, empty space. Perched against the back wall was a lone workstation on a folding table with a mess of wires underneath. And that’s where I first began packaging software. I would sit at that desk and burn copies of our compiler, one-by-one at 8x speed on to blank CD-Rs.
Of course, packaged software needs good identifying metadata. So while each disc went through its 5 minute burn period, I printed CD labels - four at a time - onto special adhesive paper and then carefully applied the label to a disc with a smoothing motion to avoid air bubbles. This was also my earliest use of containers; I assembled pre-printed boxes, folding each of the four sides upright, slotting hooked corner tabs together to lock the cardboard into holding its form.
Boxes were packed with a pink flyer advertising upcoming product launches, a yellow flyer encouraging you to visit a website (or mail in the form on the back) to register your software, and the CD slipped into a simple paper and plastic case. End-to-end integrity of the transported bits was enforced by shrinkwrap.
Years later, everything is different and yet still the same. We still ship bits to customers, but it’s via fiber and cable and wireless in our homes and offices. Containers are digital things with their own subindustry and millions of VC dollars. Instead of shrinkwrap, we use cryptographic algorithms to sign and verify code. Maybe the biggest change though is how little most software shops even think about these concerns.
Developers don’t package their own software much anymore, even digitally. In the golden age of web services, we ship software by adding a new resource endpoint. The bits are packed once for our rigidly controlled datacenter environment. Even the web browser in 2016, for all its faults, is an impressively consistent application delivery platform that makes it easy to safely deliver the most up-to-date version of your app to customers. When we deploy to app stores, we run a vendor-provided tool that manages the entire process, wrapping up our bits appropriately for the walled gardens before shipping it off to an opaque vendor-specific cloud service.
Three years ago I launched ngrok.com - a tunneling reverse proxy service. As part of that,
I distribute a command-line tool available on all major platforms (and many minor ones, too).
It has given me the privilege to watch users fail to install software in every possible way. Your users
will download your software for the wrong operating system, for the wrong computer architecture and they
will install older versions from third-party distributors. They will double-click command line apps, paste
terminal commands into web browsers and try to run unzip on tar.gz archives. They do not know how to change their
PATH environment variable or what it even is. They will try to run your software on machines
built 20 years ago without the SSE2 instruction set.
Software packaging and installation is about first impressions. It is the first step of the conversion funnel after a customer agrees you have a solution to their problems. The UX of that installation experience is crucially important. Installation sets the tone and expectations of your user before they’ve even begun using your product. And if it fails, the rest of your product experience is moot because it will never run. A smooth installation experience establishes the initial trust of your user in the quality of your software.
For indie developers who aren’t shipping to the browser or an App Store, it is exceedingly difficult to build simple installation experiences. Instead of the tedium of assembling cardboard boxes, packaging modern software is a frustrating exercise in learning poorly-designed, vendor-specific toolchains, XML manifest files and installation behaviors. You must buy code-signing certificates with week-long turnarounds after apply for official business registrations. The tools for each platform often only run on that OS itself, adding additional burdens in resources and ops. Updating software to the latest version is part of this experience as well and requires an entirely new set of tools and knowledge of platform-specific behaviors and security mindfulness.
And that’s why we built Equinox: to solve these problems and make creating first-class installations experiences easier so that you can spend more time shipping your product and delighting your customers. For any Go program, Equinox automatically builds Windows .msi, OS X .pkg, Linux .deb and .rpm installers, .zip and .tgz archives in addition to publishing new releases to your own Homebrew tap. Equinox adds a small package to your app that enables self-updating functionality with just a few lines of code.
We’re starting with an admittedly small, but growing niche. Equinox only supports Go programs, but we’ve got bigger plans down the road to widen the scope of what we can distribute and how.
Ready to get started? Sign up at equinox.io or drop us a line at contact@equinox.