Managing Commercial Package Distribution: A Better Way

The summary: Cloudsmith provides a way for vendors to sell, license and distribute software as packages. To any customer, anywhere in the world, across a reliable and performant infrastructure, and handling all licensing and invoicing / billing challenges.

The Detail

As most of the readership of this blog will know, a huge proportion of the software developed around the world is dependent upon the third-party packages and libraries we integrate into our projects.

And whilst a lot of that will be open-source, a surprisingly large amount will be distributed on a commercial basis. Plenty of organizations generate revenue by selling packages and libraries, almost always on a business-to-business (B2B) basis, to clients looking to speed up their own development processes and deliver better software, faster.

Just by way of example, consider the following common use cases:

• The creator of fonts, icons or other similar libraries that may be integrated into web projects
• Creators and/or distributors of core network libraries
• Hardware companies needing to distribute drivers to customers

These organizations have a challenge. They need to sell and distribute the packages they create to customers all over the world, and they need to do so in a way that:

• Is convenient for their own customers
• Is easy and inexpensive to support for themselves, and
• Provides a reliable, performant service

The rest of this short piece will take a look at why that has been a challenge in the past, and how new approaches mean that distributing software packages on a commercial basis is now a piece of cake (clue: it involves Cloudsmith).

Commercial Package Distribution: A Short History Lesson

For the sake of everyone’s sanity let’s not talk about prehistory: when software was shared on floppy discs, compact discs and other physical media. Instead, let us save a little time and jump ahead to the digital days.

Until pretty recently the standard way to distribute any form of software, or resources that a software developer might use, has been to put it up on an FTP server and allow customers to download them from there.

There’s only three problems with that. Unfortunately, between them they make the whole process painful for all concerned:

• First, ‘dumb’ downloads are hard to integrate. Customers have to extract what they’ve bought and figure out how to get it into their own environment and tooling. That can require plenty of work, and things go wrong, which means calls to support and time and effort on all sides wasted.
• Second, it leaves licensing and access control entirely in the hands of the vendor, which is a challenge. It requires figuring out the easiest way to give customers access to the packages they are entitled to (and only those packages), and for the amount of time they are entitled to them.
• Last (and most certainly not least) it doesn’t support modern continuous integration and deployment processes that want to access up-to-date packages on demand rather than download once and use from an on-premises repository.

Another Approach: Package Repositories

Faced with these challenges, many B2B software vendors took a new approach: distribute software and libraries as ‘packages’ from package repositories.

The good news: this involves sharing content, libraries etc as software packages in the specific package format that allows for easy, effectively automated integration into the developer environment.

So for example, if I am a frontend developer working in Javascript, an npm package ‘speaks my language’, integrates directly into my environment and tooling.

Even better, I can connect to package repositories in this way and access them on demand. In other words, whenever a person or process needs them, they can connect and integrate - rather than downloading once and then being responsible for maintaining and updating hundreds or even thousands of packages, dependencies and libraries on-site.

The problem with this approach, however, was equally simple. It requires the vendor building and setting up a private repository and sharing access to that repository with clients all over the world.

Modern development processes demand high levels of availability and performance, so that isn’t a trivial undertaking. It leads to significant amounts of resources just being put into managing and maintaining that infrastructure, resources that were hired to build software.

Oh, and you still have to handle all the complexities around licensing and managing granular access to specific packages and assets.

The Solution (That Looks A Lot Like Cloudsmith)

There is another way: let someone else handle the distribution and licensing of commercial software packages and libraries.

What would that service look like? Well, it has to solve the problems we’ve outlined above, so a checklist would look something like this:

1. Take responsibility for availability and scalability, or in other words ensure that packages are there when clients need them, and that the service scales to meet new requirements automatically.
2. Deliver high performance - to customers anywhere on the planet. As many packages are integrated into build processes directly from the repository, it is absolutely essential that this happens fast. And in an age of distributed teams and processes, not fast in one place, but fast in any place.
3. Handle licensing and access controls. Whilst the repository is effectively private, the service will need to allow customers read-only access to the right packages and confirm license agreements without too much fuss.
4. Enable the vendor to share packages in multiple languages and formats as required by customers.

That, in four brief points, is what we have built at Cloudsmith to support vendors.

Cloudsmith is ultimately a platform supporting cloud-native, universal and secure public and private repositories. Of course we work with dozens of developer orgs who simply need a single source of truth for the software assets they use every day, and also need to share those assets across distributed teams.

But we also work with vendors sharing assets to clients outside their own organization.

For vendors, using Cloudsmith has a number of advantages, that largely correspond to the benefits of the approach already detailed above:

• We already have in place a fast, reliable, content delivery infrastructure that is used to meet any challenge (so far!), and trusted by thousands of businesses all over the world.
• We pay particularly close attention to performance. Again, as a tool used by distributed teams and processes: we have to. To that end we have production instances in multiple locations around the globe and support configurable edge caching to ensure that a cloud-native distribution network means zero compromise when compared with storing packages on-premises.
• We ensure that all needs around licensing and access control are met in an intuitive way for both customer and vendor. Cloudsmith supports entitlement tokens that deliver access to specific packages across specific time periods, for specific numbers of downloads or clients, all generated and shared automatically via the Cloudsmith API. And we give control over access to our clients. Their customers don’t have to become Cloudsmith customers just to access packages!
• Lastly, Cloudsmith is universal. It doesn’t matter what you need to distribute in what format, we can almost certainly handle it. So there’s never any need to maintain more than one distribution network.

That isn’t everything of course. We are always working to ensure that our service gets faster, smarter, and more fully-featured. To give a few recent examples:

• We provide comprehensive analytics that show who has downloaded what and when, and macro trends in terms of which packages are proving popular (or unpopular).
• We integrate with Zapier to support no-code integration with leading payment platforms, automating order processing of assets stored on Cloudsmith.
• We support custom domains. From your customer’s perspective, they are always dealing with your business, and connecting to a repository branded in your name.

If you’re a vendor struggling with some of the challenges discussed in this piece, we’d love to talk. We’re pretty sure we can help you!

Liked this article? Don\'t be selfish (:-), share with others:   Tweet