I remember how excited I got when I first heard about Chocolatey. Did we finally get a package manager for Windows, one of the things I always envied about *nix and OS X(Homebrew)? I was really excited; I told my co-workers sitting around me about this amazing new tool that would finally make setting up new machines and installing applications as easy as a single command. To my surprise they didn't see how huge this was, but I didn't care. I knew how great this would be.

Two years later, I have completely given up.

Package maintenance

Probably the biggest issue with Chocolatey is its package maintenance workflow or lack thereof. The first person that submits a package for an application becomes its maintainer. If I go and create a package for an app that I use and submit it to the Chocolatey Gallery I would become the maintainer of the package regardless of my commitment to keep it up-to-date. I install my app using my newly uploaded package and forget about Chocolatey two weeks later. This happens more than you think. You can see evidence of it in the comment section in the gallery. Users asking the maintainer if the package will ever be updated followed by a reply from a member of the Chocolatey team informing them that most maintainers don’t check the comment section for their packages.

Now you have a package that hasn't been updated in months. You can go to the usergroup and ask Chocolatey admins to make you a maintainer of a specific package and if they do, you can go and update the package (if you can track down the source for its manifest otherwise you end up recreating the package from scratch). That works until the new maintainer disappears into the sunset and we are back to square one with an outdated package.

Security is a real issue

There is no formal review process for packages uploaded to the Chocolatey Gallery. Project lead himself admitted that currently they manualy review the packages AFTER they have been published. Given that everything is done in powershell someone could create a package that does real damage; Upload the fake package named as a popular unlisted application and you can cause some major hurt.

Chocolatey is not very good at being a framework

Frameworks exist to make common tasks easy. Chocolatey is not very good at being that framework. I've looked at the source of a few very popular Chocolatey packages and they are filled with boilerplate code that does the same things over and over. Things you would expect the framework to do. For example, things like checking Windows version requirements, checking registry keys or directories to see if an app is already installed or if it is already running and they all deal with each one of those situations diffidently. That’s both bad for the user and package maintainer. It’s bad for the user because they get unpredictable results with nonuniform error messages, or even false negatives (did the package maintainer implement the OS check correctly?). It’s bad for package maintainers because they have to do work that should have been done for them by the framework.

It’s open source, just fix it

Naturally my first reaction would be to fix the issues and do a pull request. But the biggest issue is package maintenance and that’s more of a process/policy/workflow issue. It is something that can’t be fixed in a pull request. It’s something that has been brought up multiple times in the usergroup and every-time dismissed by the founder.

“Some tools you don’t want the latest and greatest. Vagrant is a fantastic case of this. When a new version comes out, it’s not a tool you want to immediately upgrade as you need to wait for your plugins to get updated first.”

— Rob Reynolds

I don’t really think this is package manager’s place to tell me what version of software I would want and not even through a predefined delayed deployment process but as a side effect of poor packages maintenance.

“Is there value in having *a version* of a piece of software, even if it is not the latest and greatest? Aside from security fixes (you always want the latest security fixes), I think there is some value in getting software to your machine. I guess the point I’m trying to make is, what did you do before to make sure you were always on the latest and greatest of every tool/software on your box ALL THE TIME? Run a tool and then manually update all of them? Or use some sort of automation to do so? And two months after rebuilding your machine, were you always up to date on everything?”

— Rob Reynolds

“It’s not worse than before but it’s not that much better either” That’s not a very good value proposition for your solution.

Is there no hope for Windows?

I don’t know. But one thing I know for certain now, Chocolatey is not the answer. I’m still trying to figure out how we could fix all of these problems.

The package maintenance issues could easily be solved by following what Homebrew did. Just using github and pull request to the official package repository. That way anyone can submit a new or updated package using a simple pull request. It would be a known and simple workflow. That might even solve some of the framework and security problems too since it adds a level of curation to the process where the core team could provide feedback and suggestions on how to improve the package definitions.

Another idea is to create a packaging system that is 90% of the time driven by data and no code. Let the framework and the user decide how to act on that data. Why do I have to write a script to check the version of Windows if the manifest could provide the minimum system requirements and the framework could do the checks and the user could override it with a common flag.

I’m hoping to find some free time to actually play around with some of these ideas. I really think it’s time for us Windows users to have a proper package manager — something we can trust, something we've built and can improve together.