Microsoft released WinGet (Not to be mistaken with AppGet) earlier this week as part of their Build 2020 announcements. For the past few days, I’ve been collecting my thoughts figuring out what actually happened in the past 12 months.

TLDR; I’m no longer going to be developing AppGet. The client and backend services will go into maintenance mode immediately until August 1st, 2020, at which point they’ll be shut down permanently.

If you are still interested, here is how AppGet died.

A year ago (July 3rd, 2019) I got this email from Andrew, a high-level manager at Microsoft,

Keivan,

I run the Windows App Model engineering team and in particular the app deployment team. Just wanted to drop you a quick note to thank you for building appget — it’s a great addition to the Windows ecosystem and makes Windows developers life so much easier. We will likely be up in Vancouver in the coming weeks for meetings with other companies but if you had time we’d love to meet up with you and your team to get feedback on how we can make your life easier building appget.

Naturally, I was excited; my hobby project being noticed by Microsoft was a big deal. I replied, and two months and a few emails later, we finally had a meeting planned on August 20th at Microsoft Vancouver. The meeting was between me, Andrew and another engineering manager in the same product group. I had a great time; we talked about the ideas behind AppGet, what I thought was broken about the current package manager systems in Windows and what I had planned for AppGet’s future. We went out for lunch and talked a bit more about AppGet, Windows Phone, and a few other things, but the outcome of the meeting as far as I understood it was, what can Microsoft do to help? I mentioned some Azure credit would be nice, getting some doc on how the new MSIX packages work and if they could fix a few issues I had with some of their download links.

Fast forward to next week (August 28th), and I got this email from Andrew,

Keivan,

it was a pleasure to meet you and to find out more about appget. I’m following up on the azure startup pricing for you. As you know we are big fans of package managers on Windows and we are looking to do more in that space. My team is growing and part of that is to build a team who is responsible for ensuring package managers and software distribution on Windows makes a big step forward. We are looking to make some significant changes to the way that we enable software distribution on Windows and there’s a great opportunity (well I would say that wouldn’t I?) to help define the future of Windows and app distribution throughout Azure/Microsoft 365.

With that in mind have you considered spending more time dedicated to appget and potentially at Microsoft?

Initially, I was a bit hesitant; I didn’t want to go to Microsoft to work on Windows Store, MSI engine or some other app deployment-related stuff. Shortly after, I was assured that I would spend all my time on AppGet. After about a month of prolonged email back and forth, we came to the conclusion that the arrangement will be very similar to an acqui-hire; Microsoft would hire me, AppGet would come with me, and they would decide if they wanted to rename it something else, or it would become Microsoft AppGet.

Throughout the whole process, I was very unclear on what my role would be at Microsoft. What would my responsibilities be? Who would I report to? Who/anyone would report to me? I tried clearing some of these answers throughout those slow conversations but never got a clear answer.

After another few months of again very slow email conversations, I was told that the acqui-hire process through BizDev would take a very long time. An alternative to speed up the process would be just to hire me with a “bonus” and then work on migrating the code ownership after the fact. I didn’t have any objections, so we scheduled some meetings/interviews in Redmond.

I flew to Seattle on December 5th to have a full day of interviews/meetings at Microsoft HQ. I met with four different people; three of the meetings were more like your typical interviews; the meeting with Andrew was more about what we should do once this is all over and how we would migrate AppGet’s process and infrastructure to be able to handle Microsoft’s scale. We talked about some of our options, but in general, I thought everything went well.

My last meeting ended at around 6 pm. I took an Uber to the airport and was back in Vancouver.

And then, I didn’t hear anything back from anyone at Microsoft for six months.

Until earlier this week when I was given heads up about WinGet’s launch the next day,

Hi Keivan, I hope you and your family are doing well — BC seems to have a good handle on covid compared to the us.

I’m sorry that the pm position didn’t work out. I wanted to take the time to tell you how much we appreciated your input and insights. We have been building the windows package manager and the first preview will go live tomorrow at build. We give appget a call out in our blog post too since we believe there will be space for different package managers on windows. You will see our package manager is based on GitHub too but obviously with our own implementation etc. our package manager will be open source too so obviously we would welcome any contribution from you.

I look forward to talking to you about our package manager once we go live tomorrow. Obviously this is confidential until tomorrow morning so please keep this to yourself. You and chocolatey are the only folks we have told about this in advance.

Regards
Andrew

I wasn’t too surprised; I had figured out months ago that the “Microsoft thing” isn’t happening.

I waited until the next day to see what this new package manager was going to be like. When I finally saw the announcement and the GitHub repositories, I was shocked? Upset? I wasn’t even sure what I was looking at.

When I showed it to my friend, the first thing he said was, “They Called it WinGet? are you serious!?” I didn’t even have to explain to him how the core mechanics, terminology, the manifest format and structure, even the package repository’s folder structure, are very inspired by AppGet.

Am I upset they didn’t hire me? Not really, after visiting the campus, I wasn’t too sure I wanted to work for such a big company, also moving from Canada to the U.S. wasn’t something I was too excited about. Also, throughout the process, at no time I assumed this was done deal.

Am I upset that Microsoft, a 1.4 trillion-dollar company, finally got their act together and released a decent package manager for their flagship product? No, they should’ve done it years ago. They shouldn’t have screwed Windows Store as badly as they did.

Realistically, no matter how hard I tried to promote AppGet, it would never grow at the rate a Microsoft solution would. I didn’t create AppGet to get rich or to become famous or get hired by Microsoft. I created AppGet because I thought us Windows users deserved a decent app management experience too.

What bothers me is how the whole thing was handled. The slow and dreadful communication speed. The total radio silence at the end. But the part that hurts the most was the announcement. AppGet, which is objectively where most ideas for WinGet came from, was only mentioned as another package manager that just happened to exist; While other package managers that WinGet shares very little with were mentioned and explained much more deliberately.

There is a silver lining. WinGet will be built on a solid foundation and has the potential to succeed. And we neglected Windows users might finally have a decent package manager. —

Live and learn.

Edit to clarify some issues,

May 27th, 2020 19:04 PST

But AppGet is Open Source

Code being copied isn't an issue. I knew full well what it meant to release something opensource and I don't regret it one bit. What was copied with no credit is the foundation of the project. How it actually works. If I were the patenting type, this would be the thing you would patent. ps. I don't regret not patenting anything.

And I don't mean the general concept of package/app managers, they have been done a hundred times. If you look at similar projects across OSes, Homebrew, Chocolaty, Scoop, ninite etc; you'll see they all do it in their own way. However, WinGet works pretty much identical to the way AppGet works.

Do you want to know how Microsoft WinGet works? go read the article I wrote 2 years ago about how AppGet works.

I'm not even upset they copied me. To me, that's a validation of how sound my idea was. What upsets me is how no credit was given.

You should've followed up.

I did, There was an issue with my travel reimbursement, So I contacted the HR contact and at the same time asked about the Interviews, She told me someone will get back to me about that and they never did. This was on Feb 14th, 2020.

Four years ago I wrote an article on why Chocolatey is broken, and not in a way that could be fixed with a pull-request.

Shortly after that I started working on what I thought would be a good version of what Chocolatey was supposed to be, a proper package manager for Windows applications.

By the time I got the basics working Chocolatey launched their Kickstarter and raised $52,000. I figured well; Now that Chocolatey is no longer a hobby surely they will fix things enough that there won’t be room to compete. On top of that, add a bunch of personal “things”, a couple of job changes and the GitHub repository ended up collecting dust for about four years.

I would think of AppGet every once in a while in a what it could’ve been sort of way. One night in the middle of February 2018 I was having dinner with an old co-worker and AppGet came up again, just talking about it got me fired-up, being fair the whiskeys I’ve been drinking all night might’ve had something to do with it. So the next day, I took out the dusty GitHub repository from the metaphorical back of the drawer and,

Better late than never, I guess

I really wish I had kept going four years ago (as a bonus you would’ve been spared reading my ramblings about why it took four years), but anyways, here it is,

AppGet is my first prototype of what a proper package manager for Windows should look like. Keep in mind this is a pretty early stage, and I am VERY open to suggestions on how to make AppGet better.

Data over Scripts

AppGet uses YAML files instead of scripts; we call them manifests. Using data over scripts just seemed like a much better choice. Here are some of my reasoning,

Given data AppGet can provide a standard and predictable behavior across different packages and systems. This allows it to be an effective framework for both users and package authors. The example I brought up in my original article was checking for system requirements. AppGet has built-in support for multiple installers per package; this means each package can have different installers targeting different versions of Windows or CPU architecture.

- location: http://7-Zip.or/9.20/7z920.msi
- location: http://7-Zip/9.20/7z920-x64.msi  
  architecture: x64

-Two different installers used for different CPU architectures

This allows AppGet to do all the heavy lifting around figuring out which installers are compatible with the target system and picking the best one without requiring complicated package scripts.

It also allows us to give the user the option of overriding these constraints if they chose to use a common flag. (I haven't actually implemented this feature, but it’s trivial given our architecture)

C:\> appget install seven-zip -x86

AppGet might have support for scripted packages in the future, however, for now, the plan is focusing efforts on data-driven packages.

Open Source Manifests

AppGet doesn't have a concept of a package maintainer. No one owns any of the packages. All manifests are hosted in our official GitHub repository. This allows anyone to submit a pull-request to any of the existing packages in the repository or submit a pull-request for a brand new package.

You can also easily review a manifest before installing it on your machine, to check where the installer comes from, what the application license is or even where the source is hosted.

C:> appget view atom

We plan to add support for other package repositories in the future, public and private.

What about OneGet

There really isn't much overlap between OneGet and AppGet. OneGet as it currently stands provides a unified way to get packages from other package repositories. It has no package repository of its own. Soon AppGet will be one of those package repositories, and you will be able to easily install AppGet packages using OneGet commands.

What’s ahead

I have big plans for AppGet, but they take time, here are some of the features I’ve been thinking about,

Installation Options: Many installers have support for changing the installation settings using flags passed to the installer. We plan to add first class support for those in our manifests, so you could so something like,

C:> appget options 7zip -add-context-menu=true|false : Add 7zip commands to context menu

But we can go beyond this, for zip packages that don’t have their own installers we can give you additional “value-added” options, like adding a shortcut to start menu/startup or pin it to taskbar, associate it with specific extensions or even run the application as a windows service. This way you can install zip packages using AppGet and get more features than you would get even from the installer released by the vendor (ex. if you want the app to start with windows or be pinned to your taskbar automatically)

C:> appget install pidgin --autostart --pin-taskbar

What we have now

Install AppGet: https://github.com/appget/appget/releases

Checkout Available Packages: https://github.com/appget/appget.packages/tree/master/manifests

Read the Documentation: https://docs.appget.net/

We would love to hear from you

We don't want to build AppGet in a silo. Give it try and please let us know what you think. We would love to hear from you. Good or bad.

Email: hello@appget.net

GitHub: https://github.com/appget

Most people in my social circle use Telegram, mainly because they think it’s the most secure messaging platform out there. I’m sure the network effect has something to do with its popularity too, and if that’s the case then this article might not be for you. However, if you are using Telegram because it’s secure, you should keep reading.

When I mention to my friends or family that Telegram might not be as secure as they think I’m frequently countered with:

“But I’ve heard that it’s so advanced that ISIS uses it.” — Paraphrasing my sister.

First, let’s address the ISIS thing. It might be true that ISIS uses a particular technology — in this case, Telegram — but that isn’t necessarily a good testament to its security. Not because ISIS is evil, but because there is nothing about ISIS that makes them experts in cryptography.
Sometimes we assume that people in compromising situations or critical positions are good trendsetters for information security. But let me give you an example; Hillary R. Clinton ran the most expensive campaign in human history while being backed and supported by the most influential and cutting-edge technology companies in the world. Some of these companies are pioneers in security. Meanwhile, her campaign, as well as DNC, still managed to fail at protecting themselves… and in various amusing ways. As such, perhaps we shouldn’t be looking to ISIS for examples of security best practices.

I’m not going to get into the details of who runs Telegram and why you should or should not trust them. This is primarily because it has been well documented, and secondly, it implies a level of personal trust, which shouldn’t matter as much as some people may want you to think. After all, a general principle in information security is “Trust no one”.

To be clear, I’m by no means an expert in cyphers or cryptography. But, I know enough to spot rhetoric and fallacies.

Cryptography and encryption at their core aren’t about faith, jurisdictions or laws. It all comes down to math. Very complicated, borderline-magic-math, but still math. And just like when you were in school, you have to show your work or you don’t get any marks. Pavel Durov (founder of Telegram) can say “Telegram is secure” and the press can blindly quote him until they are both blue in the face, but until he shows his work all we have is his word.

The biggest red-flag with Telegram isn’t that they don’t show their work; that we have no idea what encryption algorithm they use; whether or not it’s secure; or whether it has any backdoors. The red flag is the fact that they decided to invent their own in-house encryption algorithm. Anyone in the industry knows (I hope) and will tell you that developing your own encryption isn’t just a bad idea — it’s an irresponsible and dangerous one.

So what should you be using? This might come as a surprise, but the answer is either Signal, WhatsApp or even Facebook Messenger. Why? Because of all the reasons you shouldn’t be using Telegram as far as security is concerned. They are all based on an open source protocol called “Signal Protocol” by Open Whisper Systems. The protocol is built on top of industry-standard crypto algorithms which have been battle tested for years or even decades, and peer reviewed by some of the smartest people in the world.

Use anything by Open Whisper Systems. — Edward Snowden.

Telegram’s security is a dubious suggestion. Signal Protocol’s security is as good as we can get in 2017.

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.