winget install learning


Last week we announced a package manager preview for Windows. Our goal is to provide a great product to our customers and community where everyone can contribute and receive recognition. The last thing that we want to do is alienate anyone in the process. That is why we are building it on GitHub in the open where everyone can contribute. Over the past couple of days we’ve listened and learned from our community and clearly we did not live up to this goal. More specifically, we failed to live up to this with Keivan and AppGet. This was the last thing that we wanted.

The desire to use GitHub as the basis for our package manager germinated as a way to lean into how developers are building their apps. GitHub allows us to have an open repository and a way to integrate with DevOps pipelines for app publishing etc.

This GitHub based approach led us to AppGet and Keivan. We talked with Keivan last summer about potential opportunities to work together to deliver the Windows Package Manager. During those conversations we were impressed with Keivan’s insights into the package management world on Windows and with his desire for there to be a great package management experience on Windows.

There are a number of qualities in AppGet that really helped us get to a better product direction for WinGet:

  • No scripts during install – something that we completely agreed with and don’t allow with MSIX
  • Rich manifest definition within GitHub – the power of being open combined with rich declarative meta data about the app is so important to meet goal #1
  • Support all types of Windows applications installers
  • Seamless updates for applications in the repository

I want to take this opportunity to thank Keivan for his thoughtful approach to AppGet and working with us. We will be open sourcing our service code into our our WinGet repository on GitHub so that we can work together with Keivan and others to enable a better WinGet repository listing service.


Comments are closed. Login to edit/delete your existing comments

  • Alexander Baggett

    Forking/copying someone’s code in the opensource community is not inherently bad. In fact it is encouraged.

    Failing to credit someone whose open source code you copied is a faux pas at best or license violation at worst.

    But courting someone about a potential job opportunity and then stealing their code and then ghosting them, that really reflects poorly on the image Microsoft has been trying to build with the open source community.

  • Robin Wilson

    It’s great that a package manager is finally coming to Windows but such as shame it is overshadowed by this.
    It seems somewhat akin to forgetting to do your referencing properly when writing your assignment and plagiarising others.
    To put it right I think Microsoft should at least offer him a position in the team, a swanky office and a free mug.

    This could revolutionise software management within organisations and his efforts should be rewarded.

  • cheong00

    Btw, before actually looking at what it is, I did expect Microsoft to use NuGet as start point so it automatically manages dependency issues like package managers in *nix systems, so installers no longer need to be bulky. Just make some modified copy of .nupkg file as optional manifest file to declare dependency for other required packages and select appropriate one to use in current system.

  • Pranav bhattarai

    A big company always hesitates to hand sake with the small company even if a big company takes a huge help from a small company because of their so-called reputation/ego.

    Now the ‘big’ boy doing it so learning from their family (company) is not a new thing.

    This is when morality hits rock bottom.

    Gob bless opensource from big fat private tech corporate organizations.
    This is just the beginning.

    I feel sorry for them.

  • Mohammad Amin Mollazadeh

    How does it install apps? Run the installer program? Extract package to “C:\Program Files”?

  • Andrew Vinci

    So many big companies are adopting the philosophy of “do any evil”. This, Andrew, this was evil. You sir have no ethics, deal underhandedly, and should not be trusted with any implement sharper than a spoon.

    I expect better Microsoft, sack this clown and move on.

  • Radomir Simić

    You really handled this badly. Adding a few words of credit is not a way to redeem yourself after you took someone’s idea, copied it and reused it – not even reimbursing the guy for his flight to Seattle.

  • Foad Sojoodi Farimani

    Regardless of what you did with the AppGet project and its developer, I wonder why Microsoft wants to reinvent every wheel available on the FLOSS world?

    • ConEmu/Cmder –> Windows terminal
    • CygWin, MinGW, MSYS/MSYS2 … –? WSL/WSL2
    • Chocolatey, Scoop, AppGet … –> WinGet

    why not just supporting the existing FLOSS projects by donation or PRs?

    • Rich TurnerMicrosoft employee

      I will answer this since it also involved Terminal and WSL which I worked on:

      There are MANY reasons why Microsoft sometimes has to re-implement the functionality of something that already exists, for example:
      * The existing thing is GPL licensed and thus we tend to avoid looking at the code in order to avoid IP taint
      * The existing thing is built on a tech stack that we can’t support in all our SKUs and product lines (e.g. Winget needs to be v. small, native, and have few/no dependencies)
      * Adding/removing features we do/don’t want may end up changing a thing so much that we may as well have started afresh anyhow
      * Many existing things do a fine job at what they do, but implement things in a way that we cannot support and ship for safety/security reasons. For example, ConEmu does some crazy-cool things to do what it does, but does have some vectors that we simply cannot expose our customers to.
      * Microsoft has to support stuff for a LONG time, often in mission critical environments, and which must meet stringent latency, perf, power, footprint, localization, a11y, i18n and other constraints which many external/public projects do not.

      In addition, CygWin is not WSL. CygWin is a collection of GNU tools ported and recompiled (using MSYS) into Windows Win32 executables. This lets you run bash scripts and the ported GNU tools on Windows, but doesn’t allow you to run Linux binaries on Windows. That’s where WSL comes in: WSL runs unmodified Linux ELF-64 binaries in a “container” atop a Linux-compatible layer at the top of the NT kernel in WSL1, or atop a real Linux kernel in a lightweight VM (in WSL2).

  • Jasper Siegmund

    Read both this post and the one of mister Beige and can’t help to conclude that this was poorly handled by Microsoft. Shit happens, but you should at least own up to it and provide the guy with some sort of compensation for a product which clearly has been inspired based on his ideas. You legal department spends enormous amounts of cash fighting big brands in courts all over the world. Since that’s not gonna happen here, I’m sure you could use a little bit of the cash saved to compensate the person who layed the groundwork for this product. It’s the right thing to do and I think you know it too. Show us all how the 2020 Microsoft operates, please.

    Edit: here’s some follow-up info I found: