It is fairly easy to package / distribute portable code (e.g python, ruby, perl, js, etc). Stuff that requires compilation tends to be trickier, unfortunately (both to use and to distribute). Compiled software that is not relocatable (i.e hard codes paths) is sadly not possible to package in ZeroInstall.

It can use system packages (e.g apt, yum, etc) when available. So you can make a simple feed for your code that just depends on system versions of your dependencies, rather than having to "package the world". Of course, this only works on linux (and maybe OSX with fink / ports, but those tend to be less reliable than linux packages).

The big downside is of course that users don't generally know about ZeroInstall, and aren't likely to care why you think it's great. I generally recommend using ZeroInstall whenever I can in my own READMEs, but I have had little feedback on whether this has actually convinced anyone.

It has some definite upsides though, which is why I don't expect to stop using it myself regardless of general uptake:

- end users who aren't comfortable with terminals can use it just fine, yet it's as easy to publish as something like `pip` or `npm` packages.

- Since ZeroInstall feeds don't install anything globally, using zeroinstall dependencies during development means you never have to bother with tools like rvm, virtualenv, etc again.

- The savings that I personally get from having my own software & tools immediately available anywhere I go is already worth the effort of packaging it for ZeroInstall. E.g I have a "tim's custom vim" feed, with dependencies on all my vim plugins and configuration, and running it doesn't touch the host system's .vimrc or anything. That's pretty damn cool, even though it's only useful to me.

- I really like the notion that if you can _run_ some code, you can _modify_ that code. I despise the jump in most software between the "install & run" steps, and the "oh, you have to do these 10 manual and rather invasive steps to set up a development environment for this code". 0compile fixes this, for feeds that make use of it.

In general, though, if there's some package you want and you look for it there you're likely to be disappointed. 0install is probably more interesting to people wanting to publish software (and particularly, collections of related software).

Good use cases would be:

- Using it to build a package manager for a programming language (Rust would have been a good fit, I think, though like most languages they prefer to build their own language-specific system).

- Distributing applications for a desktop environment (the ROX desktop was the original motivation to create 0install).

- Managing plugins for a large application (Drupal, etc).

It might be best to think of it as a platform on which you can build a package manager or community.

Of course, people use it for individual applications too, but then you pay the cost of having to explain to your users what it is the first time. With a larger collection, the payoff is better.

And if you do need to work on it, you don't need to think about the rest of the program at the same time.

e.g. because you want to make it less hairy ;-)