Photo by Ji Seongkwang

Like App Store, but open, cross-platform and decentralised
Imagining the future of software distribution
9 min. read

The “Great App Distribution Protocol” – or short: GADP – is an open, cross-platform and decentralised mechanism to distribute applications to users. That means, the publishing process of desktop apps or command line tools works in the same fashion for all operating systems, and there is no central or authoritative repository for hosting the executables.

Now, before you start to get excited, I need to tell you one thing: GADP does not exist. I wish it would, but at this point it’s nothing more than mere imagination. As far as I’m concerned, I’m pretty delighted with this idea – both from an app creator and user perspective – and would love for it to become reality. The main caveat, however, is an unfavourable effort-to-success prospect. But one can always dream, so let’s see.

In a world where GADP existed, you could learn about it by reading the following (fictional) interview.

The Great App Distribution Protocol

❡ Hey Diana, Yukio and Stanislaw! Could you maybe briefly introduce yourselves? What do you do, where are you from, and how do you use the “Great App Distribution Protocol” (GADP)?

Diana: Hello, I’m Diana. I work as SysOps engineer in a small software shop in lovely Great Falls, Montana (USA). At home, I run a small fleet of homelab servers in my spare time, and I created my own tool which helps to oversee and manage that infrastructure. My app is open-source, and I use GADP to share it with other homelab enthusiasts all around the world.

Yukio: My name is Yukio, and I’m a graphic designer, who also writes some frontend code here and there. I’m from Osaka originally, but my wife and I recently moved to Asahikawa, a smaller town in the very north of Japan. I’m using GADP to install applications on my computer, and to automatically keep them up-to-date as new versions are released.

Stanislaw: I’m Stanislaw, I work as backend software architect near Gdańsk, Poland, and I’m one of the maintainers of GADP. Our mission is to make software distribution easier, and for that I help to evolve the standard, spread the word, and provide support to the community.

❡ How would you describe GADP to someone who has never heard of it?

Stanislaw: The purpose of GADP is to facilitate the distribution of applications, i.e. the process of getting desktop apps or command line tools from their creators to their users. GADP itself is not a tool, it’s rather a standard. It allows distributors to publish information about their releases in a formally specified way. You can imagine that to be like a well-defined web API that clients can query, for example to find the right executable that matches their operating system and computer architecture, or to check for new versions.

Diana: For someone like me, who maintains and publishes an application, GADP is like a standardised way of saying: “Hello World, I made this thing. It’s ready to use and you can download it here. Please feel free to help yourself.”

Yukio: For me as a user, GADP allows me to tell my computer: “Hey, I want the thing from Diana. Please fetch it from her website, and take care of keeping it up to date.” The clients and servers then do the heavy lifting to make that happen in a smooth and secure way.

❡ Could you say that GADP is a like package manager?

Stanislaw: The idea is similar, but we find that it makes sense to distinguish system packages from standalone applications. They both serve slightly different purposes, and thus have other installation requirements. System packages are often low-level utilities, such as a drivers, services, or libraries. They might have dependencies to other packages, which need to be resolved dynamically. Or they require build procedures to be carried out upon installation. Or they need to hook into other system services. Therefore, it makes sense for package management to be platform-specific, because its job is ingrained deeply into the respective operating system.

In contrast to that, end-user applications usually come as pre-built executables without external dependencies, so they are easier to handle. It’s also common for them to be managed by “average” users who don’t have a deep technical understanding of the system. GADP specialises for this use-case and is therefore simpler and more approachable for both users and distributors. All in all, I would say that GADP doesn’t compete against package managers, it rather complements them.

❡ Before adopting GADP, what were your biggest pain points with previous solutions?

Diana: The release cycle for applications consists of three steps: (a) you build an executable from your source code, (b) you host it somewhere for downloading, and (c) you roll it out to your users. The first two steps are rather straightforward in my case: my app is written in Rust, so I can easily compile it for Linux, MacOS and Windows, and then upload the executables to my website. So much for that. The real trouble starts with the last part: how do I “push out” a new release to my users? There are mainly two options here:

I was pretty frustrated with that situation, because it seemed to me that distributing my app would be more work than actually creating it.

Yukio: As a user, I often wondered: how complicated can it be to just download or update an application? Considering how simple that task actually is, I’m astonished that the reality is so all over the place. There are: official package managers, proprietary app stores, third-party package managers, manual installation processes, custom update mechanisms – every application comes with its own set of solutions. For development tools, there is even a trend of distributing them via npm or pip. That just didn’t feel right to me.

❡ How does the distribution process work with GADP?

Diana: When I release a new version of my app, I carry out the same two initial steps that I described earlier, so I build the executables for all target platforms and upload them to my server. What’s new is that I also publish meta information about each release in a GADP-compliant format on my website. In GADP-terms, this makes me a so-called “distributor”. That way, users can use their GADP-client to download my app, install it on their computer and fetch new versions automatically. All in all, GADP has effectively cut off the entire complexity around the installation process by means of one lightweight manifest: build it, ship it, done.

By the way, instead of self-hosting my own distribution, I could just as well run it, say, directly off Github, or use one of the countless “distribution as a service” platforms, which handle the entire build and release process for you.

Stanislaw: What’s worth to note is that there is a diverse landscape of distributors. There are direct distributors like Diana, but distributions can also be run by third-parties. For example, there are community distributions, where a collective of motivated individuals provide a curated set of open-source applications that otherwise wouldn’t be available via GADP. Then there are commercial distributions, that users can sign up and pay for. These either offer their own proprietary software, or they mirror open-source applications and provide extra services around them, like performing independent security-audits of new releases, or forwarding the subscription fees as donations to the creators.

❡ How is the experience as a user?

Yukio: It’s terrific to have one uniform and streamlined way to manage all applications on my computer, regardless of whether they are native or terminal-based. By now, you find an “Install with GADP” button on many vendors’ websites, which makes the installation process quite convenient. This is even true for paid apps, of which I use several for work: since I obtain them all through the same distributor, I had to authenticate just once, and all my licenses were instantly activated.

I have to admit, though: when one of my colleagues first introduced me to GADP, it didn’t immediately appeal to me. This was because he used a terminal-based client on his computer, and I have to say that the command line sometimes feels a bit intimidating to me. But then I learned that you can actually use any client that fancies you, as long as it is compliant with GADP. I discovered a nice native one with a helpful and well-structured UI, which I feel very comfortable with. One nifty feature is that it stores all my configuration in a local file. So if I need to set up a new computer, it will only take me a few clicks to ramp up my entire tool chain.

❡ How is security taken care of in such a decentralised setup?

Stanislaw: Security is built into the GADP standard from the very start, and there are different layers to ensure the integrity and authenticity of the distributed executables. When designing the standard, it turned out to be pretty tricky to find a good balance between strictness and practicality. The protocol encourages a reasonable level of security, but it also gives distributors and users the option to deviate at their own risk. In the end, some degree of trust is inevitable, but I suppose that’s hardly novel – neither in software, nor in real-life.

Yukio: The client that I use comes with a sensible default configuration, which has proven to be viable for me. It sometimes prompts me to review potential issues, but that doesn’t happen too often, and so far I have always been able to swiftly resolve that. Depending on your personal level of paranoia, you would be able to adjust the security policies on a scale from “Fort Knox” to “Whatever”.

Diana: After I had started to distribute my app via GADP, some of my users approached me and asked whether I could provide cryptographic signatures for my releases. I was pleasantly surprised how simple that was to set up. My users are now able to automatically verify that the releases were issued by me and haven’t been tampered with, even if they obtain the executables from a third-party distribution.

❡ Thanks to the three of you for taking the time and letting us glimpse behind the curtain of GADP!